No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Architecture Decisions: Demystifying Architecture
Abstract
We believe that a key to demystifying architecture products lies in the architecture decisions concept. We can make the architecture more transparent and clarify its rationale for all stakeholders by explicitly documenting major architecture decisions.
... The use of a standard template to document the instructional dilemmas is inspired by the framework used to document architectural decisions [10]. ...
... Secondly, one of the most recent approaches defines software architecture as a set of hard decisions made during the initial stages of development that affect quality attributes or externally visible properties. These decisions are usually referred to as architectural decisions and difficult to change in the later stages of development-for example, decisions concerning the choice of technological platforms or choice of architecture style [10]. This definition highlights that software architecture is a decision making process. ...
... Similarly, the Service-Oriented-Architecture (SOA) and Micro-services are two technologies to implement componentoriented distributed applications. These implementation dilemmas are best examples to explain the significance of architectural decisions and documentation framework for architectural decisions as defined in [10]. ...
An instructor teaching a course on Software Architecture needs to be more reflective to engage students productively in the learning activities. In this reflective essay, the author identifies a few decisive moments referred to as instructional dilemmas at which a teacher reflects upon choices and their consequences so that meaningful learning happens. These situations are referred to as dilemmas because they offer two options to instructors. Some of these dilemmas arise from the inherent nature of Software Architecture as a discipline, while the source of others is the background knowledge of learners. The paper suggests a set of principles and small-teaching methods to make teaching and learning more effective in such situations.
... For instance, developers explore the current decision problem, alternatives for solving the problem, rationales justifying their choice, and additional information on the decision context, such as constraints for the decision [Tyree and Akerman 2005]. These parts of decision knowledge are called decision knowledge elements (abbreviated as knowledge elements). ...
... These approaches consider decisions and results of other development activities mainly by providing relations between them. For instance, links are provided for connecting design decisions with related requirements [Jansen and Bosch 2005;Capilla, Nava, Pérez, et al. 2006;Tang, Jin, and Han 2007] or code files Burge and Brown 2008], or specific textual attributes are given to describe related knowledge [Tyree and Akerman 2005;. In addition, a few approaches also focus on decision documentation during requirements engineering [Ngo and Ruhe 2005; or implementation [Lougher and Rodden 1993]. ...
... A prominent example is the documentation template of Tyree and Akerman, as it is the foundation for many other documentation approaches for design decisions [Davide Falessi, Cantone, Kazman, et al. 2011]. The template proposes to describe the actual design decision, but also its assumptions, related requirements, and impacts on the design [Tyree and Akerman 2005]. Implementation decisions can be documented typically as structured comments directly within the code [Burge and Brown 2008;Lougher and Rodden 1993] by adding a textual explanation of the decision near the code realizing it. ...
Decision-making is a vital activity during software development. Decisions made during requirements engineering, software design, and implementation guide the development process. In order to make decisions, developers may apply different strategies. For instance, they can search for alternatives and evaluate them according to given criteria, or they may rely on their personal experience and heuristics to make single solution claims. Thereby, knowledge emerges during the process of decision making, as the content, outcome, and context of decisions are explored by developers. For instance, different solution options may be considered to address a given decision problem. In particular, such knowledge is growing rapidly, when multiple developers are involved. Therefore, it should be documented to make decisions comprehensible in the future. However, this documentation is often not performed by developers in practice. First, developers need to find and use a documentation approach, which provides support for the decision making strategies applied for the decision to be documented. Thus, documentation approaches are required to support multiple strategies. Second, due to the collaborative nature of the decision making process during one or more development activities, decision knowledge needs to be captured and structured according to one integrated model, which can be applied during all these development activities. This thesis uncovers two important reasons, why the aforementioned requirements are currently not fulfilled sufficiently. First, it is investigated, which decision making strategies can be identified in the documentation of decisions within issue tickets from the Firefox project. Interestingly, most documented decision knowledge originates from naturalistic decision making, whereas most current documentation approaches structure the captured knowledge according to rational decision making strategies. Second, most decision documentation approaches focus on one development activity, so that for instance decision documentation during requirements engineering and implementation are not supported within the same documentation model. The main contribution of this thesis is a documentation model for decision knowledge, which addresses these two findings. In detail, the documentation model supports the documentation of decision knowledge resulting from both naturalistic and rational decision making strategies, and integrates this knowledge within flexible documentation structures. Also, it is suitable for capturing decision knowledge during the three development activities of requirements engineering, design, and implementation. Furthermore, a tool support is presented for the model, which allows developers to integrate decision capturing and documentation in their activities using the Eclipse IDE.
... It is stressed in literature that design decisions should be documented continuously during the project, preferably immediately after making decisions [10], [29], [30]. As Lee & Kruchten [31], Weinreich et al. [32], Tyree & Akerman [33] and Babar et al. [34] point out, immediate documentation is required to prevent the loss of information and knowledge. In addition, this documentation should then be evaluated and reviewed periodically [13]. ...
... There should be immediate documentation of design decisions, rationale, interrelations and context which should be ensured by periodical monitoring [10], [29], [30], [31], [32], [33], [34], [35] There should be an assessment of all available documentation performed at the start of a new project phase [2] Where There should be a documentation environment in which the user should document in a pre-defined template [2], [4], [6]. [10], [35], [37], [38] There should be good accessibility of the documentation for all involved project parties [2], [4], [35], [37] How There should be a visualization of the design decisions and interrelations in their context [6], [10], [27], [37], [41], [44] ...
In most design projects, the documentation of design decisions is considered important. Among others, documentation of design decisions contributes to the traceability of decisions that shape a project’s development process, helps deal with changes in the project and prevents the recurrence of old discussions. Yet, little attention is given to documenting design decisions in the engineering literature. In this study, a theoretical framework for the key elements of this documentation process was developed. Four infrastructure projects were studied and compared to this framework by means of pattern matching. This method compares theoretical and empirical patterns and determines whether they match or do not match. The findings demonstrate that accessibility of documentation for all involved project parties and the division of documentation tasks are in accordance with the literature. However, the documentation of design decisions and their rationale is not done as completely as is recommended in theory. Literature states that the documentation of interrelations and context of decisions should be described thoroughly, but that is barely done in practice. In addition, the findings show that neither immediate documentation nor periodical monitoring of documentation is applied. Based on these findings, this research proposes a strategy for improving the documentation of design decisions.
... Software architecture is currently perceived as a result of a set of architectural decisions [3], [4], [5]. Architectural decisions can be documented in the form of text records [2], [3], [8], [11] or as diagrammatic models [12], [10]. ...
... Software architecture is currently perceived as a result of a set of architectural decisions [3], [4], [5]. Architectural decisions can be documented in the form of text records [2], [3], [8], [11] or as diagrammatic models [12], [10]. The model of a single architectural decision usually includes a description of the problem, considered architectural solutions to this problem and their characteristics, an indication of the chosen solution, and the rationale for that choice. ...
... During the design process, architects often make many important decisions where they do not consider the complete impact, and may not explicitly document these decisions in relevant artefacts, such as technical documentation like diagrams, architectural views, requirement documents, source code itself, task management tools, code version management systems, unstructured documents like emails, plain text documents, chats, management tools, etc [56]. This can make it difficult to maintain and recover the architecture in the future and can lead to problems identified by A. Jansen et al [23], such as: ...
The definition of architecture is a crucial task in software development, where the architect is responsible for making the right decisions to meet specific functional and quality requirements. These architectural design decisions form the foundation that shapes the arrangement of elements within a system. Unfortunately, these decisions are often poorly documented, implicit in various artifacts, or inadequately updated, leading to negative consequences on the maintainability of a system and resulting in rework and cost overruns. The objective of this systematic mapping study is to comprehend the current state regarding approaches for traceability of architectural design decisions and how these decisions are linked with the different artifacts used in software development. To achieve this, an information extraction protocol is followed, utilizing databases with search strings, inclusion, and exclusion criteria. The findings demonstrate that this knowledge is highly relevant; however, it is rarely explicitly documented. As a result, most works propose diverse approaches to extract this knowledge from existing technical documentation, commonly used tools, and other sources of product and process information. In contrast, it is evident that there is no standard for documenting design decisions, leading each author to present a subjective version of what is important and where to trace these decisions. This suggests that there is still a significant amount of research to be conducted regarding the traceability of these architectural design decisions and their connection with software artifacts. Such research could lead to intriguing new proposals for investigation.
... Design Decisions. The early literature has made great efforts to develop approaches and tools for capturing architecture design decisions explicitly, including formal models (e.g., [40]) and description templates (e.g., [102]). The formal models and description templates have consensus on capturing rationale, constraints, and alternatives of architectural design decisions [86]. ...
Software architecture has been an active research field for nearly four decades, in which previous studies make significant progress such as creating methods and techniques and building tools to support software architecture practice. Despite past efforts, we have little understanding of how practitioners perform software architecture related activities, and what challenges they face. Through interviews with 32 practitioners from 21 organizations across three continents, we identified challenges that practitioners face in software architecture practice during software development and maintenance. We reported on common software architecture activities at software requirements, design, construction and testing, and maintenance stages, as well as corresponding challenges. Our study uncovers that most of these challenges center around management, documentation, tooling and process, and collects recommendations to address these challenges.
... Our analysis also shows that complex ADR templates with many sections (e.g., the template proposed by Tyree and Akerman [15]) play no role for capturing ADDs in GitHub repositories. ...
Architecture decision records (ADRs) have been proposed as a resource-efficient means for capturing architectural design decisions (ADDs), and have received attention not only from researchers but also from practitioners. We conducted a mining software repositories (MSR) study, in which we analyzed the use of ADRs in open source repositories at GitHub. Our results show that the adoption of ADRs is still low, although the number of repositories using ADRs is increasing every year. About 50% of all repositories with ADRs contain just one to five ADRs suggesting that the concept has been tried but not yet definitively adopted. In repositories that use ADRs more systematically, we observed that recording decisions is a team activity conducted by two or more users over a longer period of time. In most repositories the template proposed by Michael Nygrad is used. We, finally, provide an interpretation of the obtained results and discuss open future research challenges by elaborating on implications of the study’s findings as well as on recommendations on how to further increase the adoption of ADRs.
... Expected outcome. The proposed approach is expected to give a set of documented ADDs in an appropriate architectural decision template such as the one proposed in [25]. The documented designs would lead to a solution model as shown in Figure 5 where the decisions are realized in the System Architecture Model. ...
... With the architectural documentation, the rules to be followed to obtain the correct system behavior are determined [14], and effective architectural documentation is one of the key factors in sharing and reusing architectural knowledge [10]. In recent years, many authors have also emphasized the importance of comprehensively documenting architectural decisions in software projects [15] [16] [17] [18]. However, architectural documentation is often overlooked or, as Jansen et al. [13] called, architectural knowledge is documented "after the fact". ...
Context: Software architecture plays a fundamental role in overcoming the challenges of the development process of largescale and complex software systems. The software architecture of a system is the result of an extensive process in which several stakeholders negotiate key requirements, issues, solutions, and as a result of this negotiation, a series of architectural decisions are made.
Objective: For most organizations, it is a requirement to record architectural decisions in order to communicate to stakeholders the results and the logic behind these decision, and at the same time to use them as a source for analysis of different architectural alternatives in future projects. The aim of this survey study is to determine the experiences of the software industry experts with respect to architectural decision-making, the factors that are effective in decision-making, and the technical and social problems they encounter.
Method: Within the scope of this study, an online questionnaire-based survey was conducted with 101 practitioners. The responses were analyzed qualitatively and quantitatively, were evaluated with the use of the content analysis technique, and key contents were obtained by grouping them according to the questions.
Results: Analysis of responses revealed that majority of the participants prefer to document some or all of the architectural decisions taken and to store these documents in web-based collaboration software. Decisions are usually made by teams of two or three; and discussion-based approaches, in which the experts express their thoughts and a final decision is made, are adopted. In the software architecture decision-making process, “major business impact” was chosen as the most challenging situation. Information sharing and keeping track of decisions and decision rationale are areas in need of improvement as identified by most participants.
Conclusion: The findings of the study contribute to the development of an understanding regarding software architecture decision-making practices, the factors that influence the decision-making process, what factors make decision-making challenging and which are critical, the structure of decision-making teams, and the areas that need improvement in the decision-making process. The study confirms that the software architecture decision-making process is challenging and has an important place in the industry.
... consequent) [27]. Many formalisation or metamodels have been proposed since, including Kruchten's seminal 4+1 view model [28] and taxonomy [26], and Tyree and Akerman description template [29]. Many other formal models have appeared since (e.g., [1,30,31,32]. ...
A common trend in the software engineering field shows developers are not documenting their design decisions as much as they believe they should be. Part of the reason for this is that developers consider the design decision documentation process to be cumbersome. However documentation of design decisions proves to be a crucial aspect of software maintenance and enhance teams' shared understanding of a product. With the recent emergence of instant messaging in software teams (e.g., Slack, Microsoft Teams), our goal is to leverage their platform coupled to chat bots and natural language processing technologies to record design decisions as they arise. In doing so we place the system for recording design decisions into an environment that is already common place for software teams, dramatically reducing the barriers involved with recording design decisions as a separate task. We therefore propose a general framework composed of a chatbot, a natural language processing engine and exporting API to wikis to record and search design decisions enabling teams to focus on their day-today work with minimal disruptions in their workflow, but still keeping a project documentation up to date.
... The author enumerates a number of semi-formal models used to model software architecture such as block diagrams models [35], the Uni¯ed Modeling Language (UML) [35], the System Modeling Language (SysML) [36] and Archimate [37]. Various models for documenting architectural decisions are also discussed and compared, such as textual models [38], and a comprehensive model by Zimmerman et al. [39]. The early architecture evaluation methods developed for the evaluation of large-scale system architectures at the inception stage of development is also covered. ...
Selecting a framework and documenting the rationale for choosing it is an essential task for system architects. Different framework selection approaches have been proposed in the literature. However, none of these connect frameworks to qualities based on their implemented patterns and tactics. In this paper, we propose a way to semi-automatically compare the quality attributes of frameworks by extracting the patterns and tactics from a framework’s source code and documenting them to connect frameworks to requirements upon which a selection can be made. We use a tool called Archie (a tool used to extract tactics from a Java-based system’s code) to extract the patterns/tactics from the implementation code of frameworks. We then document and model these patterns/tactics and their impact on qualities using the Goal-oriented Requirements Language (GRL). After that, we reuse these models of patterns and tactics to model frameworks in terms of their implemented patterns and tactics. The satisfaction level of the quality requirements integrated with other criteria such as the preferences of an architect provide architects with a tool for comparing different frameworks and documenting their rationale for choosing a framework. As a validation of the approach, we apply it to three realistic case studies with promising results.
... 8. Decision evaluation: using the previously assigned priority, decisions are presented and challenged by the team by identifying some forces against the proposed solution; and participants decide by voting on whether the decision is good enough, acceptable, or must be reconsidered. 9. Retrospectives and reporting: DCAR commands the review team to write an evaluation report within no more than two weeks of the session; reporting is also useful for socializing the decisions [16]. ...
Software architecture evaluations allow systematic checking of software architecture fitness regarding the context and business. However, selecting and using an evaluation method always have some challenges and issues. This article reports an architecture review while developing an innovation projects support platform for a Chilean R&D and engineering institution. We chose DCAR (Decision-Centric Architecture Review) because it has lightweight requirements on documentation and resources, it can evaluate a project already running, and it did not impact a schedule where architecture reviews had not been considered from the start. We describe the review of three accepted and one rejected decisions. Lessons learned and benefits observed include recording decisions’ rationale, visibilization of some technological issues, and rethinking of some previously made architectural decisions. Finally, we recommend making frequent mini-reviews of architecture decisions, to understand the architecture, formalize it with its resulting reports, and raise its visibility in the team itself.
... Software architects define the architecture of the system, maintain the architectural integrity of the system, assess technical risks, perform risk mitigation strategies, participate in project planning, consult with design and implementation teams, and assist product marketing (Kruchten, 1999). Therefore, software architects make high-level design decisions every day (Tyree and Akerman, 2005). Software architects engage in processes of creation, perfection, and destruction on a daily basis. ...
Context
Software architecture is a knowledge-intensive field. One mechanism for storing architecture knowledge is the recognition and description of architectural patterns. Selecting architectural patterns is a challenging task for software architects, as knowledge about these patterns is scattered among a wide range of literature.
Method
We report on a systematic literature review, intending to build a decision model for the architectural pattern selection problem. Moreover, twelve experienced practitioners at software-producing organizations evaluated the usability and usefulness of the extracted knowledge.
Results
An overview is provided of 29 patterns and their effects on 40 quality attributes. Furthermore, we report in which systems the 29 patterns are applied and in which combinations. The practitioners confirmed that architectural knowledge supports software architects with their decision-making process to select a set of patterns for a new problem. We investigate the potential trends among architects to select patterns.
Conclusion
With the knowledge available, architects can more rapidly select and eliminate combinations of patterns to design solutions. Having this knowledge readily available supports software architects in making more efficient and effective design decisions that meet their quality concerns.
... ADDs can be classified into strategic and tactical decisions [35]. To capture such ADDs, "architectural decision description template" was proposed which includes concepts such as Issue, Decision, Assumptions, Constraints, and Related decisions [36]. Another method to capture ADDs is to use mind-maps. ...
Literature review studies are essential and form the foundation for any type of research. They serve as the point of departure for those seeking to understand a research topic, as well as, helps research communities to reflect on the ideas, fundamentals, and approaches that have emerged, been acknowledged, and formed the state-of-the-art. In this paper, we present a semi-systematic literature review of 218 papers published over the last four decades that have contributed to
a better understanding of architectural design decisions (ADDs). These publications cover various related topics including tool support for managing ADDs, human aspects in architectural decision making (ADM), and group decision making. The results of this paper should be treated as a getting-started guide for researchers who are entering the investigation phase of research on ADM. In this paper, the readers will find a brief description of the contributions made by the established research community over the years. Based on those insights, we recommend our readers to explore the publications and the topics in depth.
In the last 15 years, software architecture has emerged as an important software engineering field for managing the development and maintenance of large, software- intensive systems. Software architecture community has developed numerous methods, techniques, and tools to support the architecture process (analysis, design, and review). Historically, most advances in software architecture have been driven by talented people and industrial experience, but there is now a growing need to systematically gather empirical evidence about the advantages or otherwise of tools and methods rather than just rely on promotional anecdotes or rhetoric. The aim of this paper is to promote and facilitate the application of the empirical paradigm to software architecture. To this end, we describe the challenges and lessons learned when assessing software architecture research that used controlled experiments, replications, expert opinion, systematic literature reviews, obser- vational studies, and surveys. Our research will support the emergence of a body of knowledge consisting of the more widely-accepted and well-formed software architecture theories.
Software architecture plays a fundamental role in overcoming the challenges of the development process of large‐scale and complex software systems. The software architecture of a system is the result of an extensive process in which several stakeholders negotiate issues and solutions, and as a result of this negotiation, a series of architectural decisions are made. This survey study aims to determine the experiences of the software industry experts with respect to architectural decision‐making, the factors that are effective in decision‐making, and the technical and social problems they encounter. An online questionnaire‐based survey was conducted with 101 practitioners. The responses were analyzed qualitatively and quantitatively. Analysis of responses revealed that the majority of the participants prefer to document some or all of the architectural decisions taken and to store these documents in web‐based collaboration software. Decisions are usually made by teams of two or three, and discussion‐based approaches (brainstorming and consensus) are adopted. In the software architecture decision‐making process, “major business impact” is the most challenging situation. Information sharing and keeping track of decisions and decision rationale are areas in need of improvement as identified by most participants. From the participants' feedback and their answers to open‐ended questions, we concluded that the software architecture decision‐making process has an important role in the industry. Our key findings are that decisions made in the architectural decision‐making process are taken by teams and generally all decisions are documented. In projects where decisions are made by a single person, peer pressure is found to be significantly different from pressure in projects where decisions are made by the group. This is an indication that as the number of people in the decision‐making process increases, the disagreements also increase.
As society's reliance on software systems escalates over time, so too does the cost of failure of these systems. Meanwhile, the complexity of software systems, as well as of their designs, is also ever‐increasing, influenced by the proliferation of new tools and technologies to address intended societal needs. The traditional response to this complexity in software engineering and software architecture has been to apply rationalistic approaches to software design through methods and tools for capturing design rationale and evaluating various design options against a set of criteria. However, research from other fields demonstrates that intuition may also hold benefits for making complex design decisions. All humans, including software designers, use intuition and rationality in varying combinations. The aim of this article is to provide a comprehensive overview of what is known and unknown from existing research regarding the use and performance consequences of using intuition and rationality in software design decision‐making. To this end, a systematic literature review has been conducted, with an initial sample of 3909 unique publications and a final sample of 26 primary studies. We present an overview of existing research, based on the literature concerning intuition and rationality use in software design decision‐making and propose a research agenda with 14 questions that should encourage researchers to fill identified research gaps. This research agenda emphasizes what should be investigated to be able to develop support for the application of the two cognitive processes in software design decision‐making.
Whenever developers choose among alternative technical approaches, they make a design decision. Collectively, design decisions shape how software implements its requirements and shape non-functional quality attributes such as maintainability, extensibility, and performance. Developers work with design decisions both when identifying, choosing, and documenting alternatives and when later work requires following and understanding previously made design decisions. Design decisions encompass design rationale, describing the alternatives and justification for a design choice, as well as design rules, describing the constraints imposed by specific alternatives. This article summarizes and classifies research on these activities, examining different approaches through which tools may support developers in working with design decisions in code. We focus both on the technical aspects of tools as well as the human aspects of how tools support developers. Our survey identifies goals developers have in working with design decisions throughout the lifecycle of design decisions. We also examine the potential support tools may offer developers in achieving these goals and the challenges in offering better support.
Architecting AI-based systems entails making some decisions that are particular to this type of systems. Therefore, it becomes necessary to gather all necessary knowledge to inform such decisions, and to articulate this knowledge in a form that facilitates knowledge transfer among different AI projects. In this exploratory paper, we first present the main results of a literature survey in the area, and then we propose a preliminary ontology for architectural decision making, which we exemplify using a subset of the papers selected in the literature review. In the discussion, we remark on the variety of decision types and system contexts, highlighting the need to further investigate the current state of research and practice in this area. Besides, we summarize our plans to move along this research area by widening the literature review and incorporating more AI-related concepts to this first version of the ontology.KeywordsAI-based systemsSoftware architectureArchitectural decisionsOntologiesQuality attributesArchitectural ViewsUML class diagrams
Software architecture has long sought the attention of agile developers, but its love is unrequited. For decades, architects have offered up gifts to agile teams. In response, agile developers have responded with little more than a raised eyebrow. As a result, teams that blend architecture principles and agile practices are rare.
Communicating the rationale behind decisions is essential for the success of software engineering projects. In particular, understanding the rationale of code commits is an important and often difficult task. Although the software engineering community recognizes rationale need and importance, there is a lack of in-depth study of rationale for commits. To bridge this gap, we apply a mixed-methods approach, interviewing software developers and distributing two surveys, to study their perspective of rationale for code commits. We found that software developers need to investigate code commits to understand their rationale when working on diverse tasks. We also found that developers decompose the rationale of code commits into 15 components, each is differently needed, found, and recorded. Furthermore, we explored software developers’ experiences with rationale need, finding, and recording. We discovered factors leading software developers to give up their search for rationale of code commits. Our findings provide a better understanding of the need for rationale of code commits. In light of our findings, we discuss and present our vision about rationale of code commits practitioners’ documentation, tools support, and documentation automation. In addition, we discuss the benefits of analyses that could arise from good documentation of rationale for code commits.
Context
With an increase in Agile, Lean, and DevOps software methodologies over the last years (collectively referred to as Continuous Software Development (CSD)), we have observed that documentation is often poor.
Objective
This work aims at collecting studies on documentation challenges, documentation practices, and tools that can support documentation in CSD.
Method
A systematic mapping study was conducted to identify and analyze research on documentation in CSD, covering publications between 2001 and 2019.
Results
A total of 63 studies were selected. We found 40 studies related to documentation practices and challenges, and 23 studies related to tools used in CSD. The challenges include: informal documentation is hard to understand, documentation is considered as waste, productivity is measured by working software only, documentation is out-of-sync with the software and there is a short-term focus. The practices include: non-written and informal communication, the usage of development artifacts for documentation, and the use of architecture frameworks. We also made an inventory of numerous tools that can be used for documentation purposes in CSD. Overall, we recommend the usage of executable documentation, modern tools and technologies to retrieve information and transform it into documentation, and the practice of minimal documentation upfront combined with detailed design for knowledge transfer afterwards.
Conclusion
It is of paramount importance to increase the quantity and quality of documentation in CSD. While this remains challenging, practitioners will benefit from applying the identified practices and tools in order to mitigate the stated challenges.
The architecture of a system captures important design decisions for the system. Over time, changes in a system's implementation may lead to violations of specific design decisions. This problem is common in industry and known as architectural erosion. Since it may have severe consequences on the quality of a system, research has focused on the development of tools and techniques to address the presented problem. As of today, most of the approaches to detect architectural erosion employ static analysis techniques. While these techniques are well-suited for the analysis of static architectures, they reach their limit when it comes to dynamic architectures. Thus, in this paper, we propose an alternative approach based on runtime verification: We describe techniques to formally specify constraints for dynamic architectures and algorithms to translate such specifications to instrumentation code and corresponding monitors. The approach is implemented in Eclipse/EMF, demonstrated through a running example, and evaluated using two case studies.
This introduces the notion of organisational subculture to ACET. During an enterprise transformation, enterprise architects interact with many different stakeholder groups coming from different departments, having different roles, functions and mindsets. We argue that enterprise architects need to pay attention to the existing organisational subcultures to get the different stakeholders on board. In this chapter, we explain that cultural differences have an indirect impact on ACET and that communication is an important intermediary factor. We reflect on potential consequences of ignoring cultural differences in the context of ACET. Finally, we suggest developing a framework to analyse the role of cultural differences in ACET. To this end, we introduce four research questions.
In this we introduce and validate a logic-based framework that serves as the underlying model for Chap. 23 The resulting logic-based framework aims to address some of the challenges identified in Chap. 15
In this chapter, we derive a reference model that provides a holistic perspective on enterprise transformations. The model includes two perspectives: on the one hand, information objects that enterprise architecture management can provide are included; and on the other hand, information requirements that enterprise transformation managers posed during interviews are integrated with those discussed in literature. Both combined perspectives lead to a comprehensive overview of information requirements and objects that are relevant during enterprise transformations.
This chapter introduces an enterprise transformation taking place in the passport issuing and registration office of the Dutch government: adding innovation to the strategic agenda of a purely on maintenance focused organisation. This transformation is divided into three projects: introduction of a formal architecture board, introduction of an innovation department, and introduction of new project types (innovation projects). During the transformation the architecture board faces different challenges linked the institutionalisation of ACET, cultural aspects, and communication defects.
In this chapter, we discuss the key ACET concepts that underpin the other components as discussed in the ensuing chapters.
This chapter introduces a design artefact for value-based componential language engineering, as a response to the research questions defined in Chap. 13 The design artefact consists of two parts: (a) two formal ontologies, representing the stakeholder perspective/language-centric perspective, respectively. These two ontologies can be used to specify catalogues of language fragments, emphasising how these are valuable to stakeholders. (b) A procedural model, inspired by situational method engineering, for creating model bundles from the fragments in the catalogues. We illustrate the artefact with an experiment on combining the modelling languages e³ value, DEMO, and ArchiMate.
In this chapter we report on the case of a globally operating insurance company that has leveraged enterprise architecture management to support business transformations. In order to do so, the company has developed enterprise architecture management capabilities that help the business structuring the business transformation particularly in the early stages before handing over respective responsibilities to more specialized corporate functions later on. This case is interesting for understanding ACET because it is one of the rare cases where enterprise architecture management truly bridges the business–IT gap.
This chapter introduces an overview on the formulation of architecture principles, guidelines for a semi-formal definition and rules for modelling the architecture principles. We give insights on analysis and impact evaluation of aforementioned principles on the design of architecture models and on the implementation of enterprise architecture.
In this chapter, we argue for a component-based approach for the construction of (visual) conceptual models, so that these models are tailored to the context-specific characteristics of a particular enterprise transformation. We offset this component-based approach against (a) “one-size-fits-all” languages, such as the enterprise architecture modelling language ArchiMate, (b) federated languages, whereby languages are related by defining (semi-)formal model transformations, and (c) domain specific language design.
Modern enterprises continue to develop their profile into an even more complex assembly. Reasoned by increasing environmental turbulences and deliberate changes, researchers and practitioners need to acknowledge that addressing transformations of enterprises is a multiplex interplay between different factors. Identifying enterprises as social systems means that the system elements are social individuals and that the essence of an enterprise’s operation lies in the capabilities and interaction between involved social actors. Insights from sociology literature may help to address transformations of enterprises adequately. Rooted in the sociology literature, a framework for the analysis of change is brought forward, involving: origin, type, momentum and trajectory. By enriching those dimensions with concepts from socio-technical literature, a powerful instrument is forged to analyse and address transformations of enterprises.
This chapter highlights the importance of the use perspective for designing ACET and proposes a research agenda that needs to be completed to design ACET from a use-centric perspective. The research agenda consists of four steps (understand user’s behaviour, understand the acceptance of architectural coordination for supporting enterprise transformation, understand the continuous use of architectural coordination for supporting enterprise transformation, and design enterprise architecture/architectural coordination from a use-centric perspective) that are broken down into six research questions.
In this chapter, we discuss the need to support ACET with information on the rationalisation of design decisions. By doing so, enterprise architects can have an enhanced comprehensibility of the existing, as-is, architecture which helps them to better coordinate the enterprise transformation towards the future, to-be, enterprise architecture design.
In this chapter, we introduce our EA Anamnesis meta-model. With this metamodel we allow for (1) contextualising the decision-making process of a single decision in terms of cross-cutting/intertwining decision relationships and (2) a comparison of decision outcomes to the original decision-making process. The resulting framework aims to meet some of the challenges identified in Chap. 15
In this chapter, we derive design principles for architectural models, so that they support communication across different communities of practice by acting as boundary objects. Specifically, we derive design principles for overcoming a semantic knowledge boundary, a boundary that exists when different communities of practice fail to arrive at a shared understanding.
In this we present a reference framework, more specifically a catalogue of capabilities, needed for doing ACET. As such, it also provides guidance on which elements/artefacts of enterprise architecture can be used to support which aspects of enterprise architecture. For architects, it shows where their services might generate value, if requested. For transformation managers, it provides a “capability catalogue”, describing for which parts of enterprise architecture they may seek advice from the enterprise architects. The framework as a whole provides a structure for the solution components that addresses the challenges as presented in Part II, and it comprises of the perspectives of strategy, value and risk, design, implementation, and change. The capabilities of all the perspectives together support transformation management, which is concerned with the management tasks at the overall transformation level, and with the architectural coordination function, which forms an umbrella function of integrating the individual perspectives into a consistent whole.
In this chapter we address the fact that not all ACET problems are equal, and ACET solutions therefore need to be configured to address the specifics of the respective ACET problem. We approach this configuration problem by the means of situational method engineering. We find that the two most important differences of ACET problem situations result from the enterprise architecture management approach used, and the respective type of the transformation. We therefore present classifications for enterprise architecture management and enterprise transformation, and propose an appropriate ACET problem situation matrix. We finally demonstrate how ACET solutions are configured to a given problem situation.
In this chapter, we present an enterprise transformation of the Greek social security system. More specifically, we present the incorporation of a centralised monitoring system for pension payments in Greece. This monitoring system enabled the Greek government to have an overview of the amount of budget that was spent for pension payments across the various social security institutions.
In this chapter, we aim at analysing information requirements and providing an analysis of related dimensions. Thus, an overview of research in the field is provided and dimensions are derived. Furthermore, the management mechanisms related to information processing in terms of the organizational information processing theory during enterprise transformations are described. This leads to an examination, where and how enterprise architecture management could occur in the information processing in organisations.
In this chapter, we look back on the results presented in this book. As mentioned at the start of this book, the field of ACET is rather rich and diverse. As such, this book could only provide a humble beginning towards the creation of a more complete understanding of ACET and the development of an integrated set of instruments supporting ACET in practice. In this chapter, we therefore critically reflect on our experiences with the development of “large-scale” design artefact, such as an integrated method for ACET, as the research programme set out to do.
In this chapter, we elaborate on the critical need to anchor, that is, institutionalise, architectural coordination in organisations in order to make ACET effective and be able to capture value from it. We do so by first explaining the problem, namely to bring ACET into more effective operation among stakeholders. We then review several theoretical lenses that may contribute to a solution of the problem, concluding that institutional theory is a powerful perspective to inspect in detail. The chapter then explains institutional theory foundations and applies them to the ACET context. We close with a roadmap of research questions culminating in a prescriptive, design-oriented solution for institutionalising ACET in organisations.
This chapter introduces an overview on the formulation of architecture principles, guidelines for a semiformal definition, and rules for modelling the architecture principles. As such, we aim to provide answers to the challenges as discussed in Chap. 14 In doing so, we give insights on analysis and impact evaluation of aforementioned architecture principles on the designed architecture models and on the implementation of enterprise architecture. Furthermore, we give directions for future research and summarise possible applications of our method, including managing architectural changes and making informed decisions.
From the Book:For all but the most trivial software systems, you cannot hope to succeed without paying careful attention to its architecture: the way the system is decomposed into constituent parts and the ways those parts interact with each other. Without an architecture that is appropriate for the problem being solved the project will fail. Even with a superb architecture, if it is not well understood and well communicated—in other words, well documented—the project will fail. Not may fail. Will fail.Accordingly, software architecture is at the center of a frenzy of attention these days. A new book about it seems to pop out monthly. In response to industrial need, universities are adding software architecture to their software engineering curricula. It's now common for "software architect" to be a defined position in organizations, and professional practice groups for software architects are emerging. It has been the subject of major international conferences and workshops. The purveyors of the Unified Modeling Language promote their product by calling it "the standard notation for software architecture" (a claim that may say at least as much about the pervasiveness of architecture as about UML). The Software Engineering Institute maintains a bibliography of journal and conference papers about software architecture and its population is approaching 1000.Rather surprisingly, there is a dearth of practical guidance available that is independent of language or notation for how to capture an architecture. To be sure, piles of books exist about how to use a particular language—again, UML comes to mind—but what an architect really needs is guidancein which architecture is a first-class citizen and language is relegated more appropriately to a supporting role.First, let's agree on some basic context. The field has not anointed a single definition of software architecture, and so there are many, but we'll use this one: A software architecture for a system is the structure or structures of the system, which comprise elements, their externally-visible behavior, and the relationships among them. (Adapted from Bass 98.)Much of this book is about the meaning of elements and relationships, but for now we use this definition to emphasize the plurality of structures that exist in architectures. Each structure is characterized by different kinds of elements and relationships, and each structure provides a view of the architecture that imparts a particular kind of understanding.The architecture serves as the blueprint for both the system and the project developing it. It defines the work assignments that must be carried out by design and implementation teams. The architecture is the primary carrier of system qualities such as performance, modifiability, and security, none of which can be achieved without a unifying architectural vision. Architecture is an artifact for early analysis to make sure that the design approach will yield an acceptable system. And architecture holds the key to post-deployment system understand-ing, maintenance, and mining efforts. In short, architecture is the conceptual glue that holds every phase of the project together for all of its many stakeholders.And documenting the architecture is the crowning step to crafting it. The perfect architecture is useless if it has not been expressed understandably. If you go to the trouble of creating a strong architecture, you must go to the trouble of describing it in enough detail, without ambiguity, and organized so that others can quickly find needed information. Otherwise your effort will have been wasted, because the architecture will be unusable.The goal of this book is to help you decide what information about an architecture is important to capture and to provide guidelines and notations (and examples) for capturing it. We intend this book to be a practitioner- oriented guide to the different kinds of information that constitute an architecture. We wanted to give practical guidance for choosing what information should be documented, and show (with examples in various notations, including but not limited to UML) how to describe that information in writing so that others can use it to carry out their architecture-based work: implementation, analysis, recovery, etc. Therefore, we cover: Uses of software architecture documentation. How one documents depends on how one wishes to use the documentation. We lay out possible end goals for architecture documentation, and provide documentation strategies for each. Architectural views. We hold that documenting software architecture is primarily about documenting the relevant views, and then augmenting this information with relevant information that applies across views. The heart of the book is an introduction to the most relevant architectural views, grouped into three major families (which we call viewtypes) along with practical guidance about how to write them down. Examples are included for each. Packaging th information. Once the views have been understood, there is still the problem of choosing the relevant views, including information not contained in a view, and packaging all of the information as a coherent whole. has been created, We give practical advice for all of these facets.The audience for this book includes the people involved in the production and consumption of architectural documentation, which is to say the community of software developers. We believe strongly in the importance of architecture in building successful systems. But no architecture can achieve this if it is not effectively communicated, and documentation is the key to successful communication. We hope we have provided a useful handbook for practitioners in the field.PC—Austin, TexasFB, LB, DG, JI, RL, RN, JS—Pittsburgh, Pennsylvania
Rapid technological change has had an impact on the nature of software. This has led to new exigencies and to demands for software engineering paradigms that pay particular atttention to meeting them. We advocate that such demands can be met, at least in large parts, through the adoption of software engineering processes that are founded on a reflective stance. To this end, we turn our attention to the field of Design Rationale. We analyze and characterize Design Rationale approaches and show that despite surface differences between different approaches, they all tend to be variants of a relatively small set of static and dynamic affinities. We use the synthesis of static and dynamic affinities to develop a generic model for reflective design. The model is nonprescriptive and affects minimally the design process. It is context-independent and is intended to be used as a facilitator in participative design, supporting group communication and deliberation. The potential utility of the model is demonstrated through two examples, one from the world of business design and the other from programming language design
The 4 + 1 View Model describes software architecture using five concurrent views, each of which addresses a specific set of concerns: The logical view describes the design's object model, the process view describes the design's concurrency and synchronization aspects; the physical view describes the mapping of the software onto the hardware and shows the system's distributed aspects, and the development view describes the software's static organization in the development environment. Software designers can organize the description of their architectural decisions around these four views and then illustrate them with a few selected use cases, or scenarios, which constitute a fifth view. The architecture is partially evolved from these scenarios.The 4+1 View Model allows various stakeholders to find what they need in the software architecture. System engineers can approach it first from the physical view, then the process view; end users, customers, and data specialists can approach it from the logical view; and project managers and software-configuration staff members can approach it from the development view.
This paper focusses on how conflicts that arise during a design process and the management of conflicts can be modelled. A number of possible conflict types are distinguished and it is described how each of them can be detected during the design process, using an explicit meta-representation. Furthermore, it is shown how these conflict types can be analyzed and managed by means of strategic meta-knowledge about design processes
Building a product family is a complex task that requires careful management. To be successful in this development one has to be able to satisfy requirements for all the different members of the product family. In order to support this task we present a unified method integrating two different ways to describe software architectures. Our approach supports documenting design rationale in a complete way allowing the design to evolve gracefully. This is achieved by presenting all the design steps in a design decision tree and simultaneously mapping variation of system characteristics in a requirement space. Keywords Software Architecture, Product Family, Requirement Space, Design Decision This work is carried out in the ABACI project. ABACI project is a co-operation project between Helsinki University of Technology and NMP, NRC, NTC and Vaisala. ABACI is supported by Tekes (Technology Development Centre Finland). 1 INTRODUCTION Global marketplace has placed companies in a situation w...
As companies race to transform their businesses into e-businesses, they are discovering that the transformation process is not always straightforward. The IBM Application Framework for e-business (the Framework) is a means for achieving business transformation and a foundation framework for developing and extending e-business processes and applications. This paper describes the Framework, showing it is based on industry standards, including enterprise Java™ technologies, and focuses on enabling complete e-business solutions. It further describes how the system model and application programming model of the Framework and the IBM products that contribute to the platform of the Framework combine to enable a cohesive, prescriptive approach to creating e-business solutions. The paper also shows that the Framework will evolve to support increasingly sophisticated e-business applications, and that IBM is dedicated to working closely with the industry to contribute new technologies to open standards.
This lecture maps the concepts and templates explored in this tutorial with well-known architectural prescriptions, including the 4+1 approach of the Rational Unified Process, the Siemens Four Views approach, and the ANSI/IEEE-1471-2000 recommended best practice for documenting architectures for software-intensive systems. The lecture concludes by re-capping the highlights of the tutorial, and asking for feedback.
Recent work in the area of software architectures is exploring the
use of formal methods for specification and analysis of software
architecture designs. The work is particularly aimed at achieving better
possibilities for evolution, sharing and reuse among software entities.
However, it is believed that specifying architecture components and
connections without revealing their underlying design assumptions
increases the problems with evolution, their reuse and even
interoperability among independently operating components. The paper
reveals some of the issues underlying architectural difficulties and
concludes that implicit design assumptions pose obstacles. We ascertain
that separation of architecture ontology from its design modeling is
necessary and provides enough context to examine the assumptions behind
the central design decisions in architecture abstractions. We propose a
basic architecture ontology that is aimed at providing a formal
reconciliation of architecture design assumptions and discuss its
usefulness to software engineering
The reuse of software can be divided into four categories
according to what is being reused: the reuse of program code, the reuse
of design documents, the reuse of software processes, and the reuse of
software design decisions and their results. In this paper, we regard
software design discussions and their conclusions (i.e., design
decisions and their rationale) as software design knowledge, and we
describe the framework for a system for on-line, real-time recording of
such knowledge and its reuse in software design. We also present an
example that demonstrates the effectiveness of that framework
Architecture and governance bring an element of control that can rub people the wrong way. Architectural decisions should be focused where the payoff is highest to maximize the likelihood of success. The minimalist approach to architecture involves sorting out the highest-priority architectural requirements, and then doing the least you possibly can to achieve them! That is, keep the architecture decision set as small as possible, while ensuring that the technical staff meets key system priorities.
Recommended Practice for Architectural Description of Software-Intensive Systems
- Ieee Std
IEEE Std. 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems,
IEEE, 2000.
Architecting With RM-ODP
- J Putman
J. Putman, Architecting With RM-ODP, Prentice Hall,
2001.
<i>Architecting With RM-ODP,</i>
- J Putman