aris enterprise architecture solution - arise consulting · business process excellence white paper...

Business Process Excellence

White Paper - March 2006

ARIS Enterprise Architecture Solution

2 © IDS Scheer AG – March 2006

Table of contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42. Technical Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.1 Definition of architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.2 Definition of the Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52.3 Evolution of Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62.4 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3. Business Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83.1 The Business Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83.2 The Organizational Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93.3 The Business Performance Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93.4 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

4. Architecture Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114.1 The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114.2 The ARIS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134.3 The TOGAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .144.4 The FEAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

5. EA Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165.1 Coordination of architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165.2 Descriptive capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175.3 Implementation capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

6. ARIS Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186.1 Approaches to architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186.2 Descriptive role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186.3 Technical properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196.4 Implementation role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208 Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

List of figures

Fig. 1: The Classic Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6Fig. 2: The Y-CIM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Fig. 3: The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Fig. 4: The ARIS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Fig. 5: The Balanced Enterprise Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

© IDS Scheer AG – March 2006 3


1 Introduction

The concept of Enterprise Architecture has been around for quite some time. However, it gained considerablemomentum at the beginning of this century for a variety of reasons. Perhaps the most important was an acceler-ation of environmental changes for organizations in all industries. The concept of organizational agility was coinedas a strategic imperative. In other words, the capability to detect environmental change and respond effectivelyto that change became a condition for long-term survival and growth.

Quick and effective changes are not possible today without changes in IT application systems and infrastructures.As it turned out, in many companies relationships and interfaces between applications were not properly docu-mented and understood to facilitate planning and implementation of required changes. Application integrationefforts required extensive analysis and took longer than expected. In other companies, the same was true for man-ual activities and information flows. Actually, any larger-scale change in business processes runs into a risk ofunintended consequences and side effects. Elsewhere, due to e-business requirements, there was a need to stan-dardize inter-organizational business processes. This was also difficult because details of external relationshipswere not formalized.

The need to describe enterprise elements and their interrelationships, as well as to analyze them, became appar-ent in the business and IT domains. The growing interest in tools to support architecture efforts was noticed bysoftware vendors. However, around 70% of enterprises use office automation and drawing tools to support enter-prise architecture projects 1. To a large extent, it is closely coupled with a low degree of maturity in this respect.Some experts predict that this will change in the nearest future and more organizations will use sophisticatedtools to support their efforts. The objective of this white paper is therefore to position ARIS Platform within theEnterprise Architecture (EA) solution space.

2. Technical Architectures

2.1 Definition of architecture

There are many competing, technically-oriented definitions of architecture. The IEEE RecommendedPractice for Architectural Description of Software-Intensive Systems (IEEE Std 1471-2000) defines architec-ture as ”... the fundamental organization of a system embodied in its components, their relationships toeach other, and to the environment, and the principles guiding its design and evolution.” 2 Architecture istherefore defined as a property of an object. Other definition explains the meaning of architecture as a ”...well defined form of system description in terms of components, connections and composite structures.”3 In this definition, architecture is understood as an object of its own right. It is this definition that is mostpopular and commonly used.

Such conceptual differences, while fundamental, are probably of little concern for practitioners, who dealwith architectural descriptions and artifacts anyway. More important in practice is a difference between adescriptive and a prescriptive meaning of architecture. Gartner Group defines architecture using two alter-native definitions as:

• An overall concept employed in creating a system, also an abstraction or design of a system, namelyits structure, components and how they interrelate

• A family of guidelines (concepts, principles, rules, patterns, interfaces and standards) to use whenbuilding a new IT capability 4.

Although alternative, the two architectures as defined above are closely related. As interpreted using thefirst definition, architecture is a description of something that exists or is planned. In this meaning, archi-tectural descriptions are used for analysis and planning purposes. Architecture in the second interpretationis used to support the transition process from the present state to the future one. The guidelines guidebehavior and facilitate decision-making along the way.

2.2 Definition of the Enterprise Architecture

This white paper is focused on descriptive architectures. Using such interpretation, the EnterpriseArchitecture is an abstraction of an enterprise, namely its elements of various types and their interrelation-ships. The classic Enterprise Architecture originated within IT industry is commonly partitioned into fourparts or subsets:

• The Business Architecture, which defines the business strategy, governance, organizational structuresand business processes.

• The Applications Architecture, which provides a blueprint for the individual application systems to bedeployed, their interactions and relationships with the supported business processes.

