Module 8 — Architecture Design, Review and Governance

Coverage note. The three decks in this module (8.1 Architecture Design, 8.2 Architecture Review, 8.3 Architecture Governance) are almost entirely image-based — 120 slides yielded roughly 1,300 words of speaker notes between them. What follows is everything the notes establish, organised around the authoritative frameworks they reference. For the full detail go back to the original slides, and to Software Architecture in Practice (3rd ed.), p. 72, chapter "Guiding Quality Design Decisions", plus the SEI ATAM material and TOGAF governance chapters.

This module covers three things in sequence: the general shape of an architecture design process, then Attribute-Driven Design as a concrete method, then evaluation and governance.

Design fundamentals

Recall that one can view an architecture as the result of applying a collection of design decisions. What the seven categories from Module 3 present is a systematic categorization of these decisions, so that an architect can focus attention on those design dimensions likely to be most troublesome.

• These categories are not the only way to classify architectural design decisions, but they provide a rational division of concerns
• The categories might overlap, and it's all right if a particular decision exists in two different categories — because the concern of the architect is to ensure that every important decision is considered

There are key universal points applied while designing a solution, and they are elaborated in the SEI chapter on guiding quality design decisions.

Architecture principles should be traced directly to the business drivers. This is a source of constraints and limitations.

Do not document ALL requirements.

Note on baseline: where the course speaks of baseline architecture it means brownfield projects with legacy systems — it's clear there is no baseline architecture in greenfield projects.

The big picture from SEI, with three main points:

1. Different levels of architecture: Enterprise, System, Software
2. Architecture comprises multiple structures: modules, component-and-connector, and allocation
3. Input for the design process is Quality Attributes, Scenarios, Functional Requirements, Patterns and Tactics

The evaluation team itself fills defined roles — evaluation leader, scribe, questioner, and process enforcer — alongside the assembled stakeholders. Its analysis step sorts findings into four named categories: a risk is a potentially problematic architectural decision, a non-risk is a good decision whose rationale can be easily hidden, a sensitivity point is a component property critical to one quality attribute, and a tradeoff is a sensitivity point for more than one quality attribute at once.

The 'Solution Delivery' activities are not considered in detail here, because they were covered in the Estimation module.

Attribute-Driven Design (ADD)

The structure of the method:

The version taught here, ADD 3.0, refines SEI's earlier ADD 2.0, whose loop was a simpler four-step cycle: select element, identify the architecturally significant requirements, generate the design, and verify and refine requirements. ADD 3.0 keeps that same spirit but expands it into today's seven-step loop, adding an explicit drivers input (design purpose, functional requirements, quality attribute scenarios, constraints, architectural concerns) that feeds step 2 and an architecture-design output that closes the loop.

• Steps 1–7 constitute a design round
• Steps 2–7 constitute an iteration within that round; there can be several iterations in a round
• Each iteration focuses on achieving a particular goal
• The design we get after a particular round will be the input for the following rounds

A design round is generally performed in a series of design iterations, where each iteration focuses on achieving a particular goal. Such a goal typically involves designing to satisfy a subset of the drivers. For example, an iteration goal could be to create structures from elements that will support a particular performance scenario, or that will enable a use case to be achieved. For this reason, you need to establish a goal before you start a particular design iteration.

Refinement (step 3)

Satisfying drivers requires you to produce one or more architectural structures. These structures are composed of interrelated elements, and those elements are generally obtained by refining other elements that you previously identified in an earlier iteration.

Refinement can mean:

• Decomposition into finer-grained elements — a top-down approach
• Combination of elements into coarser-grained elements — a bottom-up approach
• Improvement of previously identified elements

For greenfield development you can start by establishing the system context and then selecting the only available element — the system itself — for refinement by decomposition. For existing systems, or for later design iterations in greenfield systems, you normally choose to refine elements that were identified in prior iterations.

Choosing design concepts (step 4)

Choosing the design concepts is probably the most difficult decision you will face in the design process, because it requires you to identify alternatives among design concepts that can be used to achieve your iteration goal, and to make a selection from these alternatives.

In practice this step breaks into three moves: identify a list of alternatives, analyze each one against the drivers and ASRs to select candidate patterns and tactics, and select the alternative that best fits the defined criteria. The alternatives themselves are typically surfaced from the architect's own experience, skills and knowledge, from known tactics and patterns, and from the wider community's experience with similar problems.

Instantiating elements (step 5)

Once you have selected one or more design concepts you must make another design decision, which involves instantiating elements out of the design concepts you selected.

