Chapter 6. Architecture Decisions

Lead by the power of conviction in your decision.

In the preceding chapter, you gained a comprehensive understanding of the architecture overview. Among other aspects, that chapter illustrated three different architecture views that collectively depicted the IT System’s high-level architecture. From the high-level architectural overview, you have to progressively dive into the details of the solution. However, certain decisions that must be made at this point will guide and influence the subsequent detailed design artifacts of the IT System. Such decisions are called architecture decisions. These architecture decisions influence, shape, and guide the framework of the solution.

This chapter discusses the importance of architecture decisions and provides guidance on how to appropriately capture them. It also gives a few examples for the Elixir case study.

Throughout, I use the terms architecture building block, its abbreviation ABB, architecture component, and building block interchangeably. Doing so will help you to accept not only any of the four terms that your team chooses to adopt but also any other term that may stick with your team; in the latter case, just ensure that the meaning and intent are the same.

Documenting the architecture decisions is of paramount importance. It is important to highlight the significance of appropriately capturing them. Such a document

• Consolidates all architecture decisions in one single structured and cataloged artifact.

• Articulates the rationale and justifications that underpin each architecture decision.

• Provides a compendium of architectural guidelines for system design.

• Provides a reference to team members to understand and be aware of the decisions that have been made already and how they influence the solution architecture.

• Ensures that the architecture is extensible and can support an evolving system.

• Avoids unnecessary reconsideration of the same issues.

• Ensures a common language to communicate the key architecture decisions with different stakeholders.

• Provides a basis for revisiting the architecture decisions as and when the system evolves and matures, maintaining traceability between newly evolved decisions and the originally approved one.

I cannot emphasize enough the need to formalize architecture decisions in order to substantiate and support a well-defined solution architecture. A multitude of experiences in building systems architecture has taught me that paying adequate attention to architecture decisions is key to developing a useful and productive architecture.

Compliance is a very important factor that influences any architecture decision. Paying due attention to the compliance factors is also very important. Following are some of the compliance checks that most architecture decisions need to consider:

• IT policies around system startup and shutdown, error handling, and logging, along with rollback and recovery from indeterminate system conditions

• IT guidelines around the adherence to standards-based interfaces; for example, JDBC/ODBC for database access, Spring framework for Model View Controller (MVC) implementation, information/data exchange standards such as ACORD (for insurance), and so on

• Ability of the relevant architecture components to support the security and privacy requirements and mandates of the enterprise

• Data management policies around data retention, archiving, transaction management, and security, among others

While compliance considerations address policy adherence, I think every decision should factor in some more pure architectural considerations. Think of them as a set of acid tests applied to any consideration before it gets finalized. I call them a Decision Litmus Test (DLT). Here is a starter kit of DLTs that you may find useful while working through each of the architecture decisions for your solution architecture:

• Integrity—The introduction and characterization of an architecture component should maintain the integrity of the overall architecture; that is, it does not break or compromise other aspects of the architecture.

• Completeness—All characterizations of each of the architecture building blocks (ABB) must be described and defined.

• Containment—Each architecture component should be prescribed to be placed in only one architecture layer.

• Validity—The ABB should be verified to perform what it is expected to do; that is, what its characterization entails.

• Reliability—Each architecture component should be able to work in multiple usage contexts and do so in a consistent manner.

• Independence—Each architecture component must be standalone or independent (a.k.a. orthogonal).

• Flexibility—The ability of an ABB to be integrated with other components and used in different contexts.

It is important to understand and acknowledge that the application of the DLTs requires prior judgment: apply only those DLTs that are applicable to the specific architecture consideration. The subset of DLTs may vary between one problem and another. Moreover, I do not claim the preceding DLT list to be exhaustive; these examples are available to help you go about developing and finalizing architecture decisions.

When you want to develop an architecture decision, it is good practice to use a template-driven approach that provides a consistent set of qualitative attributions to help guide the decision-making process. In the rest of this section, I focus on each of the qualitative attributes, what they mean, and how to address them.

Subject Area—Describes a specific domain of the IT System. The domains, also called subject areas, help classify the problems and challenges, which are architectural in nature. Examples of such subject areas could be Systems Management, Security, User Interface, and so on. One way to make things easy is to align the nomenclature of the subject areas with that of the architecture layers (refer to Chapter 5, “The Architecture Overview”). You can always refine them as and when they start to take shape and form.

ID (abbreviated form of identification)—Represents a unique number for each of the architecture decisions; for example, AD04, AD16, or AD23. Numbering helps in traceability between related architecture decisions and also may work as shorthand to refer to a particular architecture decision. Program teams often get used to referring to architecture decisions by their ID; team members know all about the decision by just referring to their ID, and when that happens, you are assured of its adoption.

Topic of Interest—Defines a topic of interest within the subject area. Although there is no hard and fast rule on a rigid set of topics, architects typically use topic elements such as efficiency, reliability, scalability, resilience, extensibility, and usability, as good starting points for categorizing the topics of interest.