• The Data Architecture, which describes the structure of an organization’s logical and physical dataassets, as well as data management resources.

• The Technology Architecture, which defines the software, hardware and network infrastructure intend-ed to support the application systems and databases 5.

The second subset is sometimes called the Software Architecture, the third is frequently called theInformation Architecture, while the fourth one is also called the Infrastructure Architecture. The classicEnterprise Architecture as understood today is illustrated in Figure 1. It must be emphasized though thatits current shape is a result of many years of bottom-up evolution.



2.3 Evolution of Enterprise Architecture

During the early days of enterprise-wide computing architectural efforts targeted technology architectures. Thefocus was on purely technical standards and principles, as well as descriptions. Later on, the concept ofEnterprise-wide Information Technology Architecture (EWITA) was born. The concept included Application, Dataand Technology Architectures. Therefore, the Enterprise Architecture became software and application develop-ment oriented. However, it was still not enough. It was realized that one cannot bypass business processes andrequirements during design of IT solutions. Therefore, to ensure effective mappings and requirements tracing, theBusiness Architecture was incorporated into the concept 6.

The merging of business and IT concepts was a big step forward towards the holistic Enterprise Architecture.However, the resulting architectures were still technically oriented in practice. Generally, business elements suchas functions, processes, organizational units and users were taken into consideration only to justify and align ITsolutions with business needs better than before. Business elements were also introduced to ease the task ofsoftware requirements analysis and to increase the quality of application development results.

Classical, technically oriented architectures are also usually developed, maintained and used by IT teams.Business managers are rarely involved in EA efforts. Business process models within architectures do not usual-ly include manual tasks, document flows and jobs. They are also rarely used to analyze and make changes in busi-ness process blueprints or organizational structures, if at all 7. Support for initiatives such as Six Sigma or qualitymanagement is probably not possible.

Fig. 1:The Classic EnterpriseArchitecture

2.4 Benefits

On the other hand, technically oriented or even purely technical architectures have a lot of advantages.They also generate important benefits, including some tangible ones. The top reason for developing a tech-nically oriented enterprise architecture is to provide foundation for an IT strategy. Such architecture makesIT as a whole more flexible, simpler and standardized. This in turn results in more efficient IT operations,as well as in lower support costs. In particular, an effective technical architecture results in:

• Lower software development, support, and maintenance costs

• Increased portability of applications

• Improved interoperability and easier system and network management

• A better ability to address critical enterprise -wide issues like security

• Easier upgrades and exchange of system components

• Reduced complexity in IT infrastructure

• Maximum return on investment in existing IT infrastructure

• The flexibility to make, buy, or out-source IT solutions

• Reduced risk overall in new investment, and the costs of IT ownership

• Simpler purchasing decisions 8



3. Business Architectures

3.1 The Business Process Architecture

Comprehensive IT oriented architectures were being developed for more than 10 years and are more mature thanbusiness ones. While there is a general consensus concerning subsets of the Enterprise Architecture in the tech-nical domain, there are many ideas as to what constitutes the Business Architecture.

Some experts believe that the Business Architecture equals the Business Process Architecture. Michael Porter iscredited with introducing the first high level Architecture of this type, under the name of the infamous Value Chain.The Value Chain consists of a series of generic activities that create and build value. They culminate in the totalvalue delivered by an organization. These activities can be classified generally as either primary or support activ-ities that all businesses must perform to generate value for their customers. Within the Chain, the primary activ-ities are Inbound Logistics, Operations, Outbound Logistics, Marketing and Sales, as well as Service. Secondaryactivities include Procurement, Human Resource Management, Technological Development and FirmInfrastructure.

A more sophisticated generic Architecture for manufacturing companies was introduced by Professor August-Wilhelm Scheer as the so-called Y-CIM-Model 9. The upper part of the model distinguishes between productionplanning and product planning processes (see Figure 2). The lower part of the model shows integration of produc-tion control with product realization. Actually, the model is useful for any enterprise which develops it’s own prod-ucts or services and has a need to manage order life-cycles together and in parallel with their product or servicelife-cycles.

Fig. 2:The Y-CIM Model

Professor Scheer introduced also thenotion of reference process models. Themodels are template process architec-tures, sometimes accompanied by nor-mative, detailed process maps prescrib-ing best practices for key sets of activi-ties. They are either generic or industry-specific. They are also devoid of imple-mentation details, such as organization-al elements and specific applications.These are added when being adapted toindividual enterprises. During adapta-tion, template process architectures arealso modified, extended and/or

