1 / 32

Enterprise Architecture is Evolution

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

honorato-horne
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Enterprise Architecture is Evolution

  2. 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

  3. 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!

  4. 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.

  5. EA, take one: The Metaphor, continued • The derivation of the architectural concept, by analogies:

  6. 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

  7. Zachman framework, Zachman, 1987 Aspects Viewpoints

  8. 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”

  9. Example: Software Architecture, cf. David C. Hay

  10. The rows…

  11. …and the columns

  12. 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

  13. 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”.

  14. 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

  15. Isomorphic metamodels

  16. MDA as framework

  17. Model Transformation

  18. 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

  19. 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).

  20. 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.

  21. 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.

  22. 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.

  23. Back to Zachman CIM PIM PSM

  24. 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

  25. 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.

  26. An example for AS-IS to TO-BE MDA Repository Replace Wrap AS-IS TO-BE Lift TO-BE Legacy

  27. 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.

  28. Analyst Architect Designer Developer Business Analyst MDA and Borland ALM PIM Together Together PSM CIM CaliberRM StarTeam

  29. 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

  30. 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

  31. 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

  32. 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

More Related