Enterprise communication using archiMate

1 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m www.csInteractiveTraining.com
Enterprise Collaboration
Presented by Louw Labuschagne

2 w w w . c s I n t e r a c t i v e T r a i n i n g . c o m
Louw is passionate about all aspects of information management and
had the opportunity to act as
strategist, architect, speaker, trainer, analyst, modeller and developer
within this field over the past 18 years holding a strong track record at
reputable organisations.
Industry Contributions
• Contributor to TOGAF 9 & ArchiMate 1.0 Standards
• Contributor to TOGAF 9 Certification for People
• Open Group white paper co-author: IT Governance
• Speaker at Open Group conferences & Webinars
Industry Articles
• Author of several published white papers on
TOGAF, Enterprise Architecture & Architecture skills
Certifications
• TOGAF 9 Certified Architect
• Licensed ZapThink Architect
• Zachman Certified
• ArchiMate 2 Certified
Louw Labuschagne
M. Tech. Professional
Practice in I.T. , MBA

Agenda
• Business Context
• The Need for Collaboration
• Business Entities
• Entity Lifecycles
• The ArchiMate Language
• Primitive & Composite Views
EA as
Strategy
COBIT
GERAM
Zachman
Framework
TOGAF
ADM
ISO/IEC
38500
ArchiMate Architecture
Capability
SOA
SOCCI
ISO/IEC
42010
Open
Enterprise
Security
Architecture

Board of
Directors
Vehicle Asset
Finance
Business
Information
Management
Dealer Call
Centre
Service
Centre
Processing
Centre
Document
Filing
Retail Banking
Division
Home Loans
Division
Shared
Services
Division
Finance
Internal Audit
MIS & Fin
Reporting
Marketing HR
Performance
Management
Learning &
Development
Enterprise
Program
Office
Project
Haraka
ICT
Strategy &
Architecture
Projects &
Development
IT Operations
Organisational Structure

• The Vehicle Asset Finance is a highly
paper intensive with 85000 applications
received monthly.
• 20% is manually faxed and contains an
average of 4 pages per application.
Vehicle Asset Finance Division
Business Challenge: The VAF has faced a 5% loss in its market share
over the past 3 years due to application processing taking longer that 4
hours per application.

Key Issues within the VAF
Process
inefficiencies
Ineffective
manual work
distribution
methods result
in bottlenecks
and high lag
times
Data Quality
Issues
No control over
the quality of
data entering
the processing
channel
System
Inefficiencies
Inability to
systematically
track where a
transaction is in
the process
Deterioration
in sales
relationships
Accountability
for service
breakdowns
can‟t be
identified
(Blaming)
Vehicle Asset Finance Division

• There is an on-going initiative in Imali Bank to make the business
paperless, resulting in an increased importance ascribed to the
value of Business Process Management (BPM) systems.
• This has led to Imali bank‟s decision to implement a BPM solution
in the Vehicle Asset Finance (VAF) environment to manage the
administration of vehicle asset finance applications.
• To ensure maximum business process efficiency the business
processes in the VAF service centre and processing centre will be
reengineered in parallel with the implementation of the BPM
solution.
Project Haraka – Automating Vehicle Asset Finance

The Business Need

How would you solve the issues in the VAF Division?
• Update the systems on a trial and error basis..
High Risk

• Appoint a professional person to help update the system..
Time consuming
Expensive

• The current system reached end-of-life; Replace with a new system
Decommission
Build from scratch

The Answer: Enterprise Architecture
"If you get really honest and search all of history, seven thousand
years of known history of humankind, to find how humanity has
learned to cope with two things, complexity and change… there is
one game in town, ARCHITECTURE.” John Zachman
ISO/IEC 42010:2007 defines “architecture” as:
“The fundamental organization of a system, embodied in its components, their
relationships to each other and the environment, and the principles governing its
design and evolution.”
Enterprise Architecture is the continuous practice of
describing the essential elements of a socio-technical
organisation, their relationships to each other and to the
environment, in order to understand complexity and manage
change.
- Enterprise Architecture Research Forum (EARF)

