Introduction to Enterprise Architecture

1

Disclaimer

This presentation is a journey into the Enterprise Architecture world through my personal lens.

My work as an innovator means I am used to trying, testing and imagining!

I’m referring sometimes to external sources (links are provided)

Course Given at La Rochelle University in France in 2009

http://eventtoons.com/home

2

Objective of this course

Understand

What is your IS patrimonial

Its organization, its structure

its components et its interactions

Manage

Analysis and KPI

Projects Specifications

Govern

Bring under control Cost Risk, and IS risks

Bring under control IS Performance

Bring under control IS evolution

3

Plan

AA vs. EA

Enterprise Architecture Frameworks

Top-Down or Bottom-up?

EA process

How to my Describe EA?

Building Your Own Framework

Example s with Mega / Casewise / UML

On the road to resilient EA

4

Application architecture vs. Enterprise Architecture

5

Architecture Scope is twofold! AA vs. EA

What is Application Architecture (AA)?

Application Architecture is the set of policies, practices, processes and tools to ensure an optimal and secured design and construction of an information system that best works for its business owner and users.

What is Enterprise Architecture (EA)?

Enterprise Architecture is the Governance and overall Plan to effectively structure, manage, integrate, secure and evolve the information system landscape of the company, aligning to business and IT strategy

Note: we assume here that the french concept of “Urbanisme” translates into “Enterprise Architecture”

•Global Scope

•High Granularity

•Local Scope

•Low Granularity

Globally based solution, ensuring CWT

Global architecture to be Coherent!

Project based decisions (Local) and delivery

optimized within that context (Optimal)

6

Application Architecture Resources To Learn Coding

Conventional wisdom (at least today) is that in the way you know how to read and write English, you need to have some understanding of the code that builds the Web and mobile.

As a person who’s grown up in the digital age, You need to know how to code.

“Those who code have the power to transform their dreams into reality.”

“Coding will help you keep [your job], or help you make a case for a raise.”

“You should learn to program because it’s easy, it’s fun, it will increase your skill set, and… it will fundamentally change your perspective on the world.”

What’s more, “If you want to start a technology company,you should learn to code.”

Program or be programmed…

7

Application Architecture Resources To Learn Coding

MIT Courseware Online Intro to Computer Science & Programming class

MIT and Harvard partnered up to create edX

Codecademy uses a curriculum of exercises to teach the basics of coding in a variety of languages

PHP Academy

Coursera: offer online courses from myriad universities for free

Khan Academy: an amalgam of Coursera and Codecademy

Codingbat: simply a series of live coding problems

GitHub, Pastebin, or SourceForge - It is a repository for coders to paste their personal code

8

More on Enterprise Architecture (EA)

Framework or "blueprint" for how the organization achieves the business objectives at hand and in the future.

The Enterprise Architecture looks at the key business, information, application, and technology strategies and their impact on business functions.

Each of these strategies is a separate architectural discipline and Enterprise Architecture is the glue that integrates each of these disciplines into a cohesive framework.

Strategies are built following business and IT principles, standards and best practices.

9

Architecture Scope is twofold! AA vs. EA

EWITA = Enterprise Wide IT Architecture

Specific BU organization Specific BU organization

10

Why Enterprise Architecture? Manage IS complexity

“The introduction of new non-standard technology imposes a voluntary tax of 5 to 12% on the development budget, and an increase of 21 to 33% on project duration.

Studies have shown that, over time, Enterprise Architectural efforts can result in a reduction of annual IT spending by as much as 20%.

“More projects can be completed within a given project budget when Enterprise Architecture Methods/Tools are followed than when they are not.

Repair Cost are greatly reduced through EA by reducing errors in IT solution designs early.

Fixing technology solutions during the … Cost to fix

Requirements phase 1

Architecture 5 x

Coding 10 x

Unit/System Testing 20 x

11

Enterprise Architecture and App. Architecture should be aligned

Common / Shared

AA

(Application

architecture) Application landscape

Business Process

Business function

Standard

Local Standards

Technical Architecture details

Data Architecture details

Integration Architecture details

Operational Architecture details Governance

City Planning

EA

(urbanisation)

Remember!

12

EA Usage and Benefit

Alignment

Ensuring the reality of the implemented enterprise is aligned with management's intent

Integration

Realizing that the business rules are consistent across the organization, that the data and its use are immutable, interfaces and information flow are standardized or controlled and the connectivity and interoperability are managed across the enterprise

Change

Facilitating and managing change to any aspect of the enterprise

Resilience

Reducing systems development, applications modernization

Convergence

Striving toward a standard IT product portfolio (service and asset reuse)

13

CEISAR

14

http://georgeletransformateur.com/

http://www.ceisar.com/

Enterprise Architecture Frameworks

15

Why need an Enterprise Architecture Framework?

