Enterprise Architecture is Evolution
Outline
The evolution of Enterprise Architecture:
 The Enterprise Architecture as metaphor
 Enterprise Architecture, the framework
 Zachman framework: explanations, usage
 Shortcomings of this approach
EA as a formal discipline
 A formal approach to Enterprise Architecture
 Borland’s approach
 A concrete case
What is Enterprise Architecture?
Enterprise Architecture (EA) embraces the disciplines of assessment,
visioning, design, controlled evolution and improvement, having the
purpose alignment with respect to business, applications/components,
information, technology infrastructure and methods and practices that
concern the Enterprise.
EA informs and guides technology decisions:
 Planning decisions
 Investment decisions
 Solution Design decisions
EA consists of principles, policies, standards, guidelines, processes, reference
models/architectures—anything that can help us make better decisions!
EA, take one: The Metaphor
 Enterprise Architecture (EA) was borne of a metaphor based
on classical architecture: the planning and construction of
buildings, airplanes, machineries.
 In the notion of information systems architecture the analogy
was built-in, as the levels of representation produced by
classical architects were projected onto the system
development lifecycle.
 These representations give rise to a set of views representing
the various perspectives taken by different participants in the
system development process.
 Each of these representations are completely different,
different in content, in meaning, in motivation, in use, with no
such discriminator as abstraction levels. These representations
are just plain different.
EA, take one: The Metaphor, continued
The derivation of the architectural concept, by analogies:
Generic
Buildings
Airplanes
Information Systems
Ballpark
Bubble charts
Concepts
Scope & Objectives
Owner’s
representation
Architect’s
representation
Work breakdown
structure
Business model
Designer’s
representation
Architect’s plans
Engineering design
IT model
Builder’s
representation
Contractor’s plans
Manufacturing
design
Technology model
Detailed
representation
Shop plans
Assembly drawings
Detailed description
Machine-language
representation
Assembled bricks,
bolts, mortar, etc.
Machine
instructions
Object code
Product
Building
Airplane
IT system
EA, take two: The birth of Framework
The need of the framework:
 Metaphoric prophecies had disasters built-in, since:
 The metaphors are ambiguous, i.e. programs are not airplanes
 Airplanes are well-delimited
 Systems have open-ends: are encompassing also people, processes,
external events
So:
 The System is the enterprise – requires a holistic approach
 For EA, to attain wide applicability, we need abstractions
Therefore:
 Must create a framework whose logic must be universal, independent of its
application - totally neutral relative to methods/tools
 The framework should be a "normalised" schema, NOT a matrix. That makes it
a good analytical tool
 There shall be no abstraction levels, just different views and different aspects
Zachman framework, Zachman, 1987
ENTERPRISE ARCHITECTURE - A FRAMEWORK
Aspects
Viewpoints
DATA
What
FUNCTION
How
NETWORK
Where
PEOPLE
Who
TIME
When
TM
MOTIVATION
Why
SCOPE
(CONTEXTUAL)
List of Things Important
to the Business
List of Processes the
Business Performs
Planner
ENTITY = Class of
Business Thing
Function = Class of
Business Process
Node = Major Business
Location
e.g. Semantic Model
e.g. Business Process Model
e.g. Business Logistics
System
Ent = Business Entity
Reln = Business Relationship
Proc. = Business Process
I/O = Business Resources
Node = Business Location
Link = Business Linkage
e.g. Logical Data Model
e.g. Application Architecture
e.g. Distributed System
Architecture
e.g. Human Interface
Architecture
Ent = Data Entity
Reln = Data Relationship
Proc .= Application Function
I/O = User Views
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
People = Role
Work = Deliverable
Time = System Event
Cycle = Processing Cycle
End = Structural Assertion
Means =Action Assertion
TECHNOLOGY
MODEL
(PHYSICAL)
e.g. Physical Data Model
e.g. System Design
e.g. Technology Architecture
e.g. Presentation Architecture
e.g. Control Structure
e.g. Rule Design
TECHNOLOGY
MODEL
(PHYSICAL)
Builder
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
End = Condition
Means = Action
Builder
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM
MODEL
(LOGICAL)
Designer
DETAILED
REPRESENTATIONS
(OUT-OFCONTEXT)
SubContractor
FUNCTIONING
ENTERPRISE
Proc.= Computer Function
I/O = Data Elements/Sets
List of Locations in which
the Business Operates
Node = Hardware/System
Software
Link = Line Specifications
List of Organizations
Important to the Business
List of Business Goals/Strat
Ends/Means=Major Bus. Goal/
Critical Success Factor
People = Major Organizations
Time = Major Business Event
e.g. Work Flow Model
e.g. Master Schedule
e.g. Business Plan
Time = Business Event
Cycle = Business Cycle
End = Business Objective
Means = Business Strategy
People = Organization Unit
Work = Work Product
People = User
Work = Screen Format
e.g. Security Architecture
e.g. Data Definition
e.g. Program
e.g. Network Architecture
Ent = Field
Reln = Address
Proc.= Language Stmt
I/O = Control Block
Node = Addresses
Link = Protocols
People = Identity
Work = Job
e.g. DATA
e.g. FUNCTION
e.g. NETWORK
e.g. ORGANIZATION
John A. Zachman, Zachman International (810) 231-0531
List of Events Significant
to the Business
e.g. Processing Structure
Time = Execute
Cycle = Component Cycle
e.g. Timing Definition
Time = Interrupt
Cycle = Machine Cycle
e.g. SCHEDULE
e.g., Business Rule Model
e.g. Rule Specification
End = Sub-condition
Means = Step
e.g. STRATEGY
SCOPE
(CONTEXTUAL)
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
SYSTEM
MODEL
(LOGICAL)
Designer
DETAILED
REPRESENTATIONS
(OUT-OF
CONTEXT)
SubContractor
FUNCTIONING
ENTERPRISE
Understanding and using Zachman framework
The cells’ semantic is freely definable by analogy, as long as will
answer to the specific questions posed:
 What, how, where, who, when, why
