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

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 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 Successful Enterprise Architecture Governance will… Provide an architecture framework from which to build and operate the entire enterprise Ensure appropriate strategies are created and aligned across relevant departments Provide a compliance process to ensure development initiatives support the defined strategies

Thank Y Greg Sparks Director of IT Strategy & Architecture Level 3 Communications Contact Information: [email_address] ou Thank Y ou

Enterprise Architecture Governance: A Framework for Successful Business

More Related Content

What's hot (20)

Similar to Enterprise Architecture Governance: A Framework for Successful Business (20)

More from Nathaniel Palmer (20)

Recently uploaded (20)

Enterprise Architecture Governance: A Framework for Successful Business