Keywords

1 Introduction

Software architecture has been defined in multiple ways since the 1960’s. From the first ideas of structuring and decomposing complex systems into more manageable modules [1,2,3], to modern definitions with focus on cooperating components, decision making [4] and knowledge management (AKM) [5].

Software architecture has been considered by many researchers and practitioners a fundamental asset in software development and maintenance [6,7,8]. For instance, the authors of a book on documenting software architecture [9] express that without an appropriate software architecture for the problem to be solved by a software, the project will fail. Other authors also express the difficulties brought by not using correctly a software architecture to handle the complexity of software-intensive systems [10], or the importance of software architectures for developing software systems that are better and more resilient to change when compared to systems developed without a clear architectural definition [11].

However, despite its importance, the process of software architecting, the evaluation of software architectures and even the social impact on the software architecture in an organization are still neglected in software development [8, 12, 13]. Creating a reliable, robust software architecture demands effort which will be almost useless in case the architecture is not well-described and understood by technical stakeholders. Software architects need to describe it on the necessary level of detail, trying to solve ambiguity issues, and organize in such a way that it is understandable, and with information that is easy to retrieve.

A case of technical debt occurs when the architectural documentation is insufficient, incomplete, or outdated. One possible reason is due to the contest between agilists and more process-oriented personnel [11, 14]. The assumption in this paper is that even though the importance of software architecture is recognized, how to describe, and at what level of detail one has to describe the software architecture, are still open issues in industry. It is frequent that industry practitioners, and even researchers, do not even know how to start to describe the architecture [8], do not know how much architecture to use [15, 16], have issues regarding agility in processes and what is named Big Design Up-Front (BDUF) architecture [17], or even which architectural elements are necessary to describe in the software architecture documents [18,19,20].

One possible solution for describing a software architecture is to rely on models and standards such as Kruchten’s 4+1 Model [21] or ISO/IEC/IEEE 42010:2011 [22]. However, the issue here is that in practice it is hard to understand such standards, as they are considered too high-level to be used in practice or too complex to be easily understandable by the software development team.

The proposal in this paper is to describe a model named ArchCaMo to access the level of architectural maturity using ISO/IEC/IEEE 42010:2011 as context. The objective of ArchCaMo is twofold. First, the ArchCaMo model can be used to evaluate current architectures, showing to development personnel at what level of maturity their architecture conforms to. In addition, it is useful for those organizations that are struggling with organizing, describing and communicating the software architecture for multiple stakeholders. For each level of architecture maturity, the organization knows exactly what to expect in terms of activities and deliverables.

Although other maturity models for software architectures were proposed, as described in the next section, to the best of our knowledge, no other models were introduced with focus on ISO/IEC/IEEE 42010:2011.

2 Related Works

Many maturity models were proposed in past decades in order to access capability of organizations and departments of information technology. Among these, SW-CMM and CMMI are well-known, and have been applied to evaluate software development processes in many countries and for a variety of domains.

SW-CMM [23], and later its evolution, Staged CMMI [24], propose evaluation in 5 levels, in which each level includes a number of activities, tasks, goals, processes, practices and so on. Therefore, when an organization is certified at some level, it is possible to know which activities and practices are performed, indicating a level of discipline and organization for software development.

Few works have proposed to evaluate and access maturity levels of software architectures.

For instance, in [25], authors contribute towards establishment of a comprehensive and unified strategy for process maturity evaluation of software product lines, showing the maturity of the architecture development process in two organizations.

Authors of article [26] propose an architectural maturity model framework to improve Ultra-Large-Scale Systems Interoperability. Although the authors present an architectural maturity model, their focus was only on organizing an interoperability maturity model, i.e., the maturity is evaluated from the interoperability point of view, and is not applicable for other architectural purposes.

The US Department of Commerce (DoC) has developed an IT Architecture Capability Maturity Model (ACMM) [27]. The ACMM provides a framework that represents the key components of a productive IT architecture process. Their approach is to identify weak areas and provide an evolutionary path to improving the overall architecture process. The DoC ACMM consists of six levels and nine architecture characteristics.

