Enterprise Architecture frameworks critique by Adrian Grigoriu

EA frameworks history and overview Date: By Adrian Grigoriu

Flows Layers

D S

1 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

EA frameworks history DoD AF 2003

references

JTA references

ISO/IEC 14252

CIMOSA

Supported by

C4ISR 1999

references

DoD TRM influenced

PERA

influenced supported by

TAFIM

TOGAF 1995

adopted by

influenced

TOGAF 2002

influenced influenced

Zachman 1987 influenced

TEAF 2000

influenced

EAP 1992

influenced

FEAF 1999

Zachman 2003

FEAF 2003 influenced

influenced

supported by

TISAF 1997

influenced

SAGA

influenced

E2AF 2003

influenced

UVA Model 1994

IAF v1 1996

influenced

IAF v3 EE 2001

XAF 2003

influenced

1985

1990

1995

2000

2005 Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA frameworks history

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA evolution

Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 2

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA evolution (ii)

Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 2

Flows Layers

D S

5 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

EA phases, MIT Sloan Centre

The MIT Sloan Centre for Information Systems Research (CISR) studies identified four distinct architectural stages that business units and IT must pass through before the benefits of SOA can be realized: silos (1), standardized IT (2), standardized business processes (3) and business modularity (SOA)(4)

“Long term, the history truly shows, that the EA maturity evolves from the silos of the ‘90s, through IT standardisation, to arrive now at stage 3 of business process rationalization and pointing at stage 4, the SOA based Enterprise”

CISR states that moving upwards, from stage 1 to 4, is increasingly difficult, since to achieve stage 3, business participation is a must and to realise stage 4, an overhaul of your Enterprise operation and organizational change are necessary. MIT Sloan Centre for Information Systems Research (CISR) studies, "IT Architecture as Strategy" and "IT-Driven Strategic Choices", based on projects involving 456 enterprises between 1995-2006 http://www.cio.com/article/27079/The_Four_Stages_of_Enterprise_Architecture Flows Layers

D S

Function

Planes

Lines/Products

Process Technology People

Engagement process Business Case production and Approval Current state discovery Startegy and target state specification Develop Target Architecture

Documented processes, initial tactical recommendations Business Scenarios, Conceptual Architecture (requirements) Target Architecture, Business Process analysis and recommendations Architecture gap analysis, Interim report (findings, recommendations)

Gap Analysis Develop Architecture roadmap Presentation of Strategies and Plans Implementation Close Down

Architecture Roadmap, High level program implementation recommendations Transformation plan, budget estimates Execution

Flows Layers

D S

7 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Zachman

About Zachman and Framework

Zachman EA Long Term Value

Zachman Framework

Zachman Framework description

Zachman Framework: Primitives and Composites

Zachman: EA Design Process and Enterprise Alignment

Zachman Framework Critique

Flows Layers

D S

8 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

About Zachman Framework

The pioneer of Enterprise Architecture was Zachman. His framework for information systems architecture - first proposed in 1987 and later extended in 1992, - represents the archetype of the EA frameworks.

Aims: “It is defined totally independently of tools or methodologies and therefore any tool or any methodology can be mapped against it to understand their implicit trade-offs ... that is, what they are doing, and what they are NOT doing. The Framework for Enterprise Architecture is not "the answer." It is a tool ... a tool for thinking. If it is employed with understanding, it should be of great benefit to technical and non-technical management alike in dealing with the complexities and dynamics of the Information Age Enterprise” Flows

Layers

"Concepts of Framework for Enterprise Architecture"

Function O

Lines/Products

Process Technology People

Planes

Zachman EA Long Term Value

Flows

Layers

"Concepts of Framework for Enterprise Architecture"

Function O

Lines/Products

Process Technology People

Planes

Zachman Framework abstractions

DATA W hat

perspectives

PROCESS How

List of Things Im portant to the Business

List of Processes the Business Performs

Entity = C lass of Business T hing

Function = Class of Business Process

SCOPE

NETWORK

PEOPLE

TIM E

Where

Who

W hen

List of Locations in which the Business Operates

List of Orga nizatio ns Im portant to the Business

Node = Ma jor Business Location

Peo ple = C lass of Peo ple a nd Ma jor Orga niza tio ns

e.g., Lo gistic s Networ k

e.g., W ork F lo w Mo de l

MOTIVATION W hy

List of Eve nts Significant to the Business

List of Business G oa ls a nd Strate gies

Time = Interr upt Cycle = Machine C ycle

End = Sub-conditio n Means = S te p

Zachman Framework for Enterprise Architecture

Planner

contextual

e.g., Se ma ntic Mo de l

e.g., Business Process Model

ENTERPRISE M ODEL Owner

conc eptual

Entity = Business Entity Rel. = Business Re latio ns hip

Process = Business Process I/O = Business Resources

Node = Business Locatio n Link = Business Linka ge

Peo ple = Or ga nizatio n U nit W ork = W ork Pro duct

e.g., Lo gical Data Mo de l

e.g., Application Architecture

e.g., D istribute d Syste m Arc hitecture

e.g., H uma n Interface Architecture

Entity = Data Entity Rel. = Data Re la tio ns hip

Process.= Application Function I/O = User Views

Node = IS F unc tio n Link = Line C haracteristics

Peo ple = Ro le W ork = De livera ble

e.g., Tec hnica l Architec ture

e.g., Presenta tio n Architecture

SYSTEM M ODEL Designer

logical

e.g., P hysica l D a ta Mo de l

e.g., System Design

TECHNOLOGY CONSTRAINED M ODEL Builder physical

Entity = Ta bles/Se gme nts/e tc. Rel. = Ke y/Po inter/etc.

Process= Computer Function I/O =Data Elements/Sets

Node = Hardware/Syste m Software Link = Line S pecificatio ns

e.g. Data Definitio n

e.g. Program

e.g. Network Arc hitecture

DETAILED REPRESENTATIONS Subcontractor out-of-c ontext FUNCT IONING ENTERPRISE

Entity = Fie ld Rel. = A ddress

DATA Imple mentation

Process= Language Statem ent I/O = Control Block

Node = Address es Link = Protocols

FUNCTION PROCESS Implementation

SCHEDULE

ST RAT EGY

Imple men tation

John A. Zachman, Zachman International

Flows Layers

D S

11 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Zachman Framework description

A generic classification scheme for EA design artifacts

A parallel to aircraft industry

Historically What, How and Where first specified, mostly for architects – Then Who, Why and When (for business management)