reduced. IDS Scheer was the first company to offer such models on the market for several industries, such as con-sumer goods, mechanical engineering, paper industry, plant engineering and others. Nowadays, such models aredeveloped by industry or topic-oriented associations. The most well known reference process models of this kindare:

• Supply Chain Operations Reference Model (SCOR), developed by Supply Chain Council for supply chainprocesses in any industry 10

• eBusiness Telecom Operations Map (eTOM), developed by TeleManagement Forum for telecommunicationsindustry 11

3.2 The Organizational Architecture

To some extent, business process architectures pushed aside the first non-IT Architecture proposed, name-ly the Organizational one. The concept was introduced in 1992 by organizational experts from DeltaConsulting Group. The Organizational Architecture was defined as a broad concept, comprising of formalstructure, the design of work practices, the nature of the informal organization or operating style, and theprocesses for selection, socialization and development of people 12. In practical terms, organizational archi-tecture is perceived as a result of strategic organization design. It is driven by enterprise strategy, decisionsare made in a top-down direction and it deals with top four hierarchy levels at most. In essence, strategicdesign creates basic shape, or architectural frame for the enterprise as a whole, expressed in terms of unitsand subunits. It is followed by operational design, focused on jobs, workflows and other essential detailsfor each element within the architecture 13.

Organization theorists treat processes as something secondary, taken into account on the operationaldesign level and playing a role somewhat limited to coordinating mechanisms. In turn, proponents ofprocess-centric enterprises treat organizational structures as something secondary. Either one can be ana-lyzed separately, yet no enterprise can exist without both of them. Therefore, business process and orga-nizational architectures are complementary.

3.3 The Business Performance Architecture

From a managerial point of view, the last missing piece of the puzzle is the Business PerformanceArchitecture, focused on performance management. Such term is used very rarely, however each organiza-tion has such architecture, linked closely with process and organizational ones. A complete architecture ofthis kind should encompass performance metrics on broadly interpreted strategic (whole enterprise), oper-ational (processes) and human (employees) levels. Ideally, metrics on all levels should be related somehow,in the same way as processes and units. A rare template for such architecture, covering strategic and oper-ational levels, is embedded implicitly within the SCOR model. The model provides a reference set of relat-ed metrics for the supply chain as a whole and for its component processes and sub-processes. The met-rics are organized in three categories:

• customer facing metrics for delivery reliability, responsiveness and flexibility

• internal-facing metrics for cost and asset management efficiency

• shareholder-facing measures for profitability, effectiveness of return and share performance 14.



3.4 Benefits

The full Business Architecture is comprised of Business Process, Organizational and Business PerformanceArchitectures. There are many benefits of business architectures with such a scope, even when used stand-aloneto support non-IT process improvement projects. However, usefulness of business architectures is strengthenedwhenever they are coupled with technical ones. The biggest is probably that it allows decision-makers to under-stand how an organization works from top to bottom, that is what are its elements and how they are statically anddynamically related. This understanding provides a foundation for an effective change. Generally, this results inmore effective and less costly change initiatives, be it purely organizational ones, purely technical ones or cross-breeds. In particular, business architectures support :

• Faster response to environmental threat or opportunity

• Better alignment of change initiatives with enterprise strategy

• More informed assessment of change scope and degree of impact

• Better alignment of application systems with business objectives and needs

• Reduced application development lifecycles

• Reduced packaged software and middleware implementation efforts

• Reduced application maintenance costs

• Improved operating procedures

• Reduced impact of staff turnover 15

4. Architecture Frameworks

4.1 The Zachman Framework

Any team responsible for development of an architecture for a particular enterprise faces a fundamentalquestion where and how to begin. It is generally accepted that some kind of meta-architecture should beused from the outset, to facilitate communication, supply shared terminology and to shape the final results.Frameworks are used as architecture foundations to that end. There are many of them, with different objec-tives in mind. In this paper, only a small sample is reviewed.

Fig. 3:The Zachman Framework

The most comprehensive andmature frameworks were andare still being developed with ITprojects in mind. The first frame-work of this kind was introducedby John Zachman in 1987.Inspired by engineering blue-prints, Zachman defined archi-tecture as a set of design arti-facts, understood as descriptiverepresentations of objects com-prising an enterprise. His Frame-work is a two-dimensional clas-sification scheme for design arti-