In a large modern enterprise, a defined framework is necessary to be able to capture a vision of the “entire organization” in all its dimensions and complexity.

Enterprise Architecture is a program supported by frameworks, which is able to coordinate the many facets that make up the fundamental essence of an enterprise at a holistic way.

That’s why architecture frameworks have become critical for enterprise architects.

Just like the old saying, “if you don’t know where you want to go, any road will take you there”

16

Enterprise Architecture Framework Objectives

Establish terms and concepts for architectural thinking and provide a uniform way to talk about Enterprise Architecture

Gain a 360-degree view across IT and development projects and propose real-time visibility to make rapid, well-informed decisions

Operationalize best practices and automate portfolio processes

Increase collaboration between Development and Service Delivery teams

Codify current best practices and insights of both the systems and software engineering communities

Promote Service Oriented Architecture

17

What an Enterprise Architecture Framework is not?

An architecture framework does not include a methodology or process for enterprise architecture.

It also does not ensure that individual programs and projects fit into a global EA vision.

It does not explicitly recognize the importance of other enterprise IT dimensions and how they’re tied together

For example, the importance of architectural governances or the different ways of transitioning an enterprise.

It does not depend on particular tools

18

Framework(s) for EA A Standard Exist: IEEE-Std-1471-2000

Recommended Practice for Architectural Description of Software-Intensive Systems.

19

Framework(s) for EA Most Used Frameworks

20

Framework(s) for EA History …

ISO/IEC

14252

Zachman

1987

TAFIM

JTA

DOD

TRM

TOGAF

1995

C4ISR

1999

TOGAF 8.1

2003

DODAF

2003

Zachman

2003

Adopted By

Supported By

Influenced

Reference

EAP

1992 FEAF

1999

UVA Model

1994

IAF V1

1996

IAF V3

2001

XAF

2003

E2AF

2003

FEAF

2003

TEAF

2000

TISAF

1997

21

Framework(s) for EA Zachman

IT centric

Views

Process

centric

Views

View described

by its viewpoint

22

Framework(s) for EA - TOGAF The Open Group Architecture Framework

Neutral

Broad Acceptance

Holistic Perspective.

Process / Planning Tool

Enterprise Architecture Development Methodology

History in Defence

Open Standard 23

TOGAF 9

24

TOGAF 9

25

TOGAF 9

26

Praxeme Free and French!

27

Semantic, Pragmatic, Geographic

Logical, Software Model

Technical,Physical and Material

PRAXEME

Use Praxeme as EA resilient Methodology

and implement your project with the

development process of your choice http://www.praxeme.org/

Framework(s) for EA: Octo

Architectes bivalents technique & métier

la double compétence permet d’analyser et de concevoir à un niveau général sans nécessité du détail, elle facilite la communication dans tous les univers (métier, MOA, MOE, production).

Expertises techniques

réalisation opérationnelle (savoir faire), engagement sur le terrain.

Analyse par patterns

recherche des formes structurantes et récurrentes du SI aux niveaux technique et métier.

Compréhensible par tous, le pattern permet de mieux communiquer.

Mise en place de communautés d’expertise, destinées à mieux partager le savoir-faire de la DSI.

28

Framework(s) for EA: Octo

Octo (French

Consulting Company)

proposed Conceptual

framework for IT

urbanization

IT centric

views

IT centric

views

Process

centric

Views

29

30

Framework(s) for EA CIO Council v.s. CIGREF

IS Technology

Application

Data

Business

Strategy

Source : CIO Council Source : CIGREF

Métier

Stratégie

IS Technique

Application

Fonctionnel

Réfé

ren

tiels

Framework(s) for EA Conclusion

Each Framework has its own advantages and drawbacks

No framework tells you how and where to start and this is a big question

No framework tells you how to progress or to do it iteratively (methodology and/or EA Governance)

Some sources define a framework by describing what it contains, and some define it describing what it does.

Recommendations

Chose the one the easiest framework to evangelize to your project architects, CIO, developers, project managers.

Taylor it to your requirements and know what you are not yet covering.

Enhance it iteratively but do not change it each year (if possible)

31

Top-Down or Bottom-up?

32

33

Top/Down

Approach

General Architecture Processes

Architecture

description

Architecture

development

Application Architecture

Recovery and Optimization

Application Architecture

Evolution

Product

experience

Quality

requirements

Quality

attributes

Design

documents Code

Architecture Design

Domain

knowledge

Bottom/Up

Approach

Assessment Re- engineering

Top-Down or Bottom-up? Two major approaches

Two major approaches to enterprise architecture (EA) have evolved

a top-down approach that assumes comprehensive scope and strictly follows a formal process

a bottom-up approach that starts with infrastructure technology standardization and then moves up the food chain to target high-priority problem areas and eventually influence business architecture.

Each approach has its benefits and drawbacks, but it is far from arbitrary which is an appropriate model to choose — it is imperative that the approach fit the culture of the organization.