The framework describes completely a system by manadating all perspectives: – planner, owner, designer, builder, subcontractor or – contextual, conceptual, logical, physical, out-of-context or – scope, business, system, technology constraints and products

The level of detail is another (3rd) dimension in each row

Enterprise Alignment means alignment of row 6 (Enterprise implementation) to rows 1 and 2 (management intent)

Flows

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Zachman Framework: Primitives and Composites

Each cell of the Framework is: a. Unique b. Primitive and the total set of cells is complete. The Framework logic is universal, independent of its application â&#x20AC;&#x201C; totally neutral relative to methods/tools.

Flows Layers

D S

13 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Zachman: EA Design Process and Enterprise Alignment

Flows Layers

D S

14 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Zachman Framework Critique

Raised significant awareness of the need for an EA and defined it

Influenced all other frameworks, all frameworks refer to it

Aims to a complete description of the Enterprise

No logical architecture of the Enterprise specifically (applies to any system)

Not all cells (primitives) have a clear meaning or usage

Composites are “excruciating” to design and some may not be meaningful

Integration between cells is not easy (I/O…)

There is no concept of interconnection or “needline”

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Zachman Quotes

As Zachman was quoted to say: "when you need it you would better look at a diagram artifact than a document because there is no time for reading then."

“Enterprises have a large inventory of current systems built out-of-context, not integrated, not supporting the Enterprise, that are consuming enormous amounts of resources for maintenance and are far too costly to replace; as a matter of fact, the inventory of existing systems has come to be referred to as ‘the legacy’”. –

ZachmanConcepts of Framework for Enterprise Architecture John Zachman, 1996

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Zachman Quotes, cntâ&#x20AC;&#x2122;d

Zachman created the first EA framework as a cognitive, thinking framework by asking the "what, how, who, where" (called collectively in this book the "w" questions) from different system development perspectives. Rudyard Kipling in "Elephant's child" from "Just so stories" beautifully reveals, in poetry, the every day life cognitive process for a child: I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who. I send them over land and sea, I send them east and west; But after they have worked for me, I give them all a rest. Flows Layers

D S

17 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Zachman Framework Critique

There is a sequence Top-Down from concept to implementation but

There is no obvious horizontal column order and

Alignment is vertical and not horizontal to “Why”

Zachman’s perspectives not clear cut for an Enterprise

“What” is usually agreed as data not component

Apears to exclude other technologies besides IT

No method/process or reference check-list

Although known for a long time there are still questions

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EAP, Enterprise Architecture Planning

EAP Framework

EAP updated Framework

EAP layers

Flows Layers

D S

19 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

EAP Framework

Planning Framework (Stephen Spewak)

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EAP updated Framework

Flows Layers

D S

Spewak, Tiemann, p.11

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

EAP layers

Layer 1: project initiation activities to determine framework, tools, plan program and resources and seek approval

Layer 2: discovers current business processes, information and technology architectures

Layer 3 designs target architecture taking into account business needs by the business. The application architecture defines application types to manage data and support business processes; the technology architecture identifies platforms for the data and applications

Layer 4 addresses the implementation schedule, cost/benefit analysis, and the roadmap for transformation from the current state to the desired state Flows Layers

D S

ÂŠ Stephen Spewak 1992Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

DODAF, Department of Defence Architecture Framework

DODAF Framework guidance documents

DODAF Framework

DODAF layers information exchange

DODAF Framework layers

DODAF Products in Views

DODAF Operational view

DODAF System view i

DODAF system view ii

DODAF Framework Critique Flows Layers

D S

23 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

DODAF Framework guidance documents The DoDAF contains four guidance documents for architecture development:

High-level process for using the framework to develop architecture descriptions

Guidelines for building architectures compliant with the framework

Architecture data and tools for the architecture-description process

Detailed description of the products (artifacts)

http://www.defenselink.mil/nii/doc/DoDAF_v1_Volume_I.pdf http://www.enterprise-architecture.info/Images/Defence%20C4ISR/Enterprise%20Architecture%20Defense.htm

Flows Layers

D S

24 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

DODAF Framework

Business Organization Model

Node Connectivity Model

Information Flow Diagram

Systems Conceptual Model

Systems Logical Model

System Physical Model

Integration Model

Implementation Model

Software Component Model

Flows

Layers

D S

25 Planning

Function O

Lines/Products

Process Technology People

Planes

DODAF layers information exchange

Flows Layers

D S

Http://www.enterprise-architecture.info ÂŠ 2004, Institute For Enterprise Architecture Developments / Enterprise Architecture Development & Strategic Planning Capgemini - All Rights Reserved Copyright Adrian Grigoriu ÂŠ Page 200826

Function O

Lines/Products

Process Technology People

Planes

DODAF Framework layers

Operational View depicts activities performed by DoD missions

Systems View describes existing and future systems and interconnections

Technical Standards View catalogs standard system parts and their interconnections. Forecasts of standard technology evolution.

All View augments the other views with context, overview-level information,and a dictionary of terms.

Flows Layers

D S

27 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

DODAF Products in Views The DoDAF defines 26 different architecture products, which are organized into the All, Technical, Operational and Systems views:

All View – Overview Information, details scope, purpose, environment – Integrated Dictionary provides definitions of all terms used

Technical Standards View – Technical Standards Profile lists technical standards aaplying to architecture – Technical Standards Forecastd describes emerging or evolving standards that might apply to the architecture Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

DODAF Operational view

Operational View – Operational Concept Graphic, a graphical and textual description – Operational Node Connectivity describing the operational nodes, activities performed at each node and interconnectivity – Operational Information Exchange Matrix – Organizational Relationships Chart lists roles, relationships among organizations – Operational Activity Model with activities performed and their interrelationships, including input/output relationships – Operational Rules Model identifies business rules that govern or constrain operations – Operational State Transition Identifies sequencing and timing of activities – Operational Event Trace for actions in a scenario or sequence of events – Logical Data Model showing data in the operational view Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

DODAF System view i

Systems View – Systems Interface Description lists systems, system components and interconnections – Systems Communications Description – Systems-Systems Matrix with connections between systems in a group – Systems Functionality Description lists functions performed by individual systems and related information flow – Operational Activity-to-Systems Function Traceability Matrix maps systems information back to the operational view – Systems Data Exchange Matrix provides detail of data moving between systems.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

