EA Fundamentals:

Core Concepts, Best Practices, & Winning Approaches

Tim Westbrock & George Paras Managing Directors twestbrock@eadirections.com gparas@eadirections.com June 15, 2010

EAdirections 2010. All Rights Reserved.

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.

EAdirections 2010. All Rights Reserved.

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

EAdirections 2010. All Rights Reserved.

Question

What do you think of when you hear the term Enterprise Architecture?

EAdirections 2010. All Rights Reserved.

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 longerterm focused, but still must be integrated with other architecture disciplines

Enterprise Strategy Enterprise Architecture Bus Arch

Project 1

Info Arch
Project 2

App Arch
...

Tech Arch
Project n

EAdirections 2010. All Rights Reserved.

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?

Strategy

Business Operations Business Solutions

Business Information

IT Infrastructure

EAdirections 2010. All Rights Reserved.

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

EAdirections 2010. All Rights Reserved.

EA Challenge of Overcoming the Inhibitors

Business Strategy

Inhibitors:
Complexity Rate of Change Misalignment of Operations from Business Strategy Enterprise vs. Project Perspective Limited Reuse/Reusability

Current Objectives

Processes

How can we:

Reduce Complexity Decrease Delivery Time Align Business Strategy and Operations Reconcile Enterprise and Project Perspectives and Increase Reuse and Reusability?
8

Data & Information

Systems & Infrastructure

EAdirections 2010. All Rights Reserved.

So What Is This Thing Called EA?

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.

EAdirections 2010. All Rights Reserved.

Driving Business Transformation

Roadmaps & Lifecycles

Business Vision & Strategy

EA Creation

Business Value

Bus.

Info.

Transformation
through Asset Portfolio Improvements, Retirements, Consolidations, Rationalizations, etc. Tech. Sol.

Future State Transformed Enterprise

Bus. Info.

Transformation
Tech. Sol. through New Business Projects

Current State

Time
EAdirections 2010. All Rights Reserved.

10

Driving Business Transformation

Roadmaps & Lifecycles

Business Vision & Strategy

EA Creation

Business Value

Portfolio Transformation
Bus.
through Asset Portfolio Improvements, Retirements, Consolidations, Rationalizations, etc.

Strategic Direction
Info.

Transformation

Tech.

Sol.

Bus.

Info.

Future State Transformed Enterprise

Tech.

Sol.

through New Business Projects

Transformation

Current State

Project Support

Time
EAdirections 2010. All Rights Reserved.

11

Enterprise Architecture Development (HL)

Enterprise Business Strategy

Identify Business Vision Identify Strategic Capabilities Define Enterprise Principles Determine Future State Identify & Analyze Gaps Conduct Impact Analysis

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

Develop Transformation Roadmap

Comparison to Current State Linkage to Project Portfolio Lifecycle, Evolutionary

Transformation Roadmap

EAdirections 2010. All Rights Reserved.

12

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 Dont be afraid to create multiple versions of an artifact aimed at different audiences
EAdirections 2010. All Rights Reserved.

13

What Senior Execs Dont Want to See

EAdirections 2010. All Rights Reserved.

14

Or This

EAdirections 2010. All Rights Reserved.

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.
Company ABC
High Level Functional Hierarchy
1.0 Marketing 2.0 Sales 3.0 Engineering 4.0 Operations 5.0 Finance & Administration

1.1 Public Relations & Communications

1.3 Marketing Ops & Lead Generation

1.2 Advertising & Brand Management

2.1 Prospecting & Lead Management

3.2 Product Development & Design

2.4 Sales Negotiations & Contracts

3.1 Research & Development

5.7 Information Systems (IT)

5.2 Accounts Recievable

3.3 Product Engineering

5.4 Financial Reporting

5.6 Human Resources

5.3 Accounts Payable

4.5 Customer Service

2.3 Sales Proposals

4.2 Manufacturing

5.5 Internal Audit

4.1 Procurement

2.2 Qualification

5.1 Purchasing

4.3 Inventory

4.4 Shipping

4.6 Returns

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.

Company ABC's Information Systems

LEGEND

System function

EAdirections 2010. All Rights Reserved.

16

5.8 Legal

EA becomes the driver of EPfM

Executive Management
Annual, Tactical Goals, Objectives & Targets Business Strategy

Enterprise Architecture
Input

New/Changed Capabilities Required

Models of the Current State Enterprise

Tactical Project Requests Populate

Models of the Future State Enterprise

Existing Operations
New/Changed Capabilities Delivered

Project Portfolio Mgt.

EA Roadmap Project Requests Adds/Changes to Applications, Infrastructure, Information, & Business Processes Timeline/Interdependencies

Represents

Project A
CLIENT (Service Requestor) Standard Service Request Service Provider WORK Standard Service Response

Project B
CLIENT (Service Requestor) Standard Service Request Service Provider WORK Standard Service Response

Project C
CLIENT (Service Requestor) Standard Service Request Service Provider Standard ServiceWORK Response CLIENT (Service Requestor) Standard Service Request Service Provider Standard ServiceWORK Response

Transforms

G O V E R N A N C E

Object

Object

Object

Object Object Object

Build & Integrate

Object Object Object

Build & Integrate

Object Object Object

Build & Integrate

Object Object Object

Object

EAdirections 2010. All Rights Reserved.

17

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

EAdirections 2010. All Rights Reserved.

18

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

Executive Steering Committee Architecture Council Issue Resolution Groups

CIO

Decisions get escalated to Steering Committee from Architecture Council Architecture Council EA Core Team
EA Core Team is represented on ARB

EA Core Team

