EAdirections Enterprise Architecture Fundamental Concepts 6-15-2010

© EAdirections 2010. All Rights Reserved.

EA Fundamentals:Core Concepts, Best Practices, & Winning Approaches

Tim Westbrock & George Paras

Managing Directors

[email protected]

[email protected]

June 15, 2010

mailto:[email protected]

mailto:[email protected]


Why We Are Here – As Leaders

• Aligning IT to business strategy

• Planning for major IT and business transformations

• Creating an effective "Office of the CIO"

• Executing global standards and reuse programs

• Manage complexity to maximize business value

• Implement ongoing enterprise optimization programs

• Etc.

2


Why We Are Here

• Make our businesses and IT organizations better…

– More cost effective

– More responsive and faster at solutions delivery

– More nimble/agile to realign to changing business needs

– More innovative

– More reliable, accurate and consistent – no surprises

• This is what many call “value delivery” and “being aligned”

• How we can do it – by making better decisions

– By being more informed

• About why, what, how and even when and where we deploy solutions

• Everyone!

– By working together instead of at cross-purposes

• By taking the long view and rationalizing the short view against it

• By taking the big (enterprise) view and rationalizing the small with it

(department, project, application, service, asset, capability, component,

etc.)

3

© EAdirections 2010. All Rights Reserved. 4

Question

What do you think of when you

hear the term

“Enterprise Architecture?”


Enterprise Architecture vs. Architecture

• EA often mistaken

for/positioned as:

– Systems Architecture

– Solutions Architecture

– Infrastructure Architecture

– SOA

– ??? Architecture

• EA is a separate and distinct

discipline that is higher-level,

more strategic, and longer-

term focused, but still must

be integrated with other

architecture disciplines

Enterprise Strategy

Enterprise Architecture

Bus

Arch

Info

Arch

App

Arch

Tech

Arch

Project 1 Project 2 . . . Project n


How to Get There? - The Problem

• How can an enterprise establish a reasonable idea for all

that has to happen in a complex organization to

accommodate necessary change in support of business

transformation?

Business

Operations

Business

Information

IT

Infrastructure

Business

Solutions

Strategy


By creating an Enterprise Architecture that …

• Expresses the impact of Business Strategy on the operations of

your business, the information you need, the applications that

support your business, and the infrastructure upon which they are

built

• Establishes a set of principles that drives consistent decision

making across disparate groups of decision makers

• Establishes/Publishes/Evolves a set of standards from which

projects and other implementation activities take direction

• Creates models that provide a broad context for impact analysis,

scenario planning, reuse opportunity identification

• Compares the future state against the current state and develops

a Roadmap that shows how to migrate from As-Is to To-Be

• Creates an environment of collaboration and consensus-building

between management, architects, SMEs, analysts, developers and

business sponsors


EA – Challenge of Overcoming the Inhibitors

Business Strategy

Current Objectives

Pro

ce

ss

es

Systems & Infrastructure

Inhibitors:

– Complexity

– Rate of Change

– Misalignment of Operations from Business Strategy

– Enterprise vs. Project Perspective

– Limited Reuse/Reusability

How can we:

– Reduce Complexity

– Decrease Delivery Time

– Align Business Strategy and Operations

– Reconcile Enterprise and Project Perspectives and

– Increase Reuse and Reusability?

Data & Information


So What Is This Thing Called EA?

9

Enterprise Architecture is a set of

artifacts/methods that help

BUSINESS LEADERS

make decisions about

DIRECTION

and communicate the

CHANGES

that need to occur in their enterprise to

achieve their vision.


Driving Business Transformation

Business Vision & Strategy

Bu

sin

es

s V

alu

e

Time

Bus. Info.

Tech. Sol.

Future State

Transformed

Enterprise

Transformationthrough Asset Portfolio Improvements,

Retirements, Consolidations,

Rationalizations, etc.

EA Creation

Current State

Bus. Info.

Tech. Sol.

Transformationthrough New Business Projects

Roadmaps & Lifecycles


Driving Business Transformation

Business Vision & Strategy

Bu

sin

ess V

alu

e

Time

Bus. Info.

Tech. Sol.

Future StateTransformed

Enterprise

Transformationthrough Asset Portfolio

Improvements, Retirements, Consolidations, Rationalizations, etc.

EA Creation

Current State

Bus. Info.

Tech. Sol.Transformation

through New Business Projects

Roadmaps & Lifecycles

Strategic Direction

Project Support

Portfolio Transformation


Enterprise Architecture Development (HL)

Identify

Business

Vision

Identify

Strategic

Capabilities

Define

Enterprise

Principles

Determine

Future

State

Identify

