Maturity of the Discipline of (Software) Architecture
Software architecture as a distinct discipline in software engineering emerged around 1990 although the problems, concepts and solutions had been discussed much longer (see [1]). Since then, software architecture has matured to encompass a broad set of concepts, techniques, practices, and methods (see [2]). Moreover, the scope of the discipline was extended to systems, enterprises, and organizations. Although the maturity of the discipline has increased, there is a significant knowledge gap related to architectural practices and methods, and how to integrate them with other software engineering practices and methods (see [3]). Particularly the transfer from research to practice is slow and much of the earlier progress within the architecture discipline is left behind (cp. to [4]). Descriptions of architectural concepts, techniques, practices, and methods are scattered across technical reports, articles, books, and other publications. Unfortunately, there is no common and organized body of knowledge for the discipline of (software) architecture1). Thus, there is a lack of transparency and reusability that thwarts the adoption of architectural practices and methods in the industry. Particularly in the agile community, software architecture is often not considered as an essential part of software engineering, although it is a critical success factor in agile development endeavors (see [3]). Therefore, there is a significant knowledge gap related to architectural concepts, practices, and methods in the industry. In a former blog post I introduced the concept to develop a library of architectural practices which encompasses existing practices and methods related to software architecture described based on OMG Essence standard (see [3] [7]). This blog post elaborates on the vision, value proposition, guiding principles and development approach of such a library.
Vision
The Architecture Practice Library (APL) aims at establishing an open, common, and organized body of knowledge related to architectural practices. A practice is considered as architectural when it can be associated to the processes defined by the ISO/IEC/IEEE 42020 standard (see [8] and figure 1).
Figure 1: Process Reference Model according to ISO/IEC/IEEE 42020 (see [8])
The standard defines six architecture-related processes including activities, tasks and work products that enable architects and other roles to adopt architecture practices more effectively and efficiently. In the context of the APL the ISO/IEC/IEEE 42020 standard is leveraged as a process reference model to identify, group, and position concrete architectural practices. The processes specified by the standard are applicable concurrently, iteratively, incrementally, and recursively to an architecture or its elements (see [8]). An architecture is described by the fundamental concepts or properties that are typically embodied its components, the relationships between components, and the relationships between the architecture and its environment (cp. to [8]). It can be applied on various levels (e.g., enterprise, organizational unit, system, solution, etc.) and different things (e.g., business, application, technology, product lines, systems of systems, etc.).
The APL leverages the OMG Essence standard to provide supplementary descriptions of existing architectural practices which are based on the Essence language and kernel. Thus, the Essence standard represents the foundation for the APL and its definition of a practice is reused: A practice is a repeatable approach to doing something with a specific objective in mind (see [7]). The APL supports the standardized description, adoption, integration, and enhancement of architectural practices. The Essence-based practice descriptions aren’t supposed to replace the books, articles, reports, etc. in which the existing architectural practices are typically documented. They are establishing an additional and effective access layer to existing practices which makes their adoption and integration easier (see figure 2). Therefore, they speed up the transfer of existing concepts, practices, and methods from research to practice.
Figure 2: Essence-based Practices as an Additional Access Layer
The Essence-based practice descriptions represent a succinct summary of the most important things about an element of a practice. According to the Essence standard those elements are the things to do (activities), the things to work with (work products), and the abilities needed (competences) (see [7]). Figure 3 illustrates a section of a practice description based on the cards view defined by the Essence standard. Please note the figure doesn’t depict the complete practice and the relationships between the elements (i.e., cards) aren’t shown for the sake of simplicity.
Figure 3: Illustrative Section of a Practice Description based on the Card View
The practices in the APL can be further enhanced with frameworks, tools, and templates which help to learn, adopt, and integrate the practices. Ideally, the APL can be leveraged to evaluate and improve the architecture competence of an organization, team or individual (cp. to [9]). The APL and included practices are further developed based on the involvement and feedback from the community of architects, researchers, and practitioners. Therefore, a practice is managed along its life cycle by leveraging mechanisms for change and version control. Eventually, the open, community- and Essence-based approach tackles the knowledge gap related to architectural concepts, practices, and methods.
Value Proposition
The value proposition of the APL is considered from the perspectives of two different roles. The owner of a practice or method can leverage the APL to share her/his work within the community of architects and industry. Thus, existing architectural practices can be brought to light in addition to existing publications like books, articles, technical notes, etc. Furthermore, the practices can be positioned and put into the context of the overall library of architectural practices. Other practices and assets in the APL can be reused as part of so-called composite practices which are compositions of other practices: All elements of the reused practices are merged into one new, composed practice (see [7]). Thus, a practice/method owner doesn’t have to reinvent the wheel when developing an Essence-based practice. An outstanding value of the Essence-based practice descriptions and APL is that it enables a practice owner to provide an update and/or extension of a practice independent from the original publication. If a practice owner has published a book in which version 1.0 of a practice is described, the Essence-based practice description can be managed independently along its own, dedicated life cycle. Therefore, the practice owner can release an updated version – for example version 1.5 of the practice – as part of the APL without having to release a new edition of the book. This approach increases the speed of the innovation cycle and transfer of knowledge from research to practice.
The user of a practice2) benefits from an encompassing view on existing architectural practices — if the APL has grown to a certain extent. Ideally, the APL supports the identification and selection of architectural practices by implementing different classification schemas and providing user friendly search and filter functions. A practice user can select the right practice and view on the practices for the job at hand. First, for example, the HTML-based guidelines of a practice might be used by an individual user to understand and select an architectural practice. Then a team might pick up a proposed practice and discuss its adoption in a virtual meeting by leveraging the Essence-based cards as digital images. For all views, the usage of the Essence language and kernel as a common ground ensures a consistent structure and look-and-feel across the practice descriptions. The Essence-based practice descriptions represent a succinct summary of the most important things a user needs to know about an element of a practice. Therefore, the effort to learn a new practice is significantly reduced. However, there is still the option to use the original publication to gather further details on the practice. The APL supports the composition, adoption, and customization of practices in the context of individual organizations and/or software development endeavors because those features are inherently supported by the OMG Essence standard. This means that once a user has selected a practice in the APL, it can be flexibly integrated into different work environments.
Guiding Principles
The development of the APL is guided by several principles to ensure it is progressing towards the vision that was described before.
Close Collaboration with the Owners of Architectural Practices
The APL is developed in close collaboration with the owners of architectural practices. This means that an owner of an existing practice should be involved in the development of the Essence-based version of her/his practice. Ideally, the practice owner independently develops and maintains the Essence-based version of a practice. However, there is also the option to join forces with a so-called practice author who takes care and/or supports the development of the Essence-based description3). A practice author knows the Essence kernel and language in detail and is adept at transforming existing descriptions of practices into Essence-based versions. Therefore, by leveraging a practice author, the development of an Essence-based description of a practice can be accelerated significantly. In addition, a practice author can also be consulted for training, support, and reviews.
Respect the Intellectual Property of Practice Owners
The intellectual property of practice owners is respected and considered when Essence-based practices descriptions are developed and released. During the development phase of an Essence-based description there are several options to manifest intellectual property rights. The Essence language includes a so-called resource element that can be used to attach further information to the description of a practice (see [7], p. 85 ff.). This element can be used to document any intellectual property rights that are associated with a practice. Furthermore, the Essence cards can be equipped with logos that represent graphically the ownership of a practice.
During the maintenance phase of an Essence-based description, the practice owner controls the life cycle of her/his practice. This means that the practice owner ultimately decides on releases and change requests associated with her/his practices. In the context of change requests, the practice owner can opt for one of two fundamental approaches: Change requests from the community of architects and industry can be considered or not. However, the latter means that the practice owner would miss the opportunity to receive valuable feedback on the practice.
Inspire and Support Collaboration and Knowledge Sharing
The community of architects, researchers and practitioners are involved in the development of the APL. There are two major prerequisites for the involvement that are in the realm of the practice owner. First, the Essence-based practice descriptions are made publicly available, e.g., based on a Creative Commons license. Second, feedback from the community of architects, researchers, and practitioners is considered in the further development of a practice. The consideration of feedback can be supported by an open change request process related to a practice.
In addition to those major prerequisites, there are other aspects that influence collaboration and knowledge sharing. The practice owner has the option to provide the Essence-based descriptions in multiple languages. Although English might be the first choice for many practice owners, other language versions can be provided to increase the acceptance and reach additional users. Moreover, the practice owners and users can proactively promote the usage of APL and its practices. The community-based approach addresses the knowledge gap related to architectural concepts, practices, and methods and eventually speeds up the transfer from research to practice.
Development Approach
The development approach of the APL is centered around the OMG Essence standard and leverages its key features. The Essence language and kernel are designed to support practitioners as well as practice and method engineers (see [7]). Essence is not another framework or method within the domain of software engineering. It defines a common vocabulary and model to describe software engineering practices and methods. Thereby, it focuses on the description of modular practices which can be adopted, composed, and extended in a flexible way.
Architectural practices are orthogonal to other software engineering practices/methods but must be integrated into the way of working related to an individual team, organization, and/or software engineering endeavor. Thus, the OMG Essence standard is the key lever for describing, adopting, and integrating practices and methods in context of the APL.
The OMG Essence standard is only a specification. Tooling is required to develop, manage, and publish Essence-based descriptions of practices. Ivar Jacobson International (IJI) is leading the development of tools for Essence which can be leveraged across the complete life cycle of a software development endeavor. I’m working closely together with the IJI product team which further develops a portfolio of tools supporting the Essence standard.
In general, the user and owner of a practice have different requirements related to tooling. The Essence-based description of a practice — once it is modelled and documented — can be published based on a markup language like HTML or digital images of the Essence-based cards. Therefore, a user of a practice typically doesn’t require specific tools other than a web browser to read, understand, and use the description of a practice. However, there are two major scenarios that require enhanced tooling.
First, the modelling and documentation of a practice based on the Essence standard a specific authoring tool is required. Although the Essence standard and language aren’t very large and complex, specific tooling is required to author the description of a practice and check its conformance against the standard. General tools like Microsoft PowerPoint, Miro, or Mural might be used for very simple practices which are just described based on the cards view. However, these tools don’t support the conformance checks and generation of multiple views on a practice (e.g., cards, HTML descriptions). Furthermore, the scope of the APL is much broader and includes more than simple architectural practices.
Second, the enactment, integration, and extension of practices by an organization, team, or individual person in the context of a concrete software development endeavor requires specialized tools. Such tools can be used e.g., to analyze and document the current state, define a distinct way of working based on a combination of different practices, or individually change and extend existing practices. The latter scenario and tooling features aren’t in scope of the APL (yet) because its primary objective is to provide transparency and access an open, common, and organized library of architectural practices. Nevertheless, the APL is an enabler for the second scenario by providing and managing the Essence-based descriptions of architectural practices. Single practices might be selected and copied to a specific tool supporting the second scenario.
The overall model for the life cycle of the APL is based on an incremental approach. It is unlikely that all architectural practices and methods can be identified initially. Moreover, as the APL is developed in close collaboration with the owners of architectural practices it isn’t likely that the participation of all practice owners can be in an overall, upfront plan. Thus, an incremental approach in which more and more Essence-based descriptions are developed in iterative cycles is a reasonable way forward.
Although it is unrealistic to identify all existing architectural practices/methods prior to the implementation of the APL, developing and maintaining an inventory of architectural practices can represent a first step towards transparency and support the identification of candidate practices and their owners. I have already started to develop such an inventory of architectural practices and plan to release it soon. The inventory is also an initial deliverable which aims at getting the community of architects, researchers, and practitioners involved in the development of the APL.
Conclusion & Next Steps
The development of an Architecture Practice Library (APL) is a concept that I’m working on for some time. It aims at establishing an open, common, and organized body of knowledge related to architectural practices to grapple with the existing knowledge gap in the industry. This blog post elaborates on the vision, value proposition, guiding principles and development approach of such a library to refine and push to concept towards implementation.
In fact, the implementation phase has already begun. I joined forces with the owners of some fundamental architectural practices for which Essence-based descriptions are already developed. However, those Essence-based practices aren’t publicly released yet.
If you’re interested in getting involved in the development of APL, I’d like to encourage you to get in touch with me. Particularly, if you’re an owner of an architectural practice and would like to discuss the development of an Essence-based version of your practice, please get in touch with me.
I own thanks to the following people for their valuable feedback and support of the concept: Simon Girvan, Ivar Jacobson, Murat Erder, Richard Hilliard, Stéphane Gagnon, Christian Piwetz, and David Enstrom.
Footnotes
1) The so-called SWEBOK Guide characterizes the contents of the software engineering discipline and is structured based on knowledge areas (see [5]). Software architecture is currently addressed under the knowledge area Software Design. The next version V4 of the SWEBOK guide will contain a new and dedicated knowledge area for the discipline of software architecture. However, the SWEBOK Guide should not be confused with the body of knowledge itself because it is just an index to existing literature. Moreover, the so-called EABOK provides an index to the body of knowledge of the discipline of enterprise architecture (see [6]). The EABOK was released as a draft version on February 6, 2004. Since then, no updates were made available. The website eabok.org represents a community-based approach to maintain an index to the enterprise architecture body of knowledge. Another approach to capture and document architecture-related knowledge is the so-called Business Technology Architecture Body of Knowledge (BTABoK) which is available as a website.
2) A user refers in this context to individuals, teams, and organizations.
3) I consider myself as a practice author and have developed several Essence-based practices descriptions collaboratively with their owners.
References
[1] Kruchten, P.; Obbink, H.; Stafford, J.: The Past, Present, and Future for Software Architecture. In: IEEE Software, Volume 23, Issue 2, 2006
[2] Shaw, M.; Clements, P.: The Golden Age of Software Architecture. In: IEEE Software, Volume 23, Issue 2, March-April 2006
[3] Malich, Stefan: On Agility and Architectural Engineering (Revisited). Blog post on stefanmalich.com, April 19, 2022
[4] Kruchten, Philippe: Software Architecture: A Mature Discipline? SEI Webcast, June 2, 2020
[5] P. Bourque and R.E. Fairley, eds.: Guide to the Software Engineering Body of Knowledge, Version 3.0, IEEE Computer Society, 2014, http://www.swebok.org
[6] Hagan, Paula J.: Guide to the (Evolving) Enterprise Architecture Body of Knowledge (EABOK). MITRE, Technical Paper, 2004
[7] Object Management Group: Essence – Kernel and Language for Software Engineering Methods. Standard Document, Version 1.2, October 2018
[8] ISO/IEC/IEEE 42020:2019, Software, systems and enterprise — Architecture processes
[9] Bass, L.; Clements, P.C.; Kazman, R.; Klein, M.H.: Models for Evaluating and Improving Architecture Competence. Technical Report CMU/SEI-2008-TR-006, Carnegie Mellon University, Pittsburgh, March 2008
