Enterprise Architecture is Evolution Outline The evolution of

Enterprise Architecture is Evolution

Outline The evolution of Enterprise Architecture: v The Enterprise Architecture as metaphor v Enterprise Architecture, the framework v Zachman framework: explanations, usage v Shortcomings of this approach EA as a formal discipline v A formal approach to Enterprise Architecture v Borland’s approach v 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 Aspects Viewpoints

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 of state Rational Architectur Information TO-BE e e Application Interim Architecture e Information Architecture Application e Business e Architectur Business Architectur e Architecture Application Architectur Information Architecture Infrastructure Projects e Business AS-IS Manage Evolution Define TO-BE Infrastructure Architecture

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 Projects & Portfolios Must support model isomorphism, and component metamorphosis Business Design Modelling 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 Metamod el XML XMI rules (or languages) Common Warehouse Metamodel UML Metamodel IT Infrastructure Metamodel Business Process Metamodel Business Rules Metamodel EDOC Profile Scheduling Profile . Net Profile XMI Files Profiles are UML compliant, and thus, also MOF-compliant metamodels (or languages) CORB A Profile EJB Profile EAI 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 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 J 2 EE 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 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, PL 1, 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 Rep lace Repository p ra W Lift E B O- T TO-BE Legacy IS AS

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 Designer Developer PSM Analyst CIM Business Analyst Caliber. RM Star. Team

MDA enables EA with generated traceability C I M Caliber. RM 1 Trace To (manually/ generated) Planner Business Owner 1 1 1. . * 1 P I M 1. . * Trace To (manually) Together Trace To (generated) Tempo Designer MDA Transformations 1. . * P S M generated Architect Builder Together Segue/J, N-Unit Builder 1. . * Trace To (generated) Star. Team Operations Manager

MDA/CMMI/ITIL: Deliverables traceability and change log Change Project plan How and What will it hit? Which requirement when implemnented? Design models 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. Enterprise Architecture portfolio SOA portfolio Enterprise Architecture design SOA infrastructure Infrastructure Architecture Is the Owner’s viewpoint. Enterprise Architecture Information Architecture Business Process 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 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 Caliber. RM and Together: § Requirements to use cases § Requirement to infrastructure § Issue management