& Analyze

Gaps

Conduct

Impact

Analysis

Develop

Transformation

Roadmap

EnterpriseBusinessStrategy

TransformationRoadmap

• Identify Strategic Capabilities– Understand business strategy

– Decompose into more specific, applicable language

• Identify the capabilities that are required to support enterprise business strategies

– Models Help!

• Principle-Based

• Future State Definition– Standards/Guidelines/Rules

– Models – of all types, contexts, scope, audience and depth

• Comparison to Current State

• Linkage to Project Portfolio

• Lifecycle, Evolutionary


Create Artifacts that Speak Business

• Artifacts must to be at a high enough level of abstraction

that executives can fully understand them

– This means one page

• Content is Business-Oriented not Tech-Oriented

– Applications are a Business entity – understood by execs

– Infrastructure Complexity is best left out of the pictures

• Business Context Diagrams

– Shows the breadth of the business operations in one page

• HL Relationship Maps – provides further context for the

strategic conversation (examples in appendix)

– Function to Organization

– Function to Application

– Application to Information

– etc.

• EA is full of different views – Don‟t be afraid to create

multiple versions of an artifact aimed at different audiences

13


What Senior Execs Don‟t Want to See

14


Or This

15


Mapping the Application Systems to the FH

In the diagram below, the Application Systems are mapped to the FH. This can be very effective in understanding which applications support which functions as well as possible overlap. The Application Systems use the same color coding in this map as in the previous slide.

1.1

P

ublic

Re

latio

ns &

Co

mm

un

icatio

ns

1.2

A

dve

rtis

ing &

Bra

nd

Ma

nage

me

nt

1.3

M

ark

eting O

ps &

Lead G

enera

tion

2.1

P

rospectin

g &

Lead M

an

ag

em

en

t

2.2

Q

ualif

ica

tio

n

2.3

S

ale

s P

ropo

sals

2.4

S

ale

s N

ego

tiatio

ns &

Co

ntr

acts

3.1

R

ese

arc

h &

De

ve

lopm

en

t

3.2

P

roduct D

eve

lopm

en

t &

De

sig

n

3.3

P

roduct E

ngin

ee

ring

4.1

P

rocu

rem

ent

4.2

M

anufa

ctu

ring

4.3

In

vento

ry

4.4

S

hip

pin

g

4.5

C

usto

me

r S

erv

ice

4.6

R

etu

rns

5.1

P

urc

hasin

g

5.2

A

cco

un

ts R

ecie

va

ble

5.3

A

cco

unts

Pa

ya

ble

5.4

F

inancia

l R

epo

rtin

g

5.5

In

tern

al A

udit

5.6

H

um

an R

eso

urc

es

5.7

In

form

ation S

yste

ms (

IT)

5.8

Legal

Customer Relationship Management (CRM)

Leads

Contacts

Accounts

Campaigns

Financial System

General Ledger

Cash Management

Accounts Payable

Accounts Receivable

Fixed Assets

Supply Chain Management

Order Entry

Purchasing

Inventory

Forecasting

Manufacturing

Bill of Materials

Scheduling

Cost Management

Quality Control

Capacity Planning

Freight Management & Shipping

Freight Management & Shippping

Human Resources

Personnel

Payroll

Benefits

Time & Attendance

Content Managent

Content Management

etc.

etc.

etc.

System function

Co

mp

an

y A

BC

's I

nfo

rma

tio

n S

yste

ms

LEGEND

Company ABC

High Level Functional Hierarchy

4.0 Operations 5.0 Finance & Administration3.0 Engineering1.0 Marketing 2.0 Sales


ExecutiveManagement

ExistingOperations

EnterpriseArchitecture

BusinessStrategy

ProjectPortfolio

Mgt.

New/ChangedCapabilities

RequiredModels of theFuture StateEnterpriseModels of the

Current StateEnterprise

Object

ObjectObject

Object

Standard Service Request

Standard Service Response

CLIENT(Service

Requestor)

ServiceProviderWORK

Project B

Build &Integrate

Object

ObjectObject

Object



CLIENT(Service

Requestor)

ServiceProviderWORK

Object

ObjectObject

Object



CLIENT(Service

Requestor)

ServiceProviderWORK

Project C

Build &Integrate

Object

ObjectObject

Object



CLIENT(Service

Requestor)

ServiceProviderWORK

Project A

Build &Integrate

PopulateNew/Changed

Capabilities Delivered

TacticalProject

Requests

Input

GOVERNANCE

Annual, TacticalGoals, Objectives

& Targets

Represents

Transforms

EA becomes the driver of EPfM

EA Roadmap• Project Requests• Adds/Changes to Applications,

