Enterprise Architecture Governance: A Framework for Successful Business

Greg Sparks

Director of IT Strategy & Architecture

Level 3 Communications

Enterprise Architecture Governance

Welcome to Transformation and Innovation 2007 The Business Transformation Conference Welcome

Contents

What is Enterprise Architecture Governance?

Organization

Strategy and Architecture

Definition

Alignment

Examples

Compliance

Criteria

Process

Compliance Levels

Enterprise Architecture Governance Defined

Key Elements of Architecture Governance

Organization

Executive sponsorship team

Cross-functional architecture core team

Strategies & Architectures

Define and maintain guiding principles, strategic end-state architectures, and roadmaps

Ensure alignment across Product, Process, IT, and Network

Compliance Processes

Ensure development initiatives are in alignment with guiding principles and target architectures

Provide holistic view of enterprise architecture so that individual initiatives are evaluated based on long-term contributions in addition to tactical benefits

Enterprise Architecture Governance is the structure by which an enterprise defines appropriate strategies and ensures development alignment with those strategies

Organization

Executive Sponsorship

Not just an IT responsibility

Steering Committee

EAG Core Team / Working Groups

Architects and Development Leads

Overall responsibility for EAG development and execution

Accountability

Strategy definition

Compliance process execution

Compliance review board

A Culture of EAG

CEO/ COO IT Network (Eng.) Ops Product IT Archs Network Archs Process Designers PD / PM Accountability Examples Core Team / Governance Board Executive Team Development, Operations, Engineering Strategies, Roadmaps Compliance Investment decisions Strategic Opportunities

Strategy and Architecture

The Scope of EAG: The Enterprise! Corporate Strategy defines what the company will be and how it will compete Competitive advantages Wholesaler / Retailer Low Cost / High End Domestic / International Centralized / Regional Control Corporate Strategy Product Strategy Product Strategy defines what the company sells and how it sells it Product lines and features Market and industry analysis Differentiation Volume Functional Strategies define how to operate the company, based on Corporate and Product inputs Guiding Principles End State Architectures & Roadmaps Functional Alignment Functional Strategies Process Network IT Tactical Plans & Execution Implementation processes and tracking mechanisms Investment Prioritization Compliance process execution and reporting

Strategy Overview

Guiding Principles

Architectural values that drive End States and provide criteria for evaluating projects

Examples:

Cost Efficient, Flexible, Manageable, Customer Focused, Reliable, Usable, Scalable, Secure

Layered Architecture Approach

Layers of architecture provide varying levels of detail, from high level domain frameworks to low level, implementation-specific views

Strategic End States

Define the target architecture by process / system domain or network layer

Architecture Layer 2: Domain Strategy

Roadmaps

Define steps to achieve strategic end state from current state

Document synchronization points and dependencies across Product, Process, IT, and Network areas

IT Network Process

Architecture Alignment by Layer IT Network Layer 0 Layer 1 Layer 2 Layer 3 Domain Framework Domain Strategy Functional Flows Product The EAG Deliverables are aligned by layer across Product, Process, IT & Network Process

Layers of IT Application Architecture

Implementation layer

Specific technologies

System components, technical architecture

Implementation layer

System names

Specific transactions, data attributes and technologies

System names

Data concepts (e.g., Customer, Order)

No technologies

Strategy Definition Layer

Can have variation by product (if required by process flows)

No system names or technologies

Very seldom changes

No system names, product variation, or technologies

High level functional areas only

Scope Dev Teams

System specific transactions, interfaces, and data attributes

Layer 4 Interface and Transaction Specifications Ownership Description Dev Teams / Architects

High level business process flows through specific systems

Layer 3 Functional Flows (aka Neighborhood) Dev Teams

System specific architecture and roadmap

Layer 5 System Architecture Specification Architects / Dev Teams

Intra-domain functional definition and high level cross-function interactions

Layer 2 Domain Strategy Architects

Highest level domains with specific high level functions in each domain

Layer 1 Detailed Frameworks Architects

Highest level functional domains for systems

Layer 0 High Level Frameworks

Example: Layer 1 Application Architecture Portals / Gateways Sales & Marketing Customer Interaction Finance Business Intelligence Product Mgmt Corporate Service Assurance Service Delivery Channel Mgmt Leads Mgmt Sales Force Mgmt Campaign Mgmt Quoting Customer Risk Mgmt Billing Accounting Revenue Assurance Mediation & Rating Vendor Billing Reconciliation Contact Mgmt Customer Mgmt Order Entry Trouble Tracking Order Mgmt Service Image Workforce Mgmt Capacity Planning Inventory Assign & Design Vendor Order Mgmt Provisioning Interconnection Activation Mgmt Fault Mgmt Usage Data Collection Network / Element Mgmt Trouble Mgmt Service Level Mgmt Performance Mgmt Testing & Diagnostics Corporate Data Warehouse Decision Support Systems Reporting Asset Mgmt Human Resources Tax & Regulatory Legal Product Catalog Portal B2B Gateway Corp Governance Document Mgmt