To the best of our knowledge, no works have described a software architecture maturity model based on ISO/IEC/IEEE 42010:2011, a standard to describe software and system architectures, briefly introduced in the next section. Therefore, novelty here regards not only the proposal of a new architectural capability model for evaluation of software and systems architectures, but also the use of a standard as a guide to the capability model.

ISO/IEC/IEEE 42010:2011 [22] addresses the creation, analysis and sustainment of architectures of systems through the use of architecture descriptions. This standard proposes a conceptual model of architecture description, including concepts such as views, models, concerns, rationale, viewpoints, frameworks and architecture description languages. The standard provides a core ontology for description of software architectures.

Several terms which have some relation to software architecture are defined in the standard. According to the standard Architecting is the process of conceiving, expressing, defining, documenting, communicating and certifying proper implementation of, maintaining and improving an architecture throughout a software’s life cycle. An Architecture is the fundamental concept or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.

ISO/IEC/IEEE 42010:2011 does not specify any format for recording architecture descriptions, but it describes the basic context of an architecture description. This context specifies that stakeholders have interests in one or more software systems. These interests, better explained as concerns, include a variety of extra-functional properties, such as maintainability, testability, and modularity, but also project management concerns, including costs, schedule, business goals and strategies. A concern pertains to any influence on a system in its environment. Each system is situated in an environment, which is a context determining the setting and circumstances of all influences upon a software system. The environment of a software system includes developmental, business, technological, operational, organizational, political, economic, regulatory, legal, ecological and social influences.

Each class of stakeholder has more or less interest, depending on how important a concern is regarding their own tasks and roles in the organization. For instance, maintainability is a concern of software developers and architects, and business goals and strategies are concerns for managers. Each system can exhibit many architectures, as for instance, when considered in different environments.

An architecture can be expressed through several distinct architecture descriptions, and the same architecture can characterize one or more software systems, as a software product line sharing a common architecture.

Architecture descriptions have many uses for a variety of stakeholders throughout the system life cycle. For instance, software developers use the architecture description for software design, development and maintenance activities. Clients, acquirers, suppliers and developers use the architecture description as part of contract negotiations, documenting the characteristics, features and design of a software system. Infrastructure personnel use the architecture description as a guide to operational and infrastructure support and configuration management. Managers use the architecture description as a support to software planning activities, such as establishing the schedule, budge, and the team.

A complete description on ISO/IEC/IEEE 42010:2011 can be find in the official standard document [22], and its practical use has been explored by many researchers in past years, for instance in health systems [28, 29], industry [30, 31], transportation systems [32], business [33], defense [34] and energy [35].

3 ArchCaMo - Architectural Capability Model

Instead of establishing in a rigid way activities, processes and tasks to be followed, in ArchCaMo the idea is to structure the levels in such a way that the organization can decide its own processes for each given practice to be executed at each level.

3.1 How the Levels Are Proposed

The ArchCaMo’s levels are based on, essentially, ISO/IEC/IEEE 42010:2011, a Systematic Mapping Study (SMS) executed by the authors, and also the authors’ own experience in software architecture.

First, almost all the levels are linked to a topic of the standard. Therefore, we did not change the standard, but we have organized it in such a way that the architecture team can document the software/system’s architecture in a sequential manner.

The second reference for ArchCaMo’s levels is the SMS. We found initially 128 papers published between 2007 and 2018. After the selection phase, 19 studies expressed that they have used ISO/IEC/IEEE 42010:2011 on their architecture description, thus we identified what aspects/points of the standard were most or least used in these studies. As a result, according to this classification and our knowledge/experience about the standard, we proposed that the most used features of ISO/IEC/IEEE 42010:2011 would be considered in the initial levels and so on.

3.2 ArchCaMo Levels

