1.
<ul><li>Greg Sparks </li></ul><ul><li>Director of IT Strategy & Architecture </li></ul><ul><li>Level 3 Communications </li></ul><ul><li>Enterprise Architecture Governance </li></ul>Welcome to Transformation and Innovation 2007 The Business Transformation Conference Welcome

2.
Contents <ul><li>What is Enterprise Architecture Governance? </li></ul><ul><li>Organization </li></ul><ul><li>Strategy and Architecture </li></ul><ul><ul><li>Definition </li></ul></ul><ul><ul><li>Alignment </li></ul></ul><ul><ul><li>Examples </li></ul></ul><ul><li>Compliance </li></ul><ul><ul><li>Criteria </li></ul></ul><ul><ul><li>Process </li></ul></ul><ul><ul><li>Compliance Levels </li></ul></ul>

3.
Enterprise Architecture Governance Defined <ul><li>Key Elements of Architecture Governance </li></ul><ul><li>Organization </li></ul><ul><ul><li>Executive sponsorship team </li></ul></ul><ul><ul><li>Cross-functional architecture core team </li></ul></ul><ul><li>Strategies & Architectures </li></ul><ul><ul><li>Define and maintain guiding principles, strategic end-state architectures, and roadmaps </li></ul></ul><ul><ul><li>Ensure alignment across Product, Process, IT, and Network </li></ul></ul><ul><li>Compliance Processes </li></ul><ul><ul><li>Ensure development initiatives are in alignment with guiding principles and target architectures </li></ul></ul><ul><ul><li>Provide holistic view of enterprise architecture so that individual initiatives are evaluated based on long-term contributions in addition to tactical benefits </li></ul></ul>Enterprise Architecture Governance is the structure by which an enterprise defines appropriate strategies and ensures development alignment with those strategies

4.
Organization

5.
Organization <ul><li>Executive Sponsorship </li></ul><ul><ul><li>Not just an IT responsibility </li></ul></ul><ul><ul><li>Steering Committee </li></ul></ul><ul><li>EAG Core Team / Working Groups </li></ul><ul><ul><li>Architects and Development Leads </li></ul></ul><ul><ul><li>Overall responsibility for EAG development and execution </li></ul></ul><ul><li>Accountability </li></ul><ul><ul><li>Strategy definition </li></ul></ul><ul><ul><li>Compliance process execution </li></ul></ul><ul><ul><li>Compliance review board </li></ul></ul><ul><li>A Culture of EAG </li></ul>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

6.
Strategy and Architecture

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

8.
Strategy Overview <ul><li>Guiding Principles </li></ul><ul><ul><li>Architectural values that drive End States and provide criteria for evaluating projects </li></ul></ul><ul><ul><li>Examples: </li></ul></ul><ul><ul><ul><li>Cost Efficient, Flexible, Manageable, Customer Focused, Reliable, Usable, Scalable, Secure </li></ul></ul></ul><ul><li>Layered Architecture Approach </li></ul><ul><ul><li>Layers of architecture provide varying levels of detail, from high level domain frameworks to low level, implementation-specific views </li></ul></ul><ul><li>Strategic End States </li></ul><ul><ul><li>Define the target architecture by process / system domain or network layer </li></ul></ul><ul><ul><li>Architecture Layer 2: Domain Strategy </li></ul></ul><ul><li>Roadmaps </li></ul><ul><ul><li>Define steps to achieve strategic end state from current state </li></ul></ul><ul><ul><li>Document synchronization points and dependencies across Product, Process, IT, and Network areas </li></ul></ul>IT Network Process

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

10.
Layers of IT Application Architecture <ul><li>Implementation layer </li></ul><ul><li>Specific technologies </li></ul><ul><li>System components, technical architecture </li></ul><ul><li>Implementation layer </li></ul><ul><li>System names </li></ul><ul><li>Specific transactions, data attributes and technologies </li></ul><ul><li>System names </li></ul><ul><li>Data concepts (e.g., Customer, Order) </li></ul><ul><li>No technologies </li></ul><ul><li>Strategy Definition Layer </li></ul><ul><li>Can have variation by product (if required by process flows) </li></ul><ul><li>No system names or technologies </li></ul><ul><li>Very seldom changes </li></ul><ul><li>No system names, product variation, or technologies </li></ul><ul><li>High level functional areas only </li></ul>Scope Dev Teams <ul><li>System specific transactions, interfaces, and data attributes </li></ul>Layer 4 Interface and Transaction Specifications Ownership Description Dev Teams / Architects <ul><li>High level business process flows through specific systems </li></ul>Layer 3 Functional Flows (aka Neighborhood) Dev Teams <ul><li>System specific architecture and roadmap </li></ul>Layer 5 System Architecture Specification Architects / Dev Teams <ul><li>Intra-domain functional definition and high level cross-function interactions </li></ul>Layer 2 Domain Strategy Architects <ul><li>Highest level domains with specific high level functions in each domain </li></ul>Layer 1 Detailed Frameworks Architects <ul><li>Highest level functional domains for systems </li></ul>Layer 0 High Level Frameworks

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

12.
Example: Layer 2 Application Architecture Trouble Management <ul><li>Network/Element Mgmt & Network Model </li></ul><ul><ul><li>Layer, device or technology-specific solutions </li></ul></ul><ul><li>Activation Mgmt </li></ul><ul><li>Fault Mgmt </li></ul><ul><ul><li>Presentation & management for alarms </li></ul></ul><ul><li>Performance Mgmt </li></ul><ul><ul><li>Data analysis, trending & reporting. </li></ul></ul><ul><li>Security Mgmt </li></ul><ul><li>Usage Data Collection </li></ul><ul><ul><li>Collect & provide normalized usage data </li></ul></ul><ul><li>Trouble Mgmt </li></ul><ul><ul><li>Ticket Mgmt </li></ul></ul><ul><ul><li>Change Mgmt </li></ul></ul><ul><ul><li>Contact & Notification Mgmt </li></ul></ul>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