…and the horizontal viewpoints are satisfied:





Objects’ use: Planner, Owner
Logical definition: Designer
Physical design: Builder
Detailed representation: Sub-contractor
Functioning enterprise: Physical realisation
Different viewpoints, not necessarily adjacent, are related via
“canonical projections”, i.e. ways to “translate perspectives”
Example: Software Architecture, cf. David C. Hay
Data (What)
Function
(How)
Network (Where)
People (Who)
Time (When)
Motivation
(Why)
Objectives /
Scope
List of things
important to the
enterprise
List of
processes the
enterprise
performs
List of locations
where the
enterprise
operates
List of
organisational
units
List of business
events / cycles
List of
business
goals /
strategies
Model of the
Business
Entity relationship
diagram (including
m:m, n-ary,
attributed
relationships)
Business
process model
(physical data
flow diagram)
Logistics network
(nodes and links)
Organisation chart,
with roles; skill
sets; security
issues.
Business master
schedule
Business
plan
Model of the
fundamental
concepts
Data model
(converged entities,
fully normalised)
Essential Data
flow diagram;
application
architecture
Distributed system
architecture
Human interface
architecture (roles,
data, access)
Dependency
diagram, entity
life history
(process
structure)
Business rule
model
Technology
Model
Data architecture
(tables and
columns); map to
legacy data
System design:
structure chart,
pseudo-code
System
architecture
(hardware,
software types)
User interface
(how the system
will behave);
security design
"Control flow"
diagram (control
structure)
Business rule
design
Detailed
Representation
Data design (denormalised),
physical storage
design
Detailed
Program
Design
Network
architecture
Screens, security
architecture (who
can see what?)
Timing definitions
Rule
specification
in program
logic
Trained people
Business events
Enforced
rules
Working systems
Functioning
System
Converted data
Executable
programs
Communications
facilities
The rows…
Row
Description
1. Objectives/Scope
(Planner’s view)
Defines the organisation’s direction and purpose, defining the boundaries of the enterprise architecture efforts.
2. Enterprise Model
(Business owner’s view)
Defines in business terms the nature of the organisation, including its structure, processes, and people.
3. Model of Fundamental
Concepts (Architect’s view)
Defines the enterprise in more rigorous terms than row 2. This row was originally called “information system
designer’s view” in the original version of the ZF.
4. Technology Model
(Designer’s view)
Defines how technology will be applied to address the needs defined by the previous rows above.
5. Detailed Representation
(Builder’s view)
Defines the detailed design, taking implementation language, database storage, and middleware considerations
into account.
6. Functioning System
(Operations View)
These are the actual, working systems within the organisation.
…and the columns
Column
Description
1. Structure (What)
Focus is on the entities/object/components of significance, and the relationships between them, within the
organisation. This column was originally called Data in the original version of the framework.
2. Activities (How)
Focus is on what the organisation does to support itself and its customers. This column was originally called
Function in the original version of the framework.
3. Locations (Where)
Focus is on the geographical distribution of the organisation’s activities. This column was originally called
Network in the original version of the framework.
4. People (Who)
Focus is on who is involved in the business of the organisation.
5. Time (When)
Focus is on the effects that time, such as planning and events, has on the organisation.
6. Motivation (Why)
Focus is on the translation of business goals, strategies, and constraints into specific implementations.
Zachman and the idea of EA evolution
Framework
Best Practices
Processes
Criteria
Analysis
Review AS-IS
Provide Interim
Manage Evolution
Define TO-BE
of state
Projects
Rationale
Architecture
Information
Interim
TO-BE
Infrastructure
Infrastructure
Architecture
Architecture
Application
Architecture
Architecture
Architecture
Information
Architecture
Application
Architecture
Application
Infrastructure
Business
Architecture
Architecture
AS-IS
Business
Architecture
Architecture
Information
Business
Shortcomings of the framework approach
 We may try to refine the framework approach for ever – will be what
