Experiences in System Architecture Evaluation: A Communication View for Architectural Design
03 Jan 2005-Vol. 10, pp 312
TL;DR: This paper claims that such a framework is easy to learn and helps to communicate architectural preferences by using the internal origin, familiar factors, and embedded support for all definitions used in the factor hierarchy.
Abstract: Successful system architecture design requires an understanding of the needs and requirements of a wide range of stakeholders covering the complete system architecture-related life cycle. Communicating with various stakeholders is a highly delicate task and may cause misunderstandings during the translation of functional needs into architectural properties. We developed the Architecture Evaluation Framework (AEF) to improve the design of telecommunication network elements architecture. The various uses of AEF include checking the appropriateness of architecture in relation to business drivers, suitability of external components (COTS, open source), evaluating internal coherence of a product family, or prioritizing development efforts. Furthermore, the AEF is scalable in terms of process phases and framework comprehensiveness. In this paper, we discuss the creation and use of the AEF. The important architectural issues gathered from product life cycle stakeholders form a framework, a hierarchy of architectural factors. We use a bottom-up approach in building the hierarchy. Thus, the selected factors reflect the terminology used among the stakeholders. Based on our experiences, we claim that such a framework is easy to learn and helps to communicate architectural preferences. These benefits are achieved by using the internal origin, familiar factors, and embedded support for all definitions used in the factor hierarchy.
Citations
More filters
26 Jun 2006
TL;DR: A collaborative environment created to support distributed evaluation of a complex system architecture is described and evaluation results from an ongoing, very-large scale application integration project with the United States Marine Corps are reported.
Abstract: In this paper we describe a collaborative environment created to support distributed evaluation of a complex system architecture. The approach couples an interactive architecture browser with collaborative walkthroughs of an evolving architectural representation. The collaborative architecture browser was created to facilitate involvement of project stakeholders from geographically dispersed, heterogeneous organizations. The paper provides a rationale for the approach, describes the system created to facilitate distributed-collaborative architecture evaluation, and reports on evaluation results from an ongoing, very-large scale application integration project with the United States Marine Corps. The paper contributes to research on early architecture requirements engineering, architecture evaluation, and software tools to support distributed-collaborative design.
12 citations
Cites background from "Experiences in System Architecture ..."
...Some reported architecture evaluation cases suggest that these shared representations are the only way to establish a common model and vocabulary for thinking about complex system architectures [34]....
[...]
04 Jan 2006
TL;DR: The attempt is made to identify how the knowledge about properties of complex systems could be utilized for the evaluation of information system architectures, based on the theoretical advances in the field ofcomplex systems.
Abstract: The design and implementation of telecommunication systems is an incremental and iterative process, and system architectures may need to be revised and refined several times during their lifetime. Formal evaluation facilitates the identification of the weak points, where improvements are due in these architectures. In the domain of telecommunications, such evaluation can be based on the Architecture Evaluation Framework (AEF). During the evaluation, a deep understanding of the processes within a system is needed. Meanwhile, the systems being designed are usually complex systems encompassing a large number of components with an intricate pattern of interaction between them. As a result, it is extremely difficult to understand, predict and control the behavior of such systems. Theoretical studies in the field of complex systems describe potential reasons of system complexity, and explain its possible outcomes, as reflected in system structure and behavior. This knowledge may be utilized in architecture evaluation, in order to deepen the understanding of the interactions imposed by the architecture, as well as to extend the understanding of the involved architectural tradeoffs. For this, the complexity factors should be taken into account during the evaluation. However, no such factors are involved in the current version of the AEF. In this paper, the attempt is made to identify how the knowledge about properties of complex systems could be utilized for the evaluation of information system architectures. Based on the theoretical advances in the field of complex systems, a list of the complexity factors to be included in the AEF is compiled. These factors are going to be further refined, as the AEF is employed for evaluating real-world architectures.
7 citations
Cites background or methods from "Experiences in System Architecture ..."
...The Architecture Evaluation Framework [4] is intended for evaluating an architecture from the viewpoint of one or several business drivers....
[...]
...Recently, building on the ideas of ATAM, the Architecture Evaluation Framework (AEF) [4] has been developed....
[...]
...Network part, for example, is decomposed into a number of network elements....
[...]
Book•
17 Oct 2012
TL;DR: An overall numerical quality score that can be used to identify the advantages and disadvantages of a system's design and associated architecture documentation, or to track its quality across discrete evaluation epochs is presented.
Abstract: : This research presents a methodology to evaluate the quality of a system's architecture using principles drawn from Value-Focused Thinking (VFT) and resulting in a Value-Driven Enterprise Architecture Score (VDEA-Score). This is an overall numerical quality score that can be used to identify the advantages and disadvantages of a system's design and associated architecture documentation, or to track its quality across discrete evaluation epochs. This effort determined which aspects of the architecture are most valuable to the stakeholder in the following areas: (1) the system's effectiveness values (quality of the instantiated system being represented and its ability to perform its stated mission), and (2) the architecture's quality values (intrinsic quality of the products themselves in terms of documentation standards and desired attributes). The results are reported across three theses. In this thesis, architecture documentation quality is assessed by examining usability, modifiability, accessibility, and other functions regarded as essential to any architecture. The evaluation methodology was tested against architectures from two enterprises, including the sponsor's enterprise of joint force protection. An overall architecture documentation quality score is reported for both enterprises which may be useful for identifying areas for potential improvement.
4 citations
TL;DR: In this article, the state-of-the-art thermal glue-based temporary fixing system for microrobotics is presented and compared: solutions based on mechanical bending, electromagnetic elements, electrostatic forces, glues, polymers or Van der Waals forces.
2 citations
Cites background from "Experiences in System Architecture ..."
...…micromechanisms (as micromotors (Klocke & Kleindiek Nanotechnologie n.d.), microgears (IMM n.d.)), miniature components (mass spectrometer (Udeshi and Tsui 2005), capsule endoscope (Norika n.d.)) and hybrid and/or 3D MEMS and MOEMS can be fabricated (Lehto and Marttiin 2005)(Weck and Peschke 2003)....
[...]
...)) and hybrid and/or 3D MEMS and MOEMS can be fabricated (Lehto and Marttiin 2005)(Weck and Peschke 2003)....
[...]
Dissertation•
01 Jan 2008
TL;DR: In this paper, a generic framework for context characterization is proposed and evaluated for its usefulness in process design activities, and the analysis method was validated by examining process design case studies within three contexts: large-scale aerospace, industrial process monitoring, and high-technology start-up.
Abstract: Analysis steps are proposed as an aid for establishing Lean Product Development (LPD) activities in an organization. The proposal is offered as an aid to engineering managers and process designers for coping with the unique challenges of implementing processes from their inception for example, at a new enterprise. As such, the thesis focuses on the creation of LPD, as opposed to traditional Lean improvement activities which benefit from the perspective of hindsight of a legacy process. Without established product development processes to improve upon, the implementation of product development activities at a new venture relies on the use of foresight to instance a LPD environment in new organizations. Therefore, the paper stresses stakeholder value delivery within the specific context that an enterprise operates and competes. A generic framework for context characterization is proposed and discussed. The framework is then evaluated for its usefulness in process design activities. The analysis steps are based on literature review and case study interviews. The proposed analysis steps include: * a comprehensive definition of the business context in which the enterprise operates and competes, * a statement of goals and objectives for the product development organization based on this context, and, * a determination of appropriate behaviors to meet these goals. Traditional Lean research has typically been approached from a large-scale, complex systems, for-profit perspective. Unique insights are gained from the perspective of small, privately funded, new ventures. The benefits include foresight-only value objectives for product development (process creation) and uniqueness of context (i.e. resource limited, mindshare-driven). The analysis method was validated by examining process design case studies within three contexts: large-scale aerospace, industrial process monitoring, and high-technology start-up. Thesis Advisor: Ricardo Valerdi
2 citations
Cites background from "Experiences in System Architecture ..."
...Functional and non-functional (Lehto and Marttiin, 2005) viewpoints are selected as appropriate....
[...]
References
More filters
01 Jan 1999
TL;DR: This work proposes a method aimed at finding and assessing the really complicated scenarios, scenarios that impose real risks, and provides a twodimensional framework to structure the process of finding those complicated scenarios.
Abstract: Software architecture analysis methods of flexibility tend to concentrate on averages. Based on the changes incurred by a number of scenarios, the flexibility of the system is assessed. This approach holds the danger that really complex scenarios, scenarios that impose real risks, are overlooked or their effect gets smoothened. We propose a method aimed at finding and assessing the really complicated scenarios. We provide a twodimensional framework to structure the process of finding those complicated scenarios.
30 citations
"Experiences in System Architecture ..." refers background in this paper
...In large organizations, an explicit consensus may never be reached and commitments before actions taken remain unclear....
[...]
01 Oct 1993
TL;DR: A domain-based method for analyzing software architectures called SAAM (Software Architecture Analysis Method) is proposed, illustrated by analyzing user interface architectures with respect to the quality of modifiability.
Abstract: Software architecture is an increasingly important research topic and in this report we investigate the potential role of architecture in evaluating the properties of a system built to a particular architecture. Currently such architectural analysis is complicated for two main reasons: authors of new architectures describe their creations in idiosyncratic terms; and there is no clear way of understanding an architecture with respect to an organization''s life cycle concerns -- efficiency, maintainability, modifiability, and so forth. This report addresses these shortcomings by proposing a domain-based method for analyzing software architectures called SAAM (Software Architecture Analysis Method). This method contains several steps. A canonical functional partitioning for the domain is adopted. Next, some candidate architectures in this domain are described in a common and simple structural language, providing a neutral context in which to understand their similarities and differences. Next, life cycle concerns for the quality of the resultant software are determined and a set of benchmark tasks are created which embody these concerns. Finally, the architectures are evaluated and compared with respect to how well they support the benchmark tasks. This report illustrates the method by analyzing user interface architectures with respect to the quality of modifiability.
17 citations
"Experiences in System Architecture ..." refers background in this paper
...SAAM’s scope has been broadened since this original publication to encompass user interfaces [15]....
[...]
15 Jul 2002
TL;DR: The research goal is to provide early performance evaluation in an effort to convey the most accurate blueprint to system implementers specifically and system stakeholders in general.
Abstract: Architectures embody the requirements expressed by system stakeholders, and the type of architecture used to capture a given set of requirements dictates when evaluation can occur and what will be evaluated. This research aims to leverage requirements and a resulting architecture dictated by the problem domain and captured early in the lifecycle. Thus, the research goal is to provide early performance evaluation in an effort to convey the most accurate blueprint to system implementers specifically and system stakeholders in general. A new software architecture evaluation tool called Arcade, developed to support the Systems Engineering Process Activities (SEPA), automates early performance evaluation of software architectures using simulation. SEPA suggests a comprehensive approach to capture and represent different types of requirements as a multi-level software architecture. One SEPA architecture level, the Domain Reference Architecture (DRA) encompasses performance characteristics inherent to the domain in terms of what processes, data, and timing are required, rather than how a system should be implemented. Performance evaluation of a DRA can provide qualitative data to (1) aid in identification and validation of domain related performance concerns, and (2) provide system implementers with performance guidelines towards satisfying the performance constraints inherent to the domain. The range of performance statistics Arcade is capable of analyzing is demonstrated through a case study of a Motorola e-business project.
8 citations
"Experiences in System Architecture ..." refers methods in this paper
...The System Engineering Process Activities (SEPA) [18] deals with requirements and architecture....
[...]
...The SEPA provides a full methodology and has a wider scope than in our trade-off analysis....
[...]
...The SEPA is a domain reference architecture and it separates and represents requirement types among a set of interrelated types of architecture....
[...]
...The SEPA aims at measuring the performance of the resulting implementation in the early phases of architecture design....
[...]
...However, the SEPA may provide an important target for our future studies....
[...]
01 Jun 1999
TL;DR: An initiative to integrate a CAIV methodology for COTS-intensive combat systems engineering into a collaborative systems engineering environment is described and a pilot effort to implement a common information model within a COTS Product Data Management (PDM) system, CAIV processes, and engineering tools supporting the execution ofCOTS-based combat systems design is described.
Abstract: The Cost as an Independent Variable (CAIV) concept requires establishing aggressive but realistic total system ownership cost objectives and goals very early during system development. A balanced set of goals are identified through cost, schedule, and performance tradeoffs and the management of associated risk. Subsequently, these ownership cost objectives guide the strategic system architecture, design and technology decisions.
The relationships and dependencies between different design views, schedules, and correlating infrastructure need to be rationalized in estimating the system cost of ownership. Furthermore, this has to be done within an environment of continuous flux. This becomes even more of a challenge in a Commercial-Off-The-Shelf (COTS)-intensive open system environment, with development, production, and system supportability being executed concurrently. The team can exploit a number of synergies that result from such a scenario. However, a prerequisite is the ability and infrastructure for timely and reliable information exchange between the disciplines contributing to design decisions. Effective execution of the CAIV methodology is dependent upon strong integration of multi-disciplinary processes, methods, information and domain specific toolsets.
This paper describes an initiative to integrate a CAIV methodology for COTS-intensive combat systems engineering into a collaborative systems engineering environment. A pilot effort to implement a common information model within a COTS Product Data Management (PDM) system, CAIV processes, and engineering tools supporting the execution of COTS-based combat systems design is described. Future extensions to the information model, the systems engineering processes, and the collaborative engineering environment supporting combat systems design, development, and life cycle engineering activities are presented.
8 citations