White Paper - March 2006

ARIS Enterprise Architecture Solution

Business Process Excellence

Table of contents
1
2.
2.1
2.2
2.3
2.4
3.
3.1
3.2
3.3
3.4
4.
4.1
4.2
4.3
4.4
5.
5.1
5.2
5.3
6.
6.1
6.2
6.3
6.4
7
8

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Technical Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Definition of architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Definition of the Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Evolution of Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
Business Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The Business Process Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The Organizational Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
The Business Performance Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Architecture Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
The ARIS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
The TOGAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
The FEAF Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
EA Tool Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Coordination of architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
Descriptive capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Implementation capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
ARIS Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Approaches to architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Descriptive role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Technical properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Implementation role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

IDS Scheer AG March 2006

List of figures
Fig. 1:
Fig. 2:
Fig. 3:
Fig. 4:
Fig. 5:

The Classic Enterprise Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

The Y-CIM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
The Zachman Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
The ARIS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
The Balanced Enterprise Architecture Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

IDS Scheer AG March 2006

Introduction
The concept of Enterprise Architecture has been around for quite some time. However, it gained considerable
momentum at the beginning of this century for a variety of reasons. Perhaps the most important was an acceleration 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 documented 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 manual 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 standardize inter-organizational business processes. This was also difficult because details of external relationships
were not formalized.
The need to describe enterprise elements and their interrelationships, as well as to analyze them, became apparent 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 enterprise 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.

IDS Scheer AG March 2006

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 architecture 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 a
descriptive and a prescriptive meaning of architecture. Gartner Group defines architecture using two alternative 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, architectural 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 guide
behavior 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 interrelationships. 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 be
deployed, their interactions and relationships with the supported business processes.
The Data Architecture, which describes the structure of an organizations logical and physical data
assets, as well as data management resources.
The Technology Architecture, which defines the software, hardware and network infrastructure intended 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.

IDS Scheer AG March 2006

2.3

Evolution of Enterprise Architecture

During the early days of enterprise-wide computing architectural efforts targeted technology architectures. The
focus 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 development 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 usually include manual tasks, document flows and jobs. They are also rarely used to analyze and make changes in business 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

IDS Scheer AG March 2006

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

IDS Scheer AG March 2006

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 technical 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 activities that all businesses must perform to generate value for their customers. Within the Chain, the primary activities are Inbound Logistics, Operations, Outbound Logistics, Marketing and Sales, as well as Service. Secondary
activities include Procurement, Human Resource Management, Technological Development and Firm
Infrastructure.
A more sophisticated generic Architecture for manufacturing companies was introduced by Professor AugustWilhelm 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 production control with product realization. Actually, the model is useful for any enterprise which develops its own products 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 architectures, sometimes accompanied by normative, detailed process maps prescribing best practices for key sets of activities. They are either generic or industryspecific. They are also devoid of implementation details, such as organizational elements and specific applications.
These are added when being adapted to
individual enterprises. During adaptation, 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 consumer 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

IDS Scheer AG March 2006

3.2

The Organizational Architecture