always was: a metaphor.
That means:
 The “canonical projections” between viewpoints are actually ad-hoc,
depending on the actual problem or domain.
 The same applies for different aspects.
 As a consequence, the dynamic of the evolutions is just mimicked using a
number of static snapshots.
 The ad-hoc nature of the projections will cause viewpoints’ & aspects’
specifications, i.e. their metadata, to diverge.
 Non-uniform approach to number of problems, e.g. tackling the “legacy
frustration”.
The idea of convergence
EUP/PLA
Business Process &
Requirements Modelling
Projects & Portfolios
Must support
model
isomorphism, and
component
metamorphosis
Business Design
Convergent Architectural Framework
System Design
Infrastructure Management
BPMN/UML
ITIL profiles
Isomorphic metamodels
MDA as framework
Viewpoint
Model
Computation
Independent
(CIM)
 Focus on enterprise, environment
 CIM
 Example: Requirement Model,
Platform
Independent
(PIM)
Focus on structure and execution
Platform specific
(PSM)
 Extends PIM with platform
and the requirements
 Structure and execution are not
part of the CIM
independent of a concrete platform
Business (Process) Model
 PIM
 Example: Use cases, Class
diagrams, Process diagrams,
Activities, …
aspects
 PSM
 Platform specific
Example: EJB Profile
Model Transformation
Model standardisation
Metamodels are
MOF Meta
MOF-compliant models
Metamodel
XML
XMI rules
(or languages)
Common
Warehouse
Metamodel
UML
Metamodel
IT Infrastructure
Metamodel
Business
Process
Metamodel
Business Rules
Metamodel
XMI Files
Profiles are UML compliant,
and thus, also MOF-compliant
metamodels (or languages)
CORBA
Profile
EJB
Profile
EAI
Profile
EDOC
Profile
Scheduling
Profile
.Net
Profile
Web Services
Profile
Model standardisation, continued
MDA is concerned with models and talks about them in two
different ways:
 First it is concerned with techniques that assure that all models
used in software development can be aligned with all others.
This focus emphasizes the use of MOF and metamodels.
 Second, MDA is concerned with organizing models used in the
software development process so that stakeholders can move
from one viewpoint to another.
 This focus emphasizes the use of Computation Independent
Models (CIMs), Platform Independent Models (PIMs),
Platform Specific Models (PSM).
The meta metamodel
 The Model Driven Architecture is supported by a number of




models and standards.
All MDA models are related because they are all based on a
very abstract metamodel– the Meta Object Facility, or MOF.
Every other model used in MDA is defined in terms of MOF
constructs.
In other words, every MDA model is MOF-compliant.
This guarantees that all models used in the MDA system can
communicate with every other MOF-compliant model.
The metamodels
The Common Warehouse Metamodel (CWM): The OMG’s formal model of
metadata is used to manage data warehouses. Using CWM, developers can generate
a number of more specific data models or formats, including relational tables,
records or structures, OLAP, XML, multidimensional database designs, and so
forth.
The UML Metamodel: UML, version 2.0 is MOF-compliant. UML defines a set of
core modelling concepts which can be combined into various diagrams: Class
Diagrams, Sequence Diagrams, State Diagrams, Activity Diagrams, includes a
facility that allows developers to establish constraints on various UML elements.
The Business Process Definition Metamodel: A metamodel that is still in the
development phase. The OMG has called for proposals for a MOF compliant
metamodel for business processes. Such a metamodel would be independent of
specific process definition languages and would allow MOF models to interface
with languages like WSBPEL and notations like BPMN.
Business Semantics for Business Rules: A metamodel for capturing business rules in
business terms, and the definition and semantics of those terms in business
vocabularies. In fact, there will be two specifications: a more generic standard for
business rules, and a more specific one for production rules that are actually used
by rule engines.
IT Infrastructure Metamodel: ITIL profile to cover DMTF's Common Information
Model.
UML Profiles
Web Services: Web Services is an example of a non-OMG profile developed to
facilitate the development of MOF- compliant Web Service models.
CORBA Profile: This profile defines how to use UML to create CORBA-specific
models. The CORBA specification includes the definition of a CORBA component
model that can be modelled in UML and used in application development.
EJB Profile: This profile defines how to use UML to create J2EE or EJB specific
models. Developed by the Java Community Process.
EAI Profile: (The UML Profile and Interchange Model for Enterprise Application
Integration.) This profile defines how to use UML to model event-driven EAI
solutions.
EDOC Profile: (The UML Profile for Enterprise Distributed Object Computing.) This
profile defines how to use UML to model distributed enterprise systems and the
aspects of the business that they support (business processes, entities, events, etc.).
The EDOC standard includes a Java profile that defines how to create Java-specific
models.
Scheduling Profile: (The UML Profile for Scheduling, Performance and Time.) This
profile defines how to use UML to model temporal aspects of (primarily real-time)
computer systems.
.NET Profile: Another example of a profile created by developers independent of the
OMG. A .NET profile defines how to use UML to create .NET-specific models.
Back to Zachman
CIM
PIM
PSM
Comments
 Zachman and MDA are two different approaches having the same goal: a




