Enterprise Architecture is Evolution

Outline

The evolution of Enterprise Architecture:The Enterprise Architecture as metaphorEnterprise Architecture, the frameworkZachman framework: explanations, usageShortcomings of this approach

EA as a formal disciplineA formal approach to Enterprise ArchitectureBorland’s approachA 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 eventsSo:

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

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 = FieldReln = Address

e.g. Physical Data Model

Ent = Segment/Table/etc.Reln = Pointer/Key/etc.

e.g. Logical Data Model

Ent = Data EntityReln = Data Relationship

e.g. Semantic Model

Ent = Business EntityReln = Business Relationship

List of Things Importantto the Business

ENTITY = Class ofBusiness Thing

List of Processes theBusiness Performs

Function = Class ofBusiness Process

e.g. Application Architecture

I/O = User ViewsProc .= Application Function

e.g. System Design

I/O = Data Elements/SetsProc.= Computer Function

e.g. Program

I/O = Control BlockProc.= Language Stmt

e.g. FUNCTION

e.g. Business Process Model

Proc. = Business ProcessI/O = Business Resources

List of Locations in which the Business Operates

Node = Major BusinessLocation

e.g. Business Logistics System

Node = Business LocationLink = Business Linkage

e.g. Distributed System

Node = I/S Function(Processor, Storage, etc)Link = Line Characteristics

e.g. Technology Architecture

Node = Hardware/SystemSoftware

Link = Line Specifications

e.g. Network Architecture

Node = AddressesLink = Protocols

e.g. NETWORK

Architecture

Planner

Owner

ENTERPRISEMODEL

(CONCEPTUAL)

Designer

SYSTEMMODEL

(LOGICAL)

TECHNOLOGYMODEL

(PHYSICAL)

DETAILEDREPRESEN-

TATIONS (OUT-OF

CONTEXT)

Contractor

FUNCTIONING

MOTIVATIONPEOPLE

e.g. Rule Specification

End = Sub-condition

Means = Step

e.g. Rule Design

End = ConditionMeans = Action

e.g., Business Rule Model

End = Structural AssertionMeans =Action Assertion

End = Business ObjectiveMeans = Business Strategy

List of Business Goals/Strat

Ends/Means=Major Bus. Goal/Critical Success Factor

List of Events Significant

Time = Major Business Event

e.g. Processing Structure

Cycle = Processing CycleTime = System Event

e.g. Control Structure

Cycle = Component CycleTime = Execute

e.g. Timing Definition

Cycle = Machine CycleTime = Interrupt

e.g. SCHEDULE

e.g. Master Schedule

Time = Business EventCycle = Business Cycle

List of Organizations

People = Major Organizations

e.g. Work Flow Model

People = Organization UnitWork = Work Product

e.g. Human Interface

People = RoleWork = Deliverable

e.g. Presentation Architecture

People = UserWork = Screen Format

e.g. Security Architecture

People = IdentityWork = Job

e.g. ORGANIZATION

Planner

to the BusinessImportant to the Business

What How Where Who When Why

John A. Zachman, Zachman International (810) 231-0531

SCOPE(CONTEXTUAL)

Architecture

e.g. STRATEGYENTERPRISE

e.g. Business Plan

TM

Aspects

Viewpoi

nts

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 (de-normalised),

physical storage design

Detailed Program Design

Network architecture

Screens, security architecture (who can see what?)

Timing definitions

Rule specification in program

logic

Working systems

Functioning System

Converted dataExecutable programs

Communications facilities

Trained people Business eventsEnforced

rules

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

Review AS-IS

Business

Architecture

Analysis of

state

Criteria

Processes

Best Practices

Framework

Info

rmat

ion

Arch

itect

ure Application

Architecture

Infrastructure

Architecture

AS-IS

Business

Architecture

Info

rmat

ion

Arch

itect

ure Application

Architecture

Infrastructure

Architecture

Interim

Business

Architecture

Info

rmat

ion

Arch

itect

ure Application

Architecture

Infrastructure

Architecture

TO-BE

Provide Interim

Rationale

Define TO-BE

Projects

Manage Evolution

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

Projects & Portfolios Business Design

System Design Infrastructure Management

Business Process &

Requirements Modelling

BPMN/UML

EUP/PLA

ITIL profiles

Convergent Architectural Framework

Must support model

isomorphism, and component

metamorphosis

Isomorphic metamodels

MDA as framework

Viewpoint Model

Computation Independent(CIM)

Focus on enterprise, environment and the requirements Structure and execution are not part of the CIM

CIM Example: Requirement Model, Business (Process) Model

PlatformIndependent(PIM)

Focus on structure and execution independent of a concrete platform

PIM Example: Use cases, Class diagrams, Process diagrams, Activities, …

Platform specific(PSM)

Extends PIM with platform aspects

PSM Platform specificExample: EJB Profile

Model Transformation

Model standardisation

MOF Meta

Metamodel

Common Warehouse Metamodel

UML Metamodel

Web Services Profile

Business Process

Metamodel

Business Rules Metamodel

CORBA Profile

EJB Profile

EAI Profile

EDOC Profile

Scheduling Profile

.Net Profile

IT Infrastructure Metamodel

Metamodels are

MOF-compliant models

(or languages)

Profiles are UML compliant,

and thus, also MOF-compliant

metamodels (or languages)

XMI rules

XML

XMI Files

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

Transform 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 – non-

documented technology models – and gives a good path to follow for legacy modernisation.

An example for AS-IS to TO-BE

MDA

Repository

Lift

Wrap

Replace

AS-IS

TO-BE

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

Analyst

Architect

Developer

Business Analyst

Designer

StarTeam

CaliberRM

Together Together

CIM

PIM

PSM

MDA enables EA with generated traceability

CI

M

PI

M

PSM

CaliberRM

Together

Tempo

Together

StarTeam

Segue/J,N-Unit

Architect

Builder

Planner

Designer

Builder

Business Owner

Trace To (manually/ generated)

Trace To (generated)

Trace To (manually)

Trace To (generated)

MDA Transformations

generated generated

1

1..*

1..*

1..*

1

11

1..*

Operations Manager

MDA/CMMI/ITIL: Deliverables traceability and change log

RequirementsRequirements

Project planProject plan

Design modelsDesign models

SourceSourceReleaseRelease

TestsTests

Which requirement whenimplemnented?

Which requirement is tested?

Which release contains a specialrequirement?

How and where are requirementsimplemented?

How and where are requirementsmodeled?

ChangeChange

How and What will it hit?

EvolutionEvolution

How was this one year ago?How was implemented?

What should be implemented, tested,delivered?

A case base on SOA

Business Architecture

Info

rmat

ion

Arch

itect

ure Enterprise Architecture

Infrastructure Architecture

Business Process Architecture

Enterprise Architecture portfolio

SOA portfolio

Enterprise Architecture design

SOA design

SOA infrastructure

Provides the context and relationship between services and the business strategy and operating model.

Is the Planner’s viewpoint.

The enterprise model.

Is the Owner’s viewpoint.

Describes the total view of what services

provide what functionality to what business

groups or processes. Develop the SOA portfolio,

with a ‘To-Be’ 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