Organizations that need to address significant inefficiencies and redundancies in their business process or application portfolios and can wait at least a year for measurable benefits should start with the top-down approach.

Organizations that need results that affect the bottom line quickly or those where rampant technology diversity has degraded service delivery quality should start with the bottom-up approach (Brownfield).

The best approach is often a combination of both

34

Application

Infrastructure

Operation and

service delivery

Top-Down or Bottom-up? Do not Forget Holistic Views!

Strategy

Technology

Function and

Services Service and

Functional

Plan

Application

Plan

Business

Business

Process

Plan Process

Security

Integration

Governance

Etc.

Holistic

Views

Infrastructure

Plan

35

The private sector and start-up favored the bottom-up approach. It works well with the focus on quick tangible results.

The program can have significant impact immediately. Cleaning up the technology architecture can be accomplished in six to 12 months.

Early successes build credibility rapidly. Early wins start the EA effort off on the right foot and build much-needed credibility for the more politically complex efforts that follow.

It attacks problems in priority sequence. The potentially overwhelming scope of an EA effort is simplified in a bottom-up approach: The biggest problem is attacked first

Scope and complexity build gradually. Bottom-up allows technologists and managers to learn as they go.

It does not need a large central EA team at the outset. Involves a central project manager and the borrowed expertise of internal SMEs. There is no need for additional staff.

The technology-oriented starting point begins in IT’s sweet spot.

The typical infrastructure origin hampers efforts to expand scope. Once the infrastructure-based EA group has cleaned up technology standards and attempts to broaden its scope, it is often blocked from influencing application development staff for political and cultural reasons — and the effort can stall.

A standards-based approach introduces governance as a police action. The most typical introduction of governance is via an architecture review board that reviews projects designs and rejects nonstandard approaches. This makes architects the bad guys and can hamper IT community buy-in and future attempts at expanded scope.

The initial technology focus appears insensitive to business issues. Governance processes introduced to prevent the introduction of nonstandard technology please neither application developers nor business project sponsors. It smacks of a “technology for technology’s sake” attitude that is far from business-enabling.

Positive aspects Negative aspects

36

The public sector and regulated business (finance) favored the top-down approach. Used to define and document business needs then align IT to them

It begins by establishing a clear view of the existing environment.

The initial data collection activity enables a consensus regarding the current state environment, which is a critical element for effective planning.

Business issues are emphasized at the outset.

The top-down approach is explicitly about improving the business.

Technology plays a subservient role as the enabler of the business.

It establishes broad scope at the outset.

With the appropriate management support, all areas in need of improvement become subject to the EA program’s scrutiny.

Top-down programs can be overly abstract and have little impact in the short term.

The data collection process delays the introduction of governance.

The formal methodology requires training to get started.

The methodology implies business process re-engineering skills.

The EA organization will have to draw important conclusions from the analysis of the as-is architecture data.

But these skills are typically the realm of senior business consultants; it remains to be seen if many organizations that have followed this approach will find value in having assembled their business process portfolios.

Positive aspects Negative aspects

37

Top-Down or Bottom-up? Top Down Approach

Top-down EA planning entails the definition of a current state (called AS-IS) or as-is architecture in four categories:

business processes

application programs

information/data

and infrastructure technology.

Then the business plans are reviewed and an appropriate future state (called TO-BE) is created for each category.

The future state is compared to the current state in a gap analysis, and a sequencing plan is developed to progress from the current state to the future state.

38

39

Top-Down vs. Bottom-Up Example: Aventis

Top down Bottom up

Process re-designed

New application developed to support standardised process

Data migrated

"Big bang" launch

Top down approach is effective when :

• Existing landscape is simple • System can be implemented and supported centrally • Strong business direction has been given

Process re-designed

Core modules developed to support standardised process

Core module progressively added "seamlessly" to existing landscape

Applications retired on a case by case basis

Bottom up approach is effective when :

• Country/site specifics are significant • Different functions are involved and moving at a

different pace (priorities, budget, resources)

All existing applications retired

Existing landscape adapted as necessary

Examples : HR Examples : SAP

40

1. EA Process

41

Business process

Function / Service

Technical

Constraints

City Planning

Design

Strategy

Business

Functional

Application

Existing

Business

Architecture

Business

Strategy

Target

Business

Architecture

Target

Functional

Architecture

Existing

Application

Architecture

Target

Application

Architecture

EA Process Top Down Approach

42

The IS Urbanization process

Urbanization Process Club URBA-EA

Elaborate and improve

the IS urbanization

framework (rules,

principles, EA targets)

Link IS urbanization with

business strategy and IS

governance

IS Urbanization plans

Drive the implementation

and the evolution of the

master data repositories

Standardize and simplify

the exchanges between

applications

Build the link with

technical infrastructures

Infrastructure basics

Participate in the

upstream phases of the