Built Environment
Lifecycle
Concept
Design
Installation

ISO 15704 Requirements for enterprise-
reference architectures and methodologies
• its initial concept in the eyes of the entrepreneurs who
initially developed it,
• through its definition,
• functional design or specification,
• detailed design,
• physical implementation or construction,
• and finally operation
• to obsolescence.
Generalised Enterprise Reference Architecture and Methodology (GERAM)
is an enterprise-reference architecture that models the whole life history of
an enterprise integration project from
Identification
Concept
Requirements
Preliminary
Design
Detailed Design
Implementation
Operation
Decommission
EntityLife-cyclePhases

Product Lifecycle
1. Identification
2. Concept
3. Requirements
4. Preliminary
Design
5. Detailed
Design
6. Implementation
7. Operation
8. Decommission
ISO 15704 GERAM Life-cycle Phases

Architecture
1. Identification
2. Concept
3. Requirements
4. Preliminary
Design
5. Detailed Design
6. Implementation
7. Operation
8. Decommission

The Zachman Framework for Enterprise Architecture has
become a de facto standard for classifying the artifacts
developed in enterprise architecture. It is a logical
structure for classifying and organising the design artifacts
of an enterprise that are significant to its management.
The Zachman Framework is:
• Simple – easy to understand, not technical, but logical.
• Comprehensive – it addresses the Enterprise in its entirety.
• a Language – helps to communicate complex concepts precisely with
few, non-technical words.
• a Planning tool – position issues in the context of the Enterprise and
assists with making better choices.
• a Problem-solving tool – working with abstractions allows for the
isolation of simple variables without losing the sense of complexity of the
Enterprise as a whole.
The Zachman Framework

• Strategic Information
– Organised Information about the environment
• Markets
• Customers / non-customers
• Technology Trends
• World-wide Finance / Changing world economy
• Tactical Information
– Foundation Information
– Productivity Information
– Competence Information
– Resource Allocation Information
• Operational Information
– Accounting Information -> focused on lowering cost
– Cost accounting / Total Quality Management
Business Success is based on Creating Value and
Wealth and not in just controlling costs – Peter Drucker
Enterprise
Architecture
Value
Contribution

Several disciplines are involved in the enterprise change
process
Change
Process
Management
Science
Industrial
Engineering
Control
Engineering
Information &
Communication
Technology

The Entity Life cycle

Strategic Management Entity (Type 1)
defines the necessity and the starting of any
enterprise engineering / integration effort.
Engineering Entity (Type 2) provides the
means to carry out the enterprise engineering
efforts defined by enterprise Entity Type 1.
Construction Entity (Type 2) provides the
Manufacturing Entity (Type 3) is the result of
the operation of Entity Type 2. It uses the
operational system provided by Entity Type 2
to define, design, implement and build the
products and customer services of the
enterprise (Entity Type 4).
ISO 15704 GERAM Entity Types & Entity Life-cycle Phases
1. Identification
2. Concept
3. Requirements
4. Preliminary
Design
5. Detailed Design
6. Implementation
7. Operation
8. Decommission
Product:
Enterprise Concept
Product:
Enterprise Design
Product:
Enterprise Installation
Enterprise Product (Type
4) is the result of the
operation of Entity Type 3.
It represents all products
and customer services of
the enterprise.