Infrastructure, Information, &

Business Processes

• Timeline/Interdependencies


Enterprise Governance

• Enterprise Governance is a consistent and interdependent system of people, process, and policy throughout the organization intended to ensure the intentions of the enterprise leadership are reflected in all decisions.

• Must be delegated authority by senior leadership

• Must understand strategy, EA and EPM; participation improves understanding

• Defines (approves) standards, policy, guidelines

• Must define consequences and apply them


Sample Organization Structure

• Combination EA/Governance org

structure

• Issue Resolution Groups are

chartered as needed by Architecture

Council

• Architecture Council members

should be delegated authority by

Steering Committee

– Mix of IT and business resources

• Decisions get escalated to Steering

Committee from Architecture

Council

• Architecture Council ≠ EA Core

Team

– EA Core Team is represented on ARB

• EPMO takes on responsibility for EA

compliance checks within SDLC

ExecutiveSteering

Committee

ArchitectureCouncil

IssueResolution

Groups

CIO

EACore Team

DomainTeam (s)

EPMO


EA vs. Subject Area Architect vs. Project ArchitectE

nte

rpri

se S

trate

gy

En

terp

rise A

rch

itectu

re

Bu

s

Arc

h

Info

Arc

h

Ap

p

Arc

h

Tech

Arc

h

Pro

jec

t 1

Pro

jec

t 2

. . .

Pro

jec

t n

InterpretedBy

Provides

Facilitates

Collaborates

• Principles• Standards• Patterns• Policy• Models• Services Needed

• Strategic Context• Best Practices• Research• Guidance• Leadership

Consults / Advises / Reviews

Collaborates

SubjectAreas Projects

Provides

• Principles• Standards• Design Patterns• Integration Approach• Models

• Project Design• Tech Selection• Service Design• Integration Design• Models

FEEDBACK

FEEDBACK

FEEDBACK


Governance Best Practices - Approval

• Authority Flows Down

– Must be granted, cannot be assumed

– EA Team has none

• Committees are not debate societies

– Up/Down votes required

• Establish committee protocols

– Membership Requirements/Proxy Rules

– Notification/Comment/Action Periods

– Quorum/Voting/Table/Veto Rules

• Consensus, Majority (Simple, ¾, etc.)

– Meeting Frequency

• Areas of Responsibility

– ESC vs. Architecture Council

– Escalation Rules

• Formal Sign-off Ceremony

• Publish Results

Perform

Analysis

Make

Recommendation

Review &

Deny or

Approve

Escalation

EA Approval

Stages

ArchitectureReviewBoard

ExecutiveSteering

Committee

EACore Team

DomainTeam (s)


Project Linkage

• EA must be defined from the Big-Picture perspective, but

realized at the project level

• Over time, the project level achieves more and more of the

strategic vision

• Project reviews must consider EA impact and guidance

• Proper checkpoints identified and criteria applied

– Including the transition of project documentation into the EA

repository

• Too many projects for EA to review; EPM must own project

review process and apply EA effectively

• Adherence to EA must be mandated; compliance expected;

deviation must be explained and approved


Governance Best Practices - Compliance

• EA Team Informs/Advises Process

– PROACTIVE - Coaches/Consults Project Teams EARLY

– Examines Projects for Compliance and identifies non-compliance concerns

– No Authority to Grant Exceptions• Informs EPMO of concerns/implications

• Projects request Exceptions/Variances from EPMO

– Should have the support of the EA Team

• Governance Body (EPMO?) Manages Exception Process

– Integrates Compliance Process with SDLC(s)

– Presents findings to Architecture Council

– Council Escalates to ESC

– Directs Project as to Outcomes

• EA Team uses results of process to improve EA Content

• Metrics kept by EPMO, analyzed by EA Core Team

Project

Proposal

HL

Design

Review

Detailed

Design

Review

Post-Project

Project Life

Cycle Gates


Conclusion: The Demands of Enterprise-ishness

• Our perspective: EA must be driven by the overarching business strategy of the „Enterprise‟

– Reflective of the desired operating model*

– Take a holistic view

– Identifying and enabling requirements for business capabilities that are enterprise-wide in scope (often not clearly articulated by the business)

– Make decisions that are optimal for the enterprise not a specific project or LOB

• Consequently, EA efforts must emphasize an „E‟-view– The scope of EA is THE ENTERPRISE

• “Solidify the Abstract” and “Simplify the Complex”

– Gaining stakeholder support

– EA team structure and participants

– Governance

– Communication

• EA must demonstrate clear & unambiguous enterprise-wide linkages; and, as appropriate, explicit decomposition