complete EA style
MDA supports Zachman framework explicitly:
 Each cell in the Zachman framework could be described by a formal
MOF meta-model.
 Mappings between cells could be described with Query-ViewTransform projections.
 Composite models could be constructed by transforming two (or more)
primitive models together
MDA makes Zachman concrete
The projections between cells are no more ad-hoc, but the result of a
universal approach
MDA defines the convergence at the metamodels level
UML for EAI, an evolution aspects
The UML profile for EAI defines three important aspects for
legacy:
 Technology: legacy messaging (e.g. MQSeries) and legacy
transaction monitors (e.g. CICS)
 Application, e.g. SAP, BAAN
 Programming language: COBOL, PL1, C/C++, generic
language
 For each aspect OMG defines metamodels to map the legacy
specifics to UML.
The profile solves the “legacy frustration” problem – nondocumented technology models – and gives a good path to
follow for legacy modernisation.
An example for AS-IS to TO-BE
MDA
Repository
Lift
TO-BE
Legacy
COBOL metamodel (see example)
 The COBOL metamodel is used by enterprise application
programs to define data structures (semantics), which
represent connector interfaces.
 The goal of this COBOL model is to capture the information
that would be found in the Data Division. This model is
intended to be used to convert COBOL data division into its
XMI equivalent.
MDA and Borland ALM
PIM
Architect
Together
Together
Designer
Developer
PSM
Analyst
CIM
Business
Analyst
CaliberRM
StarTeam
MDA enables EA with generated traceability
C
I
M
CaliberRM
1
Trace To (manually/ generated)
Planner
Business
Owner
1
1
1..*
1
P
I
M
1..*
Trace To (manually)
Together
Trace To (generated)
Designer
Tempo
MDA Transformations
1..*
generated
generated
P
S
M
Architect
Builder
Together
Segue/J,N-Unit
Builder
1..*
Trace To (generated)
StarTeam
Operations
Manager
MDA/CMMI/ITIL: Deliverables traceability and change log
Change
Project plan
How and What will it hit?
Design models
Which requirement when
implemnented?
How and where are requirements
modeled?
What should be implemented, tested,
delivered?
Tests
Requirements
Which requirement is tested?
How was this one year ago?
How was implemented?
Evolution
Which release contains a special
requirement?
Release
How and where are requirements
implemented?
Source
A case base on SOA
Provides the context and relationship
between services and the business
strategy and operating model.
Business Architecture
Is the Planner’s viewpoint.
The enterprise model.
Business Process Architecture
Is the Owner’s viewpoint.
Enterprise Architecture portfolio
SOA portfolio
Enterprise Architecture design
SOA design
SOA infrastructure
Infrastructure Architecture
Enterprise Architecture
Information Architecture
Describes the total view of what services provide
what functionality to what business groups or
processes. Develop the SOA portfolio, with a ‘ToBe’ state and a ‘Current State’. Concerns the
Architect
The enterprise technical design
artefacts. Is the Designer’s viewpoint.
Describe architecture patterns, design
principles and data standards.
Is the Builder’s viewpoint.
Tool and platform standards,
production and test environment
specifications, and SOA-specific
elements for service registration,
security, monitoring, etc. Contains the
running system.
The setup
Together Architect:
 Business Process Modelling to BPEL (Planner/Architect)
 BPEL to SOA portfolio
(Architect/Owner)
 BPM to use case model
(Planner/Designer)
 Lifting legacy applications’ logic
(evolution)
Traceability with CaliberRM and Together:
 Requirements to use cases
 Requirement to infrastructure
 Issue management