The ArchCaMo model is defined in 5 levels. The initial level, Level 1, refers to all companies/organizations that do not have a formalized way to define the software architecture, so they may document some aspects that they need or think that is necessary for the project. This level is classified as unstable from the architectural point of view.

Levels 2 and 3. These levels are made up of most relevant aspects that are necessary to describe a software architecture. The following tables describe each level consisting of KAI (Key Architecture Item), the description of the KAI, and the respective reference in ISO/IEC/IEEE 42010:2011.

Table 1. Level 2 - minimum architecture
Full size table

Table 1 describes the Minimum Architecture, which is the name of Level 2. This table is based on Context of architecture description and Conceptual model of an architecture description of ISO/IEC/IEEE 42010:2011.

Table 2 describes the Defined Architecture, and it is also based on Conceptual model of an architecture description, and Conceptual model of AD elements and correspondences of ISO/IEC/IEEE 42010:2011.

Table 2. Level 3 - defined architecture
Full size table

Levels 4 and 5. The 2 upper levels represented in Tables 3 (Consistent Architecture) and 4 (Quantified and Improved Architecture) are related to aspects that are needed to improve a software architecture situation in the life cycle that is already structured, but still has possibilities of improvement.

Table 3 describes the Consistent Architecture, based on Conceptual model of an architecture framework, and Conceptual model of an architecture description language of ISO/IEC/IEEE 42010:2011.

Table 3. Level 4 - consistent architecture
Full size table
Table 4. Level 5 - quantified and improved architecture
Full size table

Table 4 describes the Consistent Architecture, based on Conceptual model of an architecture framework, and Conceptual model of an architecture description language of ISO/IEC/IEEE 42010:2011.

4 ArchCaMo Processes for Each Level

For each level, at least one architectural process is defined. These processes are performed mostly by the architect, or team of software architects that are responsible for the software product.

First of all, we suppose that not all organizations have a defined process for defining, structuring, and evaluating their software architecture. Even though some organizations that have a defined process may not fulfill all the KAI’s, it does not mean that their architectural processes and products are irrelevant or insufficient.

4.1 Level 2 - Minimum Architecture

  • \(\bullet \) P2.1 - Environment is identified. There are many environments, not only the place where the team is coding, but also, for instance, operational environment, development environment, test environment, and so on. Additionally, when defining the environment, this will generate non-functional requirements, and establish rules for the system.

  • \(\bullet \) P2.2 - System-of-Interest is identified. System in which life cycle is under consideration [36]. One way for identifying the system is the environment in which the system is.

  • \(\bullet \) P2.3 - Supplementary information is identified. This material shall be specified by the organization or project, which may include: date of issue and status; authors, reviewers, approving authority, or issuing organization; change history; summary; scope; context; glossary; version control information; configuration management information and references [22].

  • \(\bullet \) P2.4 - Stakeholders are identified. Each stakeholder is defined and ranked for their relative importance for that specific software product. In consonance with [22], these stakeholders shall be considered, and when applicable, identified in the architecture description: users of the system, operators of the system, acquirers of the system, owners of the system, suppliers of the system, developers of the system, builders of the system and maintainers of the system.

  • \(\bullet \) P2.5 - Concerns for each Stakeholder are identified. For each stakeholder, its relative concerns are identified. In the ISO/IEC/IEEE 42010:2011 documentation, one can find some concerns that should be identified when applicable.

  • \(\bullet \) P2.6 - Viewpoints are defined. Through interpretation from architectures views it is established the viewpoints which will frame specific established concerns.

  • \(\bullet \) P2.7 - Multiple Views are defined. Each one of the multiple Views for describing the software architecture is defined to address the concerns held by one or more of its stakeholders.

  • \(\bullet \) P2.8 - Models are defined. From each viewpoint, models are defined using modelling conventions established by the architecture team, appropriate to the concerns to be addressed. Models are used to answer questions about the system-of-interest.

