Ahhhh decisions… As enterprise architects either help other to make decisions or we have to every day. These decisions are often consequential decisions that have large and lasting impacts. So it’s kinda a big deal when EAs are in the decision making seat. While these decisions are mission critical they can also be highly political in nature. Meaning there is a vested interest from many parties and not all the same goals and objectives.
So we need a collaborative model that is able to help EAs to arbitrate decisions in a productive manner that moves the organization forward while also instilling accountability with stakeholders. One way I’ve done this in the past is through Architecture Decisions.
So what are Architecture Decisions (AD)?
It’s an EA activity for evaluating architecturally significant options through a standardized framework to provide business unit and IT decision makers with the vital information needed to make informed business decisions, ensure shared accountability, and that ensure the maximization of the organization’s business outcomes.
Typically, these are decisions that address architecturally significant requirements that are or are perceived as high risk decisions that need to be made.
Best Practices for Leveraging Architecture Decisions
Architecture impact analysis and trade-offs are different from the ultimate decision and the implementation. Make sure that each activity has the right base expectations. Don’t be as rigid with the beginning phases, the goal is to get a common understanding of the problem, the impact, and collected data to support a set of recommendations.
It is ideal to only go through this rigorous process on architectural significant decisions (decisions that have significant impact on business outcomes, key strategies, or highly risky)
Ensure that architecture decisions have durability by embedding them into the governance process by making sure a system is put in place to catalog the architecture decisions and a way to search and associate.
Strive for reusability of decisions across common solution patterns
Architecture decisions should foster informed decision making with all the facts along with the rationale and justification of architectural decisionsEnsure that the architecture is well thought through and have at least 3 possible solutioned options are evaluated before having a formal meeting to make a decision.
Avoid unnecessary reconsideration of the same issues
Architecture Decisions Process w/ Enablers
Best Practices for Architecture Decisioning
Record the architects’ decisions. The following template is designed to be completed for each Architecture Decision. It is completed when proposed and must be complete and unambiguous.
Communicate the architecture. Each stakeholder is provided a chance to review proposed decisions and provide input and feedback.
Approve architecture decisions. Architecture governance processes can be established to review and approve proposed Architecture Decisions. Approved decisions become architecture standards.
Document architecture decision history. A full history or architecture changes is created that can be referenced over time.
Don’t invent it all yourself. Leverage Gartner or other standards bodies such as SEI ATAM or TOGAF.
Architecture Decisions Example Template
Each field on the form is defined as follows:
Decision Title – Short description of the title of the decision and enable the reader to frame the realm and nature of the description.
Arch ID – An identifier that uniquely references the decision.
Domain – The domain categorizes the decision and allows for the grouping and reporting of decisions that have similar focus. Architectural domain selected from the following list:
Business
Application
Information
Technical
Security
Status – The status field supports the architecture decision approval process and the state transition of the decision over its lifecycle. Valid statuses could include:
Pending – a decision that is proposed and requires approval
Open – a decision that has been reviewed and approved
Closed – a decision that has been rejected or is obsolete
Description – A description of the issue, problem or opportunity the architecture decision is intended to address and how it will be addressed. This field provides the detailed description of why the decision is required and the impact.
Assumptions – A list of the underlying assumptions that were made in formulating the decision. Definition of the assumptions enables the reader to understand the basis on which the decision is formulated and supports validation.
Motivation – A description of the key motivating reasons why the architecture decision is required. These motivating reasons define what is driving the need for the architectural decision and the overall impact.
Constraints – Constraints that impact the decision. Most decisions will constraints that limit the architectural decision both in scope and impact. Typical constraints may be technical, geographical or organizational.
Alternatives – Identification and summary of the alternative architectural options that were considered. Most architectural decisions have multiple ways they can be addressed and this field should list the alternatives. At least 2 alternatives should be identified.
Decision – Summary of the decision that was made. This field should provide identify the specifics of the decision that was made.
Driving Principles – Identification of the core architectural principles that are supported by the decision. The core architectural principles are the architecture values that drive architecture decisions within the organization. The level of alignment with these principles should be documented.
Justification – Describe the justification for the architecture decision and the benefits that will be realized from the implementation. Justification of decisions and the business and IT objectives and goals supported help frame the urgency and rationale for implementing the decision.
Implications – Implications of adopting the decision that would include costs to be incurred and initiatives that should be undertaken. The implications will also identify the remedial work and refactoring that must be subsequently completed to implement the decision.
Related Decisions – Often a decision is related to or dependent on another decision.
The related decision field is intended to identify dependencies and relationships of decisions and the nature of the relationships. In reviewing proposed decisions for approval, this enables the related decisions to be considered collectively.
Author – Name of the architect who initiated the decision
Date – Date the decision was initiated or revision made
Revision History – Full history of the actions taken on the decision including content and status changes
Approver – Name of the approver.
Title – Title of the approver
Date – Approval Date
Approver Email – Embed approval email for audit and control processes.
Other Sources That May Be Helpful
Architecture Decisions: Demystifying Architecture – https://www.utdallas.edu/~chung/SA/zz-Impreso-architecture_decisions-tyree-05.pdf
Architecture Decisions on Wikipedia – https://en.wikipedia.org/wiki/Architectural_decision
SEI ATA – https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=6265
Comments