This activity defines Architectural Decisions, which are decisions regarding the structure and components within the system that are architecturally significant.
Purpose
The purpose of this activity is to define an architectural decision. Documenting important architectural decisions provides
a repository of decision that will help guide other architects, managers and implementors in being compliant with
enterprise and business domain standards and solutions. The provided repository of decisions is also a source of
information for re-visiting decisions over time.
The purpose of this activity is to create an Architecture Decision (AD), specifically to:
Define the context of the problem, issue or decision;
Define the constraints, imposed by existing architecture, enterprise standards or others;
Define the rationale for the decision, through a well researched summary of the facts;
Extract the implications of the AD, on current systems, future systems, support aspects and other aspects;
Define the specifics of the decision.
This activity results in the production of an AD. The diagram illustrates the main inputs and outputs of this activity
as hinted at above. A problem context helps to define the scope of the AD, and the constraints (imposed by technology,
the current situation, etc.) along with the rational (that is very much local to the business and the context) help in
arriving at and defining the decision. Implications of this decision, on the business and the current situation, are
also extracted and defined.
This is explained in more detail in the descriptions of the steps involved.
Steps
Define the Problem Context and Scope
The objective here is to define the context of the problem, the environment within which the problem is found. This
includes business level context, such as processes and functions involved with the problem. The scope of the problem is
also described, that is, is it local to a system or process, does it span the business domain, or is it a problem that
involves the complete enterprise?
The context and scope help the stakeholders to understand and agree upon the intention of the solution. The same
problem, interpreted for different contexts, can yield very different solutions.
The context and scope defines the intended area in which the solution will be deployed (e.g. workgroup, division,
department, entire business, etc.) and a definition of the users of the solution. If the context is well understood, a
short description may suffice, but for new technologies or processes a more complete description of the problem space
may be needed.
If the new solution is an enhancement to an existing system or solution, the existing solution should be described.
Identify and Define the Constraints
Express the constraints under which the solution is decided upon. These constraints impact risk and cost. They could be
things like external interfaces that the solution must adhere to, standards, certifications, or a technical approach
employed for strategic reasons, such as using a certain database technology, or distribution mechanisms. Time
constraints and financial constraints are also identified.
Define the Rationale
Describe options for the solution—optional approaches, capabilities or features and associated costs and benefits—and
options in approaching or deploying the solution. Solution options might include differing technical solutions,
differing mixes of options for technical solutions, differing mixes of 'make' and 'buy', and so on. In each case, the
effect of the option on the financial forecast, and on constraints (in turn impacting risk) should be described.
The objective is to provide enough information on the options to substantiate the decision. Remember that this
description must stand on its own and be easily understood by a manager or architect reading it in 6 to 12 months or
more—in other words it needs to be readable out of context and complete in its coverage.
Describe the Decision
Describe in detail the decision taken—include details on the solution and any other information that may be relevant,
such as the timeframe of the decision (i.e. short or long term), and any implementation or migration aspects, for
example.
Define the Implications of the Decision
The implications of the decision are described. They include things such as financial, maintenance, operations or
configuration changes or constraints, usually affecting current systems, operations or processes. Implications on other
decisions and on future plans should also be described.
