Article

Architecture Decisions: Demystifying Architecture

Authors:
To read the full-text of this research, you can request a copy directly from the authors.

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.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... 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. ...
Thesis
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.
... 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]. ...
Preprint
Full-text available
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.
... This complicates the tracing of design decisions and rationale at later points, including information about evaluated alternatives and related trade-offs (van der Ven et al. 2011). As suggested by Tyree and Akerman (2005), we also believe that it would be recommended to back up the choice and the rationale with some basic documentation, as well as to revise the design choice with the goals to be attained at later points in time (Alexeeva et al. 2016). As the value of a good technology design is often not externally visible (van Gurp and Bosch 2002), it is tempting to postpone necessary design work. ...
... The decision-making characteristics for the review of design alternatives consists of the 'review approach' and 'review criteria' (Tyree and Akerman 2005). Both of these in our sample were arranged to create little effort, i.e., in the form of desk research, quick prototyping, combined with limited review criteria. ...
Conference Paper
Digital startups offer innovative products, for which they require a suitable technology solution. Choosing an appropriate technology design among the range of available designs is crucial, as the wrong design decision could have disastrous consequences for product development and quality, and waste valuable resources. While the literature has highlighted the role played by the decision context, little is known about 'how' technology design decisions are reached in digital startups. Using an exploratory research design, we investigate how technology design decisions are made in digital startups, and identify decision-making characteristics, consisting of three decision paradigms and seven decision attributes. Our empirical evidence suggests that in addition to the decision context, these decision-making characteristics play an important role in enabling digital startups to reach satisfactory technology design decisions. Our study thus lays the basis for more research on the topic, contributing to knowledge and practice of digital startups.
... Table II summarizes the features of the related studies in artefact traceability management in terms of change detection, CIA, consistency management, change propagation and CI. For instance, Zhang et al. [64], have addressed the change detection and impact analysis with a framework implemented in AspectJ programs and [65] is an architectural level artefact specific work. The workspace awareness tool in [66] has involved all the phases in continuous integration in an event-based approach, but it lacks automation. ...
... ---Architectural decisions change management to demystify architecture [65]. ...
Article
Full-text available
Software development in DevOps practices has become popular with the collaborative intersection between development and operations teams. The notion of DevOps practices drives the software artefacts changes towards continuous integration and continuous delivery pipeline. Subsequently, traceability management is essential to handle frequent changes with rapid software evolution. This study explores the process and approaches to manage traceability ensuring the artefact consistency towards CICD in DevOps practice. We address the key notions in traceability management process including artefact change detection, change impact analysis, consistency management, change propagation and visualization. Consequently, we assess the applicability of existing change impact analysis models in DevOps practice. This study identifies the conceptualization of the traceability management process, explores the state-of-art solutions and suggests possible research directions. This study shows that the lack of support in heterogeneous artefact consistency management with well-defined techniques. Most of the related models are limited with the industry-level applicability in DevOps practice. Accordingly, there is inadequate tool support to manage traceability between heterogeneous artefacts. This study identifies the challenges in managing software artefact consistency and suggests possible research directions that can be applied to manage the traceability in the process of software development in DevOps practice.
... 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. ...
... Such decisions taken by architects and developers, in turn, result in the architecture of the software system. Hence, over the last decade, with the representation of Architectural Design Decision (ADD) as a first-class 1. Introduction entity [18][19][20], there has been a paradigm shift in how we view software architecture. Today, software architecture is considered as a set of architectural design and ADDs [3,21]. ...
... And, the other two projects are closed-source projects from the industry partner. As shown in Table 6 5. Open-source projects: Measure the precision at 5,10,15,20,25,30,and max. The precision at 5 (P@5) indicates if an individual who actually resolved the design decision belongs to the top 5 results in the list of recommended experts. ...
Thesis
Full-text available
https://mediatum.ub.tum.de/?id=1521926 ---------------------------------------------------------------------- Over the last decade, there has been a paradigm shift in the way researchers and practitioners view software architectures. Today, a software architecture is not only seen as a blueprint but instead is considered as a set of design decisions that leads to the blueprint of the underlying software system. Architects and developers regularly make design decisions, for instance, concerning the selection of an architectural style, design pattern, and also the underlying IT infrastructure. Documenting such decisions especially in large projects is beneficial to answer questions such as “What design decisions have already been made?”, “Which architectural elements and quality attributes are affected by a decision?”, “Who should be involved in making a new decision?”, “Which similar decisions have been made in the past?”, and “What are the alternatives to consider while making a design decision?”. Even though many of the architectural knowledge management (AKM) tools provide means to capture design decisions, we observe that, in practice, those decisions are rarely documented. The reasons for not explicitly capturing design decisions are manifold. These include, but not limited to, the lack of integration of AKM tools in software engineering practice. Second, these AKM tools are considered intrusive since they require architects to manually document decisions which can be tedious and expensive. Contrary to the traditional AKM tools that follow a top-down approach, we propose a bottom-up approach for AK curation and reuse thereof. In the bottom-up approach, design decisions are automatically retrieved from various systems as well as annotated with publicly available knowledge sources. Specifically for understanding design decisions made in the past and for supporting architects in making future decisions, we present the realization of a framework called Amelie - Decision eXplorer (ADeX). The components within the framework first retrieve project-related information from disparate systems and then, automatically identify design decisions within project’s data using machine-learning techniques. Next, by using natural language processing, ADeX annotates architectural elements and quality attributes affected by the extracted decisions. Using the annotations from the previous step, ADeX quantifies the architectural expertise of individuals to recommend experts for addressing new design concerns. And finally, using an ontology-based approach, ADeX suggests alternatives that can be considered during architectural decision-making (ADM). Based on the results of these steps, various viewpoints are generated to support architects answer the aforementioned questions during the ADM process. The qualitative evaluation of ADeX shows that it reduces the effort required for maintaining AK and provides stakeholders with a retrospective view of design decisions in large software projects. Furthermore, the components within the framework have been quantitatively evaluated using datasets both from open-source and industrial projects. Based on those datasets, we found that decisions can be automatically extracted from issues with an accuracy of 91%, architectural elements can be annotated with an accuracy of 84%, and with an accuracy of 79% experts can be recommended to address new design concerns. Finally, ADeX, which has been realized over the last four years is currently being used by our industry partner to highlight its benefits to the business units under an initiative called AI4AM. Such a setup provides us the necessary platform to further investigate related challenges of ADM including the aspects of biases and uncertainties in decision making.
... The first question aims at investigating the architecture's evolution from a qualitative perspective. An architecture is the set of main design decisions [69], [70]. Therefore, we study architecture evolution by identifying the major design decisions that were introduced along a number of the most significant releases (see Section 4). ...
... naming conventions. Every design decision is accompanied by a rationale, which is the most important section in decision documentation [70]. The second question looks also at the evolution of the Unix architecture, but from a quantitative point of view. ...
Article
Full-text available
Unix has evolved for almost five decades, shaping modern operating systems, key software technologies, and development practices. Studying the evolution of this remarkable system from an architectural perspective can provide insights on how to manage the growth of large, complex, and long-lived software systems. Along main Unix releases leading to the FreeBSD lineage we examine core architectural design decisions, the number of features, and code complexity, based on the analysis of source code, reference documentation, and related publications. We report that the growth in size has been uniform, with some notable outliers, while cyclomatic complexity has been religiously safeguarded. A large number of Unix-defining design decisions were implemented right from the very early beginning, with most of them still playing a major role. Unix continues to evolve from an architectural perspective, but the rate of architectural innovation has slowed down over the system's lifetime. Architectural technical debt has accrued in the forms of functionality duplication and unused facilities, but in terms of cyclomatic complexity it is systematically being paid back through what appears to be a self-correcting process. Some unsung architectural forces that shaped Unix are the emphasis on conventions over rigid enforcement, the drive for portability, a sophisticated ecosystem of other operating systems and development organizations, and the emergence of a federated architecture, often through the adoption of third-party subsystems. These findings have led us to form an initial theory on the architecture evolution of large, complex operating system software.
... 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]. ...
Conference Paper
Full-text available
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. ...
Article
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.
... 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. ...
Preprint
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, with the aim of building 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.\newline 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.
... In the Software Architecture community, both the loss of understanding of a software architecture and its alignment to the running code as well as the loss of its rationale has been stressed as major issues [4], [5] and design decisions have been raised as first-class citizens into the practice [6]. However, decision-making does not usually follow a strict process [7], [8] neither design decisions are formally captured [9], despite the number of frameworks dedicated to this purpose [10], [11]. ...
Conference Paper
Full-text available
Software engineering is an intrinsically collaborative activity, especially in the era of Agile Software Development. Many actors are partaking in development activities, such that a common understanding should be reached at numerous stages during the overall development life-cycle. For a few years now, Natural Language Processing techniques have been employed either to extract key information from free-form text or to generate models from the analysis of text in order to ease the sharing of knowledge across all parties. A significant part of these approaches focuses on retrieving lost domain and architectural knowledge through the analysis of documents, issue management systems or other forms of knowledge management systems. However, these post-processing methods are time-consuming by nature since they require to invest significant resources into the validation of the extracted knowledge. In this paper, inspired by collaborative tools, bots and Natural Language extraction approaches, we envision new ways to collaboratively record and document design decisions as they are discussed. These decisions will be documented as they are taken and, for some of them, static or behavioural models may be generated on-the-fly. Such an interactive process will ensure everyone agrees on critical design aspects of the software. We believe development teams will benefit from this approach because manual encoding of design knowledge will be reduced and will not be pushed to a later stage, when not forgotten. Index Terms-agile software development, documentation, model-driven development, natural language processing
... One of the alternatives the organization may consider is commercial off-the-shelf (COTS) software. 94 An employee might describe why she favors purchasing COTS software with the following narrative: ...
Article
Engineering decision making and design requires collaboration between groups from different disciplines, each with different tools, vocabulary, and concerns. Traditional engineering decision‐making tools are generally based on understanding the decision makers’ values, modeling uncertainty with probability, and selecting the alternative that maximizes utility. This rational approach to decision making may not be well understood or used by many stakeholders involved in the engineering design process. Constructing narratives, a basic means of human communication, may aid in engineering communication and comprehension and help with decision making. Narratives represent events by means of a story and usually include characters or agents who cause events and to whom events happen. This paper recommends three methods for how the use of narrative can be applied to the area of engineering decision making. These methods include connecting the decision maker to the analysis, creating narrative simulations for training decision makers, and fostering consensus in problems with multiple stakeholders. An illustrative example of designing a better cookstove for the developing world demonstrates the role that understanding narratives of various stakeholders can play for accomplishing complex systems engineering.
... Approaches using templates for capturing ADDs [47] and are supported by existing meta-models [54] and tools [39,43,45] set the focus on architecture knowledge management. ...
Article
Full-text available
Over the past 10 years software architecture has been perceived as the result of a set of architecture design decisions rather than the elements that form part of the software design. As quality attributes are considered major drivers of the design process to achieve high quality systems, the design decisions that drive the selection and use of specific quality properties and vice versa are closely related. Consequently, quality attributes must play a role for decision making processes and be documented alongside the decisions captured. Consequently, we conduct a systematic literature review to study the importance and impact of the relationships between quality attributes and architecture design decisions and to what extent existing architecture knowledge management methods and tools deal with the decisions that affect the quality of a system. We also report on the challenges and future research paths for architectural knowledge management methods and tools. Our results reveal important explicit relationships between both software artifacts, the role of uncertainty in decision making and empirical studies reporting the use of quality attributes in architecture knowledge management activities.
... 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]. ...
Chapter
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.
... 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". ...
Article
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.
... 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. ...
Article
Full-text available
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.
... Architectural design is a creative process where you design a system organization that will satisfy the functional and non-functional requirements of a system [45]. Several authors argue that architectural decisions are the core of software architectures [46][47][48]. Jansen y Bosch [49] define an architectural design decision as "a description of the set of architectural additions, subtractions and modifications to the software architecture, the rationale, and the design rules, design constraints and additional requirements that (partially) realize one or more requirements on a given architecture". Software architectures have evolved from structural representations to decisions centered design models [50]. ...
Article
Full-text available
The explosive growth of the cloud computing industry in recent years has paying attention to problems related to software services quality. Given that quality models serve as frameworks for quality evaluation, this paper proposes a modeling and simulation framework that measures properties derived from ISO/IEC 25010 quality model as main quality concerns of cloud computing applications. The simulation models are obtained by translating the architectural design to an equivalent functional description that, with aims to obtain the quality evaluation, explores all possible component states. Moreover, the framework automatically builds the simulation models using a set of predefined behaviors as components descriptors. Such models are combined with an experimental frame in a simulation scenario that helps to estimate quality employing the performance of the architectural design. Therefore the simulation process is hidden to software architects, providing an evaluation process able to be executed by any developer without knowledge of discrete-event simulation. Two general architectures are used as case study in order to show how works the modeling and simulation framework.
... 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. ...
Conference Paper
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.
... Similarly, there were some components that were not mentioned in our study and were reported in previous work as part of design rationale. Examples are: design assumptions [18,48,52] and weaknesses [18,48]. ...
Conference Paper
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. We posit that part of such difficulty lies in rationale often being treated as a single piece of information. In this paper, we set to discover the breakdown of components in which developers decompose the rationale of code commits in the context of software maintenance, and to understand their experience with it and with its individual components. For this goal, we apply a mixed-methods approach, interviewing 20 software developers to ask them how they decompose rationale, and surveying an additional 24 developers to understand their experiences needing, finding, and recording those components. We found that developers decompose the rationale of code commits into 15 components, each of which is differently needed, found, and recorded. These components are: goal, need, benefits, constraints, alternatives, selected alternative, dependencies, committer, time, location, modifications, explanation of modifications, validation, maturity stage, and side effects. Our findings provide multiple implications. Educators can now disseminate the multiple dimensions and importance of the rationale of code commits. For practitioners, our decomposition of rationale defines a "common vocabulary" to use when discussing rationale of code commits, which we expect to strengthen the quality of their rationale sharing and documentation process. For researchers, our findings enable techniques for automatically assessing, improving, and generating rationale of code commits to specifically target the components that developers need.
Article
This work presents a design environment that allows building software architecture designs for web applications. The environment is designed to solve some of the main problems identified at architectural level by proposing a set of modules that help to develop quality architectures. Its structure is based on a metamodel of architectural components that identifies a set of elements commonly used in web application architectures. Also, a graphical software tool is built using this model as a support mechanism. Such tool is completed with a verification software module that ensures the correct application of well-known web design patterns.
Article
Software start-ups have become increasingly important to the economy and are a key to innovation. However, these companies face many challenges, such as balancing short-term and future needs with respect to technology, processes, and tools.
Article
In the past decade, we have seen a significant shift in attitudes toward the architect’s role. Many organizations now prefer to allocate the responsibility for major design decisions not to an architect but to teams without a named architect. Sometimes the roles on such teams are identified by such terms as pathfinder, master builder, ninja developer, or steward. Some of these roles appear to be merely euphemisms to avoid the (in some circles, dreaded) A-word, but others represent a genuinely different way of looking at architectural responsibilities. In this article, I will share some insights about this shift. These have been gained by a small group of instructors teaching more than 1,400 architects in dozens of organizations across the globe.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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.
Article
Full-text available
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.
Article
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.
Chapter
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.
Chapter
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
Chapter
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.
Chapter
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.
Chapter
In this chapter, we discuss the key ACET concepts that underpin the other components as discussed in the ensuing chapters.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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.
Chapter
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
Chapter
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.
Chapter
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.
Chapter
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.
Article
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.
Preprint
Full-text available
Many organizations struggle with efficient architecture decision-making approaches. Often, the decision-making approaches are not articulated or understood. This problem is particularly evident in large, globally distributed organizations with multiple large products and systems. The significant architecture decisions of a system are a critical organization knowledge asset, as well as a determinant of success. However, the environment in which decisions get made, recorded, and followed-up on often confounds rather than helps articula-tion and execution of architecture decisions. This paper looks at aspects of architecture decision-making, drawing from an industry-based case study. The data represents findings from a qualitative case study involving a survey and three focus groups across multiple organizations in a global technology company. Architects in this organization are responsible for multiple products and systems, where individual products can include up to 50+ teams. The impact is not just on others in the system; architecture decisions also impact other decisions and other architects. The findings suggest recommendations for organizations to improve how they make and manage architecture decisions. In particular, this paper notes the relevance of group decision-making, decision scope, and social factors such as trust in effective architecture decision-making.
Article
Full-text available
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
Article
Full-text available
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
Article
Full-text available
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.
Article
Full-text available
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
Article
Full-text available
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...
Article
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.
Conference Paper
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.
Conference Paper
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
Conference Paper
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
Article
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&gt
  • J Putman