projects

Monitor the architecture

of the IS projects

Relationships

with projects

Drive the IS Urbanization process

Participate in the projects arbitration committees

Ma

nag

em

en

t

Maintain and deploy the map repository for the existing and target IS

(processes, applications, data, etc…)

Su

pp

ort

&

Co

mm

un

ica

tio

n

Communicate and train on IS Urbanization

43

EA Process Club URBA-EA Index

0

1

2

3

4 1. Knowledge of

IS « as is »

2. Master data

repositories

management

3. Knowledge of

IS « to be »

4. IS building

management

5. Flows complexity

management

6. Urbanization

management and

communication

6 axis to understand IS urbanization maturity

(with 2 to 4 criteria per axis)

TO BE

AS IS

44

EA Process Example: Carlson

Develop “Target” Core Business Architecture

Develop roadmap

CIS

Pre–HAL

HAL TransitionPost-HAL

Before 31/12/04

Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07Q3 ’07 and

beyond

Before 31/12/04

Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07Q3 ’07 and

beyond

HAL MI/PM Corporate Information

System Scoping, Business Case,

Analysis

Corporate Information System Implementation

Operational Data – Scope, Analysis, Design

Operation Data – Build Phase

Press Control Systems Implementation

Group Planning Process and

System Requirements

Capture

Group Planning Implementation

Customer Management

Benefits Assessment

Customer Management Implementation

OD

CMG

PMS

CIS

Pre–HAL

HAL TransitionPost-HAL

Before 31/12/04

Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07Q3 ’07 and

beyond

Before 31/12/04

Q1 ‘05 Q2 ‘06Q2 ’05 Q3 ‘05 Q4 ‘ 05 Q1 ‘06 Q3 ‘06 Q4 ‘ 06 Q1 ‘07 Q2 ‘07Q3 ’07 and

beyond

HAL MI/PM Corporate Information

System Scoping, Business Case,

Analysis

Corporate Information System Implementation

Operational Data – Scope, Analysis, Design

Operation Data – Build Phase

Press Control Systems Implementation

Group Planning Process and

System Requirements

Capture

Group Planning Implementation

Customer Management

Benefits Assessment

Customer Management Implementation

OD

CMG

PMS

Create a high-level plan that defines

how the Technical and Informational

architectures will change over time

through a set of prioritized initiatives.

The implementation of these initiatives

will be marshalled through the

overarching Core Enterprise

Architecture.

• Define Roadmap initiatives

• Define initiative prioritization

and dependencies

• Create roadmap

Develop the “Target” Core Business

Architecture defined in terms of

process, systems and organizations

by creating target architecture views

through interviews and workshops.

Then validate with Business Owners.

Target:

•Core Business Plans

•Core Business Component Business

Model (CBM)

•Core Business Locations Maps

•Core Business Org Charts

•Core Business Events Schedules

• Map (CBM) to Application/Tech/Info

Architectures)

•Gap Analysis

Build a foundation model that provides

a functional representation of the Core

business at a Conceptual/Contextual

level. This model will remain as a

“High-Level” static reference point to

understand the key aspects of the

business. Included in the model will

be examples (and relational diagrams)

of:

•Business Plans

•Business Component Business

Model

•Business Locations Maps

•Business Organizational Charts

•Business Events Schedules

Develop Core Business Architecture

model

Define “Current” Core Business Architecture

Define the “Current” Core business

and strategy, defined in terms of

process, systems and organizations

by creating current architecture views

through interviews and workshops.

Then validate with Business Owners

Current State: •Core Business Plans

•Core Business Component Business

Model (CBM)

•Core Business Locations Maps

•Core Business Org Charts

•Core Business Events Schedules

• Map (CBM) to Application/Tech/Info

Architectures)

How to Describe my EA?

45

How to Manage Enterprise Architecture? Map Offers a Framework For Urban Renewal

Urban planning offers a useful analog on which to base a MAP program.

In the IT/Business equivalent of urban renewal, CIOs work with business leaders to understand a future community (business) vision that will guide work over the coming years.

IT staff create capability maps of the key business functions as the context and lexicon required to discuss the pending business change that will drive application change.

The direction provided by vision and the as-is condition provided by context allow IT and the business to orchestrate the work that will accomplish the long-term vision (To-BE)

46

How to Describe EA? Adopting a Layered Vision

Service and Functional

Plan

Infrastructure Plan

Application Plan

The Business Vision, goals

and processes

Business objects, capabilities,

services, functions, etc.

The Application and Data

Technical Design

The description of the

Technical Infrastructure

Business Process Plan

Plan / Layer / Architecture / landscape / etc. 47

How to Describe EA? What is important is the Mapping!

Business Vision

A process is triggered by events.

Can be within an business activity or transversal.

A process is composed of operations or successive tasks

A process can be seen as realized by functions.

Functional Vision

