An Integrated Approachto Enterprise ArchitectureAn Integrated Approach

to Enterprise Architecture

LIACS, Martijn Wiering

23 juni ‘04

2

ContextContext

• Business and ICT become closer

• Ever higher demands on ICT: complexity, flexibility

• Many changes, rapid time-to-market required

• Management & control difficult

• Enterprise Architecture as a tool

• for communication

• for governance

3

BusinessBusiness

ICTICT

4

ArchitectureArchitecture

Architecture = structure(s) of a

system in terms of

• components,

• their externally visible properties,

• their relations,

• and the underlying principles

5

What good are architectures?What good are architectures?

• Provide the overview: the most important functions,

the most important domains, etc.

• A means of communication between various stakeholders

(architects, managers, customers, engineers, …)

• A starting point for more detailed designs

• No description of implementation!

• Correctness & completeness

6

Governance with architectureGovernance with architecture• Architecture is a strategic tool

• not just high-level design

• Architecture goes beyond ICT: enterprise architecture

• Stability & flexibility• Seem to be contradictory, but a good architecture facilitates

changes! It’s no ‘blue-print’ that will hold forever.

• Communication with stakeholders• architects, managers, customers, engineers

• Analysis • impact-of-change• cost & performance

7

Enterprise architecture: describing coherenceEnterprise architecture: describing coherence

Process architecture

Application architecture Technical architecture

Information architecture Product architecture

?

?

?

?

?

8

FrameworksFrameworks

• Zachman

• Nolan Norton

• TOGAF

• Tapscott

• …

e.g. DATA

ENTERPRISE ARCHITECTURE - A FRAMEWORK

Builder

SCOPE(CONTEXTUAL)

MODEL(CONCEPTUAL)

ENTERPRISE

Designer

SYSTEMMODEL(LOGICAL)

TECHNOLOGYMODEL(PHYSICAL)

DETAILEDREPRESEN- TATIONS(OUT-OF- CONTEXT)

Sub-Contractor

FUNCTIONINGENTERPRISE

DATA FUNCTION NETWORK

e.g. Data Definition

Ent = Fie ldRe ln = Address

e.g. Phys ica l Data Mode l

Ent = Segment/Table /e tc.

Re ln = Pointe r/Key/e tc.

e.g. Logica l Da ta Model

Ent = Da ta EntityRe ln = Data Re la tionship

e.g. Sema ntic Model

Ent = Bus ine ss EntityRe ln = Business Re la tionship

Lis t of Things Importantto the Bus iness

ENTITY = Class ofBus iness Thing

Lis t of Processes theBus iness Performs

Function = Class ofBus iness Proce ss

e.g. "Applica tion Architecture"

I/O = Use r ViewsProc .= Applica tion Function

e.g. "System De sign"

I/O = Screen/Device Formats

Proc.= Compute r Function

e.g. "Program"

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Bus iness Process Mode l

Proc. = Bus ine ss Proce ssI/O = Bus iness Resources

Lis t of Locations in which the Bus iness Operates

Node = Major BusinessLocation

e.g. Logis tics Ne twork

Node = Business Loca tionLink = Bus ine ss Linkage

e.g. "Dis tribute d Sys te m

Node = I/S Function(Processor, S torage, e tc)Link = Line Characte ris tics

e.g. "Sys te m Architecture"

Node = Hardware /Sys temSoftware

Link = Line Specifications

e.g. "Network Architecture"

Node = Addre ssesLink = Protocols

e.g. NETWORK

Architecture"

Planner

Owner

Builder

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYCONSTRAINED

MODEL(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Sub-

Contractor

FUNCTIONING

MOTIVATIONTIMEPEOPLE

e.g. Rule Spe cifica tion

End = Sub-condition

Mea ns = Step

e.g. Rule Design

End = Condition

Means = Action

e.g., Busine ss Rule Mode l

End = Structural AssertionMeans =Action Asse rtion

End = Business ObjectiveMe ans = Bus iness Stra tegy

Lis t of Bus iness Goals /Stra t

Ends/Means=Major Bus. Goal/Critica l Success Factor

Lis t of Events Significant

Time = Major Bus iness Event

e.g. Proce ss ing Structure

Cycle = Process ing CycleTime = Sys tem Event

e .g. Control Structure

Cycle = Component Cycle

Time = Execute

e.g. Timing Definition

Cycle = Ma chine CycleTime = Inte rrupt

e .g. SCHEDULE

e.g. Mas te r Schedule

Time = Business EventCycle = Busine ss Cycle

Lis t of Organizations

People = Major Organizations

e.g. Work Flow Model

People = Organization UnitWork = Work Product

e .g. Human Inte rfa ce

People = RoleWork = Delive ra ble

e.g. Presentation Architecture

People = UserWork = Screen Format

e.g. Se curity Architecture

People = IdentityWork = Job

e.g. ORGANIZATION

Planner

Owner

to the BusinessImportant to the Business

What How Where Who When Why

Copyright - John A. Zachman, Zachman International

SCOPE(CONTEXTUAL)

Architecture

e.g. STRATEGY ENTERPRISE

e.g. Business Plan

TM

Zachman Institute for Framework Advancement - (810) 231-0531

9

MethodsMethods

• Information planning

• Information engineering (James Martin)

• Rational Unified Process

• TOGAF

• DYA

• …

resources& aids

standards & rulesservices

infrastructure

10

Modelling languages (I)Modelling languages (I)

• Data models (ER diagrams)

• Business process models(BPML)

• UML

Designdiagrams

Component diagrams

Use casediagrams

Processdiagrams

Deployment diagrams

11

ShortcomingsShortcomings

• Each approach or tool addresses only one or a few

aspect architectures

• Tools lack semantics• Consistency has to be checked manually

• Analysis of architectures is difficult or impossible

12

ExperiencesExperiences

• Internal inconsistencies• at the model level

• at the concept level

• at the instance level

• Processes and functions not well separated

• Tension between different architecture methods

• Many relations between models, hard to determine

• Document and version management difficult

13

OverviewOverview

• ArchiMate.

• The ArchiMate metamodel.

• Mapping to UML.

• The ArchiSurance Case.

14

ArchiMate ArchiMate

• What is ArchiMate?• A Research initiative that aims to provide concepts and techniques to

support enterprise architects in the visualization, analysis and communication of integrated enterprise architectures.

• Idea: Use enterprise architecture (business & ICT) as a basis for stability in changing organizations.

• Should give a better insight in the dependencies and

correspondences between company domains and the

impact of making changes in one of the domains.

15

The ArchiMate ProjectThe ArchiMate Project

• 2½ years, July 2002 - December 2004

• approx. 35 man-years, 4 million euro

• Consortium of companies and knowledge institutes

• Telematica Instituut leads the project

• Ideas also originated from Ordina

• ABN AMRO, Belastingdienst, ABP

• KU Nijmegen, CWI, Universiteit Leiden

16

GoalsGoals

• To describe architectures and their relations

• Communicate enterprise architectures with all

stakeholders

• Judge the impact of changes

• Realise architecture by relating to existing standards,

techniques and tools

17

The ArchiMate languageThe ArchiMate language

ArchiMate languageHigh-level modelling

within a domain

Modelling relations between domains

Basis for visualisations

Basis for analyses

18

ProcessApplication

Company-specific concepts, standards

Enterprise architecture concepts

Generic concepts

mor

e ge

neric

mor

e sp

ecifi

c

Object

Relation

Abstraction levelsAbstraction levels

19

ScopeScopeViews &

visualisation

Integrated architecturedescriptions

Analysis

20

IntegrationIntegration

An architecture might encompass for example:

• products

• organisation

• business processes

• applications

• systems

This requires concepts for domains and relations, linked with existing techniques

21

Integrated ArchitectureIntegrated Architecture

Services as central notion

for linking business & IT,

but also business &

environment

Application components and services

Roles and actors

External application services

External business services

Damage claiming process

Client Insurant InsurerArchiSurance

Registration PaymentValuationAcceptance

Customerinformation

service

Claimspaymentservice

Claimsadministration

service

Riskassessment

service

Paymentservice

Risk assessment

Claims administration

Financial system

Claimfiles

service

Claimregistration

service

Claimregistration

service

Customeradministration

service

Customer administration

Services do not exist in UML

22

Application components and services

Roles and actors

External application services

External business services

Damage claiming process

Client Insurant InsurerArchiSurance

Registration PaymentValuationAcceptance

Customerinformation

service

Claimspaymentservice

Claimsadministration

service

Riskassessment

service

Paymentservice

Risk assessment

Claims administration

Financial system

Claimfiles

service

Claimregistration

service

Claimregistration

service

Customeradministration

service

Customer administration

Integration of LanguagesIntegration of Languages

a

b

c

Process 1

UML

Testbed UML

ArchiMate architecture modelrelates to other models

23

VisualisationVisualisation

Architecture in the eyes of

• the manager

• the engineer

• the customer

• …

This requires techniques to create views on architectures

for different stakeholders

24

AnalysisAnalysis

“I want to introduce a new product, what does that

mean?”

• for our business processes

• for our security

• for our workforce

• …This requires techniques for analysis of interrelated architectures

25

OverviewOverview

• ArchiMate.

• The ArchiMate metamodel.

• Mapping to UML.

• The ArchiSurance Case.

26

The ArchiMate metamodelThe ArchiMate metamodel

ActorRole

Application component

Application function

Business object

Artifact

Value

Application service

Application interface

Infrastructure interface

Infrastructure service

Node

DeviceSystemsoftware

Network

Organisational service

Event

Organisationalinterface

Business process/function

Business

Application

Application

Infrastructure

Data object

Contract

Product

Communicationpath

Representation

Behavior

Components/ResourcesObjects

27

OverviewOverview

• ArchiMate.

• The ArchiMate metamodel.

• Mapping to UML.

• The ArchiSurance Case.

28

IntroductionIntroduction

• Detail of UML makes UML difficult to understand for

business managers and other persons involved with

business architecture.

• ArchiMate keeps diagrams global instead of detailed,

like UML.

• ArchiMate builds on existing standards (UML).

Examples taken from a case, displaying mapping of

ArchiMate to UML.

29

ArchiMate to UMLArchiMate to UML

• Focus only on the domain integration

• ArchiMate interesting since it:

• Gives relations and consistency between diagrams.

• Makes UML accessibly to less experienced users by applying a simplification to

UML.

• Mapping to UML (2.0) makes it possible to map ArchiMate models

to UML models. In the future, use UML tools to verify models.

• Domain integration makes it possible to verify models concerning

different domains.

30

OverviewOverview

• ArchiMate.

• The ArchiMate metamodel.

• Mapping to UML.

• The ArchiSurance Case.

31

The ArchiSurance CaseThe ArchiSurance Case

• A Business Case, concerning an Insurance Company

with a Intermediary and a Customer. Here restricted to

four operations.

• Used to verify and explain ArchiMate.

• Three models from the case will be discussed:

Business Structure, Business Process and Application

Structure.

32

ArchiSurance business structureArchiSurance business structure

claimhandling

premiumcollection contractingnegotiation

intermediary

insurancecompanycustomer

Role

Collaboration

Class

Class

33

Business Structure, Class diagramBusiness Structure, Class diagram

34

ArchiSurance Business ProcessArchiSurance Business Process

contractingcustomer

investigaterequest forinsurance

formalizerequest

createcontract

checkcontract

insurancecompanynegotiation

policy(contract)

formalrequest

signcontract

registerpolicy

Class +

Collaboration

Class

Activity or

Sequence diagram

Sequence

Diagram

Class

Event

Interaction

Object

Process

35

Business Process, Interaction Overview Diagram

Business Process, Interaction Overview Diagram

36

Business Process, Interaction Overview DiagramBusiness Process, Interaction Overview Diagram

37

ArchiSurance Application structureArchiSurance Application structure

PrintWise ArchiSure

viewrequests

view policies

print contracts

printbills

create & edit policies

printing

Class

Interface

Class

Operation

Interface

Actor or

Role

Service

Collaboration

38

Application Structure, class diagramApplication Structure, class diagram

39

Questions?