1. 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. 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
3. 3 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
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
4. 4 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
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
5. 5 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
• 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.
6. 6 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
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
7. 7 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
• 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
8. 8 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
The Business Need
9. 9 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
How would you solve the issues in the VAF Division?
• Update the systems on a trial and error basis..
High Risk
10. 10 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
• Appoint a professional person to help update the system..
How would you solve the issues in the VAF Division?
Time consuming
Expensive
11. 11 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
• The current system reached end-of-life; Replace with a new system
How would you solve the issues in the VAF Division?
Decommission
Build from scratch
12. 12 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
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)
13. 13 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
Built Environment
Lifecycle
Concept
Design
Installation
14. 14 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
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
15. 15 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
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
16. 16 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
Architecture
1. Identification
2. Concept
3. Requirements
4. Preliminary
Design
5. Detailed Design
6. Implementation
7. Operation
8. Decommission
17. 17 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
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
18. 18 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
• 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
19. 19 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
Several disciplines are involved in the enterprise change
process
Change
Process
Management
Science
Industrial
Engineering
Control
Engineering
Information &
Communication
Technology
20. 20 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
The Entity Life cycle
21. 21 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
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
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 & 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.
22. 22 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
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.
Construction Entity (Type 2) provides the
means to carry out the enterprise engineering
efforts defined by enterprise Entity Type 1.
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.
Construction Entity (Type 2) provides the
means to carry out the enterprise engineering
efforts defined by enterprise Entity Type 1.
23. 23 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
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.
24. 24 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
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
25. 26 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
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
26. 27 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
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
27. 28 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
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
28. 29 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
ArchiMate
29. 30 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
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
30. 31 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
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
31. 32 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
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
32. 33 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
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
33. 34 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
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
34. 35 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
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.
35. 36 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
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
36. 37 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
Generic Metamodel – Core Concepts of
ArchiMate
37. 38 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
38. 39 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
39. 40 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
Practical: Model the following in your favourite
modelling tool
40. 41 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
• 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
41. 42 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
• 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
42. 43 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
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
43. 44 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
• 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
44. 45 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
• 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
45. 46 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
Architecture
1. Identification
2. Concept
3. Requirements
4. Preliminary
Design
5. Detailed Design
6. Implementation
7. Operation
8. Decommission
46. 47 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
The Zachman Framework
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.
47. 48 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
The Zachman Framework
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
48. 49 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
The Zachman Framework
• 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
49. 50 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
Motivation Extension Metamodel
50. 51 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
Example Motivation Extension Model
51. 52 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
The Zachman Framework
• 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
52. 53 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
Business Layer Metamodel
53. 54 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
Example Business Layer Model
54. 55 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
The Zachman Framework
• 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
55. 56 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
Application Layer Metamodel
56. 57 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
Example Application Layer Model
57. 58 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
The Zachman Framework
• 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
58. 59 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
Technology Layer Metamodel
59. 60 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
Example Technology Layer Model
60. 61 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
The Zachman Framework
• 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
61. 62 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
The Zachman Framework
• 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
62. 63 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
Implementation & Migration Extension
Metamodel
63. 64 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
Example Implementation & Migration
Model
64. 65 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
65. 66 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
66. 67 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
67. 68 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
68. 69 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
ArchiMate 2 Summary
69. 75 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
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)
Notes de l'éditeur
Remember that Guns N’ Roses album, The Spaghetti Incident?You’re forgiven if you don’t, as it wasn’t one of their best. The album was essentially a mishmash compilation of cover songs that when cobbled together didn’t sound all that great. Now think about your IT architecture, can you see a resemblance? A mishmash of technologies – new and old – all trying to work together in a spaghetti-like structure?
Untangling the IT environment requires planning and management and in this presentation I will give a quick overview of some key challenges identified by research firms that will lead to even more entanglement if not managed properly.There is currently not a universality accepted definition of EA and therefore it is important to but context to the presentation, so before we start discussing standards and frameworks that address the challenges, I want to take a minute to state my definition of Enterprise Architecture.My objective with this presentation is to introduce the key frameworks and standards that provide practical guidance when tackling an EA project or implementing an EA capability.
JohnZachman is the father of EA and his framework is a brilliant “thinking model” to help in making sense of how to eat Elephant. He identified the value of EA to business in times of rapid change and increased complexity.As part of the EA research forum’s (consisting of academics, EA’s and business professionals) definition we included that section that EA is ongoing effort and that EA is not only a project.ISO 42010 is the best standard available that can be used to define the scope of work that needs to be done by Architects.
The lifecycle phases of an entity is important to understand and to note that different international frameworks and methods support different parts of the lifecycle in more or less detail.
Enterprise Architecture alone will not solve the spagetti structure in the organisation. We need a Governance structure to ensure that the architecture is implemented in the organisation.The IT engagement model described in Enterprise Architecture as Strategy, creating a foundation for business execution by Jeanne Ross, Peter Weill and David Robertson is in my opinion a good starting point for reviewing or implementing a governance structure around the EA effort.The IT engagement model is a system of governance mechanisms assuring that business and IT projects achieve both local and company-wide objectives.Companywide IT GovernanceProject ManagementLinking Mechanisms:Business LinkageAlignment LinkageArchitecture Linkage
Enterprise Architecture alone will not solve the spagetti structure in the organisation. We need a Governance structure to ensure that the architecture is implemented in the organisation.The IT engagement model described in Enterprise Architecture as Strategy, creating a foundation for business execution by Jeanne Ross, Peter Weill and David Robertson is in my opinion a good starting point for reviewing or implementing a governance structure around the EA effort.The IT engagement model is a system of governance mechanisms assuring that business and IT projects achieve both local and company-wide objectives.Companywide IT GovernanceProject ManagementLinking Mechanisms:Business LinkageAlignment LinkageArchitecture Linkage
There are a wide range of EA frameworks available that address some or all aspects of EA, but the question now is – Which one do I choose?Will it address the business need of managing change or reducing risk in my organisation?To answer that question we have another ISO standard
ISO 15704 Requirements for enterprise-reference architectures and methodologies (including the Generalised Enterprise Reference Architecture and Methodology [GERAM] addendum)The architecture aims to be a relatively simple framework upon which all the functions and activities involved in the aforementioned phases of the life of the enterprise-integration project can be mapped. It also will permit the tools used by the investigators or practitioners at each phase to be indicated. The architecture defined will apply to projects, products, and processes; as well as to enterprises.Lets step through an example where we see how the TOGAF framework support change in the organisation
As part of the framework we have the Generalised Enterprise Reference Architecture (GERA) entities.Understanding the fact that there are more that 1 type of entity in an organisation help with the management and planning of the EA effort.GERA identifies the following key entities:Strategic Enterprise Management Entity (Type 1)defines the necessity and the starting of any enterprise engineering / integration effort.Enterprise Engineering/Integration Entity (Entity Type 2) provides the means to carry out the enterprise engineering efforts defined by enterprise Entity Type 1. It employs a methodology (Entity Type 5) to define, design, implement and build the operation of the enterprise entity (Entity Type 3).Enterprise Entity (Entity Type 3) is the result of the operation of Entity Type 2. It uses a methodology (Entity Type 5) and 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).Product Entity (Entity Type 4) is the result of the operation of Entity Type 3. It represents all products and customer services of the enterprise.It is important to note that each Entity has a defined lifecycle and life history. For the purpose of our discussion today we will only look at the lifecycle.
Enterprise Architecture alone will not solve the spagetti structure in the organisation. We need a Governance structure to ensure that the architecture is implemented in the organisation.The IT engagement model described in Enterprise Architecture as Strategy, creating a foundation for business execution by Jeanne Ross, Peter Weill and David Robertson is in my opinion a good starting point for reviewing or implementing a governance structure around the EA effort.The IT engagement model is a system of governance mechanisms assuring that business and IT projects achieve both local and company-wide objectives.Companywide IT GovernanceProject ManagementLinking Mechanisms:Business LinkageAlignment LinkageArchitecture Linkage