This is the second part of the series “Become a Software Architect”
A system’s software architecture is the set of significant design decisions about how the software is organized to promote desired quality attributes and other properties.
Martin Fowler defines software architecture as “…the important stuff. Whatever that is.” The important stuff is nearly always what we think will be difficult to change without significantly increasing complexity.
Architecture is eventually a realisation of design decisions turned into execution. Design decisions where some Quality attributes will get prioritized and some will be de-prioritize. Quality attributes stakeholders want and downplay or eliminate the quality attributes stakeholders don’t want.
1. Define the Essential Structures
First, we need a basic framework to name the parts of the system so we can separate the functionality of pieces of the software. One way to call the parts is: 1) module, 2) component and connector (C&C for short), and 3) allocation.
2. Reason about Quality Attributes (and Other System Properties)
A quality attribute is any externally visible characteristic by which stakeholders judge a software system’s goodness.
Let’s take an example of developing an app to add two numbers. Now, it looks pretty straightforward problem, but when we define the software design problem, the following questions surround us. These questions are to be gathered by stockholders.
3. Screenshot of Software Architecture
At any given moment, Any software has a current state with fixed Quality Attributes values.
The requirement might force us to move the system from one state to another with better and acceptable Quality Attribute values.
JB's Blog 