Status: request for comments | proposed | accepted | rejected | deprecated | superseded
Summary: briefly explain the current position and any needs.
Describe the issue you want to address. Leave no questions about why you’re addressing this issue now.
Follow a minimalist approach. Address only the issues that need addressing at various points in the life cycle.
You may want to add some grouping information, such as tags, keywords, knowledge base links, etc.
Describe any underlying assumptions in the environment in which you’re making the decision.
Be sure to address any relevant quality attributes a.k.a. cross-functional requirements.
Example assumptions may involve scope, cost, schedule, technology, resource availability, quality of service needs, service level agreements, and so on.
Note that environmental constraints (such as accepted technology standards, enterprise architecture, commonly employed patterns, and so on) might limit which options you consider.
Capture any additional constraints to the environment that this decision might pose.
Be sure to address any relevant quality attributes a.k.a. cross-functional requirements, as above.
Example constraints may involve platform choices, vendor selections, the ease of decision reversibility, etc.
List the positions, which are the viable options that you are considering, or have considered.
Use facts and data, not opinions. The positions can often require long explanations, sometimes even models and diagrams.
This doesn't need to be an exhaustive list; however, you don’t want to hear the question "Did you think about...?" during a final review, because this would lead to loss of credibility and questioning of other architectural decisions.
This section also helps ensure that you heard others’ opinions; explicitly stating other opinions helps enroll their advocates in your decision.
Summary: briefly explain this section, and ideally highlight any outliers.
Examples:
-
Initiating, such as setup costs, time, and resources.
-
Operating, such as support and maintenance
-
Training, such as upskilling and change management
-
Licensing, such as contract agreements and legal commitments
-
Metering, such as bandwidth and CPU usage
Summary: briefly explain this section, and ideally highlight any outliers.
-
Strengths
-
Weaknesses
-
Opportunities
-
Threats
Summary: briefly explain this section, and ideally highlight any outliers.
-
Political factors
-
Economic factors
-
Social factors
-
Technological factors
Some teams like to add these as their own categories:
-
Legal factors - we prefer to have these in the political factors.
-
Regulatory factors - we prefer have these in the political factors.
-
Environmental factors - we prefer to have these in the economic factors.
-
Demographic factors - we prefer to have these in the social factors.
Add your own ideas here...
Summary: briefly explain this section, and ideally highlight any outliers.
-
By the team, ideally written by the actual teammate.
-
By other internal stakeholders, ideally written by the actual stakeholder.
-
By external people, such as third-party advisors, evaluators, reviewers, etc.
For each opinion, be clear about:
-
Who is providing the opinion
-
What other candidates were considered,
-
How did the author evaluate the candidates?
-
Why did the author choose the winner?
-
What is happening since then?
-
Knowing what you know now, what would you advise people to do differently?
Summary: briefly explain this section, and ideally highlight any outliers.
Explain your opinion here.
Summary: briefly explain this section, and ideally highlight any outliers.
Explain your opinion here.
Summary: briefly explain this section, and ideally highlight any outliers.
Explain your opinion here.
Summary: briefly explain this section, and ideally highlight any outliers.
Explain why you selected a position.
Decisions should be purpose-driven. To show accountability, explicitly map your decisions to the objectives or requirements.
The argument is probably as important as the decision itself.
This doesn't need to be an exhaustive write-up; however, you don’t want to hear the question "Did you think about...?" during a final review, because (as above) this would lead to loss of credibility and questioning of other architectural decisions.
Summary: briefly explain this section, and ideally highlight any outliers.
Clearly state your decision’s implications. This can be very effective in gaining buy-in and creating a roadmap for execution.
For example, a decision might introduce a need to make other decisions, create new requirements, or modify existing requirements; pose additional constraints to the environment; require renegotiating scope or schedule with customers; or require additional staff training.
Summary: briefly explain this section, and ideally highlight any outliers.
List any related decisions here.
We’ve found that in practice, a traceability matrix, decision trees, or metamodels are more useful. Metamodels are useful for showing complex relationships diagrammatically (such as Rose models).
Summary: briefly explain this section, and ideally highlight any outliers.
List any related requirements here.
We’ve found it more convenient to reference a traceability matrix. You can assess each decision’s contribution to meeting each requirement, and then assess how well the requirement is met across all decisions. If a decision doesn’t contribute to meeting a requirement, then don’t make that decision.
List any related artifacts here.
Examples are any scope documents, planning documents, business process models, etc., that this decision impacts.
If the enterprise has an agreed-upon set of principles, make sure the decision is consistent with one or more of them. This helps ensure alignment along domains or systems.
Because decision-making processes can take significant time, we’ve found it useful to capture notes and issues that the team discusses during the socialization process.