Architecture Decision—Provides a descriptive name to the architecture decision under consideration. The intent is to be able to identify the architecture decision by its short descriptive name. A combination of the subject area, topic, and name typically serves to provide a quick overview of the problem at hand. As an example, the Security subject area may have a topic on Federated Identity Management with a brief problem statement entitled “Supporting user authentication in a distributed deployment topology.”

Problem Statement—Provides a detailed description of the problem statement; it expands on the descriptive name captured earlier. This statement can be as descriptive as is pertinent but usually is kept to a couple of paragraphs.

Assumptions—Describe the constraints and boundary conditions that the resolution to the problem needs to adhere to. The pre-conditions and post-conditions (describing the state of the system before the problem is encountered and the state of the system after the problem is addressed, respectively) may also be stated as a measure of the architectural integrity of the overall solution that needs to be maintained with the problem resolution.

Motivations—Describe one or more incentives to address the specific problem at hand. Examples of motivations may be to reduce complexity, to avoid an inordinate increase in compute with increasing workload, to reduce system redundancy, and so on.

Alternatives—Illustrate the various resolution alternatives that have been considered with the objective of solving the problem under consideration. (They are possibly the most important aspect of any architecture decision.) Each alternative is described in detail along with its pros and cons, or advantages and disadvantages, in addressing the problem. The pros and cons could be in the form of technical ease or complexity, process ease or complexity, cost and time implications, among other factors. Keep in mind that it is not mandatory for all decisions to have multiple alternatives. It is okay if some architecture problems have only one alternative and that is the one chosen as the solution! The advice, though, is to consider multiple alternatives, if applicable.

Decision—Finalizes the decision by choosing the best possible solution, among the alternatives, as the resolution to the problem statement.

Justification—Describes the rationale behind choosing the solution among the various alternatives, substantiated by a list of architecture principles that the solution complies with, along with a potential list of principles that may be in noncompliance (substantiated by an explanation for the deviations).

Implications—Illustrate the consequences that the decision may have on the overall program. An implication can be limited only to the technical aspects if the decision has ramifications on the choice of tool, technology, or platform. The implication may also have consequences on program cost and timelines based on the solution characteristics; for example, implementation complexity, need for different tools or technology or platform, and so on. This element of the architecture decision template can be made optional if the decision does not have too many implications and keeps the solution well within the known constraints, boundaries, and scope.

Derived Requirements—Itemize additional requirements that may be generated by the chosen solution for problem resolution. An example of such a requirement may be the need to add a second firewall if the decision is to avoid placing enterprise systems in the demilitarized zone (DMZ). Similar to the implications element, this entity is also optional if no additional requirements are derived from the architecture decision. (Note: You don’t need to rattle your brain if no additional requirements can be identified; if they exist, they would naturally surface.)

Related Decisions—Describes the set of additional architecture decisions that may be related. Including this attribute helps in decision traceability and linkage.

While looking at the attributes of an architecture decision, I have often felt that either I may miss a few of them or fail to correlate them to get a holistic view. To address this issue, I have always found that having a tabular view of the attributes provides me a more compact representation of the various characterizations of the architecture decision. To that effect, I am sharing the tabular format in Table 6.1, which you may find useful.

Table 6.1 A Tabular Format to Capture Architecture Decisions

Often, I have seen that consultants have a tendency to tinker around with any template they are handed and declare, “I customized it to fit my needs!” I’m sure you have either experienced the same or have done it yourself. Now let me play the role of such a consultant.

Table 6.2 shows a customized version of the template I shared in Table 6.1 and have used in some instances. Remember: a template is only a guideline; fit it to your needs!

Table 6.2 An Example of an Architecture Decision (with a Customized Version of the Suggested Template)

The purpose of this section was to give a good glimpse and guidance on how you can develop architecture decisions. Now let’s move on to the case study.

Table 6.3 An Architecture Decision (AD004) for Elixir

Table 6.4 An Architecture Decision (AD007) for Elixir

Table 6.4 captures another architecture decision that is related to the one in Table 6.3.

The chapter provided the rationale for the intent, purpose, and significance of capturing and documenting the architecture decisions. It also provided some key elements that influence the decision-making process. A template, for formally capturing the architecture decisions, was proposed with the intent of maintaining consistency in capturing architecture decisions. The chapter concluded by providing examples of two architecture decisions that were captured for the case study of the Elixir system.

As a parting note from this chapter, and similar to the one in the preceding chapter, I strongly recommend that you pause and try to understand the essence, importance, and value of this artifact as it pertains to the development of the overall systems architecture. If you are currently working on a project as an architect, it may be worthwhile to revisit the decisions that you have either made or are forthcoming and leverage what you learned from this chapter to refine them, if applicable.

At this point, you are all set, with appropriate coverage and support of the decisions, to drive the downstream design and implementation. Did you walk away with something valuable from this chapter? I hope you did!