consortium consists of ABN AMRO, Stichting Pensioenfonds ABP, the Dutch Tax and. Customs Administration, Ordina, Telematica Instituut, Centrum voor ...
Tool Support for Enterprise Architecture – A Vision Hugo ter Doest, Marc Lankhorst Telematica Instituut Enschede, The Netherlands +31-53-4850485 {hugo.terdoest, marc.lankhorst}@telin.nl
1 Introduction In current business practice, an integrated approach to business and IT is indispensable. Without such a vision, the IT infrastructure will never adequately support the business, and vice versa, the business will not optimally profit from IT developments. In most companies, however, the alignment between business and IT is problematic. People from both these worlds speak different languages, making it difficult to get an insight in, let alone actively manage, this relationship. This lack of alignment is an important problem, because changes in a company’s strategy and business goals may have significant consequences within many domains, such as for the organisation structure, processes, software systems, data management and technical infrastructures. Enterprise architecture is an important instrument to address this company-wide integration. It is a coherent whole of principles, methods and models that are used in the design and realisation of the enterprise’s organisational structure, business processes, information systems, and infrastructure. However, in practice these domains are not approached in an integrated way. 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. Although some commercially available tools provide the comprehensive functionality needed to develop and maintain enterprise architecture, in general tools provide partial support, do not integrate with other tools and cannot be sufficiently configured for the enterprise’s context Organisational effectiveness is not obtained by local optimisations, but is realised by wellorchestrated interaction of organisational components. To create such an integrated perspective on enterprise architecture, one needs both a description technique for architectural models and tool support to realise this in practice. It would not be realistic to suppose that companies will throw their existing design practice and tools overboard and replace these by an entirely new approach. Rather, enterprise modelling should focus on bringing together already existing techniques and integrating these at the appropriate level of abstraction. We expect that in 7 years from now, enterprise architecture will be a real-time tool for management and redesign of the enterprise for better performance, flexibility and agility. The alignment of business and IT will be managed through a series of integrated views on the enterprise, each covering an appropriate set of concerns for the stakeholder addressed. There will no longer a boundary between the descriptive nature of architecture models and the operational side comprising a.o. business process management and IT management. Enterprise architecture will be the skeleton on the basis of which all assets of the organisation are managed, designed and improved. Tools for enterprise architecture will offer a dashboard-like environment for managing and controlling the enterprise while offering navigation to other tools like domain-specific modelling tools, ERP tools or network management tools.
In 3 years from now, enterprise architecture will be mature as a tool for description and analysis of complex organisations. A standardised and validated language will be available for creating EA models that integrate and relate domain-specific models. Tool support includes modelling tools for enterprise architects that support integration of models in domain-specific languages, design support like patterns and best practices, analysis and comparison of alternative designs, etc.; for other stakeholders such as managers and board member, decision support tools and easy-to-understand presentations can be created automatically. Tool integration is an intrinsic part of tool support for EA, since we believe that tool support for EA cannot be realised by one “holy grail” tool, but will be realised by the integration of domain-specific tools combined with EA tools that add the EA concepts and establish relations between domain-specific models. Such a tool infrastructure puts strong requirements on existing and future tools, since it requires not only a technical integration of tools and components, but also a conceptual integration that accommodates relations and mappings between concepts used in different languages and tools.
2 Enterprise Architecture Tools in the Market The market for EA tools is still immature, the number of tools available limited, and tools that are available suffer from partial support for enterprise architecture and limited interoperability with other tools. Often, partial support is due to the fact that tools presented as EA tools originally were domain-specific tools developed for software or business process design. The weak interoperability between tools has a both technical and a conceptual aspect. Technically, tools are not designed with interoperability in mind. Of course, a lot of tools have the ability to import or export XML Metadata Interchange (XMI) for the UML and some have features to read file formats of other files. However, often these functionalities have the sole purpose of facilitating the migration from other modelling tools. Conceptually, tools are built for creating models in a specific modelling domain, and not for modelling relations to models or objects outside that domain. EA tools that are currently available in the market can be subdivided in the following categories (see also Figure 1): 1. EA modelling tools: These are genuine EA modelling tools that cover a wide range of modelling concepts across different architecture domains. 2. Software modelling: These are software modelling tools that extend their scope to business process modelling and EA modelling by adding concepts and diagram types. 3. Business process modelling: Similar to the software modelling tools, these business process modelling tools extend their scope with IT-related concepts and higher level concepts for EA modelling. 4. Repositories and IT management: Metadata repositories and IT management tools that add modelling and analysis capabilities that partly cover the functionality that can be expected from EA modelling tools.
Enterprise architecture modelling
Software modelling
Business process modelling
Repositories and IT management
Figure 1. Position of tools
3 Importance of MDA for Enterprise Architecture Currently, Model-Driven Architecture (MDA) of the Object Management Group (OMG) is changing the way in which software is developed fundamentally. MDA wants to raise the level of abstraction at which software solutions are specified by defining a framework supported by a collection of standards that sets a standard for generating code from models and vice versa. Now already, MDA-based software development tools support the specification of software in UML instead of in a programming language like Java. Recently, OMG has extended the focus of MDA to business-oriented concepts and languages. A language for business process specification has already been published, and languages for description of business rules and business models are currently being developed. Just like UML, these new languages will be developed within the MDA framework. These developments will make MDA just as relevant for enterprise architecture as it is now for software development. The Meta Object Facility (MOF) is a standard for repositories that plays a central role in the MDA framework. A MOF-compliant repository makes it possible to manage models in an integrated fashion, even when the models are expressed in different languages. In order to make a repository effective for EA, it must be possible to model relations between models in the repository. MOF in itself does not offer a solution for this, but models in a modeling language like ArchiMate can be added in order to model these relations. In addition to MOF, OMG is developing QVT (Queries, Views and Transformations), which will address the way mappings are achieved between models whose languages are defined using MOF and will define a standard way of querying MOF models, and creating views onto these models. These developments give perspective on a set of domain-specific languages that cover the complete enterprise in an integrated and consistent way. We expect that in 5 to 10 years the MDA framework and MOF will be as important for enterprise architecture as these standards are now for software development.
4 Tool Infrastructure In order to make our vision tangible, we have defined a reference architecture that integrates both domain-specific tools and (new) tools for EA. The foundation of the architecture is a repository for storage and retrieval of models, metamodels, viewpoint specifications and views. Another key element of the architecture, although not explicitly mentioned, is a
language for description of enterprise architectures that enables integration of existing domain-specific architectures, architecture design and analysis, decision support and communication. EA Modelling Tool
Viewpoint Designer
View Presentation Tool
Impact of Change Analysis Tool
Quantitative Analysis Tool
EA Service Layer Content Selection, Model Transformation, Viewpoints, Views
modelling Domain-specific tool Modelling Tool
EA Model
modelling Reporting tool Tool
UML Model
BPMN Model
modelling Scanning tool & Monitoring
Repository
Data Model
Workflow Model
...
Figure 2. Tool infrastructure for enterprise architecture The EA Service Layer in between the repository and the EA tools at the top provides services for the manipulation of models and views: • Selection of content from domain-specific and EA models; • Transformation of domain-specific models to an EA language and vice versa; • Creation and maintenance of views; • Specification and management of viewpoints. The infrastructure outlined here requires the integration of existing tools with a repository, and the integration of EA tools with the EA Service Layer. Technically, the integration of tools can be characterised by the following aspects:
•
Data integration addresses the issue of sharing data between tools and the storage of diagrams, models, views and viewpoints.
•
Control integration addresses the issue of communication and coordination between tools (and the integration framework, if existent).
•
Presentation integration concerns the user interaction with the integrated set of tools. Some frameworks completely wrap the existing interfaces whereas others keep original interfaces intact and offer integration through a repository (model integration).
This is similar to the well-known ‘model-view-controller’ pattern. In our vision, a well-integrated suite of cooperating EA tools should adress all three integration aspects. Based on the reference architecture from Figure 2, the ArchiMate project has defined a tool architecture for the so-called ‘ArchiMate workbench’ that does exactly that. Data integration is achieved by means of the ArchiMate language. This is an enterprise modelling language that is broader in scope than existing modelling languages, covering the product, process, information, application, and technology domains.It acts as an ‘umbrella’ over modelling languages such as UML that cover specific domains.
Control integration is addressed by tool-specific adapters that may invoke native tools for the lower-level languages. Presentation integration is realised by the graphical user interface of the ArchiMate workbench. The workbench architecture consists of three tiers: a workbench tier, an integration tier and a tool tier (Figure 3). The main component in the workbench tier is the ArchiMate workbench: The workbench allows the manipulation of models expressed in the ArchiMate modelling language. Each model conforms to a viewpoint that defines which modelling constructs are allowed, with which symbols these constructs are presented and which connections these constructs are allowed to have. Workbench tier
ArchiMate viewpoint
ArchiMate workbench
ArchiMate model
controls Integration tier
Integration schema
Tool-specific adapter
Integration content
controls Tool tier
Modelling schema
Modelling tool
Tool-specific model
Figure 3. The 3-tier workbench architecture In the tool tier a modelling tool may be used to design tool-specific models according to a specific modelling language. To allow ArchiMate models to elaborate upon or break down into tool-specific models, the integration tier glues modelling tools into the ArchiMate workbench. The glue used is a tool adapter specific to each modelling tool: a tool-specific adapter. This adapter can perform transformations between tool-specific models and integration content. Along with integration content, a tool-specific adapter provides the workbench with an integration schema describing the underlying modelling language in terms of possibly specialised ArchiMate constructs. As a validation, a prototype has been built that shows the feasibility of this workbench architecture. To illustrate its value we present an example: An existing UML model and an existing business process model are integrated in an ArchiMate model (Figure 4). Damage claiming process
Registration
Acceptance
Valuation
Formal claim
Payment
Registration
Acceptance
Valuation
Payment
Risk assessment service
Payment service
External application services
Policy (contract)
Claims administration service
Customer administration service
Application components and services
Customer administration
Central administration
Risk assessment
Claims administration
Customer administration
Financial application
Claims administration
Risk assessment
Claim information service
Financial application
Figure 4. An ArchiMate model (right) based on an existing business process model (top left) and a UML application model (bottom left). The UML model depicts a number of application components that are used by our imaginary insurance company ArchiSurance. The components are translated to ArchiMate components in a straightforward way. The Testbed model represents a number of process blocks that realise claim handling from registration to payment. This model is translated to ArchiMate concepts as well. Now, the workbench can be used to order the objects and define relations
between them. In this case a layered architecture is created with services that are realised by components and provided to business processes. This results in a view relating business processes to IT components by means of service concepts. The GUI of the workbench prototype divides the application window in three frames (Figure 5): A content explorer, a canvas for modelling and a concept explorer.
Figure 5. Workbench user interface. The canvas (center) shows the currently opened ArchiMate model. Objects may be added to the model in two ways:
•
Objects from the content explorer may be dragged and dropped onto the canvas. These objects are in fact references to objects in the underlying tool-specific models.
•
Constructs from the concept explorer may be dragged and dropped onto the canvas. This way, newly created instances of those constructs are added to the model.
The content explorer (left) shows hierarchical representations of the tool-specific models on which the currently open ArchiMate model is based. These tool-specific models have been translated into (possibly specialised) ArchiMate concepts. The concept explorer (right) shows only those concepts from the ArchiMate language that are relevant to the current viewpoint.
5 Future of Enterprise Architecture Tool Support In our vision, enterprise architecture will become a real-time tool for management and redesign of the enterprise for better performance, flexibility and agility. The alignment of business and IT will be managed through a series of integrated views on the enterprise, each covering an appropriate set of concerns for the stakeholder addressed. To realise this vision, tool integration is of critical importance. We believe that tool support for EA will not be realised by a single tool, but will be realised by a combination of domain-specific tools and EA tools that add the EA concepts and establish relations between domain-specific models. The tool integration workbench we have presented is such an EA tool that is able to integrate domain-specific models. Leaving existing modelling environments intact, the workbench allows the concurrent design of enterprise architecture domains: each domain may still be
designed using its own languages, tools and techniques. More importantly, with the ability to reason across domain boundaries the workbench introduces an instrument for collaborative design. By adopting the ArchiMate modelling language, the workbench not only allows the integration of existing modelling languages, but provides a language to communicate across domain boundaries as well. Moreover, the workbench serves as a starting point for the analysis of enterprise architectures using generic analysis techniques that rely on the ArchiMate modelling language. The future of tool support for enterprise architecture depends on tool integration. The success of tool integration depends heavily on standardisation organisations and tool vendors. Vendors of modelling tools need to standardise their modelling languages and concepts on the one hand, and their interfaces and storage formats on the other hand. Repository vendors need to offer “model-intelligent” repositories and standardised interfaces and exchange formats for models.
Acknowledgments This paper results from the ArchiMate project (http://archimate.telin.nl), a research initiative that aims to provide concepts and techniques to support enterprise architects in the visualisation, communication and analysis of integrated architectures. The ArchiMate consortium consists of ABN AMRO, Stichting Pensioenfonds ABP, the Dutch Tax and Customs Administration, Ordina, Telematica Instituut, Centrum voor Wiskunde en Informatica, Katholieke Universiteit Nijmegen, and the Leiden Institute of Advanced Computer Science.