– Enterprise Business Strategy to EA & Project Portfolio Management

– Business Architecture to Information Architecture to Application Architecture to Technology Architecture

* Enterprise Architecture as Strategy: Creating a Foundation for Business Execution by Peter Weill, David C. Robertson and Jeanne W. Ross


OVERVIEW

10 Requirements for Enterprise Adoption

1. Analyzing and presenting an „Enterprise View‟

2. Linking EA to overall Business Strategy

3. Optimizing for the Enterprise not the Project

4. Addressing Culture, Politics & Leadership

5. EA Team Structure & Participants („E‟-level)

6. Approval of EA strategies and artifacts

7. Communicating „E‟ deliverables to leadership

8. „E‟ requirements of a federated business model

9. Sequencing and prioritizing EA tasks

10. Proactive & holistic planning



About EAdirections

27

Tim Westbrock

George S. Paras

We Work WITH You To:• Improve the value of IT to your enterprise

• Improve Enterprise Architecture (EA) programs

• Refine/Tune Governance Mechanisms

• Create a Portfolio-Based Culture

• Integrate Management Disciplines

• Unify Business/IT Perspectives

• Operate a World-Class Office of the CIO

• Balance the Strategic with the Tactical

How We Do It:• Continuous Mentoring of IT Leaders

• CIO, EA Team, PMO, Office of the CIO, etc.

• Assess Org Structures, People, Teams

• Build Internal Support and Sponsorship

• Analyze and Drive Activity Plans

• Review and Improve Processes & Deliverables

• Contribute Relevant Examples & Research

• Provide Pragmatic, Objective, Unbiased and Prescriptive Feedback on Everything You DoSubscribe to our

Newsletter: http://eepurl.com/bQ4_

www.EAdirections.com

http://eepurl.com/bQ4_

http://www.eadirections.com/


Our Approach – Build Effective EA Organizations

13© EAdirections 2008. All Rights Reserved.

Mapping the Application Systems to the FH

In the diagram below, the Application Systems are mapped to the FH. This can be very effective in understanding which applications support which functions as well as possible overlap. The Application Systems use the same color coding in this map as in the previous slide.

1.1

P

ublic

Re

latio

ns &

Co

mm

un

ica

tio

ns

1.2

A

dve

rtis

ing &

Bra

nd

Ma

na

ge

me

nt

1.3

M

ark

eting O

ps &

Lead G

enera

tion

2.1

P

rosp

ectin

g &

Lea

d M

an

ag

em

en

t

2.2

Q

ualif

ica

tio

n

2.3

S

ale

s P

ropo

sa

ls

2.4

S

ale

s N

ego

tia

tio

ns &

Co

ntr

acts

3.1

R

ese

arc

h &

De

ve

lopm

en

t

3.2

P

rodu

ct

De

ve

lopm

en

t &

De

sig

n

3.3

P

rodu

ct

En

gin

ee

ring

4.1

P

rocu

rem

ent

4.2

M

anufa

ctu

ring

4.3

In

vento

ry

4.4

S

hip

pin

g

4.5

C

usto

me

r S

erv

ice

4.6

R

etu

rns

5.1

P

urc

hasin

g

5.2

A

cco

un

ts R

ecie

va

ble

5.3

A

cco

un

ts P

aya

ble

5.4

F

inan

cia

l R

epo

rtin

g

5.5

In

tern

al A

udit

5.6

H

um

an R

eso

urc

es

5.7

In

form

ation S

yste

ms (

IT)

5.8

Legal

Customer Relationship Management (CRM)

Leads

Contacts

Accounts

Campaigns

Financial System

General Ledger

Cash Management

Accounts Payable

Accounts Receivable

Fixed Assets

Supply Chain Management

Order Entry

Purchasing

Inventory

Forecasting

Manufacturing

Bill of Materials

Scheduling

Cost Management

Quality Control

Capacity Planning

Freight Management & Shipping

Freight Management & Shippping

Human Resources

Personnel

Payroll

Benefits

Time & Attendance

Content Managent

Content Management

etc.

etc.

etc.

System function

Co

mp

an

y A

BC

's I

nfo

rma

tio

n S

yste

ms

LEGEND

Company ABC

High Level Functional Hierarchy

4.0 Operations 5.0 Finance & Administration3.0 Engineering1.0 Marketing 2.0 Sales

Ongoing Mentoring– Make our clients more effective– IT Strategy, Business/IT Alignment, Business Transformation,

Project Management, Application Portfolio, Enterprise Architecture, IT Governance, Cost Optimization, etc.

– Individuals or Teams– Retainer based