Board of
Directors
Vehicle Asset
Finance
Business
Information
Management
Dealer Call
Centre
Service
Centre
Processing
Centre
Document
Filing
Retail Banking
Division
Home Loans
Division
Shared
Services
Division
Finance
Internal Audit
MIS & Fin
Reporting
Marketing HR
Performance
Management
Learning &
Development
Enterprise
Program
Office
Project
Haraka
ICT
Strategy &
Architecture
Projects &
Development
IT Operations
Strategic Management Entity (Type 1)
defines the necessity and the starting of any
enterprise engineering / integration effort.
Engineering Entity (Type 2) provides
the means to carry out the enterprise
engineering efforts defined by
enterprise Entity Type 1.
Manufacturing Entity (Type 3) is the result of
the operation of Entity Type 2. It uses the
operational system provided by Entity Type 2
to define, design, implement and build the
products and customer services of the
enterprise (Entity Type 4).
ISO 15704 GERAM Entity Types
Engineering Entity (Type 2) provides
the means to carry out the enterprise
engineering efforts defined by
enterprise Entity Type 1.

Imali Bank Vehicle Asset Finance Electronic
Application Service (i-VAF)
• To optimise business processes i-VAF will provide full end-to-end
management of each vehicle asset finance application.
• i-VAF will provide full process and status visibility of application
transactions at all interfacing points.
– The visibility that is gained will enable continuous improvement to eliminate
waste from processes and improve turnaround time and costs.
– Quality assurance will be incorporated earlier in the lifecycle and feedback
required during the process will be automated where necessary.
– All manual forms and other supporting documentation related to applications
will be electronically available and greatly reduce the need for paper.
• i-VAF will provide the capability to allocate work based on business rules
as well as re-prioritise and re-allocate work when required.
– Full business activity monitoring will be available across the end-to-end vehicle
asset finance application management process with service level agreements
and escalation management.
Enterprise Product (Type 4) is
the result of the operation of
Entity Type 3. It represents all
products and customer services
of the enterprise.

Project Management
Companywide IT Governance
IT Engagement Model*
Company strategy
& operations
Project plan
Solution
Architecture
Enterprise
architecture
Alignment
Coordination
Business Linkage
• Business sponsors for projects
• Regular project reviews by
company level office
• Process owners
• Incentives tied to company goals
Architecture Linkage
• Architect on projects
• Project funding based on
Architecture compliance
• Architect training
Project
Level
Company
Level
ITBusiness
Alignment Linkage
• Project Management Office
• Business – IT relationship
managers
• Project manager training
*Based on the model defined
in Enterprise Architecture as
Strategy (Ross, Weill &
Robertson)
ISO 38500:2008
ISO 21500:2012
ISO/IEC 20000: 2005

AAF Automotive Architecture Framework
BCA Business Capability Architecture
BEAM Business Enterprise Architecure Modeling
BPEAM
iteratec best-practice enterprise architecture
management (EAM) method
CEA
CEA Framework: A Service Oriented Enterprise
Architecture Framework (SOEAF)
CIAF Capgemini Integrated Architecture Framework
DoDAF
US Department of Defense Architecture
Framework
DRA1 Dragon1
E2AF Extended Enterprise Architecture Framework
EXAF Extreme Architecture Framework
FEAF US Federal Enterprise Architecture Framework
FFLV+GODS
Functions-Flows-Layers-Views + Governance-
Operations-Development-Support
FSAM
Federal Segment Architecture Methodology
(FSAM)
GEAF Gartner's Enterprise Architecture Framework
HEAF Health Enterprise Architecture Framework
Enterprise Architecture Frameworks
ICODE iCode Security Architecture Framework
IFW IBM Information FrameWork (IFW)
4+1 Kruchten's 4+1 view model
MODAF
(UK) Ministry of Defence Architecture
Framework
NAF NATO C3 Systems Architecture Framework
NIST-EAM NIST Enterprise Architecture Model
PEAF Pragmatic Enterprise Architecture Framework
PPOOA
Processes Pipelines in Object Oriented
Architectures
SABSA
Sherwood Applied Business Security
Architecture
TEAF
(US) Treasury Enterprise Architecture
Framework
TOGAF The Open Group Architecture Framework
xAF Extensible Architecture Framework
ZF Zachman Framework
IADS IBM Architecture Description Standard
IAF Index Architecture Framework