facts, resembling the Mendeleev periodic table (see Figure 3). On the horizontal axis it provides a taxono-my of the various architectural artifacts. There are six abstraction columns, each with a different focus:

1. The WHAT column focuses on data.

2. The HOW column focuses on functions.

3. The WHERE column focuses on network (locations and connections).

4. The WHO column focuses on people.

5. The WHEN column focuses on time (events).

6. The WHY column focuses on motivation (ends and means).

The vertical axis provides multiple perspectives of the overall architecture. Each perspective (row) is dedi-cated to one of the stakeholders in information system. These are:

• Planner perspective (CEO and other top management executives)

• Owner perspective (business managers and analysts)

• Designer perspective (solution architects and implementation consultants)

• Builder perspective (system designers)

• Subcontractor perspective (programmers)



The rows should not be interpreted as successive levels of detail, although stakeholders may have differentrequirements in that matter. Each row forms a complete representation of the enterprise from a given point ofview. For each perspective there is therefore a corresponding representation, namely Scope, Enterprise, System,Technology and Detailed Representation (Out-of-Scope) Model. The last row is named Functioning Enterprise andis comprised of its actual components. The Framework provides detailed definitions for each cell within the matrix,except for the last row 16.

The Zachman Framework has been criticized due to its lack of relationships between design artifacts. The over-riding importance of processes is also not emphasized within the Framework. Nevertheless, due to its simplicity,the Framework is very popular and it is used, directly or indirectly, to shape architecture efforts in many organiza-tions.

4.2 The ARIS Framework

The Zachman Framework emphasizes classification of artifacts and is conceptual in nature. Concerning theend result, Architecture for Information Systems (ARIS), another popular framework, is more pragmatic. Itemphasizes relationships of artifacts and was used successfully as a foundation of a leading businessprocess analysis tool under the same name. The ARIS Framework is process-centric and was introduced byProfessor Scheer in 1992. It is based on a general business process model and is comprised of five viewsand three description levels. The views are:

• The Function View (goals, activities and software)

• The Organization View (organizational units, computer hardware and machine resources)

• The Data View (events, messages and environmental data)

• The Output View (material input/output, services and financial resources)

• The Control / Process View

The first four views have a static nature and are used to model internal relationships. The last view is adynamic one and is used to model relationships between elements belonging to different views. Therefore,it is the most important one within the Framework. Description levels add to it a second dimension. Theyare derived directly from a phase model depicting the steps for supporting business issues by means of ITsystems. The phases are called:

• Strategic Business Process Analysis

• Requirements Definition

• Design Specification

• Implementation Description

• Operation and Maintenance

The second, third and fourth phase is explicitly included in the Framework (see Figure 4). Similarly to theZachman Framework, the chronological sequence of description levels is not implied, it is also not manda-tory. It is assumed only that such levels are generally used in software development 17.

Fig. 4:The ARIS Framework



4.3 The TOGAF Framework

The TOGAF Framework (The Open Group Architecture Framework) is focused on architecture development process.The Framework was developed by members of the Open Group consortium. The first version of the Framework wasreleased in 1995 and it was devoted exclusively to technical architectures. Version 8 was released in 2003 and iscalled the Enterprise Edition, to emphasize its much broader scope. The last version can be used to support devel-opment of business architectures, in addition to applications, data and technology ones.

TOGAF focuses on the development of architectures. Its key component is the Architecture Development Method(ADM), essentially a methodology which prescribes phases and steps to create an organization-specific architec-ture (see picture). A key step for each architecture, be it business, applications, data or technology, is to definethe views suitable to address the needs of relevant architecture stakeholder group. The views are created usingselected modeling techniques. For example, to address the needs of business managers, planners and users, thefollowing Business Architecture views may be developed:

• Business Strategy and Goals View

• Business Objectives View

• Business Function View

• Business Services View

• Business Process View

• Business Locations View

• Business Logistics View

• People View Organizational Chart

• Workflow View

Although TOGAF describes an example taxonomy of the kinds of views that an architect might consider useful, itdoes not enforce a specific set of architecture views. The Framework provides instead guidelines for view selec-tion and development of supporting standards. Therefore, TOGAF does not compete with established EA frame-works. In fact, any detailed framework can be used as input to create an enterprise architecture for a given organ-ization, using ADM. Besides methodology, the TOGAF Framework contains also reference models and otherresources, such as standards or templates, to support architecture efforts. They are however almost exclusivelytechnical.

