I have come to realize that successful (typical) Solution Architectures rely on only a handful of areas (let’s call them corner-stones) that need to be defined. Examples are: Non-Functional Requirements, Architectural Decisions, etc. Naturally, those areas need to be defined and thought about that much more carefully…
I have wanted to share this post for a while. Based on my experience I have come to realize (this is my thesis for now) that successful Solution Architectures rely on only a handful of – that much more critical – areas that need to be designed and thought about concisely.
Indeed, there are only seven. But they need to be considered that much more carefully. The areas are:
- Non-Functional Requirements,
- System Context,
- Component Model,
- Architecture Overview,
- Architectural Decisions,
- Architectural Design, and
- Operational & Deployment Model.
A non-functional requirement is a qualitative characteristic of a software system. Examples are: performance, scalability, and others.
The system context describes the interfaces of a particular system. This means, all interfaces leading to the system as well as from the system. It is typically done using a graphical notation.
The component model sub-divides a particular solution into technical and business components. It is typically done using UML.
The architecture overview outlines all key aspects and decisions about a solution’s architecture. It can be done using text and or a graphical way. I typically do it using graphics.
This is a log of key decisions that have been made when creating a solution architecture. A decision typically encompasses advantages, disadvantages, consequences, etc. and should enable you to take a risk-based decision.
The architecture design is important as it defines the master-design for a particular solution, i.e. the blue-prints for all key aspects of the solution. It is not a detailed design, but needs to outline the principle design guidelines for a system.
Operational & Deployment Model
The operational & deployment model helps with two things. They help you to define your local and physical deployment architecture and aid in mapping installation units to physical nodes.
Copyright © 2011 Michael Pichler