Enterprise architecture is evolution
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Enterprise Architecture is Evolution PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Enterprise Architecture is Evolution

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


Enterprise architecture is evolution

Enterprise Architecture is Evolution


Outline

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

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


Zachman framework zachman 1987

Zachman framework, Zachman, 1987

Aspects

Viewpoints


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”


Example software architecture cf david c hay

Example: Software Architecture, cf. David C. Hay


The rows

The rows…


And the columns

…and the columns


Zachman and the idea of ea evolution

Zachman and the idea of EA evolution

Framework

Best Practices

Processes

Criteria

Analysis of state

Manage Evolution

Provide Interim

Define TO-BE

Review AS-IS

Projects

Rationale

Business

Architecture

Business

Architecture

Business

Architecture

AS-IS

TO-BE

Information Architecture

Application Architecture

Interim

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

EUP/PLA

Business Process & Requirements Modelling

Projects & Portfolios

Business Design

Convergent Architectural Framework

Must support model isomorphism, and component metamorphosis

Infrastructure Management

System Design

BPMN/UML

ITIL profiles


Isomorphic metamodels

Isomorphic metamodels


Mda as framework

MDA as framework


Model transformation

Model Transformation


Model standardisation

Model standardisation

XML

MOF Meta

Metamodel

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

CIM

PIM

PSM


Comments

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

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

Replace

Wrap

AS-ISTO-BE

Lift

TO-BE

Legacy


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

Analyst

Architect

Designer

Developer

Business Analyst

MDA and Borland ALM

PIM

Together

Together

PSM

CIM

CaliberRM

StarTeam


Mda enables ea with generated traceability

Business Owner

Designer

Architect

Builder

Builder

Operations Manager

Planner

MDA enables EA with generated traceability

CaliberRM

CIM

1

Trace To (manually/ generated)

1

1

Trace To (manually)

1..*

1

1..*

Together

PIM

Trace To (generated)

Tempo

MDA Transformations

1..*

generated

generated

PSM

Together

Segue/J,N-Unit

1..*

Trace To (generated)

StarTeam


Mda cmmi itil deliverables traceability and change log

MDA/CMMI/ITIL: Deliverables traceability and change log

Change

Project plan

Design models

How and What will it hit?

Which requirement whenimplemnented?

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?

How and where are requirementsimplemented?

Which release contains a specialrequirement?

Evolution

Source

Release


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


  • Login