EPMO

Domain Team (s)

EPMO takes on responsibility for EA compliance checks within SDLC

EAdirections 2010. All Rights Reserved.

19

EA vs. Subject Area Architect vs. Project Architect

Subject Areas Projects

Tech Arch

Facilitates FEEDBACK

Enterprise Architecture

Enterprise Strategy

Provides
Strategic Context Best Practices Research Guidance Leadership

Principles Standards Design Patterns Integration Approach Models

App Arch

Info Arch

FEEDBACK Collaborates
Project Design Tech Selection Service Design Integration Design Models

Interpreted By

Collaborates
Principles Standards Patterns Policy Models Services Needed

Bus Arch

Consults / Advises / Reviews FEEDBACK

EAdirections 2010. All Rights Reserved.

Project 1
20

Project 2

...

Project n

Provides

Governance Best Practices - Approval

Authority Flows Down
Must be granted, cannot be assumed EA Team has none

EA Approval Stages
Perform Analysis
Domain Team (s)

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

Make Recommendation

EA Core Team

Meeting Frequency

Areas of Responsibility
ESC vs. Architecture Council Escalation Rules

Review & Deny or Approve

Architecture Review Board

Formal Sign-off Ceremony Publish Results

Escalation

Executive Steering Committee

EAdirections 2010. All Rights Reserved.

21

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

EAdirections 2010. All Rights Reserved.

22

Governance Best Practices - Compliance

EA Team Informs/Advises Process
PROACTIVE - Coaches/Consults Project Teams EARLY Examines Projects for Compliance and identifies noncompliance concerns No Authority to Grant Exceptions
Informs EPMO of concerns/implications

Project Life Cycle Gates

Project Proposal

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

HL Design Review

EA Team uses results of process to improve EA Content Metrics kept by EPMO, analyzed by EA Core Team

Detailed Design Review

Post-Project

EAdirections 2010. All Rights Reserved.

23

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 EAdirections 2010. All Rights Reserved.

24

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

EAdirections 2010. All Rights Reserved.

25

 EAdirections 2010. All Rights Reserved.

26

About EAdirections
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

Tim Westbrock

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 Do

George S. Paras

Subscribe to our Newsletter: http://eepurl.com/bQ4_

www.EAdirections.com
27

EAdirections 2010. All Rights Reserved.

Our Approach Build Effective EA Organizations

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

Assessing Activities & Review Deliverables

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

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.
Company ABC
High Level Functional Hierarchy
1.0 Marketing
1.1 Public Relations & Communications 1.3 Marketing Ops & Lead Generation 1.2 Advertising & Brand Management 2.1 Prospecting & Lead Management

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
28

2.0 Sales
2.4 Sales Negotiations & Contracts

3.0 Engineering
3.2 Product Development & Design

4.0 Operations

5.0 Finance & Administration

3.1 Research & Development

5.7 Information Systems (IT)

5.2 Accounts Recievable

3.3 Product Engineering

5.4 Financial Reporting

5.6 Human Resources

5.3 Accounts Payable

4.5 Customer Service

2.3 Sales Proposals

4.2 Manufacturing

5.5 Internal Audit

4.1 Procurement

2.2 Qualification

5.1 Purchasing

4.3 Inventory

4.4 Shipping

4.6 Returns

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.

Company ABC's Information Systems

LEGEND

System function

EAdirections 2008. All Rights Reserved.

13

EAdirections 2010. All Rights Reserved.

5.8 Legal

APPENDIX

Additional Slides

EAdirections 2010. All Rights Reserved.

29

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

EAdirections 2010. All Rights Reserved.

30

What Does a Principle Look Like?

Principles vs. best practices: Whats the difference? A principle is:
Title Short description Rationale/justification Implications Title: CA Principle
Description: A bit more

detail

Evaluating principles
Treat as a set, not just as individual principles Resolving conflicts

Rationale: Why is this

important, and why does it support the requirements? this mean to the organization? What happens if you do, or do NOT, do this?

Implications: What does

EAdirections 2010. All Rights Reserved.

31

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.

EAdirections 2010. All Rights Reserved.

32

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

Rationale

Implications

EAdirections 2010. All Rights Reserved.

33

Modeling
Models have a variety of characteristics determined by:
Audience Purpose (communication vs. analysis) Level of detail (enterprise different from project level of detail)

Dont 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)

EAdirections 2010. All Rights Reserved.

34

EA Future State Development Context

Enterprise Intelligence Enterprise Business Strategy
Enterprise Solutions Architecture

Enterprise Technology Architecture

Enterprise Information Architecture Enterprise Business Architecture

Value Network Analysis

Information Value Chain Analysis Context Diagrams

EA Focus

The Enterprise Solutions Architecture Big Picture

Enterprise Technology Architecture Enterprise Information Architecture Enterprise Business Architecture

Required Capabilities (CRV) Enterprise Principles (CA)

EA Focus

Scenario Level Architecture Enterprise Solutions

Enterprise Technology Architecture Enterprise Information Architecture

Business Scenario Models

Business Event Analysis Function/ Process Decomposition IT Standards

Swimlane Diagrams EA/Project

Enterprise Business Architecture

Focus

CapabilitiesSolutions Architecture Level Enterprise

Enterprise Technology Architecture Enterprise Information Architecture

Integration Models Service Project Function Focus Models

Enterprise Business Architecture

Service Catalog Use Cases

Services Level

Solutions Portfolio

EAdirections 2010. All Rights Reserved.

35

Modeling Summary
While the science (standard notation, terminology, usecases, 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

EAdirections 2010. All Rights Reserved.

36