Software Architecture Methodology

9 min readFeb 22, 2021

As developers, we are focused on solving problems. And these problems exist in the space we call software development. The main challenge in this domain is to develop software with the right quality levels. So here comes the concept of Software Architecture which helps us to build a bridge between the problem space and the solution space.

Being a technical leader or manager you may think that the architecture is the job of the architect, but to truly understand the big picture, and to guide your team to achieve the mission of the product you all build, this aspect is mandatory to be on your to-do list, not just on your team’s list.

“Software architecture is the fundamental organization of a system embodied in its elements, relationships, and in the principles of its design and evolution.” [IEEE Std. 42010–2011]

“The shared understanding that the expert developers have of the system design. Architecture is about the important stuff. Whatever that is.” [Ralph Johnson, one of the authors of “Design Patterns: Elements of Reusable Object-Oriented Software”, GOF]

📑 Step 0: setup the context for defining the Software Architecture

A system is part of a context, it has a mission and roles. The roles involved in defining an architecture are:

Stakeholders

Architect

Create, communicate and maintain an architecture plan
Find the right balance between business objectives + technology + people

📑 Step 1: Inception and Identification of Quality Attribute Requirements

Main activities

Identify stakeholders and prioritize them
Identify business objectives
Prioritize business objectives

To identify the stakeholders the RACI matrix is a good tool to use

RACI Matrix for all stakeholders

Responsible (the person who does the work to achieve the task and is responsible for getting the work done or decision made);
Accountable (the person who is accountable for the correct and thorough completion of the task);
Consulted (the people who provide information for the project and with whom there is two-way communication);
Informed (the people who are kept informed of progress and with whom there is one-way communication).

📑 Step 2: Identification of Architecturally Significant Requirements (ASR)

ASRs are a combination of:

Major functional requirements (FR)
Quality Attribute Requirements (NFR — non-functional requirements)
Life-cycle requirements
And constraints

Use Cases generate Functional Requirements.

For constraints ask the next questions

How many requests per month?
How many requests per second (they may volunteer it or make you do the math)?
Estimate reads vs. writes percentage.
How much data are written per second?
Total storage required over 5 years.
How much data reads per second?
Keep the 80/20 rule in mind when estimating.

Quality Attribute Scenarios generate Quality Attribute Requirements

Based on them we get Quality Attributes
Quality Attribute Scenario structure (Source + Stimulus* + Artifact + Environment* + Response*)
Response measure

Types to consider

Use cases — anticipated uses of the system
Growth — anticipated changes to the system
Exploratory — unanticipated stresses to the system

Quality Attributes samples:

Availability: Does the mechanism have to support the failure of the external entity? Does the mechanism have to guarantee delivery?

Performance: Is the communication with the external entity sensitive to system latency or throughput?

Security: Is the communication with the external entity subject to a Threat?

Modifiability: Will the external entity change? Will the information being communicated change?

Testability: How will the communication be tested? Can the data be played back for testing?

Usability: If the external entity is a user, are any of the usability crosscutting scenarios relevant?

Reliability: Ensures the integrity and consistency of the application and all its transactions

Resilience: The ability to bounce back from failure to continue to offer some level of performance (possibly less than original)

Safety: Ability to avoid entering states that cause or lead to damage, injury, or loss and to recover and limit the damage when it does enter into bad states

Monitor-ability: The ability of the operations staff to monitor the system while it is executing

Portability: How easy software built to run on one platform can be changed to run on another

Interoperability: The degree to which two or more systems can usefully exchange information via interfaces in a particular context

Extensibility: The ability to add additional functionality or enhance existing functionality without impacting existing functionality

Evolution: The ability of the system to be flexible in the face of inevitable change after development

Manageability: system monitoring of the QA requirements and the ability to change the system configuration to improve the QA dynamically without changing the system.

Maintainability: the ability to correct flaws in the existing functionality without impacting other components of the system.

PASSME acronym for Non-Functional Requirements (NFRs):

Performance
Availability
Scalability
Security
Maintainability
Extensibility

QAW (Quality Attribute Workshop)

Input

Stakeholders & Architect
3–5 Business Goals from the prioritized list from part 1
Architectural Plan

Output

Refined Quality Attribute Scenarios

Steps

QAW Presentation and Introductions
Business/Programmatic Presentation
context + constraints + plan for development
Architectural Plan Presentation (as it is at this moment)
Identification of Architectural Drivers (qualities)
Scenario Brainstorming
Scenario Consolidation
Scenario Prioritization
Scenario Refinement

📑 Step 3: Practice of Designing Architectures

Concepts

Design of a system = sequence of decisions
Tactic = design decision that is influential in the control of a quality attribute response
Pattern = { context + problem + solution (+ rationale) }; A pattern is a prepackaged solution to a recurring problem that resolves multiple forces. Patterns package tactics

Classification of patterns:

