System Architecture

Architecture is a high level view of a system in the context of its environment, dependencies and technology. Architecture describes structure, behavior, integration and aesthetics.

Architecture must be solid, useful and beautiful.

In HSD the Architecture View encompasses Enterprise, Solution and System Architecture.

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.).

System architecture describes the overall structure, behavior and aesthetics of a Product. It provides and communicates technical direction to the team on how to structure code and work with each other. It mitigates the significant technical risks by providing mechanisms that offer:
  • 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”
Architecture must be:
  • 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.
Like Solution and Enterprise architecture, System architecture is unlikely to be “right first time”. It must be proven through delivery of working software, refined by the feedback of tests, the development team and users.
As described in the Architecture View, how much architectural elaboration and description is necessary is not easy to define. Various factors may move a project to need more or less documentation but the emphasis should always be on the minimum necessary documentation. We recommend understanding System Architecture in terms of an architectural profile, overview sketch(es) and lightweight mechanisms. Sometimes other elements might be useful such as User Experience Designs, integration scenario workflows, data models etc. but we focus on a core minimal set of products in HSD.

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 Profile

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.

Architectural Overview

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

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.