System Architecture applies architecture principles and practices to a particular software system focusing on structure and behavior to address functional and non-functional requirements (usability, reliability, performance and scalability etc.).
- Common solutions to common problems within the Product
- Ways of addressing primary Product technical Risks
- Ways of reducing significant areas of Product complexity
- Examples of how the system “hangs together and works”
- Solid – System architecture needs to provide a common “scaffolding” for developers to add their bits of a Product to. It must be reliable and logically defensible.
- Useful – If it’s not useful, retire it immediately. System Architecture isn’t just diagrams, it’s executable code. If it doesn’t make a Product easier to develop, it’s not doing its job.
- Beautiful – Good architecture is elegant and adds beauty to a solution, without being overly clever. Architecture is there to simplify the complex.
System Architecture, at least partially implemented and proven with a number of functional requirements, is a key deliverable as part of the Product De-Risked Milestone, mentioned in the Planning, Programmes and Projects view.
Architectural Profiling is a method of understanding the relative complexity of different areas of concern for an architecture.
Architecture addresses a number of concerns and so a useful early approach is to consider the profile of the architecture in terms of the relative complexity of each of these areas. This helps to give a feel for the shape of the requirements, architecture and overall solution. We can also identify possible areas in which we can reuse existing components, frameworks or maybe standard packages of requirements, components and tests. Architectural profiles may be useful at any level of architecture (Enterprise, Solution and System) and are useful to understand areas of complexity in the requirements space, especially for understanding the relative complexity of non-functionals.
An Architectural Overview is a diagram or sketch that describes key architectural elements including: the shape of the system, architectural pattern usage, primary interfaces between subsystems and external systems combined with target deployment platform information, critical data schema and important service/component/class/module structure.
Just as we describe a mix of concerns and processes in the Big Picture we recommend creating a big picture view of an architecture that communicates its key concepts. We don't recommend slavishly following a visual language such as UML, they are generally too restrictive. However, using common de facto symbology where possible is useful and standards like UML are a good source of common symbology. The purpose of an architectural overview is to explain the important structural, logical and physical characteristics of an architecture in a single diagram. In some user-centric pieces of work a User Experience Design may complement an Architectural Overview.
Architectural Mechanisms are small parts of an architecture that address a specific important concern, provide a common way of doing something or are a good example of how the architecture behaves and is structured. Architectural Mechanisms are described in terms of structure and behavior.
Mechanisms explain how the architecture does something. Mechanisms exist within the context of an architecture which provides overall structure so we recommend mechanisms are tightly bound with an Architectural Overview and are only used to refine the architectural description, where necessary, as indicated by the Architectural Profile. Architectural Mechanisms take different forms in Enterprise, Solution and System Architecture.
Collectively this information provides a lightweight set of architectural descriptions that can be used to communicate an architecture and speed up Product development.