Example: Layer 2 Application Architecture Trouble Management

Network/Element Mgmt & Network Model

Layer, device or technology-specific solutions

Activation Mgmt

Fault Mgmt

Presentation & management for alarms

Performance Mgmt

Data analysis, trending & reporting.

Security Mgmt

Usage Data Collection

Collect & provide normalized usage data

Trouble Mgmt

Ticket Mgmt

Change Mgmt

Contact & Notification Mgmt

Rating IP Transport & Infrastructure SoftSwitch Portal 7 Service Image Activation Management Network/Element Management Usage Data Collection Performance Management 1 2 4 6 Fault Management Security Management 3 5 Capacity Planning

Compliance

Compliance Overview

Goals

Enable Portfolio Management to make the best decisions

Ensure development initiatives adhere to guiding principles

Ensure development initiatives are in line with strategic roadmaps and end states

Ensure benefits and costs of programs / projects are considered holistically

Components

Compliance criteria

Rating system

Compliance processes

Defining the Compliance Criteria

Guiding Principles provide the values and context used in Compliance Criteria

Examples:

Cost Efficient

Flexible

Reliable

Usable

Scalable

Secure

Specific Compliance Criteria questions and defined responses provide for objective project assessments

Examples:

Does solution enforce strong data integrity guardrails?

Is the solution unnecessarily product-specific?

Compliance Criteria can then be applied to appropriate checkpoints in the development process

Detail of Compliance Criteria should be appropriate to point of assessment within lifecycle

Example: IT Guiding Principles FLEXIBLE The architecture will be able to support dynamic business needs quickly RELIABLE The systems must be dependable USABLE The systems will be easy to use and will automate as much as possible COST EFFICIENT The architecture will seek to minimize “all in” cost

Systems must rapidly adapt to changing business strategies, processes and technologies.

System components should be functionally-based and support multiple products and customers.

The architecture will place a premium on Data Integrity.

Applications must be highly available, scalable, and secure.

The user experience will be simple and efficient.

Workflows will be automated and manageable.

Maximize the value provided by off-the-shelf software.

The architecture will consider the long-term costs of ownership.

The architecture will maximize developer efficiency.

The following Guiding Principles define the values which drive architecture end states and provide the criteria for architecture compliance processes.

Example: Process Guiding Principles FLEXIBLE The processes will be able to support dynamic business needs quickly COST EFFICIENT The processes will be designed to minimize unit cost MANAGEABLE The process will be measured for quality purposes

Processes will be easy to understand and maintain.

Processes will be designed to isolate function and be independent of skill set.

Processes will focus on automation.

Processes will be designed for completeness.

Processes will adhere to common steps and workflows.

Processes will be measurable.

Processes will enable people to optimize their performance.

CUSTOMER FOCUSED The processes will focus on customer satisfaction

Minimize customer touch points.

Processes will serve as a competitive differentiator.

The following Guiding Principles define the values which drive architecture end states and provide the criteria for architecture compliance processes.

Example: IT Compliance Criteria COST EFFICIENT The architecture will seek to minimize “all in” cost

Predefined responses provide for a more objective assessment and for more consistency across projects

Ensure the criteria drive behaviors to accomplish the desired end states

Don’t allow compliance criteria to become too burdensome!

Will this solution require support personnel outside of the normal break-fix support? Is the solution focused on long term costs appropriately with respect to near-term gains? For COTS solutions, does the project approach adhere to development and implementation standards for the COTS application? Have both custom and COTS solutions been considered? Does the proposed project fill in existing functional gaps while leveraging existing infrastructure wherever possible?

Compliance Process Ideation Elaboration Inception Construction Educate Categorize Participate Projects Validate Inform business units of guiding principles and roadmaps Evaluate projects; realign as necessary Participate and/or check-point solution design Checkpoint with implementation team EAG Actions: Ensure architectural principles and roadmaps are understood Identify projects that will require architecture participation Ensure solutions adhere to principles and roadmaps Ensure solution implementation is in line with design EAG Goal: End States & Roadmaps None Project Rating and Recommendation Project Rating and Recommendation EAG Outputs: Project Rating and Recommendation Guiding Principles Realign Realign Gate Gate Gate Gate Development Process

Strategic

Compliant

Partially Compliant

Noncompliant

Strategic

Compliant

Partially Compliant

Noncompliant

Levels of Compliance Guiding Principles / Roadmaps Project Specification/ Scope

Proceed

Directly accomplishes architecture objectives or helps realize architecture roadmaps. Strategic

Proceed

Conforms to all relevant architecture principles and roadmaps. Fully Compliant

Proceed

Realign

Postpone

Generally conforms to architecture principles and roadmaps, but is nonconforming in in some area. Partially Compliant

Realign

Cancel

In a significant aspect, the project does not conform to architecture principles or roadmaps. Non-compliant Possible Recommen-dations Description Compliance Level

Summary