Architectural patterns — Express a fundamental structural organization schema for software systems
Design patterns — Solves a general design problem. Normally local influence
Idioms — Patterns specific to a programming language
Style = { design principles + patterns (+ types of architectural elements / relationships) }
Tier is a physical unit, where the code/process runs. E.g.: client, application server, database server;
A layer is a logical unit, how to organize the code. E.g.: presentation (view), controller, models, repository, data access.

Types of decisions

Allocation of functionality
Data and object model
Communication model
Management of resources
Binding time decisions

Defining a software architecture based on the quality attributes is called Attribute-Driven Design and it is actually a recursive decomposition process: at each stage tactics and patterns are chosen to satisfy a set of quality attribute scenarios.

Input:

Quality attribute requirements
Functional requirements
Constraints

Output:

Overall structuring decisions
Interconnection and coordination mechanisms
Application of patterns and tactics to specific parts of architecture
Explicit achievement of quality attribute requirements
NOT detailed interfaces

Steps:

Step 1: Confirm there is sufficient requirements information
Step 2: Choose part of the system to decompose
Step 3: Prioritize requirements and identify architectural drivers
Step 4: Choose design concept — patterns, styles, tactics — that satisfies the architectural drivers associated with the part of the system we’ve chosen to decompose.
Step 5: Instantiate architectural elements and allocate functionality
Step 6: Merge designs completed thus far
Step 7: Allocate remaining functionality
Step 8: Define interfaces for instantiated elements
Step 9: Verify and refine requirements and make them constraints for instantiated elements
Step 10: Repeat steps 2 through 9 for the next part of the system you wish to decompose

📑 Step 4: Document the Architecture and validate the design decisions

Architectural Description

A system has 1 or many stakeholders
A system addresses the needs of the stakeholders
A system has an architecture
An architecture can be documented by one or many architectural descriptions (a collection of products to document an architecture)
Architectural description documents architecture for the stakeholders

View

Represents structural aspects of an architecture
Illustrates how the architecture addresses concerns held by one or many stakeholders

Viewpoint

Defines the perspective from which a view is taken. More specifically, a viewpoint defines: how to construct and use a view
Defines stakeholders and their concerns
Defines template models
Defines design and document guidelines
Defines common problems and pitfalls

Viewpoint sets:

4C Model by Simon Brown

Context
Container
Component
Code

Kruchten (4 + 1 )

Logical View = functionality
Development View = implementation
Physical View = physical layer necessary to deploy the app
Process View = sequence diagrams, system processes
Use Case View = or scenarios (sequences of interactions between objects and processes)

Rozanski & Woods

is an extension and refinement of Kruchten’s set
keeps Development viewpoint
renames and evolved:
Logical → Functional
Process → Concurrency
Physical → Deployment
adds Informational and Operational

Representation

Functional viewpoint = functional capabilities
Information viewpoint (new) = information flow
Concurrency viewpoint (new) = inter-process communication
Development viewpoint = soft dev. process
Deployment viewpoint = hardware + network
Operational viewpoint(new) = when app is running in prod (backup, restore, update, migration)

📑 Step 5: Software Architecture Analysis and Assessment

Evaluation Techniques:

Questioning techniques

use questionnaires, checklists, scenarios to investigate the way architecture addresses its quality
requirements (e.g. ATAM, CBAM)

Measuring techniques

rely on quantitative measures by using a measurement tool
measure architecture’s coupling, cohesiveness, inheritance depth, etc

Review workshop techniques

peer review sessions at the fixed allocated time, just as code can be peer-reviewed (e.g. inspection, assessment)

Validating techniques

comparing reverse-engineered requirements (designs) with original requirements (designs)

ATAM

ATAM = Architecture Tradeoff Analysis Method
The purpose of ATAM is: to assess the consequences of architectural decisions in light of quality attribute requirements and business goals.

Concepts:

Risk = a potentially problematic architectural decision.
Non-risks = good architectural decisions that are frequently implicit in the architecture.
Sensitivity point = a place in the architecture that significantly affects whether a particular quality attribute response is achieved.
Tradeoff = a property that affects more than one attribute and is a sensitivity point for more than one attribute.

Bottlenecks and tradeoffs

Testing the performance
load testing — scalability
stress testing — breaking point
soak testing ( testing with a typical production load for an extended time) — leaks in resources

Post-review activities — CBAM

Cost-Benefit Analysis Method — CBAM
The aim of the CBAM is to: explicitly associate costs, benefits, and uncertainty with architectural decisions, as a means of optimizing the choice of such decisions

The process does not stop here. It is a loop.🔄 After the first version of the architecture is done the development begins and each time a new feature is required the process starts from the beginning. Software development, even if we talk about architecture or implementation, is a team effort, and it is helpful to have multiples perspectives to identify the blind spots and also to bring new ideas and approaches.

📚 Learn more

🎓 Summary

Design and analysis of architectures are mirror activities, and documenting complements them and makes effective. To do them well we need: active stakeholder involvement, clear characterisations and prioritizations of business goals and architectural drivers, an understanding of tactics and patterns, methods that keep we focused.

Originally published at http://magdamiu.com on February 22, 2021.