IFIP-IFAC Task Force, 1999)
ISO 15704 Requirements for enterprise-reference
architectures and methodologies
GERA
Identifies concepts of
enterprise integration
EEM
Describe process of
enterprise engineering
EMLs
Provide modelling
constructs for modelling
enterprise concepts
EETs
Support enterprise
engineering
GEMCs
Define the meaning of
enterprise modelling
constructs
PEMs
Provide reusable reference
models and designs of
enterprise concepts
EMs
Enterprise designs, and
models to support
analysis and operationEMOs
Provide implementable
modules
(human, process &
technology)
EOS
Support the operation of
the particular enterprise
employs utilise
Implemented in
support
Used to build
Used to implement
(Particular)
Enterprise
Operational
Systems
Human
Concepts
Technology
Concepts
Process
Concepts
Generic
Enterprise
Reference
Architecture
Enterprise
Engineering
Methodology
Enterprise
Modelling
Languages
Partial
Enterprise
Models
Generic
Enterprise
Modelling
Concepts
Enterprise
Modules
(Particular)
Enterprise
Models
Enterprise
Engineering
Tools
Strategic
Management
Entity
(Type 1)
Construction
Entity
(Type 2)
Engineering
Entity
(Type 2)
Enterprise
Product
(Type 4)
Manufacturi
ng Entity
(Type 3)
Methodology
Entity
(Type 5)
Enterprise Engineering Tool

The Architecture Development Method (ADM) is
an iterative approach to
planning, designing, realising, and governing the
change effort.
ISO 38500:2008
ISO 21500:2012
ISO/IEC 15504 (SPICE)
ISO/IEC 20000: 2005 Identification
Concept
Requirements
Preliminary
Design
Detailed
Design
Implementation
Operation
Decommission

ArchiMate

ArchiMate 2 and the TOGAF® ADM
• ArchiMate Core
– Enables modeling of the
architecture domains defined
by TOGAF
• Motivation Extension
– Enables modeling of
stakeholders, drivers for
change, business
goals, principles and
requirements
• Implementation and Migration
Extension
– Enables modeling of project
portfolio management, gap
analysis and transition and
migration planning

Have you ever seen the following happen?
THE QUICK BROWN FOX
JUMPS OVER THE LAZY
DOG
A A
B B
C C
D D
E E
F F
M M
N N
O O
P P
Q Q
R R
G G
H H
I I
J J
K K
L L
S S
T T
U U
V V
W W
X X
Y Y
Z Z
Apply English Language Rules

Can you now answer the question?
THE QUICK BROWN FOX JUMPS OVER THE
LAZY DOG
...Because everyone in the room were
taught the english language rules ...
 Standard form for each shape
 Standard spelling for using shapes
 Standard pronunciations for each shape
 Standard meanings of each shape
 Standard rules for the use of shapes

Key requirements of an Enterprise Architecture
Modelling Language
 Focused on modelling inter-domain relations
 Modelling the global structure within each domain, showing the
main elements and their dependencies, in a way that is easy to
understand for non-experts of the domain
 Models must be interpreted in an
unambiguous way
 Visualise models in a different
way, tailored towards specific
stakeholders with specific
information requirements

Introduction to [Ahr-ki-meyt]
• ArchiMate provides instruments to support enterprise architects in
describing, analysing and visualising the relationships among
business domains in an unambiguous way
• ArchiMate is an open and independent modelling language for
enterprise architecture
• Supported by leading EA tool vendors
• Tailored towards specific stakeholders addressing specific
information requirements

Layered Services Approach
Application Layer
The Application layer supports the business
layer with application services which are realised
by (software) applications.
Business Layer
The Business layer offers products and services
to external customers, which are realised in the
organisation by business processes performed
by business actors.
Technology Layer
The Technology layer offers infrastructural
services (e.g., processing, storage and
communication services) needed to run
applications, realised by computer and
communication hardware and system software.
A service is defined as a unit of functionality that
some entity (e.g., a system, organisation or
department) makes available to its
environment, and which has some value for
certain entities in the environment.