Tasks are realized by functions set grouped by domain/functionality.

Tasks creates or use information.

Application Vision

Function and information are materialized through application components running on technical architecture

Event

48

How to Describe EA? Process vs. Functionally Driven Vision

Functionally Driven Process Driven

Roles and responsibilities are aligned by functional area.

Roles and responsibilities are aligned by business process.

Business leaders have little process visibility beyond their

functional area.

Business leaders have broad visibility of the end-to-end

business process.

Business rule changes rely on IT department to schedule

changes to application code.

Business rules and process steps are changed by

business process owners.

Handoffs are implicit. Handoffs are explicit.

Cost accounting is aligned by functional area.

Cost accounting is aligned by process steps.

Risk analysis is led by business leader experience, intuition and data analysis.

Risk analysis is led by simulations based on current

operational conditions.

49

Building Your Own Framework

50

1. Defining the EA Information Model

51

Defining the EA Information Model Introduction

We defined a conceptual framework and some views related to it for enterprise architecture.

In order to be able to implement it, we need information models.

We need also to feed the information model with data, from existing (or not) information sources.

Information Models and information (data) will be implemented in a repository

52

Defining the EA Information Model IEEE Standard: Viewpoints and models

Called

Information

model in this

document

53

Defining the EA Information Model Conceptual Framework Implementation

CORE Models

Specific Modelq

Viewpoints

CORE Model needed to ensure Coherence and enterprise-wide Traceability and impact analysis. Investment Protection

Specific model, reuse core model. Customizable and extensible

Propose views on the model in order to fit to stakeholders' needs

Front End Application

Application are based on predefined (or not) viewpoints

54

Defining the EA Information Model CORE (Meta)Model

The CORE model is a pre-requisite for any IT landscape based project

It has been implemented in Rochade

The CORE model represent the nervous system of IT portfolio possible Front-end applications, guaranteeing thus a native traceability between all IT defined layers

The CORE metamodel can be reuse globally or partially

55

Let’s take an example … myEA framework

myEA framework is an example on how to design and implment your own framework.

For the sake of simplicity we will take the example of the technical layers of EA.

56

myEA framework

An application

Has a component architecture (N-Tiers)

Is reusing shared service (business or IT and framework)

Is composed of Software Standard

Is composed of Software Products (Not Standard)

Has software component deployed on several environments

A Shared Service

Can be a business service, technical service or framework

Is reusing service (business or IT or framework)

Is composed of Software Standard

Is composed of Software Products

Has a component architecture (N-Tiers)

Is deployed on several environments

Is described by its service profile

Its usage is governed by the service framework 57

myEA framework

A software product

Is describing tools bought or created to build the application that are not standard

Is composed of other tools if it is a packaged software product (ex: Microsoft Office Suite)

A software product is composed of software components

Is categorized depending on is technical function

Has a generic name

Has specific components (deployed at run time)

58

myEA framework

A software standard

Describe a standard software product

Has a profile (Word file)

Is categorized depending on is technical function

Contains information concerning standard lifecycle

can have several kinds of dependency links like: Depend on, Incompatible with, Used for service, Replaced by, Exception is, etc.

Software Standard Framework

Is a shared service

Is categorized depending on is technical function

Has a generic name

Has specific components (deployed at run time)

59

myEA framework

Component Architecture

Used for describing n-tiers client-server architecture

Deployed software component

Has a version

Is deployed on a Hardware component

Has communication ports

Data center

Are connected by Network link

Are sustaining platform and environment

60

Let’s take an example … myEA framework

61

myEA framework Application Component Architecture description

Can be business service

and/or technical service

and/or framework

Software Standard as of

today

Hardware

Standard as

of today

Test,

Integration,

Production

Software Component

Are related to standard or not Software Component

Software Product

composed of / Dependency

has

Software Standard Has

Application

Composed of / Dependency / Replaced by Source

Destination consist of

Component

Architecture

n-tiers

Shared Service

is composed of / dependency

Application

Interface

Composed of / Dependency

Environment

is composed of

Software product is

not standard but can

become a standard

N-tiers

architecture

Application

functional Interface

62

myEA framework N-tiers flows description

An Application

Application

component flows

architecture

Dependency links

between n-tiers

architecture and

software

components

Software Component

Software Product

composed of / Dependency

has

Software Standard Has

Application

Composed of / Dependency / Replaced by Source

Destination consist of

Component

Architecture

n-tiers

Shared Service

is composed of / dependency

Application

Interface

Composed of / Dependency

Environment

is composed of

63

Shared Service

Service

Framework

Service

Profile

Country

Coverage

Environment

Application

Software Product

is composed of / dependency

Software Standard

Component

Architecture

myEA framework Technical Service/Framework Description

Service framework

description (IT

process)

Service

Profile

Service

Country

coverage

Shared Service

has its own

environment Shared

Service has its

own n-tiers