4.2 Level 3 - Defined Architecture

  • \(\bullet \) P3.1 - Correspondence rules are identified. These correspondences are used for indicating relations between two or more architecture models, and the rules are used to establish constraints on two or more architecture models.

  • \(\bullet \) P3.2 - Rationales for decisions are identified. Rationales are written in a list, and the reasons regarding each decision are documented for future reference.

  • \(\bullet \) P3.3 - Concerns related to each decision are defined.

  • \(\bullet \) P3.4 - Decisions are managed. Each decision is identified and written using a template defined by the architecture team. All decisions are identified, discussed, and written. At least a spreadsheet is used, but it is better to use a specific software system to keep track of each entry.

4.3 Level 4 - Improved Architecture

  • \(\bullet \) P4.1 - Known inconsistencies are recorded. An architecture description should record the inconsistencies, and include an analysis of consistency of its architecture models and its views [22].

  • \(\bullet \) P4.2 - Use of Architecture Frameworks. If the project is using an Architecture Framework, it should include conditions of applicability [22].

  • \(\bullet \) P4.3 - Use of Architecture Description Languages. The architecture description language should support all the aspects of the system-of-interest [22].

4.4 Level 5 - Quantified and Evaluated Architecture

  • \(\bullet \) P5.1 - Metrics on elements of the other levels are defined. The software architect evaluates costs and benefits from the metrics, comparing to the other architectures that used ArchCaMo. For each architectural decisions, the architect analyzes the implications, extracting a number of metrics from it.

  • \(\bullet \) P5.2 - An Architecture Group is established, which is responsible to get information of the state of the art on software architecture. The group seeks to improve the architecture by receiving input from many sources, including research conferences on software architecture, books, articles and reports. The Architecture Group is also responsible for searching for improvements, as for instance, new methods, techniques, languages, processes, and so on, on the theme of software architecture, and try to bring these approaches to be deployed in the organization.

Table 5. ArchCaMO application level 2 in an example
Full size table

5 Application of ArchCaMo in a Research Paper

This section describes an application of ArchCaMo in a software architecture proposed in an academic research paper. The paper [37] is a work in progress towards the specification of a conceptual architecture of a smart system, for supporting the management of disruptions in the manufacturing domain. Moreover, the work describes system architecture based on a number of interrelated viewpoints according to ISO/IEC/IEEE 42010:2011.

In this example, displayed in Table 5, we read the research paper looking for any characteristic of the architecture description that follows the maturity model. After all analysis, we found that the description of the system architecture fits in Level 2, the Minimum Architecture. This conclusion may be because this is a short paper, or even it is a work in progress.

The authors did not find evidences for any one of the processes of Level 3, Level 4 or Level 5. Even if one of the KAI of any upper Level is fulfilled, the architecture would still be classified at Level 2.

This paper was chosen among 19 relevant papers found in a Systematic Mapping Study from another research. Even though this is a short paper, this paper was the one with more features following the standard ISO/IEC/IEEE 42010:2011.

6 Conclusion

In this paper, a maturity model for Software Architecture based on the standard ISO/IEC/IEEE 42010:2011, named ArchCaMO, is presented. First, notions about software models and software architecture models are briefly introduced. Then, basic notions of the standard ISO/IEC/IEEE 42010:2011 are presented.

The 5 presented levels of ArchCaMO are based on the described rules of ISO/IEC/IEEE 42010:2011. The initial level, Level 1, considered as unstable, refers to all companies/organizations that do not have a formalized way to define the software architecture. Levels 2 and 3 are made up of most relevant aspects that are necessary to describe a software architecture. Levels 4 and 5 are related to aspects that are needed to improve a software architecture situation in the life cycle that is already structured.

After the levels description, how the levels work through the process is described. To simplify these processes, the authors illustrated with an example, a software architecture published in [37] taken from the literature, showing each aspect of ISO/IEC/IEEE 42010:2011 that they have adopted.

ArchCaMO maturity model evaluates software architectures, providing a direction to the software architecture team of how to manage a description of software architectures from new and legacy systems.

As for future works, our proposal is to evaluate other software architectures in the literature and in companies according to ArchCaMo.