Software Architecture Methodology

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: T he 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: H ow 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

1. QAW Presentation and Introductions
2. Business/Programmatic Presentation
3. context + constraints + plan for development
4. Architectural Plan Presentation (as it is at this moment)
5. Identification of Architectural Drivers (qualities)
6. Scenario Brainstorming
7. Scenario Consolidation
8. Scenario Prioritization
9. 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

• Making Architecture Matter — Martin Fowler Keynote
• Visualising software architecture with the C4 model — Simon Brown, Agile on the Beach 2019
• Core Design Principles for Software Developers by Venkat Subramaniam
• Do not walk away from Complexity, Run — Venkat Subramaniam
• Qualities of a Highly Effective Architect Keynote by Venkat Subramaniam
• Software Architecture Guide

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