4.4 The FEAF Framework

Another important framework to consider is called Federal Enterprise Architecture Framework (FEAF). Itwas created as a result of Clinger-Cohen Act, approved by the US Congress in 1996. The Act requires ChiefInformation Officers in federal agencies to develop enterprise architectures, in order to maximize benefitsof technology investments. To some extent, it is based on the Zachman Framework principles, used toderive a set of architectures, namely Data Architecture, Application Architecture and TechnologyArchitecture. The Framework consists of the following components:

• Architecture Drivers

• Strategic Direction

• Current Architecture

• Target Architecture

• Transitional Processes

• Architectural Segments

• Architectural Models

• Standards

The architectures serve as a springboard for construction of a group of reference models. The models aredesigned to facilitate development of individual architectures, as well as cross-agency analysis and col-laboration. The following models are available:

• Business Reference Model (BRM)

• Performance Reference Model (PRM)

• Data and Information Reference Model (DRM)

• Service Component Reference Model (SRM)

• Technical reference Model (TRM) 18



5. EA Tool Requirements

Fig. 5:The Balanced EnterpriseArchitecture Framework

5.1 Coordination of architectures

The figure above portrays the Enterprise Architecture, based on the ideas discussed earlier. It is generic, holisticand balanced, divided into subsets located within the business and technical domains. For any organization, theenvironment shapes its mission, vision and strategy. The strategy in turn shapes the Business Architecture for agiven enterprise, consisting of the Business Process, Organizational and Business Performance Architectures.Finally, the Business Architecture shapes the Technical one. The Technical Architecture consists again of threesubsets, namely the Application, Data and Technology Architectures.

Experts say that there is a need to co-develop business and technical architectures in close coordination. This sup-ports a unified view of the organization, consistent architectural descriptions and synchronized projects spanningboth domains 19. An ideal architecture should therefore make it possible to follow links from a business goal toprocess objectives, activities and jobs, as well as to applications and software components in need of modifica-tions to achieve this goal.

This assumes however the same level of architectural maturity level for all stakeholders within an enterprise. Thisis not always the case. For example, in a certain organization business managers might pursue process manage-ment initiatives and appreciate a need to have process architecture as a foundation of improvement efforts,including process automation. In such a case, the architecture evolution will probably start in a business depart-ment and have a downward direction, from business elements towards the IT resources. In another organization,less advanced in business process concepts, IT professionals might see a need to bring proliferation of applica-tions, databases, interfaces and technologies under control. In such case, the architecture evolution will probablystart within the IT department and have an upward direction, from the IT resources towards business elements.

Although there are opinions to the contrary, an architecture tool should support both approaches and therefore alltypes of architectures, business and technological ones, more or less equally well 20. Downward evolution is apreferable one in the long run, since no one really doubts that software and configuration requirements flow frombusiness processes. However, historical reasons and others often trigger architecture evolution in the oppositedirection, that is from IT towards business. Business managers could discover later that the technically-orientedtool will not fulfill some of their key requirements. In such a case, they will be tempted to introduce another, morebusiness-oriented tool to satisfy their needs. However, this awakes painful interoperability problems, which willnot be fully resolved for many years to come.

5.2 Descriptive capabilities

As someone said, enterprise architectures are used to understand and to build. To capture and analyzeenterprise complexity, an EA tool should have a set of specific basic functionalities. Gartner Group definesseveral criteria that a mature EA tool should fulfill in this respect. Such a tool should have capabilities to:

• Create and maintain general, as well as detailed, architectural descriptions

• List and cross-reference all relevant business elements

• List and cross-reference all relevant technology elements

• Support multi-architectural framework selected by or created in an organization

• Perform versioning and support change management

• Perform efficiently in demanding environments

• Perform Web publishing

• Exchange descriptions with other tools

• Customize architectural descriptions 21

5.3 Implementation capabilities

Apart from satisfying the needs of a passive, descriptive operation mode, a mature architecture tool shouldalso provide inputs to various projects in an active, forward engineering mode. Capabilities in this respectshould satisfy the needs of pure organizational projects, pure IT projects and mixed ones. In particular, asophisticated architecture tool should support:

• Redesign of organizational structures