architecture Shared

Service is

composed of

software

product

Shared

Service is

composed of

software

Standard

64

myEA framework Deployed Software component and flow

Technical

interface

(port, IP

address, etc.)

A Flow comprises

interfaces

(functional and

technical), data

exchanged and the

type of flow (peer to

peer, hub and

spoke,

pub/subscribe, etc.)

A functional

interface is

between internal

Application (EAI)

or external

application (B2B)

Port

Deployed Software

Component

Hardware Component

Technical Flow

Data Package Application Interface

Software Component

Use

Provide

Protocol, Composed of

is deployed on

Dependency

Format of

data

exchanged

Component

deployed

65

myEA framework Data center and LAN/WAN communications

Network Link

DataCenter

Connected to

Environment

is composed of

Contains

Hardware Component

Shared Service

Application

LAN/WAN link

between data

center

Data center

description

platform (by country) and

Environment (by type)

66

myEA framework Recommendations

Information Model should be build first and adjusted

depending on the conceptual framework used

Information models and conceptual framework should be

independent of tools

Should be able to implement it in Mega, Visio, Rose or Rochade (and keep it in sync. with evolving information models specification)

The Core Information model is required for all projects

providing thus a common supply chain information nervous

system

Coherence and compatibility are ensured between viewpoints and conceptual framework

67

Defining the Information Model Takeaway

Provide exhaustive description within the Information model of :

Dependency/incompatibility between entities

Software standards, services, etc.

Cross reference between two entities

Software components on hardware components

Manage multiple granularity levels

Application is composed of other applications

Describe all needed conceptual framework and their relationships and/or granularity level

PA and EA

68

2. Defining the Views of myEA framework

69

Defining the Views of myEA framework AA Conceptual Framework

70

Defining the Views of myEA framework EA Conceptual Framework

Application Portfolio

Management

City Planning Map

Services and events

Functional Architecture

Function and application

Mapping and covrage

Aggregated ViewsRelate and aggregate

information from

several canonical viewpoints

Aggregated ViewsRelate and aggregate

information from

several canonical viewpoints

Canonical View

Canonical View

DomainFunctional

Decomposition

71

3. What about Tools?

72

73

EA Tooling Just For Drawing?

Enterprise architecture is a discipline that uses drawings and diagrams.

All real world EA contain lots of diagrams, and many are deemed central to the story being told.

This is because enterprise architecture is trying to represent n-dimensional data about businesses and systems in two dimensions.

Architects, engineers, and cartographers have worked for centuries to do the same thing in their domains.

Graphical abstract representations of complex relations are vital if we are to understand, explain, and control our environments.

So practitioners must understand some of the subtle but significant simplifications that the authors of these diagrams have made to get everything on one page.

As a result, it is a godsend in communicating with high-level managers who have limited knowledge of business processes and technology, as well as short attention spans.

74

EA Tooling How are they built

Each EA tool comes with

A central repository (could be proprietary like Mega)

A metamodel that can be already hard coded (Mega) or open (Casewise)

A script language to navigate inside the metamodel

An meta-editor to create objects and relationships within diagram

An editor for architect to describe their models and make simulation and impact analysis

An import/export tool

An administration tool

Complementary modules to generate static web site or to offer a dynamic web access to the repository.

Frameworks that can be obtained freely or bought.

75

EA Tooling Numerous Tools On The Market

Nevertheless modeling by itself is useless (Visio Effect)

Impact and risk analysis, simulation, and governance are not also supported

“Which EA tool do you use

to support your EA

framework

modeling and publishing

approach?”

EA Tooling

EA modeling tools are mature enough for the mainstream

but still require decreasing operations costs with automatic data collection

No EA modeling tool satisfies every user

Scenario of a single modeling tool but with tradeoffs

Scenario with multiple tools

What is difficult is to

Model exhaustively all plans

Manage coherence and traceability through time and models

Ensure people model the same way

Provide output from central repository (Office documents, web site)

76

77

EA Tooling Things To Know

Import and export functions remain weak points

Some are still using a proprietary DBMS

Metamodel customization is no longer a major differentiator

Products are mature, the market is mature, but none of the vendors have a clear mid-term road map. The EA market follows the current wind.

Support for both a Web-based architecture and standalone mode is a differentiator

The criteria associated with change management make the difference.

EA tool are now extended with Risk Management, Application Portfolio Management, and social communications

4. Implementing in tools you model (Mega or Casewise)

78

Canonical Views Application Environment

CWT Diagram Naming Application Environment

Building this View Application is seen as a black box and only external

relationships/message exchanged with actors and applications are

shown

79

Application

External partner

Mega

Canonical Views Application Tree

CWT Diagram Naming Application Tree

Building this View Describe all application from the family

80

Application Family

Applications

Casewise

Canonical Views Application Technology

CWT Diagram Naming Application Technology

