Architectural decision

Last updated

In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make [1] and/or costly to change. [2]

Contents

Characteristics

Architectural decisions influence and impact the non-functional characteristics of a system. Each architectural decision describes a concrete, architecturally significant design issue (a.k.a. design problem, decision required) for which several potential solutions (a.k.a. options, alternatives) exist. An architectural decision captures the result of a conscious, often collaborative option selection process and provides design rationale for the decision making outcome, e.g., by referencing one or more of the quality attributes addressed by the architectural decision and answering "why" questions about the design and option selection. Architectural decisions concern a software system as a whole, or one or more of the core components of such a system. Types of architectural decisions are the selection of architectural tactics and patterns, of integration technologies, and of middleware, as well as related implementation strategies and assets (both commercial products and open source projects). [3]

Software architecture design is a wicked problem, [4] therefore architectural decisions are difficult to get right. Often, no single optimal solution for any given set of architecture design problems exists. Architectural decision making is a core responsibility of software architects; [5] additional motivation for/of the importance of architectural decisions as a first-class concept in software architecture can be found online. [6]

History

Rationale was mentioned in an early definition of software architecture by Perry/Woolf, [7] but not researched much until 2004, when a workshop on architectural decisions and Architectural Knowledge Management was held in Groningen, NL. Early publications can be traced back to this workshop,. [8] [9] From 2006 on, the architectural knowledge management and architectural decision research communities gained momentum and a number of papers was published at major software architecture conferences such as European Conference on Software Architecture (ECSA), Quality of Software Architecture (QoSA) and (Working) International Conference on Software Architecture (ICSA). A Springer book summarized the state of the art as of 2009, [10] and a systematic mapping study from 2013 [11] compiles and analyzes more and more recent research results.

In practice, the importance of making the correct decisions has always been recognized, for instance in software development processes such as OpenUP; many templates and practices for decision documentation exist. Seven of these templates are compared in. [12] The most recent standard for architecture descriptions, ISO/IEC/IEEE 42010:2011 has a dedicated rationale entity, and gives detailed recommendations which architectural decisions to capture and which properties of an architectural decision to record in the decision log. [13]

Decision management steps

Decision identification

Before a decision can be made, the need for a decision must be articulated: how urgent and how important is the AD? Does it have to be made now or can it wait until more is known about requirements and system under construction? Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification; it has been proposed that Agile software development team should maintain a decision backlog complementing the product backlog of the project. [14]

Decision making

Identified decisions can only be made if certain criteria are met, which form a definition of ready for AD making: (1) Stakeholders have been identified, (2) Time is right, (3) Alternatives (aka options) listed, (4) Requirements and other criteria defined, (5) ADR Template chosen. [15]

A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping. [16] Group decision making is an active research topic.

Decision documentation