Language Elements
• Behavioural or dynamic aspect
– Behavioural concepts are assigned
to structural concepts, to show who
or what displays the behaviour
• Structural or static aspect
– Active structural elements
• the business actors, application
components and devices that display
actual behaviour, i.e., the „subjects‟ of
activity
– Passive structural elements
• i.e., the objects on which behaviour
is performed
• External view and an internal view
– For the external users, only this
external functionality, together with
non-functional aspects such as the
quality of service, costs etc., are
relevant

Generic Metamodel – Core Concepts of
ArchiMate

Practical: Model the following in your favourite
modelling tool

• Now that you have a basic overview of the open day process as it
is, let's see what happens when we extend the use of the new
CRM package. To understand how that will work, we need to break
apart the services that the applications provide, and represent
them in a separate 'services' layer, between the application layer
and the business layer. It will contain:
•
• The MS Exchange package realises the email service
• The CRM package realises:
– a Marketing Service
– a CRM e-mail Service
– a Print Open Day Register Service
Add Services Layer

• These services are particularly widely used inside the Open Day
Planning process, so we'll make that process box bigger and we'll
put a number of sub-processes inside of it. It starts with:
• a Confirm Room Booking process, which triggers both:
– an E-mail staff process, which triggers:
• a Book Catering process, which triggers:
• a Check and Update Signage process, which triggers both:
– a Print PGCE process
– an Update Materials process, which triggers:
– the same Print PGCE process
– a Create Marketing list process, which triggers:
• an Attach Marketing List to Event process, which triggers:
• an E-mail Marketing List process, which triggers:
• an Add Planning Tasks process, which triggers:
• the same Update Materials process
Add Sub-processes

Now that the process has been elaborated, we can connect which
services are used to make these processes happen.
• The Marketing Service is used by:
– Create Marketing List process
– Attach Marketing List to Event process
– Add Planning Tasks process
• The E-mail Service is used by:
– Confirm Room Booking process,
– E-mail staff process
– Send Update to Subject Staff process
• The CRM E-mail Service is used by:
– E-mail Marketing List process
• The Print Open Day Register Service is used by:
– Print Open Day Register process
Link Services to processes

• In addition, there now is a Role of "Open Day planner" who has
been assigned all processes in the open day planning model.
• The role has been assigned to the actor "Sue".
Add Role

• The model is fairly comprehensive, but also a bit hairy.
• It's just too complex to show to most stakeholders.
• That's why we want to create a new view on the same model.
• The ArchiMate specification itself specifies 18 views for various
purposes, but ArchiMate Modelling Tool will happily let you make your
own view.
• In each case, the important point is to be clear what the view is meant
to achieve or convey, and for what stakeholders it is intended.
• For this exercise:
– Pick your goal
– Pick your target group
– Limit the number of entities in the view to the ideal: seven, plus or minus
two
Views

Architecture
1. Identification
2. Concept
3. Requirements
4. Preliminary
Design
5. Detailed Design
6. Implementation
7. Operation
8. Decommission

 Row 2 – Conceptually define what the
owners have in mind
 Row 3 – How will the Enterprise concepts
be realised systematically
 Row 4 – Enterprise implementation based
on general technology constraints
 Row 5 –Specify the implementations to
specific technology products
 Row 6 – Functioning Enterprise
1
3
2
4
5
6
 Row 1 – Boundaries of the Enterprise,
what is included
The Zachman Framework consists of a six by six matrix with each row representing a different
perspective on the enterprise. Row 1 is the most abstract view, with each following row
representing more detail and concrete views of the enterprise until Row 6 that are the
functioning enterprise.

Contextual
Conceptual
Logical
Physical
As Built
Functioning
Contextual
Conceptual
Logical
Physical
As Built
Functioning
Why
Why
Who
Who
When
When
Where
Where
What
What
How
How
 Rule 2:
Each column has a simple, basic model
 Rule 3:
Basic model of each column is unique
 Rule 4:
Each row represents a distinct view
 Rule 5:
Each cell is unique
 Rule 6:
Combining the cells in one row forms a
complete description from that view
Basic Model = Entities and Relationships
Entity
Relationship
Entity
 Rule 1:
Columns have no order
The Zachman Framework Rules

• External Requirements and
Drivers
• Business Function Modeling
 Function/How
List of processes the business perform
High-level business functions
 Data/What
List of things important to the business
 People/Who
List of Organisations important to the business
 Network/Where
List of locations in which the business operates
 Time/When
List of events significant to the business
1
 Motivation/Why
List of business goals and strategies
Row 1: Scope/Planner’s View

Motivation Extension Metamodel

Example Motivation Extension Model

• Business Process Models
• Business Function Allocation
• Elimination of Function
Overlap and Ambiguity
 Function/How
Business processes
 Data/What
Business data
 People/Who
Roles and responsibilities in each
process
 Network/Where
Locations related to each process
 Time/When
Events for each process and sequencing
of integration and process improvements
2
 Motivation/Why
Policies, procedures and standards for
each process
Row 2: Enterprise Model/Designer’s View

Business Layer Metamodel

Example Business Layer Model

• Logical Models
• Project Management
• Requirements Definition
 Function/How
Logical representation of information
systems and their relationships
 Data/What
Logical data models of data and data
relationships underlying information
 People/Who
Logical representation of access privileges
constrained by roles and responsibilities
 Network/Where
Logical representation of the distributed
system architecture for locations
 Time/When
Logical events and their triggered responses
constrained by business events and their responses
3
 Motivation/Why
Policies, standards and procedures associated
with a business rule model
Row 3: System Model/Designer’s View

Application Layer Metamodel

Example Application Layer Model

• Physical Models
• Technology Management
• Solution Definition and
Development
 Function/How
Specifications of applications that operate
on particular technology platforms
 Data/What
Database management system (DBMS) type
requirements constrained by logical data models
 People/Who
Specification of access privileges to
specific platforms and technologies
 Network/Where
Specification of network devices and their
relationships within physical boundaries
 Time/When
Specification of triggers to respond to system
events on specific platforms and technologies
4
 Motivation/Why
`Business rules constrained by information
systems standards
Row 4: Technology Model/Builder’s View

Technology Layer Metamodel

Example Technology Layer Model

• Configuration Management
• Deployment
 Function/How
Programs coded to operate on specific
technology platforms
 Data/What
Data definitions constrained by
physical data models
 People/Who
Access privileges coded to control access
to specific platforms and technologies
 Network/Where
Network devices configured to conform to
node specifications
 Time/When
Timing definitions coded to sequence activities
on specific platforms and technologies
5
 Motivation/Why
Business rules constrained by specific
technology standards
Row 5: As-Built/Integrator’s View

• Functioning Enterprise
• Operations Management
• Evaluation
 Function/How
Functioning computer instructions
 Data/What
Data values stored in actual databases
 People/Who
Personnel and key stakeholders working
within their roles and responsibilities
 Network/Where
Sending and receiving messages
 Time/When
Timing definitions operating to sequence
activities
6 Motivation/Why
Operating characteristics of specific
technologies constrained by standards
Row 6: Functioning Enterprise/User’s View

Implementation & Migration Extension
Metamodel

Example Implementation & Migration
Model

ArchiMate 2 Summary

Business owners need to realise that their
enterprise architecture design is a reflection of
their business even if it is not intentional. If you
don‟t care about your enterprise architecture
then your design is telling people that you don‟t
care about your business.
— MARCO SUAREZ
(SLIGHTLY ADAPTED)

Enterprise communication using archiMate

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Enterprise communication using archiMate

Similaire à Enterprise communication using archiMate (20)

Dernier

Dernier (20)

Enterprise communication using archiMate

Notes de l'éditeur