• Redesign of management systems

• Improvement of existing business processes

• Design of new business processes

• Configuration of packaged enterprise applications

• Application development

• Configuration of BPM middleware

• IT infrastructure upgrades



6. ARIS Platform

6.1 Approaches to architecture

Several dedicated tools were created to support EA projects. However, the most viable players on this market arethe established vendors of business process analysis and application development software tools. ARIS has beenconsidered the leader on the process analysis market for a long time. In a recent analysis of EA tools, the GartnerGroup classified ARIS as one of the leaders. The Gartner Group took into account support for popular architectureframeworks, the range of supported models, ease of customization and administration, openness, accessibilityand costs. Considering ARIS, the Gartner Group emphasized its large number and scope of supported models, pow-erful versioning mechanism and customization potential, as well as attractive prices. It concludes that ARIS shouldbe used by enterprises utilizing primarily a top-down approach to architecture development, oriented towardsbusiness processes as a foundation for subsequent efforts 22.

It is true that ARIS is identified with business process analysis and modeling. Some researchers also claim thatARIS is particularly well developed in the area of process and organizational architectures. One must note how-ever that ARIS is also able to support development of business performance architectures for a long time, thanksto its Balanced Scorecard add-on. In particular, the add-on allows for definition of performance networks, consist-ing of objectives, indicators, data sources, processes and initiatives.

As a process-focused tool, ARIS can be used to list and cross-reference all required architectural elements with-in the business domain. However, ARIS can also be used to describe and link all relevant technological elements.ARIS is built on top of a theoretically sound multi-architectural framework, which encompasses all levels of sys-tem descriptions. It can be therefore used to inventory and link all IT resources, including network protocols andconnections, hardware, operating systems, database management systems and software licenses. Therefore,ARIS can be efficiently used to support all architecture initiatives, including bottom-up ones.

6.2 Descriptive role

ARIS can be also used to create and maintain descriptions using any multi-architectural framework selected by orcreated in an organization. First of all, it can be used to implement the Zachman Framework, which is widely usedin practice to shape architecture initiatives. A study was conducted recently to compare the Zachman and ARISFrameworks, to identify the differences and similarities between the two approaches. It demonstrates convincing-ly that:

• The Zachman Framework and ARIS have similar objectives

• The approaches are highly complementary, not competitive

• The Zachman Framework delivers high level guidelines for EA design

• ARIS is able to depict all dimensions and levels in the Zachman Framework 23

ARIS offers even more than the above in this respect. The Zachman Framework does not prescribe any specifictypes of models for architectural descriptions. ARIS offers perhaps the most comprehensive catalogue of diagramsto implement this Framework and to suit the needs of even most demanding enterprises, with widely differentrequirements.

According to a recent survey, there are at least 10 frameworks used by around 70% of organizations, while around30% create their own ones, mixing and matching many ideas from a variety of sources 24. It seems therefore thatflexibility is the key requirement as far as framework support is concerned and ARIS provides it to a very largedegree. For example, ARIS was successfully used to implement Business Enterprise Architecture for the FutureLogistics Enterprise initiative, guided by the US Department of Defense (DoD). The DoD Architecture FrameworkVersion 1.0 was used, a successor to the well-known Control, Communications, Computers, Information,Surveillance, and Reconnaissance (C4ISR) Architecture Framework 25. ARIS is used to support many other frame-works in military and financial organizations as well 26.

6.3 Technical properties

ARIS fulfills all Gartner Group’s technical criteria for a mature EA tool. It has powerful versioning andchange management features, built into its basic functionality. ARIS is able to serve hundreds of users inheavy-duty environments, owing to industry-strength database management systems it supports.

Its Web publishing engine is second to none and can be used to spread architecture knowledge acrossglobal enterprises. It has interfaces with many tools, it generates also process descriptions using XML.Furthermore, it has a wide range of customizing options, from user-defined model, object and attributenames, to user-defined report, analysis and other output scripts for processing of architectural descriptions.

6.4 Implementation role

Apart from its comprehensive descriptive and analytical capabilities, ARIS offers also a rich variety ofimplementation options. Architecture created using ARIS can be used as a springboard for change projectsof any kind, including Six Sigma efforts. Business improvements expressed as target structures and processblueprints can be implemented using purely organizational means, such as automatically generated Webprocess maps, manuals and training. ARIS is also able to support various IT implementation projects, ofwhich the following are particularly noteworthy:

• Implementation and maintenance of SAP software

• Application development using UML

• Process automation using Business Process Management (BPM) engines

IDS Scheer cooperation with SAP has a long history. ARIS has been supporting SAP implementation proj-ects for some time now. However, the ties became even stronger last year, when the two companies signedan agreement to jointly develop a comprehensive business process management solution. ARIS Platformwill be integrated into SAP NetWeaver, its open integration and application platform. SAP customers willhave the ability, for the first time, to use results of architecture-guided modeling and optimization of busi-ness processes with their configuration and execution on SAP software platform.

It is generally believed that business process modeling using Unified Modeling Language (UML) diagramsis not very efficient when business managers and end users are involved, due to its notations and termi-nology. Business process modeling tools provide better results, to be supplemented and extended later byObject-Oriented Analysis and Design (OOA&D) tools. An ideal solution to bridge them is to use a sharedrepository. The same information can then be used for a business and IT view 27. ARIS UML Designer isbased on this principle. When coupled with ARIS Toolset, it can be used to transform process specifica-tions into relevant UML diagrams. This assures a smooth and nearly transparent transition from businessprocess modeling into software engineering.

In a recent survey of Business Process Management (BPM) software market, Delphi Group discovered thatthe most important reason for BPM investments is a business issue. Nearly half of respondents stated thatthey purchased BPM software to support enterprise-wide redesign of business processes. At the sametime, lack of suitable modeling tools within BPM software was rated as the most important issue to besolved. BPM initiatives are also led predominantly by line-of-business managers and business processowners 28. If we take all this into account, the role of process analysis and modeling in BPM software imple-mentation becomes significant. ARIS is able to support such projects effectively. It already has a BusinessProcess Modeling Language (BPML) interface, plus interfaces with leading BPM solutions. It will be alsoable to support any future industry standard such as Business Process Execution Language (BPEL) withease, thanks to its scripting environment and engine.



7 Conclusions

Organizations use enterprise architectures to become more flexible and adaptable, primarily for managing busi-ness change, as well as for business and IT alignment. Formal descriptions of related enterprise elements areespecially useful in support of managing complexity and in creating change management roadmaps. Organizationsfind them very useful also because they provide overviews of business and IT structures. Last but not least, enter-prise architectures support setting business and IT priorities, help managing IT portfolio and support applicationdevelopment, they also enhance decision making in general 29.

still immature, but with enterprises increasingly understanding the need for a comprehensive architecture, it willcause an increase in revenues for software vendors by at least 25 percent annually until 2006 30.ARIS Platform isvery well equipped to take advantage of such opportunity.

8 Literature

1. Schekkerman J., Strategic Governance and Enterprise Architecture. EA Survey 2003, Institute for Enterprise Architecture Developments (IFEAD),2003

2 IEEE Computer Society. IEEE Std 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, Oct. 9, 2000

3 Rowe D., Leaney J., Simpson H., Current Developments in the Definition and Description of System Architectures - An IEEE ECBS TC ArchitectureWorking Group Discussion Paper, 1999

4 Rosser B., Defining Architecture for IT: A Framework of Frameworks, Gartner Research Note COM-16-7834, 12 August 2002

5 TOGAF, The Open Group Architecture Framework Version 8.1 ”Enterprise Edition, 2003

6 Bredemeyer D., Malan R., Krishnan R., Lafrenz A., Enterprise Architecture as Business Capabilities Architecture, Bredemeyer Consulting, 2003

7 Bredemayer D., ibid.

8 TOGAF, ibid.

9 Scheer A.-W., Business Process Engineering. Reference Models for Industrial Enterprises, Springer-Verlag, 1994

10 Kirchmer M., Brown G., Heinzel H., ”Using SCOR and Other Reference Models for E-Business Process Networks”, in: Scheer A.-W., Abolhassan F.,Jost W., Kirchmer M. (eds.), Business Process Excellence. ARIS in Practice, Springer-Verlag, 2002, pp. 45-64

11 Harmon P., Business Process Change., Morgan Kaufman Publishers, 2003

12 Nadler D.A., Gerstein M.S, Shaw R.B., Organizational Architecture, Jossey-Bass Inc., 1992

13 Nadler D.A., Tushman M.L., Competing by Design, Oxford University Press, Inc., 1997

14 Bolstroff P., ‘How Does SCOR Measure Up ?’, Keeping SCOR, March 2002