Many templates and tools for decision capturing exist, both in agile communities (e.g., M. Nygard's architecture decision records [17] ) and in software engineering and architecture design methods (e.g., see table layouts suggested by IBM UMF [18] and by Tyree and Akerman from CapitalOne. [19] G. Fairbanks included decision rationale in his one-page Architecture Haikus; [20] his notation was later evolved into Y-statements. See [21] for motivation, examples, comparisons.

Decision enactment (enforcement)

Architectural decisions are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it. Architecturally evident coding styles [22] and code reviews that focus on architectural concerns and decisions are two related practices.

Architectural decisions also have to be considered when modernizing a software system in software evolution.

Decision sharing (optional step)

Many architectural decisions recur across projects; hence, experiences with past decisions, both good and bad, can be valuable reusable assets when employing an explicit knowledge management strategy. [23]

It is important to know when a single architectural decision can be considered done. Five elements of a definition of done have been proposed: evidence, criteria, agreement, documentation, realization/review. [24]

Examples

On large scale projects, the number of architectural decisions to be made can exceed 100, including:

Refer to the design concept catalogs in Attribute-Driven Design 3.0 [26] and domain-specific decision guidance models [27] for more examples.

This is an example of a decision made, which is formatted according to the Y-statement template proposed in: [28]

“In the context of the Web shop service, facing the need to keep user session data consistent and current across shop instances, we decided for the Database Session State Pattern (and against Client Session State or Server Session State) [29] to achieve cloud elasticity, accepting that a session database needs to be designed, implemented, and replicated.”

Templates

Many templates have been suggested by practicing architects and by software architecture researchers. GitHub repositories such as "Architecture decision record (ADR)" [30] and "Markdown Architectural Decision Records" [31] collect many of them, as well as links to tools and writing hints.

Software Architecture Group Decision Making

Both practitioners and researchers recognize that software architecture decision-making is a group process that involves several stakeholders discussing, evaluating and shortlisting architectural decisions. Studies [32] [33] of practitioners found that though groups are ideally sized, a structured approach to decision-making is largely lacking. Specifically:

These challenges provide good scope for experimentation and research for the software architecture community.

See also

Related Research Articles

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

<span class="mw-page-title-main">IDEF</span> Family of modeling languages

IDEF, initially an abbreviation of ICAM Definition and renamed in 1999 as Integration Definition, is a family of modeling languages in the field of systems and software engineering. They cover a wide range of uses from functional modeling to data, simulation, object-oriented analysis and design, and knowledge acquisition. These definition languages were developed under funding from U.S. Air Force and, although still most commonly used by them and other military and United States Department of Defense (DoD) agencies, are in the public domain.

<span class="mw-page-title-main">Philippe Kruchten</span> Canadian software engineer

Philippe Kruchten is a Canadian software engineer, and Professor of Software Engineering at University of British Columbia in Vancouver, Canada, known as Director of Process Development (RUP) at Rational Software, and developer of the 4+1 Architectural View Model.

Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.

<span class="mw-page-title-main">Systems architecture</span> Conceptual model of a system

A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.

<span class="mw-page-title-main">Enterprise architecture framework</span> Frame in which the architecture of a company is defined

An enterprise architecture framework defines how to create and use an enterprise architecture. An architecture framework provides principles and practices for creating and using the architecture description of a system. It structures architects' thinking by dividing the architecture description into domains, layers, or views, and offers models – typically matrices and diagrams – for documenting each view. This allows for making systemic design decisions on all the components of the system and making long-term decisions around new design requirements, sustainability, and support.

IEEE 1471 is a superseded IEEE standard for describing the architecture of a "software-intensive system", also known as software architecture.

<span class="mw-page-title-main">Design rationale</span>

A design rationale is an explicit documentation of the reasons behind decisions made when designing a system or artifact. As initially developed by W.R. Kunz and Horst Rittel, design rationale seeks to provide argumentation-based structure to the political, collaborative process of addressing wicked problems.

ISO/IEC/IEEE 42010Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.

Domain-driven design (DDD) is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts. DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model.

<span class="mw-page-title-main">Solution architecture</span> Term used in information technology

Solution architecture is a term used in information technology with various definitions, such as "a description of a discrete and focused business operation or activity and how IS/IT supports that operation".

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle. DevOps is complementary to agile software development; several DevOps aspects came from the agile way of working.

In the context of software engineering and software architecture, service granularity is a key design concern when applying the paradigm of service-orientation for instance during service-oriented modeling. Service granularity specifies the scope of business functionality and the structure of the message payload in a service operation that is provided within a service-oriented architecture (SOA).

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

Software architecture description is the set of practices for expressing, communicating and analysing software architectures, and the result of applying such practices through a work product expressing a software architecture.

Johannes Cornelis (Hans) van Vliet is a Dutch computer scientist and Professor Emeritus of Software Engineering at the Vrije Universiteit Amsterdam, known for his work in quantitative aspects of software engineering.

In software engineering, a microservice architecture is an architectural pattern that arranges an application as a collection of loosely coupled, fine-grained services, communicating through lightweight protocols. One of its goals is to enable teams to develop and deploy their services independently. This is achieved by reducing several dependencies in the codebase, allowing developers to evolve their services with limited restrictions, and hiding additional complexity from users. Consequently, organizations can develop software with rapid growth and scalability, as well as use off-the-shelf services more easily. Communication requirements are reduced. These benefits come with the cost of maintaining decoupling, so a microservice architecture may be suitable only if the application is too complex to manage as a monolith. Interfaces need to be designed carefully and treated as public API. One technique used is having multiple interfaces on the same service or multiple versions of the same service to avoid disrupting existing users of the code.

Danny Greefhorst is a Dutch enterprise architect and consultant at ArchiXL, known for his work in the field of enterprise architecture.

Agile architecture means how enterprise architects, system architects and software architects apply architectural practice in agile software development. A number of commentators have identified a tension between traditional software architecture and agile methods along the axis of adaptation versus anticipation.

References

  1. ↑ Fowler, M. (2003). "Design – Who needs an architect?". IEEE Software. 20 (5): 11–44. doi:10.1109/MS.2003.1231144
  2. ↑ Booch, G., abstracting-the-unknown, SATURN 2016 keynote
  3. ↑ Page 64 in O. Zimmermann, Architectural Decisions as Reusable Design Assets. IEEE Software, Volume 28, Issue 1, Pages 64-69, Jan./Feb. 2011.
  4. ↑ Conklin, Jeffrey (2006). Dialogue mapping : building shared understanding of wicked problems. Chichester, England: Wiley Publishing. ISBN   0470017686.
  5. ↑ Kruchten, P., What do software architects really do?, The Journal of Systems and Software 81 (2008) 2413–2416
  6. ↑ Hohpe, G., Is This Architecture? Look for Decisions!
  7. ↑ Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" (PDF). ACM SIGSOFT Software Engineering Notes. 17 (4): 40. doi:10.1145/141874.141884
  8. ↑ Jansen, A.; Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05)
  9. ↑ Kruchten, Philippe, Patricia Lago, and Hans Van Vliet. "Building up and reasoning about architectural knowledge." Quality of Software Architectures. Springer Berlin Heidelberg, 2006. 43-58.
  10. ↑ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Software Architecture Knowledge Management: Theory and Practice (eds.), First Edition. Springer.
  11. ↑ Li, Z., Liang, P., Avgeriou, P., Application of Knowledge-based Approaches in Software Architecture: A Systematic Mapping Study, Information and Software Technology, Volume 55, Issue 5, May 2013, Pages 777-794, Elsevier.
  12. ↑ Zimmermann, O., Wegmann, L., Koziolek, H., Goldschmidt, T., Architectural Decision Guidance across Projects, Proc. of. IEEE/IFIP WICSA 2015
  13. ↑ ISO/IEC/IEEE 42010:Templates for using the Standard.
  14. ↑ Hofmeister, C., Kruchten, P., Nord, R., Obbink, H.; Ran, A., America, P. (2007), A general model of software architecture design derived from five industrial approaches.
  15. ↑ O. Zimmermann (2023). A Definition of Ready for Architectural Decisions, https://medium.com/olzzio/a-definition-of-ready-for-architectural-decisions-ads-2814e399b09b
  16. ↑ Conklin, Jeffrey (2006). Dialogue mapping: building shared understanding of wicked problems. Chichester, England: Wiley Publishing. ISBN   0470017686.
  17. ↑ M. Nygard, Documenting Architecture Decisions
  18. ↑ Zimmermann, O., An Architectural Decision Modeling Framework for SOA and Cloud Design, SEI SATURN 2010 presentation.
  19. ↑ Tyree, J., Akerman, A., Architecture decisions: demystifying architecture
  20. ↑ G. Fairbanks, Architecture Haiku, http://www.slideshare.net/matthewmccullough/architecture-haiku
  21. ↑ T. van Lessen, A Brief Introduction to ADRs, https://speakerdeck.com/vanto/a-brief-introduction-to-architectural-decision-records
  22. ↑ Fairbanks, G., An architecturally-evident coding style: making your design visible in your code, Proc. of OOPSLA 2010
  23. ↑ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer.
  24. ↑ O. Zimmermann (2020). A Definition of Done for Architectural Decisions, https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9
  25. ↑ Buschmann, Frank; Meunier, Regine; Rohnert, Hans; Sommerlad, Peter (1996). Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. John Wiley & Sons. ISBN   0-471-95869-7.
  26. ↑ H. Cervantes, R. Kazman, Designing Software Architectures: A Practical Approach, Addison-Wesley, 2016.
  27. ↑ Page 21 in Zimmermann, O., Guidance Models and Decision-Making Tooling for SOA, Cloud, and Outsourcing Solution Design, http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf
  28. ↑ Uwe Zdun et al., Sustainable Architectural Design Decisions, IEEE Software, Volume 30, Number 6 (2013), available at http://www.infoq.com/articles/sustainable-architectural-design-decisions
  29. ↑ M. Fowler,Patterns of Enterprise Application Architecture
  30. ↑ J. Parker-Hernderson, Architecture decision record (ADR), https://github.com/joelparkerhenderson/architecture_decision_record
  31. ↑ ADR organization,Markdown Architectural Decision Records
  32. ↑ Rekhav, V. Smrithi; Muccini, Henry (April 2014). "A Study on Group Decision-Making in Software Architecture". 2014 IEEE/IFIP Conference on Software Architecture. pp. 185–194. doi:10.1109/WICSA.2014.15. ISBN   978-1-4799-3412-6. S2CID   17362075.
  33. ↑ V, Smrithi Rekha; Muccini, Henry (1 September 2018). "Group decision-making in software architecture: A study on industrial practices". Information and Software Technology. 101: 51–63. doi:10.1016/j.infsof.2018.04.009. ISSN   0950-5849. S2CID   49384683.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.