DODAF system view ii – Systems Performance Parameters Matrix, performance characteristics of each system – Systems Evolution Description, migration plans for systems – Systems Technology Forecast with technologies and products that are expected to affect systems – Systems Rules Model describes constraints on system operation imposed by design or implementation – Systems State Transition Description describes system activity sequencing and timing – Systems Event Trace describing system requirements on critical event sequences – Physical Schema describing the physical implementation of the logical data model from the operational view Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

DODAF Operational vs System vs Standard views Operational

System Viewpoint

Translated into EA

Viewpoint (Logical)

(Resource/Physical)

terminology

OV-2 Operational

SV-1 Systems Nodes

Business Functions at

Nodes Model

Interconnectivity Model

Logical level and Systems/ Apps at Physical level

OV-5 Operational

SV-4 System Functions

Business Process and Data

Activity Model

Interconnectivity Model

Flow Models;

OV-4 Org Role /Unit OV-7 Information

Organisation Chart SV-11 Data Model

Information Architecture

OV-6a,b,c Operational

SV-10a,b,c System

Similar and only applied

Business Rules, State

when further insight and

Transitions,

Transitions, Sequence

behaviour are described

Sequence Diagrams

Diagrams

OV-3 Info Exchanges

SV-6 System Data

Data exchanges between

Matrix

Exchanges Matrix

nodes; result matrix

Model

Flows Layers

D S

32 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

DODAF Framework Critique

A good reference model, in use

Constituted a source for other US government frameworks

Too specialised, hard to port to a commercial Enterprise

Mapping on Zachman not clear

Flows Layers

D S

33 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF

TOGAF Framework

TOGAF Three Parts

TOGAF ADM

TOGAF Process

TOGAF Architecture Continuum

TOGAF Architecture and Solutions Continuum

TOGAF Critique

Flows Layers

D S

34 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Framework

Developed by the Open Group in 1995, based on TAFIM developed by DoD.

TOGAF aims to provide a practical, freely available, industry standard method of designing an EA, leveraging all relevant assets in the process.

Definition of EA includes:

Business Process architecture

Applications Architecture

Data Architecture

Technology Architecture Flows Layers

D S

35 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Three Parts

Architecture Development Model, ADM

The Enterprise Architecture Continuum – The TOGAF Foundation Architecture, an architecture of generic services and functions that provides a foundation on which specific architectures and architectural building blocks can be built. This Foundation includes: • TOGAF TRM provides a model and taxonomy of generic platform services • TOGAF SIB, which is a database of open industry standards that can be used to define the particular services • The Integrated Information Infrastructure Reference Model (III-RM), based on the TOGAF Foundation Architecture and is meant to help design architectures that enable and support the vision of "Boundaryless Information Flow."

TOGAF Resource Base: guidelines, templates, and information to help the architect

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

TOGAF ADM

The ADM is iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be made as to: – Breadth of coverage of the enterprise to be defined – Level of detail to be defined – Extent of the time horizon aimed at, including the number and extent of any intermediate time horizons – Architectural assets to be leveraged in the organization's Enterprise Continuum, including: • Assets created in previous iterations of the ADM cycle within the enterprise • Assets available elsewhere in the industry (e.g., other frameworks, systems models, or vertical industry models)

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

TOGAF Process i

Flows Layers

D S

38 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Process ii

Flows Layers

D S

39 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Architecture Continuum

TOGAF recognizes the need for multiple architectures within the enterprise. These architectures represent progressions from logical to physical, horizontal to vertical, generalized to specific, and an overall taxonomy. The continuum comprises two parts: the Architecture Continuum and the Solutions Continuum.

The Architecture Continuum classifies reusable architecture assets and is directly supported by the Solutions Continuum. Different architectures stretch across a continuum, ranging from foundational architectures such as TOGAF's, through common systems architectures and industry-specific architectures, to an enterprise's own individual architectures.

Flows Layers

D S

40 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Architecture and Solutions Continuum

The arrows pointing left focus on meeting enterprise needs and business requirements, while the the arrows going right focus on leveraging architectural components and building blocks.

Flows Layers

D S

41 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Views

Flows Layers

D S

42 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TOGAF Critique

TOGAF is a combination of a few types of frameworks

Is accepted and provides a certification programme

It is not used in practice or at least referred to as it is unstructured

Flows Layers

D S

43 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA, Federal Enterprise Architecture

FEA, why and what

FEA BRM Framework

FEA Mission and Vision

FEA SRM Framework

FEA Goals

FEA TRM Framework

FEA IT Lifecycle Framework

FEA vocabulary i

FEA Framework (FEAF)

FEA vocabulary ii

FEA Reference Model i

FEA achievements

FEA Roadmap

FEAF artifacts

FEAF, FEA PMO Critique

FEA Reference Model ii FEA Reference Model iii FEA PRM Framework FEA PRM

Flows Layers

D S

44 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA, why and what

Clinger-Cohen Act (formerly known as the Information Technology Management Reform Act of 1996 (ITMRA)) demands an Enterprise Architecture.

CIO Council authored the FEAF –

"Federal Enterprise Architecture Framework, V 1.1" in September 1999 and

– "A Practical Guide to Federal Enterprise Architecture, V 1.1" in Feb ‘01

Aims to improve interoperability within the United States Government by creating one enterprise architecture for the entire federal government.

Each agency would create its own enterprise architecture that aligns with the FEA aiming to serve the purpose to transform the Federal Government in citizen-centered, results-oriented and market-based

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

FEA Mission and Vision FEA Mission: Develop and use the FEA to improve government efficiency and effectiveness. FEA Vision: The FEA is the cornerstone for the design, development and implementation of information resources government wide. Goals: 1. Improve utilization of government information resources to focus on core agency mission and service delivery to citizens by using the FEA. The FEA PMO will integrate the FEA with existing policy and budget practices to ensure results-oriented, market-driven investment decisions. This will be evidenced by higher service performance metrics.â&#x20AC;? Flows Layers

D S

2005_FEA_PMO_Action_Plan_FINAL.pdf

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA Goals 2. Enhance cost savings and cost avoidance through a mature FEA government-wide. The FEA PMO, in collaboration with agencies, will utilize the FEA to support cross-agency initiatives, leverage technology and reduce redundancy where overlap limits the value of IT investments. 3. Increase cross-agency and inter-government collaboration.

The FEA PMO will continue to advance the OMB Office of E-Gov and IT’s mission of collaboratively facilitating horizontal (cross-federal) and vertical (federal, state and local) integration of information resources. Partner input and participation is actively sought and welcomed. These goals can be achieved through the execution of an integrated, multi-phase framework, comprised of three phases, Architecture, Investment and Implementation –” Flows Layers