Providing „Jump Start‟ Materials & Other Research– Provide „quick & dirty‟ enterprise-wide templates for demonstrating

Business/IT Alignment , Enterprise Architecture, etc.– Templates for demonstrating Business/IT alignment– Tools for „Business Fit‟ vs. Technical Fit‟, etc.– Perform on-going research

Building the Extended Team– Refine mission, strategy, roles and responsibilities– Establish communications strategy to enroll support– Build a culture of collaboration and effectiveness focused on

„enterprise outcomes‟

Assessing Activities & Review Deliverables– Provide honest feedback and prescriptive advice– Critique documents to improve effectiveness especially for C-level– Guide development of new artifacts– Ongoing review of emerging issues


Additional Slides

29

APPENDIX


Defining Enterprise Principles

• Principles are primarily from 2 sources:

– Best Practices analysis

• What best practices should be adopted

– Current state SWOT analysis

• How do we overcome weaknesses?

• How do we continue our strengths?

• How do we leverage opportunities?

• How do we overcome threats?

• Global Principles

– EA level

• Subject Area Principles

– EBA, EIA, ETA, ESA

• Domain Level Principles

– Network, Application Development, Data Modeling


What Does a Principle Look Like?

• Principles vs. best practices: What‟s the difference?

• A principle is:

– Title

– Short description

– Rationale/justification

– Implications

• Evaluating principles

– Treat as a set, not just as individual principles

– Resolving conflicts

“Title: CA Principle”

• Description: A bit more detail

• Rationale: Why is this important, and why does it support the requirements?

• Implications: What does this mean to the organization? What happens if you do, or do NOT, do this?


Example Principles

• EA must be primarily driven to increase business value, while enabling the enterprise to change more and more quickly and reducing complexity wherever possible.

• EA Governance is part of the Overall Enterprise Governance approach.

• Information Is Managed and Leveraged as an Enterprise Asset

• Evolve holistic enterprise architecture that models the business operating model, information environment, solutions portfolio and technology infrastructure.

• Enterprise architecture development must be an insourced effort, supplemented if needed, by outside expertise and resources to develop and support the competency of internal resources dedicated to EA.

• Information will be location transparent.

• All modules and processes will be designed as loosely coupled and highly granular using a component based development process.

• Design applications for platform independence.


Full Principle Example

• “All solutions must conform to common, enterprise interoperability standards”

– Everyone responsible for developing new IT solutions is required to use standard facilities to ensure

interoperability with other legacy and any newly designed solutions

• Rationale

– To support the “single view of the customer” direction, to freely exchange information, and to permit the agility

necessary to redesign business processes, all solutions must be implemented on a single, standard

interoperability framework

• Implications

– Compromises will be needed from line-of-business development units to adopt enterprise solutions rather than

custom solutions

– In some instances, the cost of adopting a standard solution may be greater than adopting a specialized solution

– Standard data definitions must be established

– Standard message formats and semantics must be agreed to and implemented


Modeling

• Models have a variety of characteristics determined by:

– Audience

– Purpose (communication vs. analysis)

– Level of detail (enterprise different from project level of detail)

• Don‟t model for the sake of modeling

– Are you modeling something that is likely to change? Why capture

great levels of detail?

– Are you modeling potential future state? What level of detail is

appropriate given the unknowns?

• Increased maturity demands simplification of more complex

relationships (depth and breadth)


EA Future State Development Context

Value

Network

Analysis

Business

Scenario

Models

Information

Value Chain

Analysis

Business

Event

Analysis

Function/

Process

Decomposition

Integration

Models

Services Level

Enterprise Solutions Architecture

Enterprise Technology Architecture

Enterprise Information Architecture

Enterprise Business Architecture

Capabilities Level





Scenario Level





“The Big Picture”




Enterprise Business ArchitectureEnterprise

Business

Strategy

Enterprise

Intelligence

Service

Catalog

Solutions

Portfolio

Enterprise

Principles

(CA)

Required

Capabilities

(CRV)

Use

Cases

Context

Diagrams

Swimlane

Diagrams

Service

Function

Models

IT

Standards

EA Focus

EA Focus

EA/Project Focus

Project Focus


Modeling Summary

• While the science (standard notation, terminology, use-

cases, etc.) is growing, there is more art the higher the level

you are modeling at

– Standards like UML, BPMN, BPEL are continuing to gain

momentum, but they are closer to the developer

• Finding ways to get other parts of the organization to

contribute both current and future state models to the EA

Repository is critical

– EA must take responsibility for stewarding modeling tools,

approaches, standards, naming conventions, metadata from top to

bottom

• Use the HL Strategic Context Models to direct/prioritize the

areas in which to invest more detailed modeling effort