Architectural Knowledge Management (AKM)

Forschung zu Architectural Knowledge Management (AKM) und Architekturentscheidungen an der OST

Articles on architectural decisions in  «The Concerned Architect» blog. Example: «ADR = Any Decision Record? Architecture, Design and Beyond»

Goals:

  • 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)

Results (Overview):

  • 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):

Research Papers (Selection)

Related Open Source Projects (Collaborations, Thesis Projects):