D S

2005_FEA_PMO_Action_Plan_FINAL.pdf

Function O

Lines/Products

Process Technology People

Planes

FEA IT Lifecycle Framework

Flows Layers

D S

2005_FEA_PMO_Action_Plan_FINAL.pdf

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA Framework (FEAF)

Flows Layers

D S

49 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA Reference Model i

Flows Layers

D S

50 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA Reference Model ii OMB established the Federal Enterprise Architecture Program Management Office (FEA PMO) to develop a federated enterprise architecture according to a collection of five “reference models”

Together, the reference models are intended to facilitate government wide improvement through cross-agency analysis and the identification of duplicative investments, gaps, and opportunities for collaboration, interoperability, and integration within and across government agencies.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

FEA Reference Model iii

The Business Reference Model: describes the business operations of the federal government independent of the agencies that perform them, including services provided by state and local governments

The Performance Reference Model provides a common set of general performance outputs and measures for agencies to use

The Data and Information Reference Model describes at an aggregate level, the types of data and information that support program and business line operations, and the relationships among these types

The Service Component Reference Model identifies IT service components that support federal agencies and are candidates for reuse across agencies

The Technical Reference Model describes how technology is supporting the delivery of service components, including relevant standards for implementation Flows Layers

D S

52 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA PRM Framework

The PRM is a framework to measure the performance of major IT investments and their contribution to program performance

The PRM covers strategic intent by stating mission and mandating business and customer results: it identifies a common set of general performance outcomes and metrics to be used by agencies to derive specific objectives

The high-level organization of PRM – Mission and Business Results and Customer Results – Processes and Activities – Technology, Human Capital and Fixed Assets, referred to as Measurement Areas

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

FEA PRM

Flows Layers

D S

54 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA BRM Framework

Flows Layers

D S

55 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA SRM Framework

SRM is a functional framework that classifies Service Components with respect to how they support business and performance objectives

SRM defines "componentâ&#x20AC;&#x153; or service as a self-contained business process functionality that may be exposed through an interface

Flows Layers

D S

56 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA TRM Framework

TRM is a component-driven technical framework used to identify standards, specifications and technologies that support the service components

TRM provides the foundation for a Component-Based or Service-Orientated Architecture

Flows S

57 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Layers

http://www.software.org/pub/architecture/

Function O

Lines/Products

Process Technology People

Planes

FEA Definitions Enterprise “An organization supporting a defined business scope and mission. An enterprise is comprised of interdependent resources (people, organizations, and technology) who must coordinate their functions and share information in support of a common mission (or set of related missions)”.

Enterprise Architecture “A strategic information asset base, which defines the agency’s mission and business activities supporting the mission, the information necessary for agency operations, the technologies necessary to support operations, and the transitional processes necessary for implementing new technologies in response to changing business needs. It is an integrated model or representation”. (Source: FEAF version 1.1, adapted.)

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

FEA vocabulary i

Architecture Drivers: external stimuli that cause the FEA to change

Strategic Direction: ensures that changes are consistent with the Federal aims

Current Architecture: describes the current state of the enterprise

Target Architecture: target state for the enterprise dictatedby the strategic direction

Architectural Segments: focus on a subset or a smaller enterprise within the total Federal Enterprise

Transitional Processes: the transformation of the current to target architecture in compliance with the architecture standards, migration planning, budgeting, transition controlled by configuration management and change control Flows Layers

D S

59 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA vocabulary ii

Architectural Models: provide the documentation and the basis for managing and implementing changes in the Federal Enterprise

Standards: mandatory standards, voluntary guidelines and best practices for promoting interoperability

Flows Layers

D S

60 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEA achievements â&#x20AC;&#x153;During the last four years, development of the FEA has led to several important milestones, including:

Release of the five FEA reference models established a common language for diverse agencies to use while seeking to collaborate on common solutions for services;

Analysis of agency IT mappings revealed five major lines of business presenting more than $5 billion in potential savings and substantial collaboration opportunities across the Federal government; and

Use of the reference models to guide the development of agency enterprise architectures in FY 2004, FY 2005 and FY 2006 resulted in a better understanding of agency IT investments and business lines

Flows S

61 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Layers

2005_FEA_PMO_Action_Plan_FINAL.pdf

Function O

Lines/Products

Process Technology People

Planes

FEA Roadmap

Flows Layers

D S

2005_FEA_PMO_Action_Plan_FINAL.pdf

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEAF artifacts

Flows Layers

D S

63 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

FEAF, FEA PMO Critique

FEAF is a framework while FEA PMO is a reference model

Used as the US government baseline

Wild variations in existance making FEAF not relevant

Flows Layers

D S

64 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TEAF, Treasury Enterprise Architecture Framework

TEAF Reference Model

TEAF Artifacts

FEAF vs TEAF

TEAF Critique

Flows Layers

D S

65 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TEAF Reference Model

"A bureau will be considered compliant with the TEAF when it can demonstrate that the bureau adheres to its EA Roadmap and that gaps, if any, are not significant. A bureau will establish a compliance/waiver process for examining proposed projects or decisions to ensure compliance with its own EAâ&#x20AC;?. Flows Layers

D S

66 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TEAF Artifacts F u n c tio n a l V ie w

P la n n e r P e r s p e c tiv e

M is s io n & V is io n S ta te m e n ts

In fo r m a tio n A s s u r a n c e T ru s t M o d el

B u s in e s s P r o c e s s / S y s te m F u n c tio n M a tr ix

D e s ig n e r P e r s p e c tiv e

E v e n t T r a c e D ia g r a m s S ta te C h a r ts

B u ild e r P e r s p e c tiv e

In fo rm a tio n D ic tio n a r y

O rg a n iz a tio n a l V ie w

O r g a n iz a tio n C h a r t

In fr a s tr u c tu re V ie w

T e c h n ic a l R e fe r e n c e M odel S ta n d a r d s P r o file

A c tiv it y M o d e l

Ow ner P e r s p e c tiv e

In fo rm a tio n V ie w

In fo r m a tio n E x c h a n g e M a trix (C o n c e p tu a l)

In fo rm a tio n E x c h a n g e M a tr ix (L o g ic a l) D a ta C R U D M a tr ic e s

N o d e C o n n e c tiv ity D e s c r ip tio n (C o n c e p tu a l)

N o d e C o n n e c tiv ity D e s c r ip tio n (L o g ic a l)

