A system resides in an environment, and this environment influences the architecture. This is sometimes referred to as "architecture in context." In essence, the environment determines the boundaries within which the system must operate, which then influence the architecture. The environmental factors that influence the architecture include the business mission that the architecture will support, the system stakeholders, internal technical constraints (such as the requirement to conform to organizational standards), and external technical constraints (such as the need to interface to an external system or to conform to external regulatory standards).
Conversely, as eloquently described in Bass, Clements, and Kazman,11 the architecture may also influence its environment. Not only does the creation of an architecture change the environment from a technology perspective -- it may, for example, contribute reusable assets to the owning organization -- the creation of the architecture may also change the environment in terms of the skills available within the organization.
When it comes to software-intensive systems, there is a particular aspect of the environment that must always be considered, as discussed earlier in this chapter. In order for software to be useful, it must execute. In order to execute, the software runs on some kind of hardware. The resulting system is therefore a combination of both software and hardware, and it is this combination that allows properties such as reliability and performance to be achieved. Software cannot achieve these properties in isolation of the hardware on which it executes.
IEEE Std 12207-1995, the IEEE Standard for Information Technology -- Software Life Cycle Processes, defines a system differently from the IEEE 1471 system definition noted earlier (which focuses on software-intensive systems), but is in agreement with the definitions found in the systems engineering field:
[A system is] an integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. [IEEE 12207]12
A configuration of the Rational Unified Process® for Systems Engineering (RUP SE) contains a similar definition.
[A system is] a set of resources that provide services that are used by an enterprise to carry out a business purpose or mission. System components typically consist of hardware, software, data, and workers13.
In the systems engineering field, tradeoffs are made regarding the use of software, hardware, and people. For example, if performance is key, then a decision may be made to implement certain system elements in hardware, rather than software or people. Another example is that in order to provide a usable system to customers, a decision is made to provide a customer interface that is a human being, rather than an interface implemented in software or hardware. More complex scenarios require certain system qualities to be achieved through a combination of software, hardware, and people. (Accordingly, this series of articles makes reference to elements other than software where appropriate.)
It is interesting to note that systems engineering is specifically concerned with treating software and hardware (as well as people) as peers, thus avoiding the pitfall where hardware is treated as a second-class citizen to the software and is simply a vehicle for executing the software, or where software is treated as a second-class citizen with respect to the hardware and is simply a vehicle for making the hardware function as desired.