Mastering Software Architecture: An Intro to ADD and Key Architecture Structures

Mastering software architecture involves understanding and applying various architectural structures to meet system properties like security, availability, and maintainability. Not all software structures are considered architectural; only those that impact these key properties are. Modern systems are complex, so focusing on specific structures or properties at a time helps in better understanding and communication. A 'view' in architecture represents a particular structure and the interactions among its elements, aiding in clarity and focus during discussions.

Architectural Structures and View:

Are all structures of software considered architectural? No. Only those that exhibit/constrain/satisfy any/all of the system properties, like security, availability, maintainability. Thus, architectural structures may vary depending on the context.

Modern systems are generally quite complex to grasp all at once. To understand it better, we want to focus on one or a handful of structures/properties at once. To communicate better, we make it clear what structure/s are the matter of concerns at the point – which ‘view’ of the architecture is being discussed. Thus, a view is a representation of a structure (i.e. set of elements) and the relations/interactions among them.

Types of structures:

Module structures: Modules are assigned areas of functional responsibilities, and explain:

• The primary functional responsibility assigned to each module

• Other software elements that a module can use

• Other software a module depends on

• How a module is related to other modules via inheritance relationship, and so on

A few examples are:

• Decomposition: Tells how modules are decomposed into smaller modules recursively until the modules are small enough to be easily implemented.

• Dependency/Uses: Explains the module’s dependency on other modules, how to extend it to add functionalities for incremental development.

• Layers: A layer is a related set of services, allowed to use other layers, typically in a managed manner (i.e. immediately below/above layer etc).

• Data model: Describes the information structure in terms of data entities, their attributes and their relationships.

Component-and-connector structures: Tells the runtime components and interactions among them, and explains:

• The important components and how do they interact at runtime

• Major data stores

• How the data progresses/processed through the system, and so on

A few examples are:

• Service structure: Services that interoperate with each other by a service coordination mechanisms (i.e. REST/SOAP etc), allows independent development.

• Concurrency structure: Determines where parallelism can be achieved and where contention may occur.

Allocation structures: Shows the relationship between the software elements and external environment elements, and explains:

• The processor/worker each software element executes on

• Assignment of a software element to development teams, and so on

A few examples are:

• Deployment structure: Shows how software is assigned to hardware processing and communication elements, and provides the basis to reason about performance, security, and availability etc.

• Work assignment structure: Assigns responsibility for implementing and integrating the modules, to the teams, as the architect would know the expertise required on each team.

Above are a few structures, there may be more, but do you need to use all the structures to document architecture? Not really – think about how the various structures available provide insight into the system’s most important quality attributes, and then choose the ones that best delivers those attributes.

Process of design:

Carnegie Mellon University introduced a process/method to systematically approach the creation of design – ADD (Attribute Driven Design). It was first introduced in 2000 (V1), then revised in 2006 (V2), and then ADD-3.0 was introduced in 2016 to improve upon the shortcoming of earlier versions.

ADD provides step by step guidance in how to architect software systems in a series of iterations. It focuses on the achievement of quality attributes through the use of different types of architectural structures, and the best practices applied in past competent architecture (reference architecture).

Of course there are alternate methods, like Architecture-Centric Design Method (ACDM), Rational Unified Process (RUP), Microsoft’s 5-steps technique, viewpoints and perspectives method etc.

More about these in later posts.

In a nutshell:

Software architecture involves different structures based on system properties like security, performance, and maintainability. Key structures include:

• Module structures: Define functional responsibilities, module dependencies, and relationships (e.g., decomposition, layers).

• Component-and-connector structures: Represent runtime components and their interactions (e.g., service structure, concurrency).

• Allocation structures: Map software elements to hardware or teams (e.g., deployment, work assignment).

Not all structures are necessary; architects should choose those that best address the system's quality attributes. A view represents a specific structure, aiding communication and focus when discussing architecture.

Carnegie Mellon University introduced Attribute Driven Design (ADD) as a method to guide software architecture systematically, focusing on achieving quality attributes through iterations and architectural structures. ADD was first introduced in 2000 and refined with ADD-3.0 in 2016 to address earlier shortcomings. Alternative methods include Architecture-Centric Design Method (ACDM), Rational Unified Process (RUP), and Microsoft's 5-step technique.