State of the Art in Architecture Support. Archimate Deliverable D3.1

Transcription

1 State of the Art in Architecture Support Archimate Deliverable D3.1

2

3 Colophon Title : State of the Art in Architecture Support Date : Version : 1.0 Change : Finalized Project reference: ArchiMate/D3.1 TI reference : TI/RS/2002/114 Company reference : URL : Access permissions : Project Status : Final Editor : Maria-Eugenia Iacob Company : Telematica Instituut (TI) Centrum voor Wiskunde en Informatica (CWI) Ordina Institute for Research and Innovation Author(s) : Maria-Eugenia Iacob (TI) Wolf Huijsen (TI) Diederik van Leeuwen (TI) Hugo ter Doest (TI) Hans Bosma (Ordina) Marcel Vos (Ordina) Juan Guillen Scholten (CWI) Synopsis: This report gives an overview of the state of the art in techniques, tools and methods that support the architect in his daily work which includes designing and analysing architectures, communicating designs to colleagues and management. COPYRIGHT 2002 TELEMATICA INSTITUUT / ARCHIMATE CONSORTIUM PERSONAL USE OF THIS MATERIAL IS PERMITTED. HOWEVER, PERMISSION TO REPRINT/REPUBLISH THIS MATERIAL FOR ADVERTISING OR PROMOTIONAL PURPOSES OR FOR CREATING NEW COLLECTIVE WORKS FOR RESALE OR REDISTRIBUTION TO SERVERS OR LISTS, OR TO REUSE ANY COPYRIGHTED COMPONENT OF THIS WORK IN OTHER WORKS MUST BE OBTAINED FROM OR VIA TELEMATICA INSTITUUT (

4

5 ArchiMate Organisations need to adapt increasingly fast and flexible to changing customer requirements and business goals. This need influences the entire chain of activities of a business, from the organisational structure to the network infrastructure. How can you control the impact of these changes? Architecture may be the answer. The ArchiMate project will develop an integrated architectural approach that describes and visualises the different business domains and their relations. Using these integrated architectures aids stakeholders in assessing the impact of design choices and changes. Architecture is a consistent whole of principles, methods and models that are used in the design and realisation of organisational structure, business processes, information systems, and infrastructure. However, these domains are not approached in an integrated way, which makes it difficult to judge the effects of proposed changes. Every domain speaks its own language, draws its own models, and uses its own techniques and tools. Communication and decision making across domains is seriously impaired. The goal of the ArchiMate project is to provide this integration. By developing an architecture language and visualisation techniques that picture these domains and their relations, ArchiMate will provide the architect with instruments that support and improve the architecture process. Existing and emerging standards will be used or integrated whenever possible. ArchiMate will actively participate in national and international fora and standardisation organisations, to promote the dissemination of project results. The project will deliver a number of results. First of all, we will provide a visual design language with adequate concepts for specifying interrelated architectures, and specific viewpoints for selected stakeholders. This will be accompanied by a collection of best practices and guidelines. Furthermore, ArchiMate will develop techniques that support architects in visualisation and analysis of architectures. Finally, project results will be validated in real-life cases within the participating organisations. To have a real impact on the state of the art in architecture, the ArchiMate project consists of a broad consortium from industry and academia. ArchiMate s business partners are ABN AMRO, Stichting Pensioenfonds ABP, and the Dutch Tax and Customs Administration (Belastingdienst); its knowledge partners are Telematica Instituut, Ordina Institute, Centrum voor Wiskunde en Informatica (CWI), Leiden Institute for Advanced Computer Science (LIACS), and Katholieke Universiteit Nijmegen (KUN). More information on ArchiMate and its results can be obtained from the project manager Marc Lankhorst (Marc.Lankhorst@telin.nl) or from the project website, archimate.telin.nl. ARCHIMATE/D3.1 V

6

7 Table of Contents 1 Introduction Target group Position of this work in ArchiMate Working process How to read this document Organisation of this report 7 2 Methods and Processes Methods Method Survey TOGAF-ADM RSD MEMO RUP Other methods Methods overview Design approaches 20 3 Supporting Tools Microsoft Visio System Architect METIS Testbed Studio Other tools Tool overview 39 4 Analysis and Visualisation Techniques Analysis techniques Scenario Based Analysis Performance analysis Visualisation techniques The use of visual attributes in modelling Techniques 49 ARCHIMATE/D3.1 VII

8

9 Management Summary This report surveys the current state of the art in architecture support. Architecture support is the support for architects in their daily work, which includes designing and analysing architectures, communicating designs to colleagues and management, etc. Although there is a strong emphasis in ArchiMate (and also in this document) on the modelling and visualisation aspects of business architectures, we have also pay attention to software architectures (see for instance the sections about patterns, components and analysis techniques) and to pragmatic aspects related to (business and software) architectures by investigating development methods and processes, design approaches, analysis and visualisation techniques and supporting software tools. Methods, design approaches, tools, and all the techniques are not described in full detail, but their basic role and context are given. The large number of relevant concepts does not leave much space for extensive discussions, but we provide references to more detailed information, both in this document and in our web-based application The ArchiMate Resource Tree (see Section 1.3). We have also refrained ourselves from doing detailed comparisons between the subjects we have surveyed. However, we have tried to digest the major issues and trends from the information we had at our disposal, and to give our opinion on the relevance of these subjects for ArchiMate. Next we will address briefly the main topics that will be later on presented in the rest of the document and highlight our most important findings. Methods and processes In the context of this document, a method (or methodology) is a detailed and structured step-by-step process for transforming the aspiration for the existence of a system architecture into the architecture itself. In practice, methodologies typically specify the order in which the various phases of an architecture development lifecycle are applied, and how each stage is tested. To the interest of ArchiMate are methods aimed at architecture development or domain-specific methodologies that can be applied with a broader scope as well. The following methodologies are worth mentioning here because they cover multiple domains and are the most comprehensive and mature in their descriptions: N The TOGAF Architecture Description Method (ADM) aims at enterprise architecture development and covers several architectural views. Also, it features a lifecycle model that supports the development process from Initiation to Implementation and Maintenance. ADM is independent of modelling languages or tools. However in version 7 of TOGAF-ADM Metis is mentioned as a possible modelling tool. TOGAF-ADM is proprietary, but annual licenses are issued free of charge to any organization using it for internally non-commercial purposes. N Multi Perspective Enterprise Modelling (MEMO) is a method for enterprise modelling that offers a set of specialised visual modelling languages together with a process model as well as techniques and heuristics to support problem specific analysis and design. The languages allow the modeling of various interrelated aspects of an enterprise. MEMO is freely available. ARCHIMATE/D3.1 1

10 Design approaches In the course of time several practices have been proposed not only to speed up and improve the quality of the architecture work, but also to preserve architectural knowledge for the declared purpose of reuse of this knowledge assets. The following are of interest to ArchiMate: Standards Several standards exist (from ISO, CEN, IEEE among others) that standardise the modelling and descriptions of enterprise architectures. The well-known IEEE-1471 standard is the recommended practice for architecture description and already adopted for some of the work in ArchiMate as a principal source of concepts for architecture description like view, viewpoint and stakeholder. Patterns A pattern is an idea that has been useful in one practical context and will probably be useful in others. Pattern techniques are generally acknowledged as valuable architectural design techniques. An architectural pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. The most interesting approaches are the Design Pattern Catalogue of Gamma et al. (software patterns - see Gamma et al. 1994), U.S. Treasury Architecture Development Guidance (TADG) (architectural patterns), and the IBM Patterns for e-business. Components The central idea behind component-based architectures is the composition of software systems from discrete, highly reusable components - units of data, and functionality that can be connected together to produce complete software package. The difference between component-based systems and more conventional software systems (e.g. using function libraries and class frameworks) is that component-based systems allow components to be plugged in at deployment-time, or unplugged and interchanged with other components. This supports user configuration of systems, reusability of components, and a more versatile and potentially robust building block approach to system architectures. Tool support The tool review focuses on tools for modelling and designing systems and architectures. Both domain-specific tools (supporting e.g. process modelling or software modelling) and cross-domain enterprise modelling tools are included. Out of several of tools we have reviewed (the reader can find all our reviews in ART), we mention here the ones we consider the most relevant for ArchiMate, for reasons that we explain below. These tools should be considered for inclusion in the Tool Evaluation (D3.2), while the tool vendors of these tools may become members of the Tool Vendor Forum (D1.2.3). N Metis METIS is a visual modelling tool for enterprise knowledge. METIS can capture and link information in multiple areas of an enterprise, from products to processes, and further on, to systems. With METIS one can view an enterprise as a whole or can focus on the details. Also, the users are allowed to define their own meta-models. This makes METIS a tailorable tool, capable of satisfying various needs. 2 STATE OF THE ART IN ARCHITECTURE SUPPORT

11 N N N N N System Architect System architect supports various modelling domains (and languages) including business process modelling, object-oriented and component modelling with UML, relational data modelling, and structured analysis and design. The underlying metamodel can be changed to some extent. Visio Visio is a powerful drawing and modelling tool at a competitive price when compared to other tools. Visio does not have a metamodel and adding semantics or for analysis will be troublesome. However, Visio is attractive for rapidly prototyping visualisation ideas and a cheap and fast introduction of a new modelling language in a team or organisation. Testbed Testbed Studio is an integrated toolset for the design, analysis, and management of business process models. ArchiMate users of Testbed include de Belastingdienst and ABP (for process modelling). Rose Rose is a UML tool for detailed software design and code generation. Some of the ArchiMate companies already use it and therefore it is a strong candidate for further study in the tool evaluation (ArchiMate/D3.2) and for integration in the tool integration environment (ArchiMate/D3.3.1). Select Component Architect A UML tool for both process an software modelling. In addition, it is advisable to include one or two repository products in the tool evaluation, since storage and retrieval of models and other design artefacts is essential in architecture management. Besides the ASG Rochade repository used by ABP, we recommend to evaluate an XML database in the tool evaluation (ArchiMate/D3.2). Tool Vendor ArchiMate users Limitations Why is it relevant for ArchiMate? Metis Computas - - Supports cross-domain enterprise modelling. Has an adaptable metamodel. System architect Popkin ABP - Supports cross-domain enterprise modelling. Metamodel can be changed to some extent. Visio Microsoft ABN-AMRO Belastingdienst Testbed BizzDesign ABP Belastingdienst Rose Rational ABN-AMRO Belastingdienst Select Component Architect (Select Enterprise) Visio has no underlying metamodel. It is a drawing tool. Adding semantics is difficult. Domain-specific (BPR) Domain-specific (detailed software design) It is easy to create your own modelling language (prototyping, cases). Low cost. Powerful metamodel. Large tool vendor that is of interest for the TVF initiative. Limited to UML Aonix ABN-AMRO Limited to UML Large tool vendor that is of interest for the TVF initiative. Table 1 Overview of modelling tools relevant for ArchiMate ARCHIMATE/D3.1 3

12 Analysis techniques In an architecture development/change process there are at least two moments when the usage of analysis techniques is required. In the early stages of the architecture development process, the primary goal is to formulate a model of the problem domain. To this purpose, techniques such as use cases and scenario based analysis are the most appropriate. In this respect, ArchiMate might benefit from a methodology for the definition of SMART Business Scenarios proposed by TOGAF (see section 3). Secondly, analysis can be used in a more advanced stage of architectural development. Namely we refer to means to evaluate how well the implemented/designed architecture meets the initial requirements using a number of quality attributes like: robustness, completeness, granularity, minimality, efficiency and effectiveness, perspicuity, precision/granularity, consistency, dependency, adaptability, modifiability, etc. Typical analysis techniques are simulation, performance analysis, quantitative and qualitative analysis. An overview of such techniques is provided in section However, in practice, there is no clear separation between the two types of techniques. It might very well happen that combinations of both types are used, or that the very same technique is used for different purposes at different moments of the development process. The best example that supports this statement is the family of analysis techniques SAAM, ATAM and ARID (developed by Kazman, Klein, Clemens et al., see section 3), that use scenarios for the assessment of various quality attributes. Visualisation techniques Since one of the main concerns of ArchiMate is related to the visualisation of architectures, we have considered that a presentation of the role of visualisation techniques in the graphical appearance of models would be also appropriate. There are three main areas of concern when discussing architecture visualisation: 1. First, there is the readability of architecture diagrams. This is dependent on and significantly influenced (for better or for worse) by the use of visual attributes (such as form of objects, connectors, colours, graphics, layout patterns, etc.) in diagrams (see section 4.2.1). 2. Second, given the variety of content types of architecture reports (various views, types of models, concepts etc.) it is essential to find the right visual expression for each type of architecture report by using the right graphical notation (standardised or not). It is also important to easily link them and navigate from one to another. With respect to these circle of problems we present (see section 4.2.2) the main principles that govern the 2D and 3D visualisation approaches, several aspects related to dynamic visualisation (animation and simulation) and how these are implemented by some of the surveyed architecture support tools. 3. Third, when designing the visual appearance of architecture models, the various user groups must be taken into account, in the sense that visual representations are adjusted to their understanding, culture and needs. That is why, in section 4.2.2, the multiple perspective visualisation approach taken by the DIVA project is presented. 4 STATE OF THE ART IN ARCHITECTURE SUPPORT

13 1 Introduction By architecture support we mean the support for the architect in his daily work, which includes designing architectures, making analyses, communicating designs to colleagues and management, etc. Although there is a strong emphasis in ArchiMate on the modelling and visualisation aspects of architecture, we also pay attention to the pragmatic aspects of architecture by investigating developments methods and processes for architecture, software and business processes. In addition, there is an explicit focus on analysis and visualisation techniques. 1.1 Target group This state of the art is written for domain architects, enterprise architects, project managers of projects that use and create architecture, and for their managers (senior management). Nevertheless, this report is also useful for the researchers that work in Archimate. The primary goal of this report is to inform all ArchiMate participants about the current state of the art in support for the architect including tool support and methods and processes for architecture development. Readers will understand what architecture support exists to date, and which of these are relevant for ArchiMate. 1.2 Position of this work in ArchiMate Architectures are often complex and hard to understand. Architects therefore need ways to express these architectures as clearly as possible, both for their own understanding and for communication with other stakeholders. To date, there is no standard language for describing architectures, and they are often described in informal pictures that lack a welldefined meaning. This leads to misunderstandings, and makes it very difficult to provide tools for visualisation and analysis of these architectures. Fundamental to developing a suitable architecture language paired with appropriate visualisation and analysis techniques is an understanding of the working process of the architect as follows. Figure 1 illustrates how initial ideas are formulated and communicated in an informal manner, for instance by drawing on a whiteboard or sketching on paper or writing a short memo. As soon as ideas become more stable and more people are involved in the development process, a more formal and rigorous language is needed to capture the design. To that purpose, a formal language like UML or Testbed comes into the picture in most cases supported by a modelling tool. ARCHIMATE/D3.1 5

14 Formal models Analyses Design Communication with stakeholders Whiteboard Powerpoint Idea Gebruik Connection with implementation Management Maintenance Version management Figure 1 Architecture process Figure 2 illustrates the position of models within the scope of the project. Models described in a common ArchiMate language are the basis for different types of visualisation and analysis, which are the primary means for stakeholder communication. Different models and descriptions currently in use by architects, both at the business level and the application level, can be either mapped onto the common language or linked to the ArchiMate models. Architects Stakeholders Visualisation techniques ArchiMate models Analysis techniques Figure 2 Scope of the ArchiMate project On the basis of the ArchiMate language visualisation techniques will be developed in order to provide architects and stakeholders with useful and easy-to-understand and manipulate presentations of their systems. Furthermore, architectures will develop over time, and changes need to be made. The complexity of an architecture makes it difficult to determine the consequences of these changes. To overcome this problem, what-if analysis techniques will be developed that help in assessing the business and technical impact of architectural decisions. This report gives an overview of the current state of the art in architecture support, and as such it is the starting point for the work in ArchiMate on architecture support (work package 3) which includes design and a prototype of a tool integration environment, visualisation techniques and analysis techniques. Furthermore, this report 6 STATE OF THE ART IN ARCHITECTURE SUPPORT

15 N N provides the tool evaluation (D3.2) with a list of tools we recommend for an in-depth technical investigation with regard to integration possibilities. informs Tasks 3.4 Architecture Visualisation and 3.5 Architecture Analysis about current developments and trends in visualisation and analysis. 1.3 Working process The work compiled here is the result of a two-stage process. In the first stage the basic material was gathered and assembled, in the second stage this report was created and supplemented with a management summary and an introduction. The basic material will be made available in a web-based application (called the ArchiMate Resource Tree - ART) combined with the basic material collected for the State of the Art in Architecture Concepts and Descriptions (D2.1). 1.4 How to read this document From the very start, we have to stress that this document (and especially the web-based application the ArchiMate Resource Tree- ART) should be seen more like an architecture encyclopaedia. Our goal was to make available, in very condensed manner, information (and proper references to more detailed information) about a large number of topics that will be beneficial not only for target group of this document, but also for the research work in all the tasks within ArchiMate. Apart from the fact that the topics and the topic-related information were selected to meet the specific needs of ArchiMate (as stated in the project plan), we have also tried to express our opinion about the value and relevance of this information for the project. However, since the number of topics is large, and since many of them are indirectly related, there is a high risk that, while reading this document from the beginning to the end, the reader might miss the continuity of the discourse, and might find some of the subjects more interesting than others. Therefore, we recommend the reader to look at this document as a structured collection of various subjects, and possibly to select only chapters/sections (topics) that he/she finds interesting. In general, each chapter can be read in isolation from the others (this is even more obvious for ART). This also holds for the sections of one particular chapter, but in this case the reading of the introduction of that chapter should precede the reading of any of its sections. 1.5 Organisation of this report This report is organised as follows. The next chapter gives an overview of methods and processes for development of systems and architectures. Chapter 3 reviews a collection of modelling tools that are relevant for ArchiMate; some of them are specific to one domain, others cover multiple domains and allow cross-domain relations and analysis. Chapter 4 surveys analysis and visualisation techniques currently available in tools or known in literature. ARCHIMATE/D3.1 7

16 Analysis Techniques (Ch. 4) supported by applied in Methods Processes (Ch. 2) supported by Supporting Tools (Ch. 3) supported by applied in Visualisation Techniques (Ch. 4) Figure 3 Overview of this report 8 STATE OF THE ART IN ARCHITECTURE SUPPORT

17 2 Methods and Processes This chapter gives an overview of available methods and processes for architecture development. Also, general design approaches like patterns, components and standards are taken into account. 2.1 Methods In the context of this document, a method (or methodology) is defined as a detailed and structured step-by-step process for transforming the aspiration for the existence of a system architecture into the architecture itself. In practice, methodologies typically specify the order in which the various phases of an architecture development lifecycle are applied, and how each stage is tested. Methodologies differ in several respects. First, they may, or may not, specify the detailed techniques, languages or tools to be used in each stage of the lifecycle. Therefore we will refer to the methodologies, which cover the whole lifecycle of an architecture as being complete. The rest will be considered as being partial methodologies. Second, they differ in the degree to which they encourage the repetition of various stages of the lifecycle. Some methodologies strongly emphasize a right first time approach to each stage of development, while others allow for planned repetition. Some methodologies favour continuous involvement of the prospective users of the architecture, while others prefer to get the user involvement only in an early stage. Last but not least, methodologies can differ also with respect to their scope and purpose. The role of current methodologies is to assist the developer through all the phases of the lifecycle of architectures. Although these phases might be named differently or described more or less detailed we can summarise them as follows: N Analysis (requirements) phase: in this phase models of the problem to be solved are created. They cover that part of the real world that is relevant to the future architecture. Functional and nonfunctional requirements, constraints are to be determined and incorporated into these models. The whole activity performed in this phase can be defined as domain analysis and the result of this activity as analysis models of the architecture domain (problem). N Design (construction, modelling) phase: in this phase models of the future solution (architecture) are created. The set of all possible solutions (architectures) is restricted by the functional and nonfunctional requirements. The analysis models of the problem are mapped to models of the solution (architecture) space. The main goal of the design phase is to structure the system under development. This is the phase where the architecture is determined. N Implementation phase: in this phase we get a usable solution (in terms of code) out of the design models, and some of the architecture components will be translated in a code/application module. ARCHIMATE/D3.1

18 N Integration, conformance testing, and evaluation phase: in this phase each code/application module is tested separately in order to ensure its quality. Then the modules are integrated to form the system. The last step is to test the resulted system for conformance with all the initial requirements. The testing activities make use of several conformance analysis techniques. Most of the architecture support tools provide such analysis instruments. Below we propose and define a general set of features that we consider adequate for the synthesis of the most relevant information related to a method. Later on, in Section 2.2 we use them to characterize a number of development methodologies that are currently used in the field of (enterprise/software) architectures. N Name: Complete name of the method and used acronyms. N Ownership/Authorship: This criterion is meant to determine whether the surveyed method is proprietary (supported by commercial tools) or belongs to the public domain. N Statement of scope and purpose: Most of the architectural methodologies are domain-specific, meaning that they were designed for a particular type of architecture (e.g. business architectures, software engineering, artificial intelligence systems, etc.). A class of architectures for the development of which a method can be used is defined as its domain. The statement of purpose describes this domain. The scope of a method is expressed as the architectural view coverage of that method. More precisely, the scope is a description of a number of architectural views that will be delivered using that method. For the purpose of this document we will judge the scope of each method by the means of the following coverage map (the figure is a hypothetical example): Data Function Organisation Process Network Business (conceptual) layer System (logical) layer Technological (physical) layer N N not covered less covered well covered Type: This criterion is meant to determine whether the surveyed method is complete (i.e. covers the whole lifecycle of an architecture) or partial. Lifecycle Model: Methodologies eventually specify a road to follow trough the entire lifecycle of an architecture. The sequence of steps to be completed has a number of characteristics like loops, repetition of certain steps, spiral iterations of the whole sequence or of parts of it. These characteristics define the lifecycle model of a method. A formal definition of a lifecycle model can be: a prescriptive model of the activities in developing a system /architecture from concept to its end-of-life. The most popular models are: Waterfall: A system (architecture) lifecycle model, described by Royce (1970), in which development is supposed to proceed linearly/sequentially through the phases of requirements analysis, design, implementation, testing (validation), integration and maintenance. Spiral: A system lifecycle model (Boehm 1986), which supposes incremental development. It uses the waterfall model for each step, with the aim of managing risk. In the spiral model, developers define and implement features in order of decreasing priority. According to this model the developers should only define and implement the highest priority features. Then feedback will be asked from users/customers and a new iteration will start. 2 STATE OF THE ART IN ARCHITECTURE SUPPORT

19 N N N N Rapid prototype development: Prototyping moves the developer and customer towards a "quick" implementation. Prototyping begins with requirements gathering. Then, the developer defines a quick design and builds a working model (the "prototype") of some element(s) of the system. The customer or user "test drives" the prototype, evaluate its functions and recommend changes to better meet his needs. Iteration occurs as this process is repeated, until an acceptable model is derived. Incremental model: This model is a combination of ideas from the linear process model (waterfall) and prototyping, and consists out of a series of linear (waterfall) sequences. Each linear sequence produces a deliverable increment on previous delivery. Unlike prototyping, each delivery in the incremental model is an operational system. Although it might appear that the spiral model and the incremental model are the same, they are not. While in the spiral model each linear sequence (iteration) starts after the previous one was completed, in the incremental model the several linear sequences (the increments) can overlap in time, and therefore evolve in paralel. Architectural Framework: Most of the surveyed methods are globally and generically describing an architecture by showing its structure, in terms of views, domains, components, perspectives, units, layers, tiers, etc., and the relationships/dependencies between them. We will call this structure the Architectural Framework. Domain Analyses: A critical step which must take place before an architecture can be designed is to perform analyses of the architecture target domain and to reveal its essential characteristics. These analyses are called domain analyses. Different frameworks suggest different forms of domain analysis. Functional analysis, information analysis, and dynamic/behavioral analysis are commonly used forms of domain analysis. Other types of domain analyses we found in the literature are resource analysis (CIM-OSA), organizational (actor/role) analysis (RSD, Periorelis, Bokma 1998), decisional analysis (GRAI), requirements/constraints analysis etc. Architectural Specifications/Design: An architectural specification is a prescription of the overall structure of the future system. This consists of a set of abstract models (called architectural specifications) of the overall structures and their relations and interactions. They capture all the functional and non-functional requirements: they describe which parts are distributed, which are concurrent, which are to be persistent, what is the topology of the system etc. Models are built for each of the views for which a domain analysis was completed and they show the usage of the system, not only the understanding of it. Method for Architectural Implementation: This usually consists of a set of procedures for refining and implementing an architecture. The architectural elements become expressed in the programming language. Given the existence of architecture description languages we may have a separate description of the architectural elements and have an integrated program and/or an architecture compiler do the integration job (in the integration, conformance testing, and evaluation phase). Such a method might refer to elements as (Nowak 1999): program: A description of the system in an object-oriented programming language. We used the term program for any collection of source code, i.e., a program can also be a set of related programs; (run-time) component: a reusable, programmatic building block that contains code for performing a task or set of tasks. Components can be combined with other components (even across networks) to create an application. ARCHIMATE/D3.1

20 N software domain (at the programming level): Descriptions of software. The notation used is a programming language. Complete descriptions form the programs of applications, whereas partial descriptions form the program-fragments that make up class libraries and object-oriented frameworks. physical platform: The platform on which the system is going to be executed at the physical level - i.e. in terms of for example operating systems, graphical user interface systems, file systems, computer networks, dedicated hardware devices etc. organisation: the hierarchy of people which are going to use the new architecture, and their access/usage privileges. processes: the new or changed processes that can be deployed due to the new architecture. Such a method also defines a procedure for the implementation process possibly including iterative cycles, in which the program is constructed from the architecture models/specifications under the influence of relevant non-functional requirements and the physical platform. The result of the architecture implementation is on a second level of abstraction, an instantiation of the architectural specification. Conformance Analysis: A conformance analysis is a procedure/method that determines if the requirements (quality attributes, constraints and other functional requirements) that were identified in the analysis phase have been met (e.g. capacity, workload and performance tests, consistency, completeness, complexity, robustness, and adaptability, safety, ambiguity, duplication, and compliance with standards checking, etc). 2.2 Method Survey In this section we discuss the following methodologies: TOGAF-ADM, RSD, MEMO, RUP, ARIS, PERA, CIMOSA, GRAI, and GERAM. The presentation of the first four in this list is organized according to the set of criteria defined in Section 2.1. For the remaining methodologies one can find in brief descriptions. Detailed information for all these methodologies and a number of others (Catalysis, ABD, XP, RAD&DSDM) the reader can find in ART. Also, in Section we give summary method overview (in the form of Table 2) TOGAF-ADM Name: TOGAF (The Open Group Architectural Framework) Architecture Description Method ( Ownership/Authorship: Proprietary. Developed by TOGAF. The original development of TOGAF Version 1 in 1995 was based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense. The DoD gave The Open Group explicit permission and encouragement to create TOGAF by building on the TAFIM. The Open Group's Architecture Forum have developed successive versions of TOGAF each year and published each one on The Open Group's public web site (current version 7). For internal/non-commercial use the licence is free of charge. Statement of scope and purpose: The TOGAF Architecture Development Method (ADM) forms the core of TOGAF. It is a reliable, proven method for developing an IT architecture 4 STATE OF THE ART IN ARCHITECTURE SUPPORT

21 that meets the business needs of an organization, utilizing the other elements of TOGAF, and other architectural assets available to the organization. TOGAF-ADM Data Function Organisation Process Network Business (conceptual) layer System (logical) layer Technological (physical) layer Type: Complete. Architectural Framework: See Buuren et al Lifecycle Model: The recommended approach for architecture development is a cyclic (spiral) one of the phases shown in Figure 4. Figure 4. TOGAF-ADM lifecycle model (source: Domain analyses: Key steps in this phase include: N Problem: Identify, document and rank the problem that is driving the project. N Business Architecture: Identify and document the business and technical environment where the problem situation is occurring. N Business Scenarios are a useful technique to discover and document business requirements, as described in Part IV of TOGAF (see Section and N Objectives: Identify and document desired objectives, the results of handling the problems successfully. N Human and Computer Actors: Identify human/computer actors and their place in business/technology model, and their roles. N Roles, Responsibilities and Measures of Success: Identify and document roles, responsibilities and measures of success per actor, the required scripts per actor, and the desired results of handling the situation properly. N Statement of Architecture Work: Document the Statement of Architecture Work. ARCHIMATE/D3.1

22 N Checkpoint: Check the original motivation for the project against the Statement of Architecture Work and Business Architecture, and refine only if necessary. Outputs The deliverables are: the Statement of Architecture Work and the Business Architecture - Version 1. Architectural Specifications/Design: Key steps in design include: N Identify existing technology in a brainstorming session specifically set-up to identify reusable assets. N Brainstorm candidate architecture building blocks in a discovery session and document. N Deliverable: Business Architecture - Version 2 N Considering a number of architectural viewpoints to ensure that all stakeholder concerns in the required system are considered N Selecting a high-level model for the architecture N Establishing a set of criteria for service selection N Selecting the services required N Validating that business goals are met N Defining the architecture in detail; and N Conducting a gap analysis to identify any missing functionality. N Deliverables: Technical Architecture - Version 1 Method for Architectural Implementation: Key steps for implementation include: N The project recommendation formulation, that for each separate implementation project has to: document scope of individual project in Impact Analysis, document strategic requirements (from the architectural perspective) in Impact Analysis, document change requests (such as support for a standard interface) in Impact Analysis, document rules for conformance in Impact Analysis, document time-line requirements from road-map in Impact Analysis, Document Architecture Contract, obtain signature from all developing organizations and sponsoring organization N Main deliverables: Impact Analysis (Implementation recommendations) Architecture Contract. The implemented system: the implemented system is actually an output of the development process. However, given the importance of this output, it is stated here as an output of the architecture development method. Conformance Analysis: The conformance criteria are part of the Architecture Contract. According to TOGAF, the conformance analysis is covered during the Architecture Compliance Reviews. An architecture compliance review is a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives. A formal process for such reviews normally forms the core of an enterprise architecture compliance strategy. The goals of an architecture compliance review include some or all of the following: N Ensure the application of best practices to architecture work N Provide an overview of the compliance to mandated enterprise standards N Identify where the standards themselves may require modification N Identify services that are currently application-specific but might be provided as part of the enterprise infrastructure 6 STATE OF THE ART IN ARCHITECTURE SUPPORT

23 N N Communicate the status of technical readiness of the project to management Identify significant architectural gaps to product and service providers In addition to Architecture Compliance Reviews, a maintenance method is proposed RSD Name: Rapid Service Delopment (RSD) Ownership/Authorship: Public. Created at Telematica Instituut within the framework of Giga Transaction Services project (see Fielt et al. (2000), and Statement of scope and purpose: The RSD method defines an integrated framework for the specification and development of e-business services, with a particular focus on business-to-business transactions. Generally, the development of such services is highly complex, as it involves many different aspects ranging from high-level strategic business concerns to low-level protocol definitions. In order to deal with this complexity, the separation of concerns principle is applied. The RSD framework distinguishes seven different aspect areas, called cornerstones, from which models and specifications can be made. In this way, one can focus on one set of concerns at a time, resulting in a lower (perceived) complexity. At the same time, however, the method provides well-defined links between the cornerstones, thus rendering an integrated framework for business-driven design of transaction services. RSD it is definitely a component based development method. RSD Data Function Organisation Process Network Business (conceptual) layer System (logical) layer Technological (physical) layer Type: Partial. RSD does not cover the implementation/ coding phase and the integration, testing and evaluation phase. Architectural Framework: See Fielt et al. (2000), and Buuren et al. (2002). Lifecycle Model: RSD is proposing a number of usable lifecycle models. We present them below. 1. The classic waterfall model could be employed: starting with Ambition & Scope and the business-oriented models for requirements analysis and definition, and then through the technology-oriented models for implementation, integration and deployment (see Figure 5). 2. A second lifecycle model proposed is an evolutionary one (see Figure 6) that is counterclockwise; top-down design approach followed by a bottom-up realisation approach. A clockwise evolutionary process is also possible. Such a clockwise method seems especially useful in the case of legacy integration and technology-driven development. ARCHIMATE/D3.1

24 Figure 5. RSD Waterfall (source: Fielt et al. 2000) Figure 6. Evolutionary model (source: Fielt et al. 2000) Figure 7.RSD's Generic lifecycle model (source: Fielt et al. 2000) 3. The third, so-called generic model would follow, roughly, the following steps: NIdentify the goals, side-conditions and scope of the design (scope and ambition); NIdentify the actors involved (what parties should be taken into account in the new e- business application?); NIdentify the roles that are present: what are the different responsibilities in the process (what actor can perform what role?), NDetermine how goods, information and money flow through different roles. These first four activities define the ambition and scope and sketch the networked enterprise model of the e-business services. The next step makes the transition to transaction scenarios. NDetermine the activities underlying the flows, and assign the activities to different roles. When activities are related to different roles and actors, they are called transactions: interactions between different actors. From these are choosen those that will be developed and implemented further. NDetermine what restrictions current processes, systems and ICT architectures and applications impose. NDetermine the technologies most suited for different transactions, depending on the level of openness, security restrictions, implementation frameworks and so on. NRefine the transactions to such a level that they can be implemented and combined with existing systems and processes. NBuild the e-business system components, and integrate them into a running system. The approach is visualised in Figure 7. 8 STATE OF THE ART IN ARCHITECTURE SUPPORT

25 Domain analyses: RSD is defining five types of domains, and the corresponding domain analyses: Actor Domain, Role Domain, Function Domain, Process Domain and Data Domain. In order to support the activities entailed by the Analysis phase, a tool and a method have been developed (BFIT Analysis Tool see Architectural Specifications/Design: For each of the above-mentioned domains a conceptual framework, a formalism and a supporting modeling language are defined. The tool used for model creation is called RSD Studio and it is not commercial. Method for Architectural Implementation: Not covered by RSD. The focus in the RSD method is on domain analysis, design, and business modelling. Conformance Analysis: Not covered by RSD MEMO Name: Multi Perspective Enterprise Modelling (MEMO) Ownership/Authorship: Public. The development of MEMO started in 1993 as an interdisciplinary research project at the German Research Center for Computer Science, GMD (Universität Koblenz-Landau, see Frank 1994, and Statement of scope and purpose: MEMO is a method for enterprise modelling that offers a set of specialised visual modelling languages together with a process model as well as techniques and heuristics to support problem specific analysis and design. The languages allow the modeling of various interrelated aspects of an enterprise. They are integrated on a high semantic level. MEMO models have two goals: N they are an instrument to develop information systems that are well integrated with a company s strategy and its organization N they can be used as the foundation of an enterprise schema. Its instantiation would allow for a permanent representation of all relevant aspects of an enterprise (strategy, business processes, organisational structure, business entities, business rules etc.). MEMO puts special emphasis on modelling languages. MEMO Data Function Organisation Process Network Business (conceptual) layer System (logical) layer Technological (physical) layer Type: Complete Architecture Framework: MEMO was motivated by the vision of generic enterprise models that can be (re-) used by many companies as a reference to build information systems which are effectively integrated with a company s organisation and its long-term strategy. Therefore, MEMO differentiates three so-called perspectives - strategy, organisation and ARCHIMATE/D3.1

26 information system - each of which is structured by four aspects: structure, process, resources, goals. A particular aspect within a perspective is called a focus - for instance process within information system, and one or more foci correspond to a particular model. For instance: an organization model serves to represent an organisation structure, business processes as well as related resources and goals. Within the information system perspective, the focus structure is represented by an object model. A strategy model renders the structure (strategic business units) and the dynamic aspects (value chain) of a corporate strategy. Lifecycle Model: Waterfall (depicted in Figure 8). Feasibility Study Maintenance Introduction Test Strategic Analysis & Design Organisation Analysis & Design Information Analysis Implementation OO Design Figure 8. MEMO lifecycle model (source: Domain analyses: There are four types of domain analysis that are described in MEMO: Feasibility Study: Inputs: documents produced within the feasibility study, existing strategy reports, corporate philosophy, business reports, balance sheets, data from accounting, information about relevant markets and competitors, forecasts Goals: evaluate competitive position, record strategic assets, record relevant developments (technology, markets), analysis of present corporate strategy, assess strategic relevance of information systems, eventually design a new corporate strategy, identify core processes Techniques: workshops, interviews, presentations, creativity techniques, integrated frameworks Strategic Analysis and (Re-) Design: Inputs: business reports, statistics, existing studies, forecasts, specialised journals, textbooks, etc. Goals: to define project goals, estimate amount of time and resources, guidelines for project management, draft project plan (corner stones, cost-plan), define tasks to be performed by external partners, define project roles, assign employees to roles Results: generic strategy, strategic success factors, detailed description of the corporate value chain, catalogue of operational goals for organisational analysis/design, catalogue of core processes, dictionary of relevant terms 10 STATE OF THE ART IN ARCHITECTURE SUPPORT

27 Techniques: workshops, interviews, workshops, interviews, presentations, creativity techniques, integrated frameworks, value chain analysis, portfolio analysis, templates, checklists presentations, creativity techniques, integrated frameworks, modelling language MEMO-SML. Organizational Analysis and (Re-) Design: Inputs: documents/models from strategic analysis, organisation manual, data from corporate accounting, results from previous organisational analysis Goals: analyse selected business processes, possibly redesign processes, define requirements for organisation structure, possibly design process-oriented accounting systems, define future profiles for employees Results: models of business processes (developed in modelling language is MEMO- OrgML), dictionaries of information required and produced, communication diagrams, organisational charts, profiles of required positions, possibly management concepts, dictionary of relevant terms Techniques: workshops, interviews, presentations, integrated frameworks, structured descriptions of business process, templates, checklists. Information Analysis Inputs: documents/models resulting from organisation analysis, existing data models, existing data structures Goals: object-oriented modelling of information required and produced by business processes, possibly further refinement of business processes Results: object model (focus on domain objects), models of business processes (made in MEMO -OrgML and workflows, guidelines for naming model elements, dictionary of events and exceptions Techniques: language for object-oriented modelling (using MEMO-OML), stepwise refinement of business process models, analysis patterns, guidelines for object-oriented modelling, possibly use of generic reference models. Architectural Specifications/Design: Inputs: models/documents resulting from information analysis, possibly design patterns, reference models, and frameworks Goals: to refine and formalise object model and corresponding workflow models, design of system architecture, check reusable frameworks, possibly design of frameworks, specify transactions within workflows, design user interface, select standards and platforms, define strategy for integrating existing data and applications. Techniques: language for object-oriented modelling, reuse of existing artifacts (classes, frameworks, reference models), use of style guides, prototyping Results: extensive and widely formalised object model (modeling language MEMO-OML), workflow models, system architecture, dictionary with specifications of events and exceptions, dictionary of standards to be taken into account, guidelines for integrating existing data and application, style guide for user interface, possibly Framework(s), list of required platforms and software to be purchased management concepts, dictionary of relevant terms Method for Architectural Implementation: ARCHIMATE/D3.1

28 Inputs: documents/models resulting from object-oriented design, possibly existing class libraries, frameworks, possibly existing applications, data, data base schemata Goals: possibly refine and complete object model, generate/write code for class implementations, implement interfaces compliant with selected standards, integration with data base system(s), possibly performance tuning, polish user interface, write user manual Techniques: principles of object-oriented programming, use of style guides, reuse of existing code, prototyping Results: implemented classes, user manual, documents/models required for maintenance, list of known bugs. Conformance Analysis: Inputs: documents/models resulting from implementation and previous stages, user manual, guidelines for performing software tests, data/scenarios for testing Goals: evaluate system/system components against requirements, test ergonomic features, evaluate manuals/help systems, implement necessary organisational changes, provide training for users, implement required platforms and software, introduce and run system Techniques: testing strategies, use of testing tools, introduction on a trial basis, workshops Results: list of bugs, list of modifications to be performed, comments on the user manual, organisation manual RUP Name: Rational Unified Process (RUP) Ownership/Authorship: Commercial, developed by Rational Corporation (see Kruchten 2000 and the same company that introduced what has become the industry-standard modelling notation, the Unified Modeling Language (UML). The heart of the RUP is the Objectory Process, one of several products and services that Rational acquired when they merged with Ivar Jacobson s Objectory organization several years ago. Rational enhanced the Objectory with their own processes, and those of other tool companies that they have either purchased or partnered with, to form the initial version of RUP, officially released in December of Currently RUP consists of N a web-enabled searchable knowledge base providing all team members with guidelines, templates, and tool mentors for all critical development activities. The knowledge base can further be broken down to: extensive guidelines for all team members, and all portions of the software lifecycle, Rational Rose examples and templates, SoDA templates (SoDA is Rational's Document Automation Tool), Microsoft Word templates (Word templates assisting documentation in all workflows and all portions of the lifecycle), Microsoft Project Plans templates, Development Kit describing how to customize and extend the Rational Unified Process to specific needs. N a book Rational Unified Process--An Introduction, by Philippe Kruchten, published by Addison-Wesley. The book provides a good overview to the process and the knowledge base. Statement of scope and purpose: Rational Unified Process (RUP) is an object-oriented and Web-enabled program development method. According to Rational, RUP is like an online mentor that provides best practices, guidelines, templates, and examples for all 12 STATE OF THE ART IN ARCHITECTURE SUPPORT

29 aspects and stages of program development. RUP is a comprehensive software engineering tool that combines the procedural aspects of development (such as defined stages, techniques, and best practices) with other components of development (such as documents, models, manuals, code, and so on) within a unifying framework. All the phases of RUP are supported by Rational software tools. RUP Data Function Organisation Process Network Business (conceptual) layer System (logical) layer Technological (physical) layer Type: Complete Architectural Framework: RUP is purely a method for software development. It does not define any explicit reference architecture. Lifecycle Model: Figure 9 presents the lifecycle of the Unified Process, made up of four serial phases and nine core disciplines (formerly called workflows). It is organised along two dimensions: time and content. The time dimension is decomposed in phases, which apparently follows a typical waterfall model: N The Inception phase is where the project scope and the business case for the system are defined. N The Elaboration phase focuses on detailed analysis of the problem domain and the definition of an architectural foundation for the project. N The Construction phase, often the heart of software projects is where the detailed design for the application is developed as well as the corresponding source code. N The purpose of the Transition phase is to deliver the system to the user community. Figure 9. RUP's lifecycle model (source: ARCHIMATE/D3.1

30 Still, during some of the phases, the development cycle should be organized into what RUP calls iterations. Therefore, the RUP lifecycle is a combination of a waterfall model and a prototyping model. RUP is relying for modeling on Rational Rose, and it assumes the development of models for a number of views (data, function, network, people, time at the enterprise and system levels) covered by this tool. However, RUP eventually is a knowledge base and methodology, and therefore we do not see any significant obstacle for using it in combination with any other UML modeling tool. Domain analyses: In the Inception Phase of a given software project RUP requires a formal process to measure the scope of work activity involved. The goals of the proposed development activity are detailed, the business terminology is defined, and a high-level definition of the business processes of the customer organization is documented. The Inception phase's deliverable work products (artifacts) are used as a basis for work done in Elaboration phase. N Deliverables: o The Project Vision Document: This document provides the development team and the customer with a common understanding of the business and technical reasons for the creation of the proposed software application. In a commercial company this document will often include a business case that justifies the creation and its benefit to the company. Defines the client s key participants and stakeholders. The Project Vision document is created in Requisite Pro. o The Business Glossary: Tracks terms and acronyms specific to the system development project at hand. Provides English-language definitions for non-technical project participants. Allows changes in project terminology to be tracked and recorded as the project grows during its lifecycle. Business glossary is created in Requisite Pro. o The Business Use Case Model (high level): These are business processes as seen by the customer s stakeholders within their business units. It capture the high-level view of system business processes, and the interactions between business processes. The business use-case model is created in Rational Rose. Architectural Specifications/Design: The RUP Elaboration phase focuses on lower-level (detailed) requirements. Detailed requirements are converted into use cases, resulting in a Use Case Model. The types of requirements to be collected and their attributes are defined. Customer management and staff stakeholders (being the users of the new system), are interviewed and their requests are documented in detail. A formally structured hierarchical catalogue of detailed software requirements is then compiled. The business object model is also developed during Elaboration Phase. Elaboration Phase Deliverables: N The Requirements Management Plan: Describes the types of requirements needed to define the system. Each requirement type may have a customized set of attributes assigned to it (types of requirements: Non-Functional Requirements, System Constraints, General System Features, System Business Functionality Detail, Requirements Change requests, types of requirement attributes: Requirement s priority, Development Costs, Benefits to the organization). The Requirements Management Plan is created in Rational Requisite Pro. 14 STATE OF THE ART IN ARCHITECTURE SUPPORT

31 N N N The Stakeholder Requests Document: This documents contains a set of questions, to be asked during a stakeholder interview, that will yield all the facts required to define the system, categories, priorities, requirement interrelationships. The Stakeholder Requests Document is created in Rational Requisite Pro. The Software Requirements Plan: This is a detailed compendium of customer requirements for the proposed application. This document will contain sufficient detail to allow the developer(s) to design and construct the proposed software application. The Software requirements plan is created in Rational Requisite Pro. The Business Object Model: This document is a high-level definition of the customer s business processes and their interactions. It describes the realization of business use cases and the interaction among business objects. The Business Object Model is created with Rational Rose. Method for Architectural Implementation: The construction phase involves converting the assembled requirements into software and database designs. Those designs are then used to create software constructs and data structures that make up the system. Within this phase object oriented development is leveraged through the use of Rational Rose. Multiple architectural views and class models are constructed, providing the development team with a clear roadmap of the detailed requirements to be coded. Typically, within the RUP development cycle, the features of the system are scheduled for development and release within ever more complete prototype versions of the application under development. Construction Phase Deliverables: N System software Components: operating system(s), databases, hardware interfaces. The System Software Components Class Diagrams are created with Rational Rose. N Middleware Components: GUI builders, interfaces to database management systems, platform-independent operating system services, third-party components. The Middleware Components Class Diagrams created with Rational Rose. N Business-specific components: Business-specific components, used in several applications, Application layer, Application-services. The Business Process Specific Sequence Diagrams created with Rational Rose. N Implementation: Implementation consists of the execution of the designed work for the current iteration of the project, involving software and database construction. The implementation deliverables are Source codes and Constructed Databases and are created in the selected software development tools and database management tools. Conformance Analysis: The last phase of RUP, the Acceptance Testing of the completed software application measure compliance of the final product with the application's features as defined in a final Requirements Document, which will have evolved with iterations of Phase II development. Features are verified by each unique requirement. Technical errors in the application must also be resolved during this final testing process. Acceptance Testing Deliverables: N Comprehensive Test Plan mapping Requirements and Use Cases from Requisite Pro into Rational's Testing Tools. N Automated Test Scripting in the selected testing tool. N Automated and Manual Testing Operations managed with Rational's Testing Tools. N Final, "Ready" Version of the Application's source code, compiled components and database artefacts. ARCHIMATE/D3.1

32 N System Technical Documentation compiled in part from Rational Requisite Pro and Rational Rose using data extraction capabilities of the Rational SoDa documentation management tool. For more information see Other methods ARIS: Architecture of Integrated Information Systems (ARIS) is a method developed by IDS Scheer (see Scheer 1992, 1994). ARIS is accompanying a toolset, which is commercially successful and used in several industrial applications. It has as objective to describe an enterprise information system, from all views in a holistic manner. ARIS has an elaborated decomposition of an enterprise in several views: data view, function view, organization view and, to realize the connection between these views, the control view. For each view, ARIS uses a sequential lifecycle model: requirements definition design specification implementation description. These will describe each view at different levels of abstraction. The starting point is always the managerial/economic description of the enterprise domain, the requirements definition. The concepts are formulated in business terms but are strongly influenced by technical possibilities. The resulting models of this first level are laid down in semiformal diagrams. The design specification is also modelled semi-formally, but uses terms of the envisioned information systems solution (i.e. it speaks about modules and transactions). The last part consists of the physical implementation description of the upper levels. ARIS owes its success to the simplicity and the intuitive character of its models. However, van der Aalst (1998) affirms that this kind of modelling methods (EPCs) suffer from a serious drawback: they lack formalism. Neither the syntax nor the semantics of an event-driven process chain are well defined. PERA: The Purdue Enterprise Reference Architecture (PERA) is a method developed by the Purdue Laboratory for Applied Industrial Control at Purdue University (Williams 1994). The Purdue Enterprise Reference Architecture and its associated Method are a comprehensive approach for defining a generic architectural specification and integration method for enterprise integration or other enterprise development programs. PERA is entirely based upon the concepts of enterprise integration. PERA suggests the definition of a general task representation of the information system tasks the manufacturing tasks and the human based tasks. The functional descriptions of the tasks are divided between the information stream and the manufacturing stream. The first is initiated by the planning scheduling, control and data management requirements of the enterprise whereas the manufacturing stream is initiated by the physical production requirements of the enterprise. The final version of the models presents the enterprise from two different viewpoints: the functional view and manufacturing or physical view. The PERA lifecycle Model is a waterfall divided in four phases: analysis (identification of business entity; concept mission, vision, values; definition), design (functional design, detailed design), implementation (manifestation),), and integration, testing & evaluation (operation and maintenance, refurbishment or obsolence, final disposal). PERA has 16 STATE OF THE ART IN ARCHITECTURE SUPPORT

33 proposed an Enterprise Reference Architecture in which the emphasis lies on domain analysis and architectural design. PERA does not develop any specific modelling tools. Instead it uses existing tools to model different aspects of an enterprise. CIMOSA: The Computer Integrated Manufacturing Open Systems Architecture (CIMOSA) method was presented by the AMICE Consortium in the ESPRIT Programs no. 688, 2422, CIMOSA (see Kosanke 1995) is aimed at process based enterprise modelling and application in the control and monitoring of enterprise operations. CIMOSA consists of an Enterprise Modelling Framework and an Integrating Infrastructure and it proposes a sequential (waterfall) lifecycle Model (see Zelm, Vernadat, Kosanke 1995). The CIMOSA Reference Architecture Model is frequently referred to as "The CIMOSA Cube." The cube graphically displays the three orthogonal dimensions of CIMOSA: the generation, instantiation, and derivation dimensions. GRAI: Graphes et Resultates et Activités Interreliés Integrated Methodology (GRAI, GIM) was created at Grai Laboratory, University of Bordeaux I within the framework of the ESPRIT program (projects: Open CAM no. 418, IMPACS no. 2338, FLEXQUAR). GIM is a method to analyse and design integrated manufacturing systems. It uses the GRAI formalisms to model the decisional system, the MERISE formalisms for the informational system and IDEF0 for the physical system. The GRAI lifecycle Model is a waterfall: Analysis, User Oriented Design, Technical Oriented Design, Implementation & Integration. Note that, although mentioned in the lifecycle model, the GRAI-GIM handles only analysis and design phases out of manufacturing system lifecycle. Although GRAI-GIM does not handle system development itself, it produces input data for development work. GERAM: Generalised Enterprise Reference Architecture and Methodology (GERAM) was developed by the IFIP-IFAC Task Force (IFAC/IFIP 1993, Bernus and Nemes 1996). GERAM s ambition and scope is to provide the most comprehensive enterprise reference architecture and methodology. It builds upon CIMOSA, PERA and GRAI. Figure 10. The lifecycle and life history of GERAM (source Bernus and Laszlo 1997) GERAM make distinction between the lifecycle concept and the so-called life history (see Bernus and Laszlo 1997). While the lifecycle of an entity is the representation of main activity types that contribute to the life (creation, operation, and decommissioning) of that ARCHIMATE/D3.1

34 entity (see Figure 10 left), the life history captures the main events in the life of the entity (seefigure 10 right). Change processes form part of the history of an entity, with possibly many small and big change processes simultaneously happening. The reference architecture proposed by GERAM has three dimensions: N The lifecycle dimension (see the lifecycle model of GERAM) N The instantiation dimension allowing for different levels of controlled particularisation N The view dimension with four views: Entity Model Content view, Entity Purpose view, Entity Implementation view, and Entity Physical Manifestation view. 18 STATE OF THE ART IN ARCHITECTURE SUPPORT

35 2.2.6 Methods overview Table 2. Methods overview ARCHIMATE/D3.1

36 2.3 Design approaches Information system architecture development is a complex task involving modelling several aspects of the enterprise: the enterprise goals, the enterprise business rules, actors and resources, concepts and business processes; in addition technical requirements have to be specified. To facilitate this activity, several issues have been widely debated in the literature: development methodologies, modelling techniques guiding the development process, and components, reuse and patterns approaches. In this section we present several practices that are considered not only to speed up and improve the quality of the architecture work, but also to preserve architectural knowledge for the declared purpose of reuse of this knowledge assets. Namely we refer to topics like standardisation, recommendations and best practices, architectural components and patterns, etc. Architectural Standards and Recommended Practices In the case of architectures, the role of standards was to provide the architecture community with a set of common concepts, structures and procedures for the development of architectures. In other words, they helped this community to speak the same language and they contributed to a more structured development of this field. In what follows we mention a number of standards relevant for the development of architectures. N ISO Concepts and Rules for Enterprise Models. N ISO Requirements for enterprise-reference architectures and methodologies (GERAM is part of this standard) N Software Capability Profiles (Complementary new ISO standard external to WG1) N PSL - Process Specification Language - Rules for ontology N Universal Enterprise Modeling Language (UEML) N ISO TR Shop-floor-production model. N CEN (Comité Européen de Normalisation) ENV CIM-systems-architecture framework for modeling (CIMOSA) N CEN ENV Constructs for enterprise modelling. N IEEE 1471 codifies in terms of recommended practices a number of concept and terms of reference on which there is consensus and reflects the generally accepted trends in practice for architecture description. Architectural styles The main contributions with respect to architectural styles come from Garlan and Shaw (1993) and Perry and Wolf (1992). Garlan and Shaw define software architecture in terms of high level design elements and constraints on the elements. Their approach defines elements as components and connectors, described in some idiom-specific manner. Idioms are represented as topologies of the component/connector vocabulary, along with constraints on how the topologies can be arranged. They have also developed a taxonomy based on case studies of actual systems. Another classification of architectural styles can also be found in Shaw and Clemens (1996). Some of the major styles and patterns that have been identified are depicted in Figure STATE OF THE ART IN ARCHITECTURE SUPPORT

37 Batch sequential - Each step runs to completion. Pipes and filters - Linked stream transformers. Main program and subroutines - Traditional functional decomposition. Hierarchical layers - Well-defined interfaces and information hiding, e.g., kernels, shells. Object-oriented systems - Abstract data types with inheritance. Communicating processes - Asynchronous message passing. Event systems - Implicit invocation. Interpreters - Input-driven state machine. Rule-based systems - Rule-based interpreter. Transactional database systems - Central data repository/query driven. Batch Sequential Translational Database Systems Blackboards Communicating Processes Layered Rule-Based Systems and Interpreters Figure 11. Architectural styles Main Programs And Subroutines Event Systems Object-Oriented Patterns A "pattern" is an idea that has been useful in one practical context and will probably be useful in others. (see Fowler 1997). Pattern techniques are generally acknowledged as valuable architectural design techniques. Alexander (1979), a buildings architect, introduced the ideas behind the use of patterns, and the features of a pattern approach to architecture. Ever since, patterns enjoy a significant amount of attention from the architecture community as an emerging important resource, and as a placeholder for hopefully more rigorous descriptions (Gamma et al. 1994, Buschmann et al. 1996). Several different formats are used in the literature for describing patterns. However, there is broad agreement on the types of patterns (architectural patterns, design patterns, idioms), types of things that a pattern should contain (name, problem, context, forces, solution, resulting context, examples, rationale, related patterns, known uses) and the qualities of a pattern (encapsulation and abstraction, openness and variability, generativity and composability, equilibrium). Three examples of collections of architectural patterns in use are outlined below. The Design Pattern Catalogue of Gamma et al. (see Gamma et al. 1994). These catalogue started in 1991 as a part of E. Gamma s Ph.D thesis. By 1993 it became what now is part of the Design patterns book (Gamma et al. 1994). A foreseen use of this catalogue was as a teaching instrument in the field of object-oriented design. Therefore patterns are very detailed described (an average of 10 pages per pattern) including examples and motivation. The template used for the description of each pattern consists of the following elements: intent, motivation, applicability, participants, collaborations, consequences, implementation, sample code, known uses, and related patterns. The catalogue contains 23 patterns, divided into three main classes of patterns, depending on their purpose. The authors of the Design Patterns book suggest the connections between patterns, but do not give a ARCHIMATE/D3.1

38 navigation sequence through them. Many of the patterns show up more than once in the book and their level of complexity is different. U.S. Treasury Architecture Development Guidance (TADG) document ( The U.S. Treasury Architecture Development Guidance (TADG) document - formerly known as the Treasury Information System Architecture Framework (TISAF) - provides a number of explicit architectural patterns. Section 7 of the TADG document describes a rationale, structure, and taxonomy for architectural patterns, while the patterns themselves are formally documented in Appendix D. The architectural patterns presented embrace a larger set of systems than just objectoriented systems. Some architectural patterns are focused on legacy systems, some on concurrent and distributed systems, and some on real-time systems. The content of an architectural pattern as defined in the TADG document contains the following elements: Name, Problem, Rationale, Assumptions, Structure, Interactions, Consequences, and Implementation. The IBM Patterns for e-business ( gives a group of reusable assets in the form of architectural patterns that go from the business problem to specific solutions, firstly at a generic level and then in terms of specific IBM product solutions. The IBM Patterns are aimed at speeding up the process of developing e-business applications. A supporting resource is IBM's set of "Red Books. IBM's patterns are focused particularly on solutions for e-business, i.e., those which allow an organization to leverage web technologies in order to re-engineer business processes, enhance communications, and lower organizational boundaries with customers and shareholders (across the Internet); employees and stakeholders (across a corporate Intranet); and vendors, suppliers, and partners (across an Extranet). The IBM web site also provides specific (IBM) product mappings for the run-time patterns, indicating specific technology choices for implementation. Components Component-based software architectures are becoming more common as developers realise these have greater potential to effective design practice for improved reusability, robustness and end-user configuration than conventional software systems. The central idea component-based architectures is the composition of software systems from discrete, usually highly reusable components - units of data and functionality that can be connected together to produce complete software package (Szypersky 1997). In general, a reusable component can be defined as a unit of design (at any level), for which a structure is defined, a name identifying the component is associated, and design guidelines (in the form of design documentation) are provided in order to support the reuse of the component and to illustrate the context where it can be reused, including constraints (for instance, indicating which other components must be used in combination with the one being considered, see Pernici et al. 2000). The difference between component-based systems and more conventional software systems (e.g. using function libraries and class frameworks) is that component-based systems allow components to be plugged in at run-time, or unplugged and interchanged with other components. There are three main parts to a component: Interface (specifies what the component does), Implementation (the code which performs 22 STATE OF THE ART IN ARCHITECTURE SUPPORT

39 what the component does), Deployment (how the component is physically packaged). A more complex reference model of a component is presented in Sparling (1999) (also see Figure 12; Figure 12. Component reference model. Component Properties: N Components are encapsulated: A consumer only needs to know what a component does, not how it is done. N Components are replaceable: This means that, provided there is no change to the interface, the implementation of a component can be changed without affecting the consumer. N Components are descriptive: Since a component can only be accessed via defined interfaces, it must provide information about itself so consumers know how to use it. N Components are extensible: It is possible to extend a component's range of services without affecting consumers using two methods: Adding interfaces and delegating responsibility. Component Types: N Business Components, like customer, order, or invoice. Business Objects are considered as basic components in the conceptual model (see Sims 1994). N Activity Components, like notification and release, which are the reusable elements of a business process. N Development Components, like source code management and test harnesses that assist the programmer. N Technical Components, like ORB bindings and persistence (data storage) gateways that enable the architecture. N Structural Components, like smart financial currency data types and security that provide highly generalized and highly reused capabilities. N Wrapped Components, which can include pieces of legacy systems that have been "upgraded" to a component architecture. ARCHIMATE/D3.1

40 Component Market: There are two things driving the component-based design development: standards and reuse. Until now the fields in which the component-based approach was successful were those ones in which the framework is well defined: e.g., the development of the graphical user interfaces. Currently there are three main commercial component models: the OMG CORBA Component Model (CCM), the Enterprise JavaBeans (EJB) architecture and the Microsoft.NET. The first one is defined by a consortium of vendors and users, the Object Management Group (OMG). The second and the third ones are de-facto standards, promoted by Sun, IBM, Oracle and others and by Microsoft, respectively. Web services Web services are business functions exposed to the Web via a well-defined interface and using standard Web protocols. They allow companies and individuals to make their digital assets available to the global community in a simple and effective manner. XML plays an important role in the definition, implementation, and execution of Web services. From a technology point of view, the Web service concept is not really new; it provides functionality that has been offered for years by the likes of CORBA. However, the secret of their success is not in the facilities they offer but in the relative ease of hooking up a set of Web services and in their reliance on open, Internet-based standards. Next, we will shortly refer to the XML-based standards for accessing, describing, and discovering Web services. For more information on web services and many other related topics, one can refer to Bargh et al.(2001). Simple Object Access Protocol (SOAP) According to the W3C note, SOAP (Simple Object Access Protocol, see Box et al. 2000) is a lightweight protocol for the exchange of information in a decentralised, distributed environment. It is an XML-based protocol that provides a specification for: N an envelope that defines a framework for describing what is in a message and how to process it (the header provides contextual information about the message), N a set of serialisation and encoding rules for expressing instances of application-defined datatypes, N a convention for representing remote procedure calls and responses, N binding to HTTP and other first transport layer protocols N exception processing rules and formats The power of SOAP is that it refrains from implementation details on any side of the connection, and it does not invent what already exists (be it CORBA, DOM, EJB, or anything). The only requirement is a mapping from SOAP to the existing component model of the application. Web Services Definition Language (WSDL) WSDL (Web Services Definition Language, see Christensen et al. 2001) is an XML format for describing network services as a set of endpoints operating on messages containing 24 STATE OF THE ART IN ARCHITECTURE SUPPORT

41 either document-oriented or procedure-oriented information. Its specifications are the result of a joint effort from Microsoft, IBM and Ariba. WSDL is an important factor in the development of SOAP, and it facilitates the interoperability of Web services. An increasing number of SOAP implementations support this description language. Thanks to WSDL, SOAP implementations can self-configure exchanges between Web services while masking most of the technical details. A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types, which are abstract collections of operations. Universal Description, Discovery, and Integration (UDDI) UDDI (Universal Description, Discovery, and Integration) is intended to be an Internet standard for creating an online business registry in a platform-independent way, and was introduced in August 2000 by Microsoft, IBM and Ariba. In May 2001, Ariba resigned and HP became a new UDDI operator. At the high level, the standard defines White Pages (general business information), Yellow Pages (business categories, taxonomies), and Green Pages (services offered by a business). Businesses can list and describe themselves in a registry that is maintained by a number of different companies. Microsoft has begun beta-testing its implementation of the UDDI Business Registry. Orchestration of Web services Next to defining the interface and discovery of Web services, the orchestration, flow, or process between these services must be defined. Several process modelling languages for Web services exist: N the Business Process Modelling Language (BPML) (see of BPMI; N Microsoft s XLANG (see Thatte 2001), part of BizTalk; N IBM s Web Services Flow Language (WSFL) (see Leymann 2001); N HP s Web Service Coordination Language (WSCL) (see Banerji et al. 2001); N RosettaNet s PIPs ( N ebxml s Business Process Specification Schema (BPSS) ( Currently, BPSS is probably the most generic modelling language for business processes. However, no common standard for describing the coordination of Web services has been agreed upon in the marketplace. It remains to be seen which of these initiatives will be successful. ARCHIMATE/D3.1

42

43 3 Supporting Tools This chapter gives an overview of available tool-support for business/software architectures. We are going to discuss a number of software tools that are currently used in the field of (enterprise/software) architectures: Microsoft Visio, System Architect, Metis, Testbed Studio, Enterprise Architect, ARIS, Rational Suite Analyst Studio, Select Component Architect, and ASG-Rochade. The presentation of the first four in this list is organized according to a set of criteria that we define below. For the remaining tools one can find in 3.5 brief descriptions. More detailed information for all these tools the reader can find in ART. Finally, in Section 3.6 we give a summary tool overview (in the form of Table 7). The selection of each tool was based on one or more of the following arguments: N It is used by the ArchiMate partner(s), N the tool has acquired an important share of the market and is considered very successful, N it offers good modelling functionality, N it is comprehensive (multi domain). In table below we present a list of the tools together with their main selection criterion and their application domain: Tool Supplier Criterion Application domain Testbed Studio BizzDesign Used by ArchiMate partner(s) Rose Rational Well defined position on the market, comprehensive Business process design, organisational modelling Software design System Architect Popkin Functionaliteit Multiple domains Select Component Architect Aonix Used by ArchiMate partner(s) Software design, business process design (UML) Enterprise Architect Sparx Functionality Software design, business process design (UML) Visio Microsoft Functionality Drawing tool Metis Computas Functionality, comprehensiveness Multiple domains RSD Studio Telematica Instituut Functionality Networked enterprise design ARIS IDS Scheer Well established in the market Business process design Rochade ASG Functionality, used by ArchiMate partner(s) Repository ARCHIMATE/D3.1 27

44 Table 3. Tool selection criteria If we take into account the primary information from Table 3, then (as shown below) we can already roughly position the selected tools with respect to the two main application areas: business process design and software design. Visio RSD Studio Rose System Architect Testbed Studio Business process design ARIS METIS Select Component Architect Enterprise Architect UML Software design Rochade Table 4 Positioning the tools Next we define a general set of features that we consider adequate for the synthesis of the most relevant information concerning a tool. General Information: The general information refers to issues such as name of the vendor and its contact information, known users among the ArchiMate consortium, contact persons at the vendor or at ArchiMate partners, licence types, versions, corresponding prices and any other background information that may be available. Content Management: Content management is concerned with the way in which the tool handles the user's data: Are there repositories for storing the models? Does the tool offer versioning mechanisms? And, as security aspects, how does the tool handle access control, and to what extent does the tool guarantee data integrity? Functionality: This criterion is about the functionality that the tool provides to edit the models. How well are basic operations on models supported, such as copying and pasting (groupings of) model components? Can models be split into multiple models, and can models be merged into one? Can models be imported and exported, and in which formats? These functionality aspects of a tool determine in a major part the user's overall experience. Modelling: Within modelling we address issues such as: N Analysis: This criterion refers to the types of analysis techniques supported by a tool. N Domains: This criterion is about the domains that the tool covers. These can include software applications, information, infrastructure, organisation, business processes, and products. 28 STATE OF THE ART IN ARCHITECTURE SUPPORT

45 N N N N Languages: The languages criterion discusses the modelling languages. Which languages does the tool offer? Are these tool-specific, shared with other tools, of even a standard? Are the languages configurable? Best practices: They are usually meant for beginners and consist in a set of recommendations/tips in how to design a certain architectural model. They have an educational purpose and attempt to help the user in developing a certain modeling style. Best practices for the usage of tools are sometimes provided also in other phases of the architecture development (analysis, implementation and testing). Methodologies: The role of methodologies is to assist in all the phases of the life cycle of architectures, including development, testing and management. Methodologies impose a disciplined process and they are usually conceived as stepwise guiding plans and describe a number of procedures /operations to be followed within each step. The steps correspond to different phases in the architecture development process. There are a number of different methodological models (waterfall, spiral, star, iterative etc.), but all of them start from identifying the several phases of the architectural evolution. Libraries/Templates: These are repositories of architectural design patterns. Design Pattern Libraries can provide the developer with predefined architectural components, but it is his task to place them into his own particular context. Our concern regarding such libraries is to determine whether they are provided by the surveyed tools. Openness: The openness of a tool refers to the extent to which a tool can work together with other tools and to the extent to which one can understand and even adapt its inner workings. In this line of thinking, we will try to assess: the interoperability of the surveyed tools, to what extent they adhere to any standards, and whether the semantics of the tool's models is available, or if the tool is open source. Interoperability is the ability of a tool to work together with other tools to exchange information. It can be direct, indirect, horizontal, or vertical. In the case of direct interoperability, information exchange is done through an API. In the case of indirect interoperability, it is done trough exchange of files. Horizontal interoperability is interoperability with tools of the same type. For example, word processors that are horizontally interoperable can exchange each others file formats. A tool can be said to be vertically interoperable if it can exchange information with other types of tools. 3.1 Microsoft Visio General Information: Microsoft Visio ( is a very powerful diagramming tool, which was originally designed for drawing flowcharts and other technical diagrams. Microsoft bought Visio in 1999, and since then has integrated several Visio variants in its products. Here, we discuss Visio 2002 Standard and Professional Edition, Visual Studio.NET Enterprise Architect Visio can be configured by the user with custom shapes, stencils and templates. Microsoft Visio 2002 can be ordered on-line (~450$/licence). Other tools related to Visio 2002: Visio Enterprise Network Tools, Visio Viewer 2002, Visual Studio.NET Enterprise Architect. Content Management: Visio has no repository itself, but can be used in conjunction with Microsoft's repository solutions (SourceSafe). ARCHIMATE/D3.1 29

46 Functionality: The Microsoft Visio product line includes Visio Standard and Visio Professional. Both products share a common file format, so that you can share diagrams with other Visio users, regardless of the product you choose. Visio Standard includes diagramming solutions that help business professionals project managers, marketers and salespeople, HR personnel, administrative staff, IT specialists, developers, and engineers visualize and share information they work with every day. Visio Professional also includes the business diagramming solutions found in Visio Standard. Visio 2002 Professional Edition offers basic support for software and systems modelling, and information (database) modelling. It offers UML 1.2 support, but no reporting or code generation. A point-by-point comparison of the Visio 2002 Products (which also gives their main features) is given below: Features Visio Standard Visio Professional Intelligent SmartShapes symbols ' ' Drag-and-drop diagramming ' ' Microsoft Office look and feel ' ' Custom properties for shapes ' ' Property reporting ' ' Microsoft Visual Basic for Applications 6.3 ' ' Block diagrams ' ' Flowcharts ' ' Organization charts ' ' Timelines and calendars ' ' Sales and marketing visuals ' ' Directional maps ' ' Basic office layouts ' ' Web site maps ' Software/database diagramming and reverse engineering ' Engineering drawings ' Building, space, and floor plans ' Logical network diagrams ' Directory services diagrams ' Table 5 Visio 2000 products comparison More details on Visio 2002 functionality can be found in the Microsoft Visio 2002 Product Guide ( Modelling Modelling Domains: Visio in its most basic form offers no support for any cell in the Zachman framework. However, as a UML tool, Visio 2002 Professional Edition and especially Visual Studio.NET Enterprise Architect cover most of the system model and enterprise model cells. 30 STATE OF THE ART IN ARCHITECTURE SUPPORT

47 Modelling Languages: Visio supports a large number of modelling languages, or, more precisely, drawing types. Some of these are formally defined, others not. For ArchiMate, the most interesting drawing types are UML diagrams. The UML solution includes the following tools, shapes, and functionality: The UML Navigator (provides a tree view of your model and a means of navigating from one view to another), predefined intelligent shapes consistent with the UML semantics, easy to access UML Properties dialog, dynamic semantic error checking, support for Microsoft Repository, reverse engineering projects created in Microsoft Visual C++ 6.0, Microsoft Visual J++ 6.0, or Microsoft Visual Basic 6.0 to generate UML static structure models, generation of code skeletons from class definitions in UML models into C++, Java, or Microsoft Visual Basic, code checking utility, creation of reports for UML static structure, activity, and deployment diagrams. Openness: N Vertical/horizontal interoperability: Microsoft Visio offers good vertical integration with other Microsoft products. Horizontal interoperability is offered by the support for XMI, allowing for the exchange of models with e.g. Rational Rose. Other tools are related to Visio 2002: BizTalk Orchestration Designer, Process Navigator. N Standards: Visio has its own XML file format, facilitating interoperability with other tools. However, this is not a standard XML schema. XMI is supported by.net Enterprise Architect. 3.2 System Architect General information: System Architect is a modelling tool with a repository. The tool supports various major areas of modelling, including business process modelling, objectoriented and component modelling with UML, relational data modelling, and structured analysis and design. The tool belongs to Popkin Software, their home page is Content Management The tool has a repository on which there are several interfaces for Microsoft Visual Basic, CSV, XML, and Schema/ OO code. There is also reporting possible to Microsoft Word. Functionality System Architect is based on the Popkin Enterprise Architecture Framework, which is a derivative of the Zachman framework. Figure 13 shows the major features of the tool. ARCHIMATE/D3.1 31

48 Shared Definitions Business Modeling Analyze Business: Processes Organization Functions Technology Infrastructure IDEF0/IDEF3 Simulation UML Design Applications: Use Cases Object Interactions Classes Components State Machines Java Data Modeling Design Databases: ERD Model Physical Model IDEF1X DB Synchronize Structured Methods Analyze Legacy Systems: Gane/Sarson Ward/Mellor Yourdon/DeMarco SSADM XML Design Design XML Schemas: DTDs BizTalk Instance Docs Test Data UML Integration Data Modeling Integration Repository Customizable Repository Metamodel Reporting Browsing Interfaces Matrices OLE MS Office Automation CSV XML Schema / OO Code Figure 13: Major Features of System Architect. Modelling Modelling Domains: The tool supports: business modelling (processes, organization, functions, technology infrastructure, IDEF0, IDEF3, simulation), requirements modelling, object-oriented modeling, UML modeling (use cases, object interactions, classes, components, state machines, Java); data modeling; design databases (ERD model, Physical model, IDEF1X, DB Synchronize); structured modeling: analyzing legacy systems,xml design, matrix editors.analysis. System Architect provides simulation functionality for process models. Modelling Languages: Copying and pasting of symbols and whole diagrams is possible. The metamodel can be adapted to some extent: N System Architect has a scripting language for expanding its underlying metamodel. It can be used to define new diagram types, or modify existing diagram types. N Creation of new properties for existing diagrams, symbols, and definitions. N Creation of new relationships between combinations of diagrams, symbols, and definitions. Methods: System Architect contains several manuals (e.g.:user Guide, System Architect Process, Extensibility guide, Tutorial). Libraries of templates or patterns are provided. System Architect comes with a lot of models and built-in concepts. These are all stored in a text file saprops.cfg (to give an impression it amounts to 400 pages of text). As a user you can add or change these built in models by creating a file, with the name usrprops.txt. Also functionality can be added to the tool with Visual Basic. The extensibility manual provides comprehensive information regarding the flexibility of the tool (400 pages text). Openness: Interoperability can be accomplished using the XML interface, at least for the UML-based models. There is also vertical interoperability possible for creation of schema and OO code, connecting it to possible lower level development tools. System Architect provides integration with Microsoft Visual Basic, and Microsoft Office. 32 STATE OF THE ART IN ARCHITECTURE SUPPORT

49 3.3 METIS General Information: The METIS home page is The tool belongs to Computas AS. We evaluate version 3.2 of the METIS tool. Content Management: METIS saves the models on hardisk or on a network, including the internet. However, for reasons of reusability of the metamodel, type and symbol files, these files are never stored in the model itself but are referenced and saved as small files. By doing this the tool enforces a single-point-of-change policy; if the metamodel is changed the models are immediately updated as well. Also, exchange of data between models is easier when using the same definitions; there are no conflicts possible between the metamodel definitions. Computas AS provide a tool, named the Model Packager for Metis 3.x, for merging all the files into a single one. Functionality: The METIS tool consists out of 4 components, the Model Annotator, the Model Editor, the Model Designer, and the Metamodel Developer. All these components can run stand-alone and they call each other when needed. These components can be updated, for example with new features, without having to change the others. The user interface: Once understood, the user interface is quite clear. The main portion of the METIS window is the modeling area. This is the place to create the containers and objects and link them together. Most of the modeling functions in this area are available from the right-mouse button menu. The menu options are context-sensitive which means that they are applicable to the selected object. On the left-side of the screen, METIS uses a tree structure similar to Windows Explorer to show several aspects. These are the structure of the repository, the model itself (all objects), the view of the model, the metamodel (templates), and the symbols used by the metamodels. METIS sees a model as a collection of objects and relationships. Objects can be created either by right clicking of the mouse or copying some existing object. These models have a domain and a metamodel. Several views can be made from the models. The user creates a model by choosing or making a template and just adding objects and relationships. The type of these two entities is determined by the template in use. Several models can be made in METIS and related to each other. Also parts of models can be copy/pasted, including the models saved under different names. Models can be interchanged within users that have the same definitions (templates) by passing the model files, viewed through the web, imported and exported using the CSV standard to third party tools. For presentation purposes the tool can also make a HTML version of the model. Finally, the tool allows the user to check for inconsistencies in the model, and provides the user with some facilities to perform model analysis. These facilities are in general search facilities to either objects or relations. For more automatic high level analysis and model simulation the user should export the model and use other tools (none known to us). Modelling and Concepts: Modelling Domains: METIS covers in principle all desired domains. Domains and metamodels are specified in a template (creation and modification of these templates is discussed in de next paragraph). METIS comes with a generic enterprise modelling ARCHIMATE/D3.1 33

50 template (GEM), we tested this template and it supports: Organization structures with its Persons and where they are Located. Business Processes performed by these Organizations, also linking them up to responsible Persons as well as to what Business Applications support the Processes and what Information and Products are related to the Process. Goals and Strategies of these Organizations, also linking to Change Initiatives and Requirements that may be defined from the Strategies. METIS also offers an IT Management (ITM) template that is used for building visual models of all aspects and issues of Information Technology and Information Systems supporting an enterprise. We also tested this template, it supports: Applications (types, function, external, etc.), business operation (business processes, organisation, product, etc.), business strategy (policies and rules, strategy how, strategy why, and environmental factors), IT infrastructure (technologies, and technical architecture), IT products and resources (products, personnel resources, vendors, etc.), logical architecture modelling (design rules, architectures, etc.), strategic IT considerations (information needs, IT implications, IT requirements, etc.), and transition (IT planning, IT projects, etc.). Modelling Languages: Figure 14 shows the concepts of METIS. The tool regards the whole world as a big model on which different views about it are possible. A model consists of objects and relationships. Views and instance views can be made of this model and be visualized. Different domains can be specified, domains represent particular aspects of the enterprise the user is modelling. They are used to organize the meta-model in a logical way to the user. Metamodels are definitions or collections of definitions for using objects and relationships in a model. Specifically, it defines object types, relationship types, methods that can be performed on particular objects types, criteria that can be used to search a model. Figure 14: Concepts of METIS. Furthermore, the user can create containers; these are special types of objects used to group related objects, including relationships and other containers. 34 STATE OF THE ART IN ARCHITECTURE SUPPORT

51 Analysis: The tool concentrates more on advanced analysis techniques than early ones. It supports analysis by offering several functions the user can perform on the model. The major functions are: search functions, a relationship matrix, and a model validation. For analysis not supported by the tool and simulations the user has to export the model to some other tool (none known to us at this moment). Openness: Standards: METIS can produce HTML-reports about the models. These are HTML files that show the model view on the web browser. METIS model contents can be imported and exported between METIS and other software applications using CSV files (Comma Separated Values). CSV conversion rules are developed using MML (Metis Model Language), and can easily be inspected and controlled before execution. Several predefined CSV-rules are packaged with the product. Vertical/Horizontal interoperability: There is no direct interoperability between tools, perhaps some indirect by using the CSV conversion. However, we are not aware of any tools that support this. 3.4 Testbed Studio General Information: Testbed Studio is an integrated toolset for the design, analysis, and management of business process models. It originated from the Testbed project of the Telematica Instituut and is commercially available from BiZZdesign BV ( ArchiMate users of Testbed include de Belastingdienst, ABP (for process modelling). Several licence types are available. All editions of Testbed Studio are supported with a clear tool manual on how to use the different tool features. More details can be found at: Content Management: Models and components can be saved in a library. A library consists of a shared storage location (typically accessible to more than one user, mostly on a network location) with a local copy for private use. Only by checking in a modification of this local copy, it is stored in the library. Multiple libraries may exist, for example a personal library and a group library. Testbed has a versioning mechanism in which the latest version of a model or component can be compared with older versions. Newer versions can be annotated to make the difference with older versions clear. Also an overview of all the existing versions can be given. Access control is performed by the above mentioned checking in / checking out mechanism: the tool gives precedence over a shared model that has been updated more recently than the local copy. There are no checks regarding data integrity. Functionality: Testbed Studio is a process, organisation & data modelling tool. It offers its own repository for model management, and has limited functionality for information modelling. Basic model operations are straightforward; copy/paste, grouping/ungrouping etc. can be easily done within one model. Copy/paste across models can be accomplished via the library/repository. Merging/splitting is not supported. Import of models is not supported, export can be done to Cosa and Staffware workflow tools. However, the internal ARCHIMATE/D3.1 35

52 format that Testbed uses is XML. The results of some analyses can be exported to Excel. In addition reporting to HTML and Word formats is possible. Modelling: Testbed Studio offers several checks to ensure the semantic validity of the model. Next to this semantic model checker, other functions are available to check the correctness of the model. One is functional analysis, checking preceding and next actions, sequences of actions, mutual exclusiveness and so on. Stepwise simulation can of course be used to illustrate the operation of a business process. Testbed Studio offers analytical and simulation techniques for performance analysis, based on stochastic simulation, queuing theory, graph models and hybrid models. Analysis of completion times, critical paths, resource utilisation, and cost analysis are currently available. Views are used to generate feature overviews of the model. For example, colour views emphasize certain aspects of the model. Other views generated by Testbed Studio visualise precedence relations, labels, tables, dataflow, or the assignment of behaviour to actors. Structural transformations illustrate different aspects of a model structure. An organigram, for example, shows the hierarchical structure of an organisation. A powerful concept is that of process lanes. A business process model can be automatically structured with respect to any attribute. For example, the actions can be structured into a block (sub-process) for every actor involved, showing the change in responsibility in a process, e.g. to reveal the handovers between different organisations. Alternative process lane structures are for example based on the business function associated with an activity, or whether the activity belongs to the primary or secondary part of the process. Openness: Vertical/horizontal interoperability: Testbed Studio offers export filters for vertical interoperability with workflow management tools (Cosa and Staffware). No horizontal interoperability is currently defined. The existing exports are based on a generic import and export mechanism, with which it is relatively easy (for a software engineer) to create new import or export filters. Standards: Testbed Studio uses XML as its native file format, which allows for relatively easy linkage with other tools that also use XML. The experimental e-business evolution of Testbed in use at the Telematica Instituut, RSD Studio, can be directly parameterized with XSLT style sheets for transforming the models to other formats. To date, this has been done for export to ebxml ( business process specifications, and for SVG - the XML-based scalable vector graphics format. Metamodel: The metamodel of Testbed Studio is extensively documented. In principle, this metamodel is fixed. However, the attributes of the individual model concepts can be parameterized by the user. Furthermore, the experimental tool framework for RSD Studio includes a specification language and associated compiler with which you can design and implement your own metamodel and model editors. 3.5 Other tools Enterprise Architect: EA is a UML based software engineering tool ( Enterprise architect comes in two different versions: the Desktop edition (single user) in which it is not possible to share files with other users, and the Professional edition supporting the sharing of a project by replication or shared 36 STATE OF THE ART IN ARCHITECTURE SUPPORT

53 network file. The Professional version also has an ActiveX interface for interrogating EA projects and extracting information in XMI format. The Professional version also fully supports code import/export and synchronisation of model elements with source code and reverse engineering Oracle, SQL Server and MS Access databases. Enterprise Architect supports UML use case, logical, dynamic, component and physical models. You can model business processes, web sites, user interfaces, networks, hardware configurations, messages and more. EA supports copying and pasting of elements. Duplication of entire diagrams is possible. Alignment of elements in diagrams is possible; grouping of elements is not supported. EA provides an automatic layout function, but in complex cases the results are not always optimal. A Package may be imported from and to an XMI (XML based) file. This allows EA Model elements to be moved between models, for distributed development, version control and other benefits. Import of EA model elements from Rational Rose and other tools is not yet supported, but is under development. It also allows limited export of EA model elements to Rational Rose and other tools (which implement the UML1.3 XMI 1.1 standard). It is not possible to merge complete models or split them in separate parts. ARIS started as the academic research work of Prof. A.W. Scheer (see Scheer 1992). It is now a very successful commercial tool for enterprise modelling ( ABN-AMRO is one of the customers of IDS Scheer AG (Other: KPN, AKZO-NOBEL). ARIS provides a repository system that is realised via a database server. The management of database server is performed by a Server Administrator. Databases are used for the storage of models and objects. As far as security aspects are concerned, the tool handles the control of access to the databases using access privileges for users and user groups. The ARIS Model Generation Wizard offers two possible procedures: use of existing models to generate a new model, or directly select individual objects to generate a new model. Selecting, inverting the selection, copying, pasting, splitting and merging of models, part of models and objects are possible in ARIS. Moreover, the ARIS Merge component supports the combination of contents from different ARIS databases or distributing the contents of a database among different databases. With respect to import/export functionality, ARIS Export/Import allow the export data to an ASCII file and the import of data from this ASCII file. This is used for the translation of texts using ASCII files, and to make possible that other applications can access ARIS data via an interface. The domains covered by ARIS correspond to the areas of the ARIS House (see Scheer 1992, 1998), namely: Organisation view, Data view, Process view, and Function view. Each of these views are supported by specific types of models, according to the phase of architecture development (requirements definition, design specification and implementation). The modelling language behind ARIS is EPC (event-driven process chains). The language is tool specific and it is described extensively in Buuren et al. (2002). ARIS also supports UML. Via the report functionality ARIS can export UML Class Diagram Modells to XML files in UML XMI notation. This file can be then imported into Rational Rose 2000 environment (or any other tool supporting XMI) using its XMI interface. For each selected Model a separate export file is created. Direct vertical interoperability is possible with Excel and SAP R/3 (only for import of data). ARCHIMATE/D3.1 37

54 Rational Suite Analyst Studio: The Rational Software Corporation has a website at Rational offers a range of products for requirements & analysis, software development, system testing, project management and team infrastructure. The products available for requirement & analysis are Rational Suite Analyst Studio, Rational Requisite Pro and Rational Rose. All the user s data is stored in files or in a database. Rational supports a variety of databases, including Oracle, Microsoft SQL Server and Microsoft Access. Rational Suite Analyst Studio is a suite of products, including Rational Unified Process, Requisite Pro, Rational Rose, ClearQuest, ClearCase, ProjectConsole, SoDa and TestManager. All tools are integrated. Rational Unified Process Requisite Pro Rational Rose ClearQuest ClearCase ProjectConsole SoDa Testmanager Description of software development process Requirement management Visual modelling tool Change request management Configuration management Project management Report and documentation management Test case management Table 6 Overview of Rational tools Rational Rose is a tool for modelling use-cases in UML. Model components can easily be copied and pasted. Splitting and merging of models is also provided. Models, or parts of models can be imported and exported only in Rational Rose formats. Since Rational are the developers of UML, Rational Rose supports all types of UML diagrams. Rational provides no tools for simulation, performance analysis etc. The methodology support for Rational Rose is provided by Rational Unified Process (see section 2.2.4). The user interface of all Rational Tools is intuitive for users who are familiar with the Microsoft Windows user interface and with UML and Rational Unified Process. All Rational tools offer extensive help-functionality. Select Component Architect is a product of Aonix. ( It is part of Select Component Factory. Select stores all its data in a data repository. Version control and security are integrated parts of this repository. Select supports modelling of a number of (UML) diagrams. These diagrams include Process Hierarchy Diagrams, Process Thread Diagrams, Use case Diagrams, Class Diagrams, Object Sequence Diagrams, Object Collaboration Diagrams, State Diagrams, etc. Select does not support modelling languages other than UML. It focuses on reuse of components and has a number of functions to assist in reuse. The user interface of Select Component Architect is intuitive for users who are familiar with the Microsoft Windows user interface and with UML. ASG-Rochade is a meta-data repository providing a central point for collection, control, management, and reuse of information assets. Figure 15 shows examples of meta-data that can be inserted into the repository. The tool belongs to ASG software solutions, their home page is 38 STATE OF THE ART IN ARCHITECTURE SUPPORT

55 Programs Languages Application Systems Modeling/ Developmen Tools DBMSs Files Records Rochade Repository Video Clips, Word Docs, Sound Bytes, Any Other Meta Data Source Goals Objectives Organization Locations Data and Tools Figure 15. ASG-Rochade Repository ASG-Rochade stores its data in files. These files cannot be accessed directly. Data can only be accessed via client tools or via the Rochade Application programming interface (API). ASG-Rochade is implemented in a client/server architecture, and provides many client tools and applications for accessing the server. An example of such an application is the AutoPilot GUI client (windows), a tool supplied with Rochade to navigate through the repository via single objects, attributes, and relationships, and to visualize and manipulate/update the information. The costumer can create his own client applications using the Rochade Application programming interface (API), including an XML (SAX2) API. Other major features of ASG-Rochade include: N Web-based access to the meta-data. N An XML interface to support exchange of meta-data. N Extensive model management for repository information models (RIMs). N A graphic RIM utilizing the UML component of the open information Model. N Remote procedure call interoperability between platforms. N Support for the Object Management Group s Common Warehouse Meta Model. Among other tool (Data Base Management and Data Warehouse Systems, Languages), ASG-Rochade provides meta data interfaces for the following development (CASE) tools: ADW, PowerDesigner, ARIS Toolset, Cool:Gen, Bachman Analyst/DBA, CoolDat/CoolBiz, Erwin, Rational Rose, Designer/2000, Bpwin, Systems Architect, Select Enterprise, TeamWork, CASE4, Excelerator. 3.6 Tool overview ARCHIMATE/D3.1 39

56 Tool Owner Purpose Modelling Languages Modelling Methods Visualisation Openness Comments Relevance to ArchiMate Microsoft Visio Microsoft diagramming UML and others 2D shapes and connections limited (Visual Basic) widely used; good integration into Office suite; many tools extend Visio ARIS IDS Scheer enterprise modelling Rational Tools Select Component Architect System Architect Enterprise Architect Testbed Studio Metis Rochade RSD Studio Rational Aonix Popkin Software Sparx Systems software UML development & project management enterprise modelling business modelling, data modelling, requirements modelling software engineering tools BiZZdesign business modelling Computas AS ASG Software Solutions Telematica Instituut enterprise modelling metadata repository e-business process modelling UML, EPC ARIS House 2D, context sensitive, excellent model navigation Rational Unified Process good (XML, UML XMI) limited to business modelling, supports UML XMI full range on integrated tools; when working with UML, Rational tools are the preferred modelling tools UML XMI focus on business hierarchy and business processes multiple good (XML) very comprehensive: covers all cells of the Zachman Framework; integrated with MS Office and Visual Basic UML XMI focus on software projects AMBER Testbed 2D, clear diagrams, good structuring, simulation Metis Model Language good (XML) very well documented metamodel good good users can define their own metamodel good (XML, OMG Common Warehouse Network Enterprise Modelling Language RSD 2D, clear Methodology diagrams, good structuring, simulation good (XML) Rochade is a repository and not a modelling tool; provides metadata interfaces for many databases, programming languages, and development tools very well documented metamodel Table 7. Tool overview It is easy to see that ranking such a diverse collection of tools is not an easy task. If we only take into account the differences in terms of applications areas and functionality, it is an obvious matter that a comparison will always be biased by the needs, taste or expertise of the one who is doing it. However, when we gave here our opinion about the surveyed tools (see the last column of Table 7), we based our judgement on arguments like single or multi domain, comprehensiveness, success in the market, user interface and visualisation features, interoperability, price/quality, ratio, in-house expertise etc. A number of overall conclusions can be drawn from our survey: N There is a broad offering of UML tools and BPR tools. N With every new version, both types of tools strive to cross the borders of their initial application-domain, towards the opposite type, in order to become more and more comprehensive. There is a price to pay for this approach: tools became more and more complex and require supplementary efforts and expertise for usage. The so-called learn while you work is no longer an option: huge documentations of thousands of pages came together with tools. 40 STATE OF THE ART IN ARCHITECTURE SUPPORT

57 N N N N N N N N Most of the tool providers, tend now to supply their tools with methodologies and architectural frameworks. There are extremely few tools that truly support cross/multi domain modelling. There is little support for traceability. There is little support for impact-analysis or what-if analysis. In terms of visualisation, most of the tools use only 2D techniques. There is little support for multiple (perspective) visualisations per view. Except for UML, there is no other standard modelling notation. In fact the ability to support UML, has became a common reference point for most of the tools. The majority of tools still have a long way to go to achieve interoperability. ARCHIMATE/D3.1 41

58 4 Analysis and Visualisation Techniques 4.1 Analysis techniques In an architecture development/change process there are at least two moments when the usage of analysis techniques is required. In the early stages, of the architecture development process the primary goal is to formulate a model of the problem domain. To this purpose, techniques such as use cases and scenario base analysis are the most appropriate. In this respect, ArchiMate might benefit from a methodology for the definition of SMART Business Scenarios proposed by TOGAF (see section 3). Secondly, analysis can be used in a more advanced stage of architectural development. Namely we refer to an evaluation of how well the implemented/designed architecture meets the initial requirements using a number of quality attributes like: robustness, completeness, granularity, minimality, efficiency and effectiveness, perspicuity, precision/granularity, consistency, dependency, adaptability and modifiability etc. Typical such analysis techniques are simulation, performance analysis, quantitative and qualitative analysis. An overview of such techniques is provided in section However, in practice, there is no clear separation between the two types of techniques. It might very well happen that combinations of both types are used, or that the very same technique is used for different purposes at different moments of the development process. The best example that supports this statement is the family of analysis techniques SAAM, ATAM and ARID (developed by Kazman, Klein, Clemens et al., see section 3), that use scenarios for the assessment of various quality attributes Scenario Based Analysis SAAM: The Software Architecture Analysis Method (SAAM) was developed by Kazman et al. (1994). It is a scenario-based method and it provides means to characterise how well an architectural design responds to the demands placed on it by a set of scenarios, where a scenario is a specified sequence of steps involving the use or modification of the system. The main steps of SAAM are: scenario development, architecture description, scenario classification, indirect scenario evaluation, assessment of scenario interaction, overall evaluation. The quality of SAAM resides in its simplicity. SAAM is not proposing heavy methodological procedures. In fact an evaluation does not necessarily need to perform all the steps described in the method. Moreover, although it was designed for the analysis of software architectures, because of its simplicity we believe that the method can be applied in a broader context (e.g. in the analysis of enterprise architectures). We also find very important for Archimate that SAAM is not trying to analyse a whole range of ility attributes (like maintainability, security, scalability, performance, reliability etc) that are too general, complex and also amorphous to be evaluated in a simple way. Instead SAAM promotes the context-based analysis, meaning that any attribute evaluation should be placed trough proper scenarios in the particular context of the system. One point where SAAM is not very clear concerns the measurement of the complexity and extent of the architectural changes for a particular indirect scenario. ATAM: The Architecture Tradeoff Analysis Method (ATAM) was developed by Kazman, Klein and Clemens (see Kazman et al. 2000). The purpose of the method, as stated in 42 STATE OF THE ART IN ARCHITECTURE SUPPORT

59 Kazman et al. (2000), is to assess the consequences of architectural decisions in light of quality attributes requirements. The three key concepts on which ATAM is based are quality attribute characterisation, scenario and attribute based architectural style. Each quality attribute characterization is divided into three categories: external stimuli, architectural decisions, and responses. In ATAM are identified three types of scenarios: use case scenarios (these involve typical uses of the existing system and are used for information elicitation); growth scenarios (these cover anticipated changes to the system), and exploratory scenarios (these cover extreme changes that are expected to stress the system). The steps of the method are as follows: Presentation (Present the ATAM, Present business drivers, Present architecture), Investigation and Analysis (Identify architectural approaches, Generate quality attribute utility tree, Analyse architectural approaches), Testing (Brainstorm and prioritise scenarios, Analyse architectural approaches), Reporting (Present results). ATAM is clearly a specialisation and development of SAAM. It is primarily targeting the analysis of software architectures, which makes it of limited interest for Archimate. However, we want to emphasize the concept of utility tree and the categorisation of scenarios, that we consider valuable for the analysis part of Archimate. ARID: Active Reviews for Intermediate Designs (ARID) is a method for reviewing preliminary software designs (such as for a component or a subsystem) for suitability in its intended usage context and environment. It relies on assembling the design's stakeholders to articulate what the important usage scenarios. ARID was developed by the same authors as ATAM, and therefore it is closely related to it. ARID consists of 9 steps divided into two phases (see and it resembles with a brainstorming excercise: Phase 1: Rehearsal. First, a meeting between the lead designer and the review facilitator takes place to prepare for the exercise and in which the following steps are taken: Step 1: Identify reviewers, Step 2: Prepare design briefing, Step 3: Prepare seed scenarios, Step 4: Prepare materials. Phase 2: Review. Next, the stakeholders are assembled and the main activities of the review commence: Step 5: Present ARID, Step 6: Present design, Step 7: Brainstorm and prioritise scenarios, Step 8: Apply scenarios, Step 9. Business scenarios and the TOGAF ADM: An interesting methodology (that might be relevant for the partner specific research and application cases in Archimate) is provided by the architecture development method of TOGAF for the development of good business scenarios. Business scenarios are in this case perceived as instruments to identify the business requirements, which will be further on used to derive the characteristics of the technical architecture. According to TOGAF ( a Business Scenario describes: N a business process, application, or set of applications, enabled by the architecture N the business and technology environment N the people and computing components (called "actors") who execute the scenario N the desired outcome of proper execution ARCHIMATE/D3.1 43

60 A good Business Scenario is also "SMART": N Specific, by defining what needs to be done in the business N Measurable, through clear metrics for success N Actionable, by clearly segmenting the problem, and providing the basis for determining elements and plans for the solution N Realistic, in that the problem can be solved within the bounds of physical reality, time and cost constraints N Time-bound, in that there is a statement of when the solution opportunity expires. The phases of developing a business scenario, a business scenario template and a number of guidelines for each development phase are also proposed Performance analysis Few approaches exist for performance analysis based on architectural descriptions. As performance is a dynamic property, it requires at least a model of the dynamic aspects of a system (e.g. processes or a workload description). Moreover, it may be influenced by the static aspects of a system (e.g. resource constraints). Performance issues can be considered at both the business level and the application level (including technical infrastructure). In principle, similar analysis techniques can be used for both. Performance measures of interest include process completion times or application response times, throughputs and resource utilisations (either organisational resources or computing resources). Basically, three classes of methods can be applied to derive estimates of performance measures of any system, at the organisational level, application level as well as the technical infrastructure level: measurement, (quantitative) simulation, and analytical methods (Jonkers and Franken 1996). N Measurements can only be carried out if the system of interest is already operational. Therefore, they will be of limited use for the guidance of the process design, because they cannot be used to obtain performance predictions. However, measurements are useful to obtain benchmark measures, and to calibrate model parameters. In this category falls the sensitivity analysis, which is concerned with the assessment of how sensitive is the output of a certain system to parameter change. N (Quantitative, discrete-event) Simulation is the direct execution of a model, which is expressed in either a special-purpose simulation language or a general-purpose programming language. It is a very powerful tool, because it enables the study of every system aspect to any desired level of detail. However, a drawback is that it is timeconsuming. Moreover, it results in numeric, non-parameterised results, so that a separate simulation run is required for each parameter selection of interest. Also, because nearly all models contain sources of non-determinism, simulation yields a confidence interval rather than an exact prediction of the performance measures. N Sensitivity analysis shows how sensitive are the outputs of a system to changes of the input parameters. N Analytical solution techniques derive performance measures (either exact or an approximation) in a mathematical way. They can be subdivided in symbolic techniques and numeric techniques. A drawback of (especially symbolic) analytical techniques compared to simulation is that the class of models, which are analytically tractable is limited. 44 STATE OF THE ART IN ARCHITECTURE SUPPORT

61 As a guideline for the selection of an appropriate analysis method in a given situation a number of criteria can be applied. N The usefulness of performance predictions largely depends on their accuracy. Two main sources of prediction errors can be identified: analytical errors (in the case of approximate analysis techniques), and modelling inaccuracies, which are due to the fact that a model is a simplification of the real system. The latter can be caused by insufficient insight in the structure of the real process, insufficient expressive power of the modelling formalism, or errors in the model parameters. N The robustness of the results is important in addition to the absolute accuracy. A technique which yields reasonably accurate results over a whole range of possible parameter settings will generally be preferable to a technique which yields very accurate results for some parameter settings, but results in high errors for certain extreme values. N The efficiency (inversely related to the analytical complexity) of a performance prediction technique determines whether the results are obtained within acceptable computing time. Of course, what is still acceptable strongly depends on the application of the predictions: in early design optimisations, when a large number of alternative solutions must be compared, we need very quick results, while in the final stages, when fine-tuning the design, more time-consuming analysis techniques might be justified to obtain more accurate results. A central issue in performance modelling is the trade-off between expressive power (which directly influences the accuracy) and analytical tractability. Therefore, the requirements of accuracy and efficiency are in conflict, so that in practice a compromise must be sought. Many different types of analytical performance prediction methods exist, generally associated with different modelling formalisms. These methods mainly differ in the position they occupy on the trade-off between prediction accuracy and efficiency. N Static techniques are used to quickly obtain first-order performance estimates based on process structures (Fahringer 1995, Gemund 1996). Critical path analysis of (business) process models (Jonkers et al. 1999) falls into the same category. N Traditionally, queueing models have been one of the most popular techniques to analyse the performance effects of resource sharing. Their main application area has been computer and telecommunicaiton systems and production systems. For an overview of queueing theory, we refer to, e.g., Harrison. and Patel (1993). N Techniques based on (timed, stochastic) extensions of Petri nets (Ajmone, Balbo and Conte 1986) yield accurate results, but are time-consuming due to a state explosion (which results in a complexity which is exponential in the model size). N Between these extremes, several techniques exist to obtain reasonably accurate results at moderate complexity, which are usually a hybrid of the above-mentioned techniques (e.g. static techniques and queueing models, or Petri nets and queueing models). A more elaborate explanation of these techniques is beyond the scope of this document. For more details, we refer to, e.g., (Ajmone, Balbo and Conte 1986, Gemund 1996, Harrison. and Patel 1993). 4.2 Visualisation techniques In this section we will make an inventory of visualisation techniques currently used in the presentation of (system) designs or of complex information structures. Since one of the ARCHIMATE/D3.1 45

62 main concerns of ArchiMate is related to the visualisation of architectures, we have considered that a presentation of the role of visualisation techniques in the graphical appearance of models would be also appropriate. There are three main areas of concern when discussing architecture visualisation: 1. First, there is the readability of architecture diagrams. This is dependent on and significantly influenced (in better or in worse) by the use of visual attributes in diagrams (see section 4.2.1). 2. Second, given the variety of content types of architecture reports (various views, types of models, concepts etc.) it is essential to find the right visual expression for each type of architecture report by using the right graphical notation (standardised or not) and means to easily link them and navigate from one to another (see section 4.2.2). 3. Third, when designing the visual appearance of architecture models the various user groups architectures must be taken into account, so that the visual representation is adjusted to their understanding, culture and needs (see section 4.2.2) The use of visual attributes in modelling In this section we make a summary of the common features characterising most of the graphical conventions used in the field of modelling. Where necessary we illustrate them with example diagrams. Some of items in this list are inspired by the work of Oude Luttighuis et al. (1999) and Koning et al. (2002). Forms of objects: N N N N The forms of objects, usually match the intrinsic properties of the objects (for example, the cylinder shape for a data-storage, an agent is represented by a human stick-figure, etc. see Figure 16). There is a tendency to use realistic (possibly three-dimensional) symbols for concrete and tangible objects (e.g. cylinder, human figure, factory symbol, graphics of computers) and use simple, geometric shapes for abstract concepts (e.g. action, function, class, actor etc.) and architectural constructs (e.g., rectangles rounded or not, ovals, circles, cubes, balls, cylinders, cones) (see Figure 17). Similar objects are usually represented by graphical symbols of equal size, unless a difference in size is intentionally meaningful (see Figure 17). The number of graphical symbols types used in one type of diagram is usually limited to STATE OF THE ART IN ARCHITECTURE SUPPORT

63 Figure 16.Example of use case diagram Figure 17. Example of a flow diagram Connectors: N In architectural models connectors between objects are intended to express a certain relationship between the connected objects. Examples of such relationships are (temporal) precedence, causality, inheritance, hierarchy, membership etc. N Connectors are typically represented by (straight, rounded, curved) lines. Rounding of bends is used to give the impression of flow. N Some types of connectors are also provided with line ends like arrowheads, (solid or empty) diamonds. The common purpose of line ends is to indicate that the relationship between the connected objects is ordered. N In order to differentiate several types of relationships (like for instance flow of goods, flow of money, and flow of information), different line widths (e.g. thicker lines) or appearances (dotted lines, double lines etc.) are used. Use of colours: The text in this section is based on information collected from N Using a distinct colour in a diagram for an object with a particular attribute, can program the meaning of that colour for the rest of the models describing a particular architecture. It is important to keep in mind that colours can enlarge the appeal of the diagram, but can also lead to contrary effects by abusive usage of them (such as confusion, distraction, eye fatigue, difficulties in following the diagram). N The number of colours used in a diagram is usually limited to seven, plus or minus two, because seven seems to be the optimum number for short-term memory. N Colours in models are meaningful and consistent with the rest of the design. N There is a perceptual order to colour that follows the colour spectrum of red, yellow, green, and blue. When viewing these colours, red tends to focus in the foreground, yellow and green focus in the middle, and blue focuses in the background. Consequently, red is usually used to emphasize a feature, while blue is used for backgrounds. N Different objects/concepts are usually represented with different colours. N There is a language to colour, based on the culture, education and experience of people. Colours can be very symbolic (red implies importance or danger; yellow refers to caution). ARCHIMATE/D3.1 47

64 N N N Colour has physical and emotional effects on the viewer. For example, red is exciting, green restful, and blue is cheerful. The simultaneous display of highly saturated or pure colours is in general avoided, because the wrong combination of these colours for backgrounds and foregrounds can create effects that cause eye strain. The colours selected for small texts, thin lines, and small shapes are usually saturated or pure. If contrary, the edges of these objects will tend to blur and blend into a white background. Graphics and icons in diagrams: Figure 18. Example of use for graphics and icons (Metis) Small graphics & icons can be very useful to make diagrams appealing. However, their usage in modelling languages is limited and mostly suited for non-technical models. Adding graphics & icons might also be useful for a quick categorisation (e.g. indicating all functions related to organisation charts, products or personnel see Figure 18). Use of text: N Text can be very strong in suggesting the proper interpretations and associations and in stimulating thinking. The guidelines on the use of text try to stimulate the architect to be diligent in adding proper titles, subscripts and annotations. Text is important to speed up the building up of a mental model and a line of reasoning. N Some modelling languages (e.g. Testbed, IDEF0) define naming conventions, which are aimed to associate implicitly a certain type of object with a grammatical construct. Such conventions might also refer to the use of capital letters for names. N Most of the used names are short (if possible consisting of one word), clear and unique. These will allow a quick identification of an object throughout the whole architecture. N Many developers of tools use text to indicate the cardinality of a relationship or an object. N Object attributes are shown as text, not as separate nodes (e.g. UML). 48 STATE OF THE ART IN ARCHITECTURE SUPPORT

65 Layout patterns: N A good layout is perceived instantly and almost unconsciously. An unclear layout keeps nagging and hinders perceiving the more detailed information. Providing enough, but not too much, white space makes diagrams elegant. N Putting the objects in a diagram in a pattern that is easily recognizable and fitting to the underlying message, is a great aid to the viewer of the diagram. It very much helps in discerning and remembering which objects there are and which relationships are relevant to consider. N Layout aspects of a diagram include: basic pattern, horizontal and vertical alignment (e.g. left-to-right process flows), above/before positioning, symmetry, distance of objects from the centre and from other objects, distribution of white space, distribution of connectors with an emphasis on avoidance of intersecting connectors, density of objects and connectors. Figure 19 is an example of a diagram in which attention was paid to choosing a basic pattern and proper horizontal and vertical outlining of objects. Order-to-cash standard machine-made rugs search result project file file order database to financial settlement no longer in stock cancel order delayed delivery accepted confirm delayed delivery order ready capture to ship authorize/capture downpayment remaining amount select rug send order authorize full payment forward to supplier re-check availability delayed delivery requested confirm in stock order capture full amount to fulfilment Figure 19. Example of layout Techniques 2D and 3D visualisation techniques All the surveyed architecture support tools use 2D visualisation environments. That is a general indication that 3D graphics does not necessarily improve the quality and the perception/understanding of architectural models. Moreover, since in general all these tools are conceived to support modelling of large systems, a 3D representation of large diagram would be an unnecessary complicated problem. A second general remark is that models are represented as directed or undirected graphs. Edges/arcs in such graphs have attached a precise semantics (e.g. flow or precedence/causality relation) and a precise representation (specific lines, arrowheads etc.). There is a general tendency in modelling to avoid as much as possible edge intersections in order to increase the clarity of representations. Nodes correspond to different instances of modelling concepts and are represented with different graphical symbols depending on the concept they instantiate. Nodes and edges/arcs are very often labelled according to a naming code in order increase their semantic significance. A special type of graph used in the visualisation practice is the tree. It is primarily suited for ARCHIMATE/D3.1 49

66 the representation of hierarchies, such as organisational charts, functional hierarchies, class hierarchies etc. Circuits in model representations are in most of the cases associated with a repetitive part of a process. In the area of 2D architecture visualisation two graphical notations have been the most successful in imposing themselves over the years as de facto standards: the UML notation and the IDEF notation. An argument supporting this statement is that a number of architecture support tools are providing support for their usage in modelling. 3D approaches for architectural models visualisation are not essentially different from the 2D ones, in the sense that they still provide representations of graphs (seefigure 20). The notable difference is that the nodes are represented by 3D graphic primitives like spheres, cones, cubes, etc., and the resulting graph can be moved, rotated etc. in order to create the sensation of immersion/walk through the model (Feijs and De Jong 1998). Figure 20. 3D visualisations (from different angles) of a software architecture using ArchView VRML generator source: Feijs, De Jong 1998 An interesting 3D approach to architecture modelling can be found in Schönhage et al. (2000). The paper gives a detailed (technical) account of the realisation of 3D visualisations of GAK business processes. Dynamic visualisation: simulation & animation Simulation (see Stam and Proper 2000, Weston and Guilders 1996) can be described as the process of developing a simulation model of a real system and experimenting with this model in order to gain insight in its behaviour under various circumstances. Simulation and animation techniques can be very helpful in the field of architectures for finding a valid solution for a problem. Instead of trying to compute a valid solution (which is impossible or infeasible for many problems), with simulation and animation one can try several candidate architectures and analyse their benefits and shortcomings. Simulation is also a powerful instrument to define and capture the dynamic behaviour of a system s architecture (like behaviour, process, events, flows etc.). This can help in the evaluation of several strategies to move from a current situation of the system to a future (visionary) situation. Multiple perspective visualisation 50 STATE OF THE ART IN ARCHITECTURE SUPPORT