15 Adaptive, Inc., The Road to Enterprise Architecture, 2002

16 Sowa, J.F., Zachman J.A., ‘Extending and formalizing the framework for information systems architectures’, IBM Systems Journal, 31(3), 1992, pp.590-616.

17 Professor Scheer A.-W., ARIS – Business Process Frameworks, Springer-Verlag, 1998

18 Schekkerman J., How to survive in the jungle of Enterprise Architecture Frameworks, Trafford Publishing, 2003

19 Drobik A., Enterprise Architecture: Far Too Important to Be Left to the IT Team, Gartner G2 Report, July 2002

20 TOGAF, ibid.

21 James G., Tools for Enterprise Architecture, Gartner Research Note M-19-2089, 31 January 2003

22 James G., MarketScope: Enterprise Architecture Tool Market, Gartner Research Note M-21-6251, 7 January 2004

23 Leonardo Consulting, Successfully Building Enterprise Architectures. A White Paper, 2001

24 Schekkerman J., ibid.

25 Department of Defense, Business Enterprise Architecture – Logistics (BEA-LOG). Operational View Model Guide, 2003

26 Gulledge T. R., Simon G., Sommer R. A., “Using ARIS to Manage SAP Interoperability”, in: Scheer A.-W., Abolhassan F., Jost W., Kirchmer M. (eds.),Business Process Excellence. ARIS in Practice, Springer-Verlag, 2002, pp. 87-107

27 Duggan J., Evaluating OOA&D Functionality Criteria, Gartner Research Note DF-20-7297, 11 September 2003

28 Delphi Group, BPM 2003. Market Milestone Report , September 2003

29 Schekkerman, ibid.

30 James G., ibid.


The software and consulting company IDS Scheer (Saarbrücken) is the leading provider of Business ProcessManagement and IT solutions. With ARIS, it offers an integrated and complete tool portfolio for “Business ProcessExcellence”; this encompasses methods, software and solutions for designing, implementing and controlling businessprocesses. As part of the continuous development of its portfolio, IDS Scheer has bundled all the products of the ARISfamily in the ARIS Platform for Process Excellence, including several new developments. Highly integrated both tech-nologically and from the content aspect, the platform offers tools for all phases of the process lifecycle – from designand implementation through to controlling. It is thus a clear unique selling point for IDS Scheer and provides customerswith software support for their process lifecycles. Within the ARIS Platform for Process Excellence, ARIS Toolset is theworld's most frequently purchased tool for process optimization. Under a strategic cooperation with SAP, the ARIStools and methods will in future be standard in the NetWeaver platform. ARIS SmartPath is a tool that will make rap-id SAP introduction a reality for medium-sized companies as well. Thanks to the integrated approach of ARIS ValueEngineering (AVE), IDS Scheer consultants view their customers’ enterprises holistically. AVE means building bridgesbetween corporate strategy, the processes derived from it, the IT solutions needed to support it and also the control-ling of running processes. Moreover, customers profit from complete global services for outsourcing and support.

“ARIS”, “IDS” and “Y” symbol are registered trademarks of IDS Scheer AG, Saarbruecken. “SAP NetWeaver” is a trademark of SAP AG, Walldorf.Allother trademarks are the property of their respective owners. All rights reserved. The contents of this document are subject to copyright. Anychanges,modifications, additions or amendments require prior written consent from IDS Scheer AG, Saarbrücken. Reproduction in any form is only per-mitted onthe condition that the copyright notice remains on the actual document. Publication or translation in any form requires prior written consentfrom IDS Scheer AG, Saarbrücken.

Inventory number AEA0306-E-WP © Copyright IDS Scheer AG, Saarbrücken, 2006

Business Process Excellence

IDS Scheer worldwide:

Austria

Belgium

Brazil

Canada

China

Czech Republic

France

Germany

Hungary

Japan

Luxemburg

Malaysia

Netherlands

Poland

Russia

Singapore

Slovakia

Slovenia

South America

Sweden

Switzerland

Turkey

United Kingdom

USA

www.ids-scheer.com

Headquarters:

Germany

IDS Scheer AGAltenkesseler Straße 1766115 SaarbrückenPhone: +49 (0)681-210-0Fax: +49 (0)681-210-1000E-mail: [email protected]

aris enterprise architecture solution - arise consulting · business process excellence white paper...

Documents