Building this View Describe all technologies used by an application following the

Application Architecture city planning diagram

81

Mega

Canonical Views Business and Technical Services

CWT Diagram Naming Business and Technical Services

Building this View Describe business services required/offered by the applications and the

technical services

82 Mega Casewise

Canonical Views Application N-tiers Architecture

CWT Diagram Naming

Application N-Tiers Architecture

Building this View

Describe the N-tiers client server architecture and the technical flows between them

based on “N-Tiers Architecture” city planning diagram

83 Casewise

Aggregated Views Application Deployment Platforms

CWT Diagram Naming Dev/Test/Pre-production/Production Deployment Platforms

Building this View Describe datacenter and network connections between them

84

Datacenter 1

Datacenter 2

Mega

Technical Standard View Technical Standards

CWT Diagram Naming Technical Standard View

Building this View Describe Standard Technical API and Frameworks

85 Casewise

Example: EA Architecture Framework

Business

Views

IS - IT

Views

TechnicalInfrastructure

Application InfrastructureCompany Infrastructure &

Backbone Services

Application & Data Architecture

Logical & Technical Application &

Data Architecture

Company Standards and

Architecture Patterns

Application Landscape

Application Context & Flows in scope

Applications Map

Functions & Services

Function(s) to be deliveredCity PlanningIS & IT Views

BusinessProcesses

Process(es) in scopeBusiness Processes Map

BusinessOrganizations

Business context in scopeCompany Business Map

Enterprise Architecture Project Architecture

Operations & Services Delivery

Operations & Services Delivery

TechnicalInfrastructure

Application InfrastructureCompany Infrastructure &

Backbone Services

Application & Data Architecture

Logical & Technical Application &

Data Architecture

Company Standards and

Architecture Patterns

Application Landscape

Application Context & Flows in scope

Applications Map

Functions & Services

Function(s) to be deliveredCity PlanningIS & IT Views

BusinessProcesses

Process(es) in scopeBusiness Processes Map

BusinessOrganizations

Business context in scopeCompany Business Map

Enterprise Architecture Project ArchitectureEnterprise Architecture Project Architecture

Operations & Services Delivery

Operations & Services Delivery

86

Example: EA Architecture Framework City Planning Views in Mega

What

Framework to be used for mapping technologies or applications

Mega Diagram

City Planning

Objects to be used

Application

Software Solution

Software Suites

Software Component

Shared Services

Service

Description type

Structural

87

City Planning Views in Mega IS Domain Model

<< IS Domain Model Framework >>

Business Process

<< IS Domain Model Framework >>

User Interface

<< IS Domain Model Framework >>

Computing Platforms

<< IS Domain Model Framework >>

Application & Data Integration

<< IS Domain Model Framework >>

Data Technologies

<< IS Domain Model Framework >>

Application Technologies

<< IS Domain Model Framework >>

Application & Data Logic

<< IS Domain Model Framework >>

Network

<< IS Domain Model

Framework >>

Security

<< IS Domain Model

Framework >>

Services

<< IS Domain Model

Framework >>

Quality

88 Mega

City Planning Views in Mega Portal Framework

<< Portal Framework >>

Presentation layer

<< Portal Framework >>

Portal Layer

<< Portal Framework >>

Integration Layer

<< Portal Framework >>

Authentication Source<< Portal Framework >>

Structured data<< Portal Framework >>

Unstructured Content<< Portal Framework >>

Technology and Application

<< Portal Framework >>

WAP client<< Portal Framework >>

Web Client<< Portal Framework >>

PDA client

<< Portal Framework >>

Presentation<< Portal Framework >>

Personalization<< Portal Framework >>

Taxonomy<< Portal Framework >>

Collaboration<< Portal Framework >>

Content

Management

<< Portal Framework >>

Authentication<< Portal Framework >>

User Mgt and Authorization<< Portal Framework >>

Integration

<< Portal Framework >>

Messaging service<< Portal Framework >>

Publish-Subscribe Service<< Portal Framework >>

Web Services

89 Mega

City Planning Views in Mega SOA Framework

<< SOA Framework >>

End User Services

<< SOA Framework >>

Composite service

<< SOA Framework >>

Business Service

<< SOA Framework >>

Service Infrastructure

<< SOA Framework >>

Enterprise Systems

<< SOA Framework >>

Management

<< SOA Framework >>

Security

90 Mega

5. Implementation in UML

91

Conceptual framework Application Architecture Conceptual Framework

DeploymentArchitecture

Security Architecture

Application Contex(flow &

interfaces)

Application InternalLogical

Components

Application Data

Application Infrastructure

Application n-tiers

Technical Architecture

Application COTS

Business Continuity

Service Level Management

Aggregated ViewsRelate and aggregate

information from

several canonical viewpoints

Aggregated ViewsRelate and aggregate

information from

several canonical viewpoints

Canonical View

Canonical View

