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.
Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
Usage Guidance
The following is provided to aid in deciding if a decision is architecturally significant, or if it is simply a design
decision.
Table – Architectural Decisions vs. Design Decisions
Architectural Decision
(Must be documented using the AD Process)
Design Decision
(Not documented using the AD Process)
Architectural structure decisions such as “Client Server”, “N-Tier”, etc.
Any detailed design decision (e.g., the layout of a user interface, the detailed user steps in a
manual task, the detailed format of the data in a component interface).
Software “Buy vs. Build”. How much customization is needed in the buy option and how easy is it to
do so, how agile is the buy option, how agile is the custom option, how complex is it to interface
with the buy option.
The detailed format of the data in the interface to the COTSsoftware. The specification of COTS interfaces.
Customize COTS software or integrate within the system using custom software.
Detailed design of COTS integration software.
What is the backup / restore architecture used (e.g., SAN vs. Tapes vs. Optical)?
The SAN switch design and configuration needed in order to support the backup and restore.
What is the Application Framework used? (Struts, home-grown, etc.)?
What are the functional application-layers used inside the business logic layer of the application
framework?
What are the different tiers used by the application architecture?
What are the details of the business logic application tier?
What is the transaction support needed inside a system and how to achieve it?
What are the detail specifications for interfaces and other transaction level aspects?
What is the persistence mechanism used? (e.g., audit, data purging, data archiving)
What is the detailed design for the defined persistence approach?
What is the communication mechanism between components?
What are the detailed specifications of the communications between components?
What is the performance requirement and how is it achieved?
How is this component designed in order to provide the needed performance level?
What authentication mechanism is used by the component or system?