13.
Compliance

14.
Compliance Overview <ul><li>Goals </li></ul><ul><ul><li>Enable Portfolio Management to make the best decisions </li></ul></ul><ul><ul><li>Ensure development initiatives adhere to guiding principles </li></ul></ul><ul><ul><li>Ensure development initiatives are in line with strategic roadmaps and end states </li></ul></ul><ul><ul><li>Ensure benefits and costs of programs / projects are considered holistically </li></ul></ul><ul><li>Components </li></ul><ul><ul><li>Compliance criteria </li></ul></ul><ul><ul><li>Rating system </li></ul></ul><ul><ul><li>Compliance processes </li></ul></ul>

15.
Defining the Compliance Criteria <ul><li>Guiding Principles provide the values and context used in Compliance Criteria </li></ul><ul><li>Examples: </li></ul><ul><ul><li>Cost Efficient </li></ul></ul><ul><ul><li>Flexible </li></ul></ul><ul><ul><li>Reliable </li></ul></ul><ul><ul><li>Usable </li></ul></ul><ul><ul><li>Scalable </li></ul></ul><ul><ul><li>Secure </li></ul></ul><ul><li>Specific Compliance Criteria questions and defined responses provide for objective project assessments </li></ul><ul><li>Examples: </li></ul><ul><ul><li>Does solution enforce strong data integrity guardrails? </li></ul></ul><ul><ul><li>Is the solution unnecessarily product-specific? </li></ul></ul><ul><li>Compliance Criteria can then be applied to appropriate checkpoints in the development process </li></ul><ul><li>Detail of Compliance Criteria should be appropriate to point of assessment within lifecycle </li></ul>

16.
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 <ul><li>Systems must rapidly adapt to changing business strategies, processes and technologies. </li></ul><ul><li>System components should be functionally-based and support multiple products and customers. </li></ul><ul><li>The architecture will place a premium on Data Integrity. </li></ul><ul><li>Applications must be highly available, scalable, and secure. </li></ul><ul><li>The user experience will be simple and efficient. </li></ul><ul><li>Workflows will be automated and manageable. </li></ul><ul><li>Maximize the value provided by off-the-shelf software. </li></ul><ul><li>The architecture will consider the long-term costs of ownership. </li></ul><ul><li>The architecture will maximize developer efficiency. </li></ul>The following Guiding Principles define the values which drive architecture end states and provide the criteria for architecture compliance processes.

17.
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 <ul><li>Processes will be easy to understand and maintain. </li></ul><ul><li>Processes will be designed to isolate function and be independent of skill set. </li></ul><ul><li>Processes will focus on automation. </li></ul><ul><li>Processes will be designed for completeness. </li></ul><ul><li>Processes will adhere to common steps and workflows. </li></ul><ul><li>Processes will be measurable. </li></ul><ul><li>Processes will enable people to optimize their performance. </li></ul>CUSTOMER FOCUSED The processes will focus on customer satisfaction <ul><li>Minimize customer touch points. </li></ul><ul><li>Processes will serve as a competitive differentiator. </li></ul>The following Guiding Principles define the values which drive architecture end states and provide the criteria for architecture compliance processes.

18.
Example: IT Compliance Criteria COST EFFICIENT The architecture will seek to minimize “all in” cost <ul><li>Predefined responses provide for a more objective assessment and for more consistency across projects </li></ul><ul><li>Ensure the criteria drive behaviors to accomplish the desired end states </li></ul><ul><ul><li>Don’t allow compliance criteria to become too burdensome! </li></ul></ul>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?

19.
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 <ul><li>Strategic </li></ul><ul><li>Compliant </li></ul><ul><li>Partially Compliant </li></ul><ul><li>Noncompliant </li></ul><ul><li>Strategic </li></ul><ul><li>Compliant </li></ul><ul><li>Partially Compliant </li></ul><ul><li>Noncompliant </li></ul>

20.
Levels of Compliance Guiding Principles / Roadmaps Project Specification/ Scope <ul><li>Proceed </li></ul>Directly accomplishes architecture objectives or helps realize architecture roadmaps. Strategic <ul><li>Proceed </li></ul>Conforms to all relevant architecture principles and roadmaps. Fully Compliant <ul><li>Proceed </li></ul><ul><li>Realign </li></ul><ul><li>Postpone </li></ul>Generally conforms to architecture principles and roadmaps, but is nonconforming in in some area. Partially Compliant <ul><li>Realign </li></ul><ul><li>Cancel </li></ul>In a significant aspect, the project does not conform to architecture principles or roadmaps. Non-compliant Possible Recommen-dations Description Compliance Level

21.
Summary <ul><li>Successful Enterprise Architecture Governance will… </li></ul><ul><ul><li>Provide an architecture framework from which to build and operate the entire enterprise </li></ul></ul><ul><ul><li>Ensure appropriate strategies are created and aligned across relevant departments </li></ul></ul><ul><ul><li>Provide a compliance process to ensure development initiatives support the defined strategies </li></ul></ul>

22.
Thank Y <ul><li>Greg Sparks </li></ul><ul><li>Director of IT Strategy & Architecture </li></ul><ul><li>Level 3 Communications </li></ul><ul><li>Contact Information: </li></ul><ul><li>[email_address] </li></ul>ou Thank Y ou