To some extent, business process architectures pushed aside the first non-IT Architecture proposed, namely the Organizational one. The concept was introduced in 1992 by organizational experts from Delta
Consulting Group. The Organizational Architecture was defined as a broad concept, comprising of formal
structure, the design of work practices, the nature of the informal organization or operating style, and the
processes for selection, socialization and development of people 12. In practical terms, organizational architecture is perceived as a result of strategic organization design. It is driven by enterprise strategy, decisions
are made in a top-down direction and it deals with top four hierarchy levels at most. In essence, strategic
design creates basic shape, or architectural frame for the enterprise as a whole, expressed in terms of units
and subunits. It is followed by operational design, focused on jobs, workflows and other essential details
for each element within the architecture 13.
Organization theorists treat processes as something secondary, taken into account on the operational
design level and playing a role somewhat limited to coordinating mechanisms. In turn, proponents of
process-centric enterprises treat organizational structures as something secondary. Either one can be analyzed separately, yet no enterprise can exist without both of them. Therefore, business process and organizational 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 Performance
Architecture, focused on performance management. Such term is used very rarely, however each organization has such architecture, linked closely with process and organizational ones. A complete architecture of
this kind should encompass performance metrics on broadly interpreted strategic (whole enterprise), operational (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 operational levels, is embedded implicitly within the SCOR model. The model provides a reference set of related metrics for the supply chain as a whole and for its component processes and sub-processes. The metrics 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.

IDS Scheer AG March 2006

3.4

Benefits
The full Business Architecture is comprised of Business Process, Organizational and Business Performance
Architectures. 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 understand 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 crossbreeds. 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

10

IDS Scheer AG March 2006

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 objectives in mind. In this paper, only a small sample is reviewed.
Fig. 3:
The Zachman Framework

The most comprehensive and

mature frameworks were and
are still being developed with IT
projects in mind. The first framework of this kind was introduced
by John Zachman in 1987.
Inspired by engineering blueprints, Zachman defined architecture as a set of design artifacts, understood as descriptive
representations of objects comprising an enterprise. His Framework is a two-dimensional classification scheme for design artifacts, resembling the Mendeleev periodic table (see Figure 3). On the horizontal axis it provides a taxonomy 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 dedicated 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)

IDS Scheer AG March 2006

11

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 overriding 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 organizations.

12

IDS Scheer AG March 2006

4.2

The ARIS Framework

The Zachman Framework emphasizes classification of artifacts and is conceptual in nature. Concerning the
end 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 mandatory. It is assumed only that such levels are generally used in software development 17.
Fig. 4:
The ARIS Framework

IDS Scheer AG March 2006

13

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 development 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 architecture (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 selection and development of supporting standards. Therefore, TOGAF does not compete with established EA frameworks. In fact, any detailed framework can be used as input to create an enterprise architecture for a given organization, 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.

14

IDS Scheer AG March 2006

4.4

The FEAF Framework

Another important framework to consider is called Federal Enterprise Architecture Framework (FEAF). It
was 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 collaboration. 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

IDS Scheer AG March 2006

15

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 supports 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 modifications 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 management 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 department 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 applications, 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 will
not be fully resolved for many years to come.

16

IDS Scheer AG March 2006

5.2

Descriptive capabilities
As someone said, enterprise architectures are used to understand and to build. To capture and analyze
enterprise 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

IDS Scheer AG March 2006

17

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, powerful 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 that
ARIS is particularly well developed in the area of process and organizational architectures. One must note however 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, consisting 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 within 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 system 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 convincingly 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 frameworks in military and financial organizations as well 26.

18

IDS Scheer AG March 2006

6.3

Technical properties
ARIS fulfills all Gartner Groups technical criteria for a mature EA tool. It has powerful versioning and
change 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 projects 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 Platform
will 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 business 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 terminology. 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 specifications 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 implementation 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.

IDS Scheer AG March 2006

19

Conclusions
Organizations use enterprise architectures to become more flexible and adaptable, primarily for managing business 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, enterprise 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.

20

IDS Scheer AG March 2006

Literature
1.

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

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

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

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

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

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

Bredemayer D., ibid.

TOGAF, ibid.

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.

IDS Scheer AG March 2006

21

Headquarters:
Germany
IDS Scheer AG
Altenkesseler Strae 17
66115 Saarbrcken
Phone: +49 (0)681-210-0
Fax:
+49 (0)681-210-1000
E-mail: info@ids-scheer.de

The software and consulting company IDS Scheer (Saarbrcken) 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 technologically 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 rapid 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 controlling of running processes. Moreover, customers profit from complete global services for outsourcing and support.

IDS Scheer worldwide:

Austria
Belgium
Brazil
Canada
China
Czech Republic
France
Germany
Hungary
Japan
Luxemburg
Malaysia
Netherlands
Poland
Russia

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, Saarbrcken. Reproduction in any form is only permitted 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, Saarbrcken.
Inventory number AEA0306-E-WP

Copyright IDS Scheer AG, Saarbrcken, 2006

Singapore
Slovakia
Slovenia
South America
Sweden
Switzerland
Turkey
United Kingdom
USA
www.ids-scheer.com

Business Process Excellence