In fo r m a tio n A s s u r a n c e R is k A s s e s s m e n t S y s te m In te r fa c e D e s c r ip tio n Level 1

S y s te m In te r fa c e D e s c r ip tio n L e v e ls 2 & 3

L o g ic a l D a ta M o d e l

In fo r m a tio n E x c h a n g e M a trix (P h y s ic a l)

S y s te m F u n c tio n a lity D e s c r ip tio n

N o d e C o n n e c tiv ity D e s c r ip tio n (P h y s ic a l)

P h y s ic a l D a ta M o d e l

S y s te m In te r fa c e D e s c r ip tio n Level 4 S y s te m P e r fo r m a n c e P a r a m e te rs M a trix Flows

E s s e n tia l W o r k P r o d u c ts

S u p p o r tin g W o r k P r o d u c ts

Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

FEAF vs TEAF

Flows Layers

D S

68 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

TEAF Critique

Adds Organization and Functional to FEA

Infrastructure appears to include both Applications and technology

A good model though not much progress since elaboration

Flows Layers

D S

69 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC, Pension Benefit Guaranty Corporation

PBGC Framework

PBGC Artifacts and Mapping Matrixes i

PBGC Artifacts and Mapping Matrixes ii

PBGC Context diagram

PBGC Data areas

PBGC Applications inventory

PBGC Applications interfacing diagrams

PBGC Applications to Technology matrix

PBGC Logical partition of systems for As-Is EA

PBGC Logical partition of systems for To-Be EA

PBGC critique

Flows Layers

D S

70 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Framework

Flows Layers

D S

71 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Artifacts and Mapping Matrixes i

Context Diagram, Stakeholders

Logical Partitioning of Systems for As-Is/To-Be

PBGC Business Areas and their Functions

Business Functions Mapped to FEA-BRM Lines of Business

Business Functions to Goal Matrix

Data areas and classes

Business Function to data CRUD Matrix

Flows Layers

D S

72 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Artifacts and Mapping Matrixes ii

Applications Inventory

Applications interfacing diagram

Applications to Function Matrix

Applications to Technology Matrix

Applications to Data Matrix

Organization Chart

Business Functions to Organization Matrix

Flows Layers

D S

73 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Context diagram

Flows Layers

D S

74 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Data areas, sample

Data Areas and Class Diagrams Flows Layers

D S

75 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Applications inventory

Flows Layers

D S

76 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Applications interfacing diagrams

Flows Layers

D S

77 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Applications to Technology matrix

Flows Layers

D S

78 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Logical partition of systems for AsAs-Is EA

Flows Layers

D S

79 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC Logical partition of systems for ToTo-Be EA

Flows Layers

D S

80 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

PBGC critique

Well done!

No overall framework: – Organization is outside the framework – Too many point to point matrixes outside the framework – No stakeholder views – No clear relation to FEA

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Business Process Trends

BPTrends Enterprise Architecture Pyramid

BPTrends, eTOM re-arranged

Flows Layers

D S

82 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

BPTrends Enterprise Architecture Pyramid

Flows Layers

D S

83 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

BPTrends, eTOM rere-arranged

Flows Layers

D S

84 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Purdue Enterprise Reference Architecture

There are three types of Enterprise Architecture: – People/Organization Architecture – Production Facilities Architecture – Control and Information Systems Architecture

PERA divides the enterprise lifecycle into "phases“. At the end of each development phase, a set of "Deliverables" are produced, typical of a process industry facility such as a refinery, power plant, pipeline, etc.. However similar deliverables would be produced for a service industry, or discrete manufacturing enterprise.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

PERA Framework i

Flows S

86 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Layers

http://www.pera.net/Intro_Engineering_Integration.html

Function O

Lines/Products

Process Technology People

Planes

PERA Framework ii

Flows S

87 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Layers

http://www.pera.net/Intro_Engineering_Integration.html

Function O

Lines/Products

Process Technology People

Planes

Enhanced Telecommunications Operations Map (eTOM) Next Generation Operations Systems and Software (NGOSS)

eTOM framework goal

eTOM Framework

eTOM Framework, level 0

eTOM process hierarchy

eTOM Enterprise management

eTOM swimlane diagram

eTOM/NGOSS data framework (SID)

NGOSS

Flows Layers

D S

88 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM/NGOSS framework goal

The eTOM is a reference business process model or framework for the operation and management of a telecommunications company. It describes all enterprise processes

It serves as the blueprint for process design and provides a neutral reference point for internal process reengineering

eTOM was developed to drive a consensus around the processes, inputs, outputs and activities required from an Operator

For suppliers, eTOM outlines potential boundaries of software components to align with the customersâ&#x20AC;&#x2122; needs and highlights the required functions, inputs, and outputs that must be supported by products. Flows Layers

D S

89 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM Framework

Flows Layers

D S

90 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM Framework, level 0

Flows Layers

D S

91 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM process hierarchy

eTOM presents a three level hierachical decomposition of all processes in the Enterprise so that the framework can be adopted to these various levels

Flows Layers

D S

92 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM Enterprise management

Flows Layers

D S

93 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM swimlane diagram

Flows Layers

D S

94 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

eTOM/NGOSS data framework (SID) Market / Sales Market Strategy & Plan

Marketing Campaign

Contact/Lead/Prospect

Market Segment

Competitor

Sales Statistic

Product

Strategic Product Portfolio Plan

Product Performance

Product Specification

Product Offering

Product Usage Statistic

Customer

Customer Order

Customer Problem

Applied Customer Billing Rate

Customer Bill Collection

Customer Interaction

Customer Statistic

Customer SLA

Customer Bill

Customer Bill Inquiry

Service

Service Applications

Service Performance

Service Strategy & Plan

Service Specification

Service Configuration

Service Usage

Service Trouble

Resource

Resource Topology

Resource Performance

Resource Strategy & Plan

Resource Specification

Resource Configuration

Resource Usage

Resource Trouble

Resource Test

S/P Performance

S/P Bill

Supplier/Partner

S/P Interaction

S/P Order

S/P Problem

S/P Bill Inquiry

S/P Plan

S/P Product

S/P SLA

S/P Statistic

S/P Payment

Product

Customer

Sales Channel

Service

Resource

Supplier / Partner

Enterprise

Service Test

Common Business (Under Construction)

Party

Business Interaction

Location

Policy

Agreement

Flows Layers

The SID Framework Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

NGOSS

• eTOM is a processed based framework; • NGOSS (New Generation Operations Systems and Software) aligns technology to processes Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu © 2008

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