92

Implementation in UML Creating the UML profile

Definition of all elements we would like to manage natively and that are not

part of UML

The ULML profile is based on the information model

93

Implementation in UML Creating the UML profile

We can associate a specific icon to the UML

element created ("stereotype")

94

Implementation in UML Creating the Views

95

Implementation in UML Application Data Flow Description

96

Implementation in UML Application Data Flow - Actors

97

Implementation in UML Application Data Flow - Interaction

98

Implementation in UML Application Data Flow - Communication

99

Implementation in UML Functional Interfaces Description

100

Implementation in UML Shared Service (Pattern)

101

Implementation in UML Shared Service – Catalog of services (Pattern )

102

Implementation in UML Software Standard

103

Implementation in UML Software Product

104

Implementation in UML N-tiers Technical Architecture

105

Implementation in UML Data Center and their network

106

Implementation in UML Platform Description

107

Implementation in UML Environment Description

108

Application component description Internal Logical Component

109

Application component description Internal Logical Component

110

Conclusion about myEA!

111

Conclusion

Metamodel and framework should be designed first and independently from the tool

Then select your tool and use it as a knowledge Mgt tool

Link it to developer wikis, continuous build platform, devops scripts

Depending on the company core focus the framework may evolve

From discovery of technical infrastructure and application landscape to information security and integration between company bricks.

Documentation and training is key

112

113

EA in 2nd life (Michelin) Training in the Island

114

EA in 2nd life (Michelin) Teaching enterprise architects how to build roadmaps

On the Road to Resilient EA

115

IT Midlife Crisis World Economic Recession, IT is the first to suffer

The timing of contractions in sector-level sales and EBITA indicates that the four most recent recessions began with a core underlying shock that then spread through the economy in a fairly predictable way.

Three began with similar declines in the IT sector

When real EBITA growth resumes in these sectors, it may be a useful indication that the economy is turning around.

116

What is Enterprise Architecture City Planning (Urbanisation des SI)

Understand and document

My Information System patrimonial

Its organization, its structure

its components, its interactions

Its information managed and data exchanged

Its relationships with others (ecosystem and B2B dialects)

Manage

Analysis, KPI, IT Portfolio

Govern

Bring under control Cost, IS Performance and evolution risks

117

What is Enterprise Architecture City Planning (Urbanisation des SI)

Understand and document

My Information System patrimonial

Its organization, its structure

its components, its interactions

Its information managed and data exchanged

Its relationships with others (ecosystem and B2B dialects)

Manage

Analysis, KPI, IT Portfolio

Govern

Bring under control Cost, IS Performance and evolution risks

Deliver value with/to the business

on time and on market (Tailored EA framework like eTom, Agile, Lean,

MDx, xaaS, BPx, etc.)

Agile and elastic platform and Infrastructure to

support all architecture, “ilities” and

deployment needs

(ITIL, PaaS, Virtualization, SAN, etc.)

Resilient EA

Use EA as a control tower for assessing and ensuring resilience 118

Resilient Enterprise Architecture Described via a layered approach

Strategy

Technology

Resilient EA

Methodology, policies and

rules should be applied at

all layers

Make EA more dynamic

(not only static description)

– requires new set of

integrated tools

Holistic

Views

Security

data and

Information

Integration

SOA

Business

Architecture

Application

Portfolio

Application

Architecture

Technical

Architecture

Business

Model

119

Resilient Enterprise Architecture Some Deliverables

Business Architecture

(cartographie des métiers)

Process Architecture

(cartographie des processus)

Functional Architecture

(cartographie fonctionnelle)

Application Landscape

(cartographie applicative)

Application Architecture

(cartographie architecture

technique)

Business (Métier)

Function (Fonctionnelle)

IS (Informatique)

Plan d’occupation des sols

Décomposition fonctionnelle

Projection fonction/application

schéma d’architecture logique

Master data et référentiels

Couverture fonctionnelle de

l’application

schéma inter-applicatif

schéma d’architecture logique

Schéma d’architecture de

contexte technique, de

composants, de données

applicatives, d’architecture

technique (n-tiers, couches)

Description des processus

opérationnels, des activités, des

objets métiers

Organigramme, acteurs

Infrastructure Architecture

(cartographie architecture

technique)

Schéma d’architecture

d’infrastructure, de déploiement

Information

and Data

Architecture

Modèle d’information

et règles de gestion

Master Data

Schéma de description

des échanges

Schéma conceptuel de

données

Schéma de données

techniques

Glossaire de termes

Métier, Description

des objets métiers

120

EA – The dream! Comes true?

121

Twitter

http://www.twitter.com/welkaim

Travel 2.0

http://www.netvibes.com/travl20

Linkedin

http://fr.linkedin.com/in/williamelkaim

Blog

http://www.reimagine.fr/

Contact: welkaim@carlsonwagonlit.com

122