- Contribute to body of software architecture knowledge (both general and style-specific knowledge: SOA, cloud, microservices)
- Transfer research results from Software Architectural Knowledge Management (SAKM) research community to practice
- Propose and empirically validate simple but powerful techniques for architectural decision identification, making, enactment - and integrate them into agile practices and tools (e.g., decision backlog, architecturally evident coding styles)
- ADMentor, prototypical tool support for architectural decision modelling and reuse, and Cloud Design. See WICSA 2015 conference paper for more information (authors' copy).
- Cloud Guidance Model collecting architectural decisions that recur when designing cloud-native applications and when migrating and refactoring existing applications for the cloud
- Quality stories; POINT criteria for API design and management; service contract template
- Contributions to IEEE Software (e.g., Insights column editing, Pragmatic Architect column installment, Impact column installment)
- Selected project results are featured in a WICSA 2015 presentation (slides). Also see sibling project Architectural Refactoring for the Cloud (ARC).
What is an Architectural Decision (AD)?
- A decision that you wish you could get right early in a project (M. Fowler, in an IEEE Software article).
- A design decision that is costly to change (G. Booch, SATURN 2016 keynote).
- A more elaborate definition: Architectural decisions directly or indirectly determine the non-functional characteristics of a system. Each decision describes a concrete, architecturally significant design issue (design problem) for which several potential solutions (options) exist, and provides rationale for the selection of the chosen solution(s), e.g., by referencing desired quality attributes. Architectural decisions concern a software system as a whole, or one or more of the core components of such a system. Examples are the selection of programming languages and tools, of architectural patterns, of integration technologies, and of middleware assets. Also see this article in Wikipedia and this story on Medium.
- Make sure to make ADs at the Most Responsible Moment (MRM) and stop when a decision satisfies its Definition of Done.
- More definitions can be found in software architecture books and scientific papers.
Decision Capturing Advice and Templates (in Alphabetical Order):
- ADR template by M. Nygard
- IBM ARC 100 table template (see this presentation for an example)
- ISO/IEC/IEEE 42010 template
- Markdown ADR (MADR), see The Markdown ADR (MADR) Template Explained and Distilled on Medium and the Architectural Decision Records organization on GitHub
- Table format in IEEE Software article by J. Tyree and A. Akerman
- Y-Statements by O. Zimmermann (presentation with examples, IEEE Software/InfoQ article, Medium story post)
Research Papers (Selection)
- O. Zimmermann, L. Wegmann, H. Koziolek, T. Goldschmidt, Architectural Decision Guidance across Projects, Proc. of. IEEE/IFIP WICSA 2015 (features ADMentor)
- O. Zimmermann, Architectural Decisions as Reusable Design Assets. In: IEEE Software, Volume 28, Issue 1, 2011 (features meta issues and decision identification techniques in SOA context)
- M. Anvaari, O. Zimmermann. Semi-automated design guidance enhancer (SADGE): A framework for architectural guidance development. Proc. of ECSA 2014, Lecture Notes in Computer Science 2014; Volume 8627 LNCS.
Related Open Source Projects (Collaborations, Thesis Projects):
- Markdown Architectural Decision Records (MADR), featured in this ZEUS 2018 workshop paper.
- ADMentor and Embedded Architectural Decisions (a.k.a. AD annotations or AD@R)
- Architectural Refactoring Tool (ART) and corresponding master thesis (in German, with English AR content in Appendix).
- Service Cutter (ESOCC 2016 Conference Presentation, Authors Copy of ESOCC 2016 Paper)