IAF, Integrated Architecture Framework (Cap Capgemini gemini) Aspect Areas

Business

Information

InformationInformationSystems

TechnologyTechnologyInfrastructure

Systems Goals, Drivers and Concepts

Technology Goals, Drivers and Concepts

Abstraction Levels Business Goals, Drivers and Concepts

Why?

• Corporate Strategic Plans

Vision / Strategy Business / Technology Drivers Scope

Contextual Level

What?

• Business Drivers • Guiding Principles • Scope of the Change • Environmental Dynamics, e.g. Laws • Business Goals & Objectives, KPI’s Viewpoints = Competition, Value Net, etc.

Conceptual Level

How?

• System Development policy

• Locations in which the Business Operates

• Responsibilities & Competencies

• Integration Policy

• Technology Infrastructure policy

• Confidentiality of Information • Dependencies of others • Activities in Scope

• Business - Technology Enablers

• Responsibility of IS

• Responsibility of TI

• Application portfolio • Guiding Principles

Activities = Generic or Specific Activities = Critical / Overhead End = Information Situation

End = To-Be Information-System Situation

Level of Business Collaboration

Level of Information Interaction

Level of Interoperability

• Business Requirements

• Functional Requirements • Non-Functional Requirements

• Business Relationships

• Quality of Services

• Budget of Change

• Information Relations

• Stakeholders / Win-Win Conditions

• Information Characteristics

• As-Is Information Systems Environment • Functional Requirements • Non-Functional Requirements • Information-Systems Behaviour

• Non-Functional Requirements • Quality of Services

Type of Information Interaction

Type of Interoperability

Type of Inter-Connection

• Value Net Position

• • • •

• Business Culture

• Information Resources

• Business Commitment

• Information Locations

• Business Area Structure • Role Players / Actors

• MDA Platform-Independent Modelling (PIM) • Business functionality and behavior

Information Processes Information Objects & Relations Information Interaction Information Flow Characteristics

• Many Middleware Technologies • Shared & Pluggable Services Standards = MDA Development Standards

With what?

Solutions of Business Collaboration

Solutions of Information Interaction

Solutions for Interoperability

• Business Functions structure and relations • Business Tasks / Activities • Business Objects

Characteristics = Time, Availability, Security, Maintainability, etc.

• Technology Standards • Infrastructure Profile • Hardware Systems Profile • Communication Profile • Security Profile • Governance Profile

End = Information Behaviour

Viewpoint = Human Perspective

• Type of Information Exchange •Formal / Informal • Grouping of Information Objects • Grouping of Information Resources • Type of Triggers / Events

Positioning = Allocation of Services Interaction = Concepts of Layering

Solutions of Inter-Connection

• MDA Platform-Specific Modelling (PSM)

• Technology Overview

• Map PSM to application interfaces, code, GUI descriptors, SQL queries, etc.

• Solutions & Products for Inter-Connection

Viewpoints = Characteristics of a View

• Formats of Communication

End = Business Outcome

Priority = Dependency of Information Relation = Information Flow End = Information Outcome

Structure = Spectrum of Styles Quality = Component Characteristics End = PSM

• Security Integration Node = Hardware + System Software, etc. Connectivity = Middleware / Messaging, etc. End = Structure of Relations, Products + Specifications

Granularity of Change

Impact of Change

Timeframe of Change

• Business Resources • Business Knowledge • Business Benefits • Technology Possibilities

• Grouping of Information Types

• Business Case

• Transformation Roadmap

• Information Systems Roadmap

• Make or Buy Decision

• Business Case • Transformation Plan

• Priority Plan

• Security Plan

• Implementation Roadmap

• Priority Setting

• Budget Plan • Governance Plan

• Tools for Development / Implementation • Governance Plan

Selection = Set of ICT Supported Objects

• Security Impact e.g. Business Process Redesign or Outsourcing

Transformational Level

• Functional Requirements

Type of Business Collaboration

Viewpoint = Business Perspective End = Business Behaviour

Organisational Impact

• As-Is Infrastructure • TI Principles

Link = Business System Connection Node = Business System Environment

Logical Level

When?

Level of Inter-Connection

End = Business Purpose

Entities = Classes, Attributes & Associations End = PIM

Physical Level

• Guiding Principles

• Abstraction & Precision of Data • Quality of Services Characteristics = Time, Availability, Security, Maintainability, etc. Structure = Interfaces

• Business Rules

Solution Representation

• TI Portfolio

Node = Major Business Location

Policy = Business Purpose Domains = Functional Areas I/O = Business Resources End = Information Resources

• Quality of Services Characteristics = Time, Flexibility, Availability, Security, Maintainability, etc.

• Organisation Structure

Logical Representation

• Information Policy

Ends/Means = As-Is / To-Be Business Situation

• Project Goals & Objectives

Goals & Objectives Requirements

Activities the Business Performs

End = Business Transformation

e.g. Information Roadmap

e.g. Design of Application & Components

Interface = Type of Information Exchange End = Activities to be supported by ICT

Security

Priority = Dependencies End = Roadmap for realization

• IS Alignment Impact e.g. Blue Print of Technology Implementation Portfolio of Products and Components. Catalogues of used Standards End = Roadmap for implementation

Governance

Architecture ViewPoints

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

E2AP (IFEAD) Abstraction Levels

Aspect Areas

Why?

With Who?

Vision / Strategy Business / Technology Drivers Scope

Value Net Relations Cooperating / Collaborating Elements

Contextual Level

Environmental Level

Business Goals, Drivers and Concepts

Business

Information

Conceptual Level Level of Business Collaboration

• Collaborative Value Parties

• Extended Business Drivers

• Scope of the Collaborative value

• Extended Guiding Principles

• Collaboration Contracts, Service Levels

• Program Goals & Objectives • Business Requirements • Business Relationships

• Scope of Collaboration

• Law & Regulations

How? Logical Representation

Logical Level Type of Business Collaboration

With what?

When?

Solution Representation

Enterprise Impact

Physical Level

Transformational Level

Solutions of Business Collaboration

Granularity of Change

• Organisation Structure

• Business Functions structure and relations • Business Tasks / Activities

• Budget of Change

• Business Area Structure • Role Players / Actors • Value Net Position

• Enterprise Business Case • Enterprise Transformation Roadmap

• Business Objects

• Enterprise Priority Plan

• Business Resources

• Enterprise Budget Plan

• Environmental Dynamics, e.g. Laws

