Architecture decision
An architecture decision establishes a significant aspect of software structure. Context and consequences explain why the choice was made.
An architecture decision concerns a significant aspect of software structure, such as component boundaries or the handling of important interfaces. It should be understandable in relation to requirements and constraints.
A hypothetical portal team decides to deploy the ordering interface and background processing separately. The decision note records the need this serves and the additional operational tasks it creates. The names of the tools used would not supply that reasoning on their own.
An Architecture Decision Record, or ADR, can document context, decision and consequences. If new knowledge requires a different choice, the previous reasoning remains as history and a new decision can supersede it. A change of direction then retains its explanation within project knowledge.
Sources
Related terms
- Requirements analysisRequirements analysis clarifies what a solution must achieve and why. Requests are examined for meaning, conflicts and verifiable outcomes.
- Exit strategyA prepared route to switch, take over or retire an IT service in an orderly way.
- Migration costsEffort and expenditure for the planned move of data or functions to another environment.
- Investment costsCosts of building a new or expanded IT capability, as considered in project planning.
- Operating costsExpenditure to plan for the ongoing operation of an IT solution.
- Scope creepScope creep is gradual expansion of project scope without adequate assessment and corresponding changes to the plan.
Articles on this topic
IT Consulting & Strategy with ASES
Strategy, architecture and technology choice