- There is nothing “static” about architecture. It’s constantly changing and evolving.
- Requirements and circumstances change. It’s up to you to modify your architecture to meet new goals.
- For every decision, you will be faced with multiple solutions. To find the best (or least worst), do a trade-off analysis. This collaborative exercise helps you identify the pros and cons of every possible option.
- The First Law of Software Architecture is: Everything in software architecture is a trade-off.
- The answer to every question in software architecture is “it depends.” To learn which solutions are best for your situation, you’ll need to identify the top priorities and goals. What are the requirements? What’s most important to your stakeholders and customers? Are you in a rush to get to market, or hoping to get things stable in growth mode?
- The product of a trade-off analysis is an architectural decision: one of the four dimensions needed to describe any architecture.
- An architectural decision involves looking at the pros and cons of every choice in light of other constraints—such as cultural, technical, business, and customer needs—and choosing the option that serves these constraints best.
- Making an architectural decision isn’t just about choosing; it’s also about why you’re choosing that particular option.
- The Second Law of Software Architecture is: Why is more important than how.
- To formalize the process of capturing architectural decisions, use architectural decision records (ADRs). These documents have seven sections: Title, Status, Context, Decision, Consequences, Governance, and Notes.
- Over time, your ADRs will build into a log of architectural decisions that will serve as the memory store of your project.
- An ADR’s title should consist of a three-digit numerical prefix and a noun-heavy, succinct description of the decision being made.
- An ADR can be assigned one of many statuses, depending on the kind of ADR and its place in the decision workflow.
- Once all parties involved in the decision sign off on the ADR, its status becomes Accepted.
- If a future decision supplants an Accepted ADR, you should write a new ADR. The supplanted ADR’s status is marked as Superseded and the new ADR becomes Accepted.
- The Context section of an ADR explains why the decision needed to be made to begin with.
- The Decision section documents and justifies the actual decision being made. It always includes the “why.”
- The Consequences section describes the decision’s expected impact, good and bad. This helps ensure that the good outweighs the bad, and aids the team(s) implementing the ADR.
- The Governance section lists ways to ensure that the decision is implemented correctly and that future actions do not stray away from the decision.
- The final section is Notes, which mostly records metadata about the the ADR itself—like its author and when it was created, approved, and last modified.
- ADRs are important tools for abiding by the Second Law of Software Architecture, because they capture the “why” along with the “what.”
- ADRs are necessary for building institutional knowledge and helping teams learn from one another.
Credits : Head First Software Architecture By Raju Gandhi, Mark Richards, Neal Ford
