Enterprise architecture is evolution
1 / 32

Enterprise Architecture is Evolution - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Enterprise Architecture is Evolution' - honorato-horne

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  • 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
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
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
EA, take one: The Metaphor, continued

  • The derivation of the architectural concept, by analogies:

Ea take two the birth of framework
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

Understanding and using zachman framework
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”

Zachman and the idea of ea evolution
Zachman and the idea of EA evolution


Best Practices



Analysis of state

Manage Evolution

Provide Interim

Define TO-BE

Review AS-IS











Information Architecture

Application Architecture


Information Architecture

Application Architecture

Information Architecture

Application Architecture

Infrastructure Architecture

Infrastructure Architecture

Infrastructure Architecture

Shortcomings of the framework approach
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
The idea of convergence


Business Process & Requirements Modelling

Projects & Portfolios

Business Design

Convergent Architectural Framework

Must support model isomorphism, and component metamorphosis

Infrastructure Management

System Design


ITIL profiles

Model standardisation
Model standardisation


MOF Meta


Metamodels are

MOF-compliant models

(or languages)

XMI rules

Business Rules Metamodel

Business Process Metamodel

IT Infrastructure Metamodel

Common Warehouse Metamodel

UML Metamodel

XMI Files

Profiles are UML compliant,

and thus, also MOF-compliant

metamodels (or languages)

.Net Profile

Web Services Profile

EDOC Profile

EJB Profile

Scheduling Profile

EAI Profile

CORBA Profile

Model standardisation continued
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 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 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
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
Back to Zachman





  • 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
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
An example for AS-IS to TO-BE

MDA Repository







Cobol metamodel see example
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





Business Analyst

MDA and Borland ALM








Mda enables ea with generated traceability

Business Owner





Operations Manager


MDA enables EA with generated traceability




Trace To (manually/ generated)



Trace To (manually)






Trace To (generated)


MDA Transformations








Trace To (generated)


Mda cmmi itil deliverables traceability and change log
MDA/CMMI/ITIL: Deliverables traceability and change log


Project plan

Design models

How and What will it hit?

Which requirement whenimplemnented?

How and where are requirements


What should be implemented, tested,




Which requirement is tested?

How was this one year ago?

How was implemented?

How and where are requirementsimplemented?

Which release contains a specialrequirement?




A case base on soa
A case base on SOA

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

Is the Planner’s viewpoint.

Business Architecture

The enterprise model.

Is the Owner’s viewpoint.

Business Process 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 ‘To-Be’ state and a ‘Current State’. Concerns the Architect

Enterprise Architecture portfolio

SOA portfolio

The enterprise technical design artefacts. Is the Designer’s viewpoint.

Enterprise Architecture design

Describe architecture patterns, design principles and data standards.

Is the Builder’s viewpoint.

SOA design

SOA infrastructure

Tool and platform standards, production and test environment specifications, and SOA-specific elements for service registration, security, monitoring, etc. Contains the running system.

Infrastructure Architecture

The setup
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