• Collaborative Business Goals & Objectives

• Stakeholders / Win-Win Conditions

• Business Culture

Viewpoint = Collaborative Value, etc.

Viewpoints = Competition, Value Net, etc. Ends/Means = As-Is / To-Be Business Situation

Ends/Means = As-Is / To-Be Collaborative Environment

• Quality of Services Characteristics = Time, Flexibility, Availability, Security, Maintainability, etc.

• Business Commitment

• Business Goals & Objectives, KPI’s

End = Business Purpose

Viewpoint = Business Perspective End = Business Behaviour

End = Business Outcome / Business Solutions

End = Enterprise Business Transformation

Activities the Business Performs

Extended Enterprise Information Exchange

Level of Information Interaction

Type of Information Interaction

Solutions of Information Interaction

Impact of Change

• Enterprise Information Policy

• Extended Information Exchange Services

• Responsibilities & Competencies

• Extended Information Ownership

• Ownership of Information

• Parties Information Confidentiality

• Internal / External Dependencies

• Extended Dependencies

• Quality of Services • Information Relations

• Internal / External Activities in Scope

• Activities out of Scope

• Information Characteristics

• Functional Requirements • Non-Functional Requirements

End = Information Situation

End = Ext. Enterprise Information Exchange

Policy = Business Purpose Domains = Functional Areas I/O = Business Resources End = Information Resources

Systems Goals, Drivers and Concepts

Extended Enterprise Interoperability

Level of Interoperability

Information = Generic or Specific Information = Critical / Overhead

• Business Rules

• Information Tasks / Activities • Information Objects & Relations • Information Interaction • Information Flow Characteristics • Information Resources • Information Locations

Priority = Dependencies End = Roadmap for realization

Timeframe of Change

• Official & De-facto IS Standards Standards = IS Interoperability Standards End = PIRS

Type of Inter-Connection

Solutions of Inter-Connection

• Non-Functional Requirements

• Choice of Middleware Technologies

• Information-Systems Behaviour

• Shared & Pluggable IS Services / Solution sets

Technology Goals, Drivers and Concepts

Extended Enterprise Inter-Connection

Level of Inter-Connection

• Locations in which the Business Operates

• Enterprise Inter-Connection Standards

• Enterprise Technology Infrastructure policy

• Enterprise Inter-Connection Governance

• Enterprise Business - Technology Enablers

• Enterprise Inter-Connection Quality of Services (e.g. Security)

• Enterprise Responsibility of TI • Enterprise TI Portfolio

• Enterprise Inter-Connection portfolio

• Enterprise Guiding Principles

• Enterprise Inter-Connection Principles

Node = Major Enterprise Business Location

End = To-Be Inter-Connection Definitions

• Interface Definitions & Standards

• As-Is Enterprise Infrastructure • TI Principles • Functional Requirements • Non-Functional Requirements

• Enterprise Communication Profile

• Quality of Services Characteristics = Time, Availability, Security, Maintainability, etc.

• Enterprise Security Profile

Link = Enterprise Business System Connection Node = Enterprise Business System Environm.

e.g. Information Roadmap

Timeframe of Change

• Enterprise Interoperability Quality of Services (e.g. Security)

End = To-Be Interoperability Definitions

• Security Plan Selection = Set of ICT Supported Objects

• Product-Specific Reference Solution (PSRS) • Map PSRM to Product Solutions and options, etc. • Interface Solutions • Implementation of Quality of Services • Refinement Technical Reference Model Viewpoints = Selection of a Product Solutions Structure = Spectrum of Styles & Solutions sets Quality = Solution Interface Characteristics End = PSRS

• Business - Technology Enablers

End = As-Is / To-Be Information-System landscape

• Information Systems Roadmap

• Grouping of Information Resources • Type of Triggers / Events • Grouping of Information Types

Solutions for Interoperability

• Functional Requirements

• Abstraction & Precision of Data • Quality of Services Characteristics = Time, Availability, Security, Maintainability, etc. Structure = Interfaces

• Business Case

• Product-Independent Reference Solution (PIRS) • IS Functions & behaviour

• Enterprise Interoperability Governance

• Enterprise Collaboration Principles

• Type of Information Exchange •Formal / Informal • Grouping of Information Objects

Type of Interoperability

• Enterprise Interoperability Policy

• Enterprise Interface portfolio

• Technology Possibilities

Interface = Type of Information Exchange End = Activities to be supported by ICT

• As-Is Information Systems Environment

• Enterprise Application portfolio

e.g. Business Process Redesign or Outsourcing

Priority = Dependency of Information Relation = Information Flow End = Information Solutions Sets

Viewpoint = Interaction Perspective

• Enterprise Interoperability Standards

• Enterprise Responsibility of IS

• Enterprise Governance Plan

• Business Knowledge • Business Benefits

End = Information Behaviour

• System Development policy

• Enterprise Guiding Principles

Technology Infrastructure

Goals & Objectives Requirements

• Corporate Strategic Plans

Activities = Generic or Specific Activities = Critical / Overhead

Information – Systems

Extended Enterprise Value Net

What?

• Enterprise Technology Standards

• Technology Overview

• Enterprise Infrastructure Profile

• Solutions & Products for Inter-Connection

• Enterprise Hardware Systems Profile

• Formats of Communication • Security Integration • Refinement Technical Reference Model

• Enterprise Governance Profile • Technical Reference Model & Standards Positioning = Allocation of IT Services ~ TRM Interaction = Concepts of Service Layering

• Business Case • Make or Buy Decision • Implementation Roadmap • Tools for Development / Implementation • Governance Plan • Security Impact e.g. Design of Application & Components

• Business Case • Enterprise Transformation Plan • Enterprise Priority Setting • Enterprise IS Alignment Impact

Node = Hardware + System Software, etc. Connectivity = Middleware / Messaging, etc.

e.g. Blue Print of Technology Implementation

End = Structure of Relations, Products + Specifications

Catalogues of used Standards End = Roadmap for Enterprise Implementation

Portfolio of Products and Components.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

CIMOSA framework

Flows Layers

D S

99 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

CIMOSA Process layers Enterprise

Activity

•Information •Constraints

Structure

•Function •Material •Resource

•Rules •Organisation

User Input Function Information resource Organisation CM-OSA Reference Architecture

Requirements

Generic Building Blocks

Function Information resource Organisation

Design

Partial Models

Function Information resource Organisation

Implementation

Enterprise System Requirements

Enterprise System Constraints