For example, if you selected the Layers pattern as a design concept, you must decide how many layers will be used, since the pattern itself does not prescribe a specific number. In this example, the layers are the elements that are instantiated.

Sketching views (step 6)

The views you have created are almost certainly incomplete, so these diagrams may need to be revisited and refined in a subsequent iteration. This is typically done to accommodate elements resulting from other design decisions that you will make to support additional drivers.

This factor explains why we speak of "sketching" the views in ADD — creating a preliminary type of documentation. The more formal, more fully fleshed-out documentation of these views, should you choose to produce them, occurs only after a number of design iterations have been finished.

The following step, analyzing the design, is where you check whether the requirements have actually been satisfied and refine responsibilities accordingly, and review the sketches, views and decisions you just recorded. The module recommends using a checklist or asking for an external, unbiased review at this point, precisely because a design that looks complete to its own author can still hide gaps.

Architecture review and ATAM

Architecture review — a process where architectural decisions are evaluated as to how they enable or restrict the system in meeting its Architecturally Significant Requirements.

The module presents ATAM — the Architecture Tradeoff Analysis Method — through two lenses:

1. A context view of the ATAM: what the inputs are, and what the outcome is
2. A conceptual flow of the ATAM

ATAM evaluations run through four named phases: Phase 0 (Partnership and Preparation), Phase 1 (Initial Evaluation), Phase 2 (Complete Evaluation), and Phase 3 (Follow-up), with Phase 1 and Phase 2 each typically running 1.5–2 days on-site. Phase 1 works through six steps — present ATAM, present business drivers, present the architecture, identify architectural approaches, generate the quality attribute utility tree, and analyze architectural approaches — and Phase 2 recaps Phase 1 for the larger stakeholder group before repeating scenario brainstorming, re-analyzing architectural approaches, and presenting results as steps seven through nine.

Executive summaries

The module spends dedicated time on this, and the point is explicit: writing the right executive summary is critical — and difficult.

From the graduate-work guidance, after reading your executive summary the customer should see that:

• You understand the business, the current state and the goal(s)
• The proposed solution will cover the current and future needs
• The solution will be delivered on time and on budget

Architecture governance

The conceptual setup, worth reading slowly:

Suppose you are interested that an entity works in a way you want it to work. If you are managing the entity then you have the necessary authority to ensure it. However, if you don't manage the entity directly, then what do you do? To do anything you need to have some authority or influence over the entity. You can discuss with the management team of the entity and come to an agreement on what needs to be done. Then you also come to an agreement on how to ensure that what you have agreed is followed. In other words, you lay down a governance framework.

Useful analogies to reach for: how corporate governance works, and how a government makes all parties — physical and legal entities — follow rules.

The six characteristics

Adapted from Corporate Governance (Naidoo, 2002), and positioned to highlight both the value and the necessity for governance as an approach adopted within organizations and their dealings with all involved parties:

The three strategy elements

There are three important elements of an architecture governance strategy that relate particularly to the acceptance and success of architecture within the enterprise:

1. Architecture Board
2. Architecture Principles
3. Architecture Compliance

The Architecture Board is presented as the first success factor of an architecture governance strategy.

It is important to consider all of these to ensure a successful approach to architecture governance, and to the effective management of the Architecture Contract.

Governance in practice

Concrete examples of architecture governance:

• Consistency between sub-architectures
• Identifying re-usable components
• Architecture compliance over the enterprise

The scenario to recognise: there are different units in an organization with different projects in these units. They can build overlapping frameworks and systems in their own way. The goal of an enterprise architect is to detect such a situation and mitigate or fix it — by identifying reusable components, creating consistency between sub-architectures, and so on. This is very important, but it is a bit outside the focus of a solution architect.

Architecture governance includes control, compliance, management, accountability — the core definition from TOGAF. It is one of the main activities of enterprise architects: any company wishing to be successful and build a business that will last decades should have an enterprise architect who, among other activities, engages in architecture governance.

Exercises — Module 8

Task. One ADD iteration on a high-priority Lumen ASR from your Module 3 utility tree, plus the questions an ATAM reviewer would ask. Output: the chosen scenario, the design concept and instantiated elements, a sketch of the view that shows it, and five review probes. You will reuse this discipline on Halcyon.

• Read the Lumen Diagnostics case
• Pick one H/H or H/M quality-attribute scenario from your Lumen utility tree
• Run one ADD iteration

  • Choose a design concept
  • Instantiate the elements
  • Sketch the view that shows the decision
• Traceability in one sentence: which requirement does this decision satisfy?
• Five questions an ATAM reviewer would ask

  • Cover risk, trade-off, and sensitivity