The sheer scale and complexity of created systems has grown over the decades, and the need to understand the ‘bigger-picture’ leads organisations to an increased use of models and system architectures as part of the systems engineering discipline. This is driven by the need to communicate and coordinate the developing system in terms of its components and interrelationships (both internal and external), to the wider stakeholder audience, such as designers and end-users [1].

Created systems are intended for specific purposes or primary functions, for example, a passenger railway system transports people to and from various locations. However, to achieve this, the systems and its architecture must also meet other requirements such as safety, maintainability, flexibility and so on. This invariably leads to trade-offs and analysis of options. In addition, complex systems have behaviours and properties that are above and beyond those of its components. Some of these are engineered deliberately as the product of the design activity while other behaviours or side effects arise as a consequence of the complexity. These are known as emergent behaviours and may represent properties that are possibly useful, or as more often feels to be the case, unwanted. Modelling the architecture of the system can be an invaluable tool to understand these aspects [2].

You do not currently have access to this chapter.
Don't already have an account? Register

Purchased this content as a guest? Enter your email address to restore access.

Please enter valid email address.
Email address must be 94 characters or fewer.