Component Catalogue

System Components

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Gartner Framework (<2003)

Flows Layers

Source: Gartner Research (October 2003); obsolete since acquiring Meta Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

101

Function O

Lines/Products

Process Technology People

Planes

Gartner Framework, Tiers 1. Multi-Enterprise Grid It's a series of models that enable businesses to communicate for e-business –

refers to physical communication -- pipes and networks and protocols.

–

semantics -- a common language for representing the exchange of information

2. Business Process Styles – That's the alignment layer between technology and the business. Transaction processing is an example of a style. These are technology core competencies.

3. Patterns, re-usable logic models: client/server, a hub-and-spoke, or messaging 4. Bricks, foundation technologies: operating systems or databases

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

MIT Sloan Centre EA stages

silos standardized IT standardized business processes business modularity (that is SOA)

history truly shows, that architecture evolves from the silos of the ‘90s, through

IT standardisation, to arrive now at stage 3 of business process rationalization – CISR states that moving upwards, from stage 1 to 4, is increasingly difficult, since to achieve stage 3, business participation is a must and to realise stage 4, an overhaul of your Enterprise operation and organizational change are necessary. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

Oakton Framework

Flows Layers

D S

104 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Kruchten's 4+1 model view

Use Case view

Logical view

Process view

Implementation view

Deployment view Each such view may be further described by its structural, behavioral, and nonfunctional semantics each based on specific patterns

Flows Layers

D S

105 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

An own telecom cube framework

A Cube framework

A telecoms cube, services view

A telecoms cube, systems view

Flows Layers

D S

106 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

An early own framework The System Bussiness, Operations, Availability… Support Planes

Content Applications, 3rd Pariesy

Services Transport Plane

Core Plane Control

GSM/GPRS

Transport Plane Control/Sevices Plane Security

...

Availability Plane Data Plane (Provisioning, Care…) NTP Plane LI Plane

Transport Plane Access Control Plane

User Plane (MGw, IP/ATM)

Charging Plane OA&M Plane

...

Transmission Layer

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

A telecoms cube, services view IT/eTOM View

IT/eTOM View

Vertical View Fullfilment New Order Management System UK Purchasing & Logisticsâ&#x20AC;&#x2122; Stock Handling Forecasting and Replenishment Service Views In-Store Systems Voice Stock and Sales BI VT Staff Financial Incentive System Messaging Other Significant System Changes Short Meesaging Assurance CBC Billing SMS UM MIM EMAIL VMAIL FMAIL Internet Access Web WAP IVR Streaming OTA STK Dev Mng JAVA Corporate

Horizontal View Customer Management Partner&Supplier Management Service Management Resource Mangement Zachman OA&M WHWWWW What How Where Who When Why Decomposition Context Business Logical 1 Domain 2 BE 3 Data/Object Implemetation Detail

Flows Layers

D S

108 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

A telecoms cube, systems view System Views Telecom Views Net Elem View Traffic View Control View Location View Presence View LI View Availability View BC/DR View Data View Transport Views TCP/UDP HTTP IP View ATM View MPLS View VPN Views Transmission Views Optical SDH PDH Dark Fiber Electrical E1 Giga Ethernet Protocol Views 2G Access 3G Access CS Core PS Core

IT/View Horizontal View Provisioning Billing Customer Care

Zachman WHWWWW What How Where Who When Why Decomposition Context Business Logical 1 Domain 2 BE 3 Data/Object Implemetation Detail

Flows Layers

D S

109 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

Conclusion, Jaap Schekkerman (EA frameworks presentation on IFEAD web site)

Most EA Frameworks have different evolutions

Most EA Frameworks serve different Purposes

Most EA Frameworks are different in Scope

Most EA Frameworks are based on different Principles

Most EA Frameworks have different Structures

Most EA Frameworks are supported by different approaches

Most EA Frameworks are different in compliancy with the Clinger Cohen Act

http://www.enterprise-architecture.info Jaap Schekkerman

Flows

110 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA frameworks types

“W” matrixes, cognitive “tools for thinking” – they help you structure the EA thinking by asking investigative questions (what, how, who…) This is, essentially, Zachman's framework. – "cognitive" tools as it structures the process of discovery of the Enterprise –

IFEAD's E2AF framework.

Cubes or pyramids describing the layers dimension of the Enterprise – Many frameworks (e.g. FEAF) consist of four basic layers: business, information, applications and technology (the common denominator framework). Some frameworks add on top a business strategy and objectives layer. These frameworks look like cubes or pyramids. Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA frameworks types, ii

Reference models, deliveries checklist (e.g. FEA) – align the products of all development parties. These look like lists of diagrams, standards, technologies and matrixes of information exchange and components interconnections.

Business Architecture, functional architecture – specifying a logical architecture (e.g. eTOM/NGOSS). They describe, in truth, BPM process maps. The outcome is formatted in interconnected functional blocks and process diagrams, at various level of detail.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA frameworks types, iii

Development and implementation best practices and EA program management process guidelines (e.g. EAP). – They are mostly described in text documents and business plans.

Combination frameworks – Some, as TOGAF, are a combination of most of the above.

Flows Layers

D S

Function O

Lines/Products

Process Technology People

Planes

EA frameworks types, iv

Many frameworks limit the scope to the technology to IT, although, 50 years ago, there were few Enterprises served by IT, if at all.

Few frameworks are pointing at organization and people issues which appear to be in different knowledge domains such as HR, Organization Development and Human Performance.

Few are offering views or points of views, e.g. aspects of interest for various stakeholders.

Navigation and linkage between EA entities in artifacts remain a point of debate for most EA frameworks. Flows Layers

D S

114 Enterprise Architecture Development & Strategic Planning Copyright Adrian Grigoriu ÂŠ 2008

Function O

Lines/Products

Process Technology People

Planes

EA frameworks types, v

Thinking/Cognitive: represented as Matrixes – To aid scoping, discovering the Enterprise (Zachman’s, E2AF) – Provide answers to What, How, Where, Why, When Enterprise delivers – Used for classifying the EA artifacts

Functional/Logical structures, business process maps,: – Showing business functions and process structure (eTOM)

Layered structures, from processes to resources, Cubes and Pyramids – Describe Enterprise layers: Process, Applications, Data, People … (FEAF, TEAF, PBGC, BPTrends …)

Planning process and Best Practices (EAP)

Reference Models – Check list of deliveries (FEA PMO)

Flows

Layers

D S

Function O

Lines/Products

Process Technology People

Planes