ARIS Enterprise Architecture Solution WP

8/16/2019 ARIS Enterprise Architecture Solution WP

1/22

Business Process Excellence

White Paper - March 2006

ARIS Enterprise Architecture Solution


2/222 © IDS Scheer AG – March 2006

Table of contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

2. Technical Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.1 Definition of architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.2 Definition of the Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

2.3 Evolution of Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.4 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3. Business Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.1 The Business Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.2 The Organizational Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.3 The Business Performance Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.4 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

4. Architecture Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

4.1 The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

4.2 The ARIS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

4.3 The TOGAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

4.4 The FEAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

5. EA Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

5.1 Coordination of architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

5.2 Descriptive capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

5.3 Implementation capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

6. ARIS Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

6.1 Approaches to architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

6.2 Descriptive role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186.3 Technical properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

6.4 Implementation role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19

7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

8 Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21


3/22

List of figures

Fig. 1: The Classic Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Fig. 2: The Y-CIM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Fig. 3: The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Fig. 4: The ARIS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Fig. 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 coined

as a strategic imperative. In other words, the capability to detect environmental change and respond effectively

to 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 integration

efforts 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 of

unintended 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 by

software 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 sophisticated

tools to support their efforts. The objective of this white paper is therefore to position ARIS Platform within the

Enterprise Architecture (EA) solution space.


5/22

2. Technical Architectures

2.1 Definition of architecture

There are many competing, technically-oriented definitions of architecture. The IEEE Recommended

Practice 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 to

each other, and to the environment, and the principles guiding its design and evolution.” 2 Architecture is

therefore 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 most

popular and commonly used.

Such conceptual differences, while fundamental, are probably of little concern for practitioners, who deal

with 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, namely

its structure, components and how they interrelate

• A family of guidelines (concepts, principles, rules, patterns, interfaces and standards) to use when

building a new IT capability 4.

Although alternative, the two architectures as defined above are closely related. As interpreted using the

first 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 interpretation

is 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 Enterprise

Architecture 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 four

parts or subsets:

• The Business Architecture, which defines the business strategy, governance, organizational structures

and 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 data

assets, 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 the

Information Architecture, while the fourth one is also called the Infrastructure Architecture. The classic

Enterprise Architecture as understood today is illustrated in Figure 1. It must be emphasized though that

its 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 of

Enterprise-wide Information Technology Architecture (EWITA) was born. The concept included Application, Data

and 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 and

requirements during design of IT solutions. Therefore, to ensure effective mappings and requirements tracing, the

Business 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 such

as functions, processes, organizational units and users were taken into consideration only to justify and align IT

solutions with business needs better than before. Business elements were also introduced to ease the task of

software 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 quality

management is probably not possible.

Fig. 1:

The Classic Enterprise

Architecture


7/22

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 makes

IT 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 than

business 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 is

credited 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 total

value 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. Secondary

activities 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 production

planning 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 service

life-cycles.

Fig. 2:

The Y-CIM Model

Professor Scheer introduced also the

notion of reference process models. The

models 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 to

individual enterprises. During adapta-tion, template process architectures are

also 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 are

developed by industry or topic-oriented associations. The most well known reference process models of this kind

are:

• Supply Chain Operations Reference Model (SCOR), developed by Supply Chain Council for supply chain

processes in any industry 10

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

industry

11


9/22



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-alone

to support non-IT process improvement projects. However, usefulness of business architectures is strengthened

whenever 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 and

dynamically related. This understanding provides a foundation for an effective change. Generally, this results in

more 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


11/22

4. Architecture Frameworks

4.1 The Zachman Framework

Any team responsible for development of an architecture for a particular enterprise faces a fundamental

question where and how to begin. It is generally accepted that some kind of meta-architecture should be

used 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 and

mature frameworks were andare still being developed with IT

projects in mind. The first frame-

work of this kind was introduced

by John Zachman in 1987.

Inspired by engineering blue-

prints, Zachman defined archi-

tecture as a set of design arti-

facts, understood as descriptive

representations 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 different

requirements in that matter. Each row forms a complete representation of the enterprise from a given point of

view. 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 and

is 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.


13/22

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. It

emphasizes relationships of artifacts and was used successfully as a foundation of a leading business

process analysis tool under the same name. The ARIS Framework is process-centric and was introduced by

Professor Scheer in 1992. It is based on a general business process model and is comprised of five views

and 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 a

dynamic 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. They

are derived directly from a phase model depicting the steps for supporting business issues by means of IT

systems. 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 the

Zachman 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 was

released in 1995 and it was devoted exclusively to technical architectures. Version 8 was released in 2003 and is

called 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 define

the views suitable to address the needs of relevant architecture stakeholder group. The views are created using

selected modeling techniques. For example, to address the needs of business managers, planners and users, the

following 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, it

does 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 other

resources, such as standards or templates, to support architecture efforts. They are however almost exclusively

technical.


15/22

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 Chief

Information Officers in federal agencies to develop enterprise architectures, in order to maximize benefits

of technology investments. To some extent, it is based on the Zachman Framework principles, used to

derive a set of architectures, namely Data Architecture, Application Architecture and Technology

Architecture. 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 are

designed 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 Enterprise

Architecture Framework

5.1 Coordination of architectures

