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 1985
TL;DR: Analytic Hierarchy Process (AHP) as mentioned in this paper is a systematic procedure for representing the elements of any problem hierarchically, which organizes the basic rationality by breaking down a problem into its smaller constituent parts and then guides decision makers through a series of pairwise comparison judgments to express the relative strength or intensity of impact of the elements in the hierarchy.
Abstract: This chapter provides an overview of Analytic Hierarchy Process (AHP), which is a systematic procedure for representing the elements of any problem hierarchically. It organizes the basic rationality by breaking down a problem into its smaller constituent parts and then guides decision makers through a series of pair-wise comparison judgments to express the relative strength or intensity of impact of the elements in the hierarchy. These judgments are then translated to numbers. The AHP includes procedures and principles used to synthesize the many judgments to derive priorities among criteria and subsequently for alternative solutions. It is useful to note that the numbers thus obtained are ratio scale estimates and correspond to so-called hard numbers. Problem solving is a process of setting priorities in steps. One step decides on the most important elements of a problem, another on how best to repair, replace, test, and evaluate the elements, and another on how to implement the solution and measure performance.
16,547 citations
Book•
01 Jan 1979
TL;DR: An apparatus for investigating the course of fast chemical reactions, which are initiated in a liquid chemical system under investigation by an external perturbation, e.g. a steep temperature rise (temperature jump), and an optical system of extremely high aperture which allows a wide variety of types of measurements.
Abstract: An apparatus for investigating the course of fast chemical reactions, which are initiated in a liquid chemical system under investigation by an external perturbation, e.g. a steep temperature rise (temperature jump). The apparatus comprises first and second light paths conveying a probing light beam and a sense light beam, respectively, and an optical system of extremely high aperture which allows a wide variety of types of measurements, including absorption, fluorescense, fluorescense polarization, and the like with a high signal-to-noise ratio even of small sample concentrations.
2,255 citations
"Experiences in System Architecture ..." refers background in this paper
...These benefits are achieved by using the internal origin, familiar factors, and embedded support for all definitions used in the factor hierarchy....
[...]
TL;DR: The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns.
Abstract: The 4+1 View Model organizes a description of a software architecture using five concurrent views, each of which addresses a specific set of concerns. Architects capture their design decisions in four views and use the fifth view to illustrate and validate them. The logical view describes the design's object model when an object-oriented design method is used. To design an application that is very data driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. The process view describes the design's concurrency and synchronization aspects. The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. The development view describes the software's static organization in its development environment. >
2,177 citations
TL;DR: A model of software architecture that consists of three components: elements, form, and rationale is presented, which provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements.
Abstract: The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements --- that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our contributions, and relating our approach to other current work.
2,119 citations
"Experiences in System Architecture ..." refers background in this paper
...These benefits are achieved by using the internal origin, familiar factors, and embedded support for all definitions used in the factor hierarchy....
[...]
01 Jan 1967
TL;DR: Most design activity requires continually making choices, and many of these choices may be more than design decisions; they may also be personal decisions the designer makes about his own future.
Abstract: That kind of intellectual activity which creates a useful whole from its diverse parts may be called the design of a system. Whether the particular activity is the creation of specifications for a major weapon system, the formation of a recommendation to meet a social challenge, or the programming of a computer, the general activity is largely the same. Typically, the objective of a design organization is the creation and assembly of a document containing a coherently structured body of information. We may name this information the system design. It is typically produced for a sponsor who usually desires to carry out some activity guided by the system design. For example, a public official may wish to propose legislation to avert a recurrence of a recent disaster, so he appoints a team to explain the catastrophe. Or a manufacturer needs a new product and designates a product planning activity to specify what should be introduced. The design organization may or may not be involved in the construction of the system it designs. Frequently, in public affairs, there are policies which discourage a group's acting upon its own recommendations, whereas, in private industry, quite the opposite situation often prevails. It seems reasonable to suppose that the knowledge that one will have to carry out one's own recommendations or that this task will fall to others, probably affects some design choices which the individual designer is cailed upon to make. Most design activity requires continually making choices. Many of these choices may be more than design decisions; they may also be personal decisions the designer makes about his own future. As we shall see later, the incentives which exist in a conventional management environment can motivate choices which subvert the intent of the sponsor.!
792 citations
"Experiences in System Architecture ..." refers background in this paper
...These benefits are achieved by using the internal origin, familiar factors, and embedded support for all definitions used in the factor hierarchy....
[...]