Making Architecturally Significant Decisions

By Paul Preiss

Architecturally significant decisions (ASDs) are “the stuff that matters” as Martin Fowler describes it. They describe the scope and boundaries of a decision that will have significant impact on the outcomes of a particular piece of work or the organization as a whole.

An ASD should be motivated by previous and similar works. The goal of the ASD is to make decisions explicit, easy to track and link to requirements, design reasoning and outcomes.

Guidance

Architectural decisions are at the root of our practice but they are often hard to spot. The vast majority of decisions get processed at the team level and do not apply architectural thinking or have an architect involved at all. This approach can be a benefit in agile organizations if managed and communicated effectively.

Engagement Principle: Bottom up decision making is a benefit or a risk. Ensure all teams are trained on decision characteristics that impact its formality.

Envision an enterprise or company, then imagine all the teams in the organization working in parallel on changes, remember to add in maintenance teams and operations teams doing ‘keep the lights running’ work. Now if you set the decision level of architectural significance at $20,000 (this will vary by organization) in impact or cost, how many of those decisions are made with a basic tradeoff analysis? This is the fundamental world of architectural decisions and ultimately the outcomes of these decisions lead the organization to the benefits or failures of architecture.

Manage the Scope of Decisions Carefully

Decisions have an impact radius that can be much larger than many think. By understanding decision scope you can determine appropriate characteristics of the decision, its velocity and its type. Determining a decisions scope and impact is essential to ensuring that appropriate decision tools are used.

Scope Decision Management
Ecosystem These decisions will impact not only the enterprise but its entire ecosystem as well. A governments choice of procurement requirements for vendors or standards for banking are examples. An enterprise choosing to enforce standards on its customers or suppliers are others.
Enterprise Decisions which impact the entire enterprise. Choice of ERP, cloud strategy, or similar. These are slightly different from standards or guardrails which guide decisions at a lower level.
Value Stream Those decisions which impact an entire value stream for a company.
Solution A solution level decision impacts multiple services and products and supports a value stream.
Product/Service Decisions which are limited to impact on a specific product or service but which do not impact neighboring products or services.
Module Decisions for a sub-component of a system.

Manage Decisions Effectively Across the Enterprise

To effectively manage decisions, the architecture team should put in place a decision management process early in its lifecycle, by making critical investments into how the organization is going to process decision point in the architecture engagement model. During the engagement methodology update and the engagement principles definition, the team will decide what levels of decisions must be exposed in the repository and their limits in duration, quality and effort. These principles will guide the decision methods for the entire team until the next methodology update.  There are numerous decision methods and theories in the marketplace in making better decisions. The goal of the architecture decision repository is to ensure that decisions are made clearly, with appropriate tools and with respect for traceability.

A Decision Management Method/Process

  1. As a team, identify critical levels of and types of decisions as well as their complexity or scope of impact.
  2. Identify which of these decisions the team has the ability to be proactively involved in (able to work toward the decision in a multi-functional environment.
  3. Identify decisions, which the team cannot (time, access, scope) be proactively involved.
  4. Identify critical stakeholders as a part of the extended team involved in the architecture lifecycle who may be mentored into rigorous decision methods.
  5. Create a set of engagement models principles to address each of these situations based on the outcomes the team would like to achieve.
  6. Revisit during engagement method update.

For the rest of the article, visit https://iasa-global.github.io/btabok/decisions.html#architecturally-significant-decisions