The figure above portrays the Enterprise Architecture, based on the ideas discussed earlier. It is generic, holistic

and balanced, divided into subsets located within the business and technical domains. For any organization, the

environment shapes its mission, vision and strategy. The strategy in turn shapes the Business Architecture for a

given 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 three

subsets, 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 spanning

both domains 19. An ideal architecture should therefore make it possible to follow links from a business goal to

process 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. This

is 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 probably

start 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 all

types of architectures, business and technological ones, more or less equally well 20. Downward evolution is a

preferable one in the long run, since no one really doubts that software and configuration requirements flow from

business processes. However, historical reasons and others often trigger architecture evolution in the opposite

direction, that is from IT towards business. Business managers could discover later that the technically-oriented

tool will not fulfill some of their key requirements. In such a case, they will be tempted to introduce another, more

business-oriented tool to satisfy their needs. However, this awakes painful interoperability problems, which willnot be fully resolved for many years to come.


17/22

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 defines

several 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 should

also provide inputs to various projects in an active, forward engineering mode. Capabilities in this respect

should satisfy the needs of pure organizational projects, pure IT projects and mixed ones. In particular, a

sophisticated 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 are

the established vendors of business process analysis and application development software tools. ARIS has been

considered the leader on the process analysis market for a long time. In a recent analysis of EA tools, the Gartner

Group classified ARIS as one of the leaders. The Gartner Group took into account support for popular architecture

frameworks, the range of supported models, ease of customization and administration, openness, accessibility

and 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 should

be used by enterprises utilizing primarily a top-down approach to architecture development, oriented towards

business 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, thanks

to 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 and

connections, 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 or

created in an organization. First of all, it can be used to implement the Zachman Framework, which is widely used

in practice to shape architecture initiatives. A study was conducted recently to compare the Zachman and ARIS

Frameworks, 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 specific

types of models for architectural descriptions. ARIS offers perhaps the most comprehensive catalogue of diagrams

to implement this Framework and to suit the needs of even most demanding enterprises, with widely different

requirements.

According to a recent survey, there are at least 10 frameworks used by around 70% of organizations, while around

30% create their own ones, mixing and matching many ideas from a variety of sources 24. It seems therefore that

flexibility is the key requirement as far as framework support is concerned and ARIS provides it to a very large

degree. For example, ARIS was successfully used to implement Business Enterprise Architecture for the Future

Logistics Enterprise initiative, guided by the US Department of Defense (DoD). The DoD Architecture Framework

Version 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.


19/22

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 in

heavy-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 across

global 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 attribute

names, 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 of

implementation options. Architecture created using ARIS can be used as a springboard for change projects

of any kind, including Six Sigma efforts. Business improvements expressed as target structures and process

blueprints can be implemented using purely organizational means, such as automatically generated Web

process maps, manuals and training. ARIS is also able to support various IT implementation projects, of

which 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 signed

an 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 will

have 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) diagrams

is 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 by

Object-Oriented Analysis and Design (OOA&D) tools. An ideal solution to bridge them is to use a shared

repository. The same information can then be used for a business and IT view 27. ARIS UML Designer is

based 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 business

process modeling into software engineering.In a recent survey of Business Process Management (BPM) software market, Delphi Group discovered that

the most important reason for BPM investments is a business issue. Nearly half of respondents stated that

they purchased BPM software to support enterprise-wide redesign of business processes. At the same

time, lack of suitable modeling tools within BPM software was rated as the most important issue to be

solved. BPM initiatives are also led predominantly by line-of-business managers and business process

owners 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 Business

Process Modeling Language (BPML) interface, plus interfaces with leading BPM solutions. It will be also

able to support any future industry standard such as Business Process Execution Language (BPEL) with

ease, 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 are

especially useful in support of managing complexity and in creating change management roadmaps. Organizations

find 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 application

development, they also enhance decision making in general 29.

still immature, but with enterprises increasingly understanding the need for a comprehensive architecture, it will

cause an increase in revenues for software vendors by at least 25 percent annually until 2006 30.ARIS Platform is

very well equipped to take advantage of such opportunity.


21/22

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 Architecture

Working 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, 200312 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.



22/22

The software and consulting company IDS Scheer (Saarbrücken) is the leading provider of Business Process

Management and IT solutions. With ARIS, it offers an integrated and complete tool portfolio for “Business Process

Excellence”; this encompasses methods, software and solutions for designing, implementing and controlling business

processes. As part of the continuous development of its portfolio, IDS Scheer has bundled all the products of the ARIS

family 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 design

and implementation through to controlling. It is thus a clear unique selling point for IDS Scheer and provides customers

with software support for their process lifecycles. Within the ARIS Platform for Process Excellence, ARIS Toolset is the

world's most frequently purchased tool for process optimization. Under a strategic cooperation with SAP, the ARIS

tools 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 Value

Engineering (AVE), IDS Scheer consultants view their customers’ enterprises holistically. AVE means building bridges

between 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. Any

changes,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 consent

from IDS Scheer AG, Saarbrücken.

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

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 AG

Altenkesseler Straße 17

66115 Saarbrücken

Phone: +49 (0)681-210-0Fax: +49 (0)681-210-1000

E-mail: [email protected]

ARIS Enterprise Architecture Solution WP

Documents