CMAD Group Workbook 7 Governance

11

Authored by: Alexander Doré August 14, 2010

Workbook 6

Architecture Services Mobilization Transparent Governance

Business Architecture Program Business Enterprise Architecture Governance (BEAG)

Confidential

C-MAD Group Inc Computer Science & Engineering Architecture Consulting Services

22

Objective

To delineate two instruments to implement transparent governance…

•  To define a flexible and adaptable transparent governance-lean framework by adopting an Enterprise Architecture Governance Strategy (EAGS).

•  To establish Business Enterprise Architecture Governance Program (BEAGP) Group driven by best practices to execute the Enterprise Architecture Governance Strategy (EAGS).

•  Workbook Sections •  EAGS Framework •  BEAGP Approach to executing EAGS •  EAGS Executive Summary, Process Integration, Metrics and

KPI Appendix

33

1

Governance EAGS Framework

44

EAGS Framework

Critical constituents of a successful EAGS effort: –  Leadership (Alcatel-Lucent US) –  Organization (limited) –  Investment (value proposition TBD) –  Processes (UML, RUP, Agile) –  Policies & Principals (Lean) –  Measurements (TBD) –  Enabling Tools (SAP)

55

EAGS Framework - Components 1 EA Governance Framework

Governance Component Architecture Sub-component Scope

Leadership: TBD •  TBD

Organization: Operating Model

•  Definition of architecture roles and responsibilities for project oversight, managing of principles and standards, metrics and reporting

•  Coordination with ITIL •  Engagement model and coordination with project teams

Investment: Communication with Stakeholders

•  Defining the value proposition for stakeholders •  Gain buy-in from stakeholders •  Communicate EA governance roll-out plan

Project Process: Oversight

Issue Escalation & Resolution Process

•  Escalation of issues at the project, program or enterprise level •  Resolution process with clearly defined decision makers

Issue Tracking Process •  Monitoring and managing the status of each issue

Exceptions Approval Process •  Manage the approval process for architecture exceptions

66



Architecture Process: Issue Management

Review & Validation

•  Architecture review at various checkpoints of SDLC. Include adherence to:

–  ALU Technology Standards –  ALU Architecture Patterns –  ALU Architecture reference models

•  Applies to all layers of the architecture, i.e. Information, Application, Integration, Security and Infrastructure

•  Architecture review process across phases of the SDLC for small, medium and large projects - includes templates for each phase

Recommendations •  Documenting solution design recommendations and options •  Provide phasing of architectural solutions and technical

dependencies

Reporting & Monitoring Exceptions

•  Reporting exceptions to architecture standards and seeking approval from the BEA Governance committee

77

EAGS Framework - Components 3

EA Governance Framework Governance Component Architecture Sub-component Scope

Policies, Principals & Standards

Governance Principles

•  Architectural principles, e.g. scalability principle, point-to-point principle, phasing principle, commonality principle, operational / decision support principle

•  Architecture standards across architecture layers, i.e. presentation, application, integration, data, infrastructure and security

•  Architectural patterns, reference models and architectures

Technology Standards •  Technology standards for each architecture layer and

platform (Distributed vs. Mainframe), •  Managing standards across all layers of architecture

Blueprints

•  Model enterprise architecture blueprints (EAP). This includes: –  Enterprise architecture blueprints –  Domain architecture blueprints –  System architecture blueprints

•  Alignment with ALU target state vision •  Managing blueprints from current through interim state

and target state

88



Metrics & Reporting

Issue Management •  Capturing key metrics for issues, e.g. risks by project or program

Governance & Effectiveness •  Capturing metrics around effectiveness of governance,

e.g. exceptions and deferrals, compliance to standards by program/project, Project oversight conducted etc.

Track ROI •  Measures how well architecture investments are made in partnership with business priorities and strategy

Resource Management •  Staffing report showing current and future demand vs. resources at hand

Enabling Tools

Modeling Tool •  Tools to model enterprise architecture blueprints (EAP)

Governance Tool •  Tool used to govern and track architecture issues, project oversight reporting and results of architecture reviews

Metrics & Reporting Tool •  Capturing metrics and reporting effectiveness of EA functions

Resource Management Tool •  Manage architecture resource staffing for projects,

enterprise architecture management (issues mgmt., communication, standards)

SDLC Tool

99 9

Suggested EAGS Discovery Timing

*Timing is estimated since this is a new process Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

Establish High Level EAGS Guiding Principals

Establish Realizable EAGS Process Improvements

Develop EAGS Value Proposition & ROI Strategy

Roll-Out EAGS Time to Market Package

Roll-Out Transitional EAGS Commitment Plan

1

2

3

4

5

1010

Manage Gap from Current State to Target State Light

Build on current state of thinking and practice developing more precise and standardized practices that offer ready reasonableness and mitigate future risk

Evidentiary: In Business Requirements Document Collaborations and Dependencies are not analyzed, Use Cases are not standard, non-functional requirements are absent

Establish a more optimized method of organizing artifacts, documents and models that improve traceability and audit ability and the overall standard of the product

Current State Manageable GAP Target State [LIGHT]

Discovery of Enterprise Architectural tools that offer library reuse, common configuration managed repository and flexibility of model and process management

Evidentiary: Use Cases and Models are not in a library state or stored in a configure managed repository; cohesion and traceability lacking, no plans for systemic tool adoption present

Adoption by key users in the discovery process of tools that economize and improve the overall delivery of the product in the production of blueprints and schedules

Look at meaningful options that improve the overall capability maturity model and ROI

Unknown: Some Artifacts in Evidence; Charter & SDLC docs

Establish guiding principals that improve discovery effectiveness & accuracy and mitigate future risk

EAGS Standards & Principals

EAGS Discovery Practices

EAGS Tool Utilization Adoption

1111

2

Governance EAGS Approach

1212

The objectives of this approach section is to…

!  Define the components of Enterprise Architecture Governance Strategy (EAGS) to be executed by the Business Enterprise Architecture Governance Program (BEAGP)

!  Outline the BEAGP team structure and key responsibilities !  Identify the key points of integration with the ALU operating model and

sub-teams !  Highlight the overall governance process, including key inputs, outputs

and checkpoints !  Identify next steps for mobilizing the BEAG team and EAGS processes

1313

•  Perform oversight of all projects via detailed artifact reviews at key milestones

•  Ensure macro-designs align with blueprints and standards from inception to delivery

EAGS

Enterprise Architecture Governance Strategy (EAGS)

Project Oversight Organization

Enterprise Blueprints

& Standards

Tools

Reporting & Metrics

Arch. Issue Management

•  EA Governance teams’ roles and responsibilities are clearly differentiated

•  Coordinate with migration project teams and the BEAGP to enable several layers of support

•  Provide consistent communication to stakeholders

•  Integrate with BEAGP regarding new strategies and known architecture gaps

•  Coordinate with domain architects to formulate the enterprise standards, governance and compliance bylaws

•  Coordinate with BEAGP to create a systematic approach to ensure projects adhere to EAGS* blueprints and CTO

•  Coordinate with BEAGP and Value Realization Team on metrics and reports that communicate success of delivery against blueprinting goals, benefits, deferrals, exceptions, and actionable information needed to mitigate issues

•  Coordinate with BEAGP on reports that track overall project and program delivery and measure EA effectiveness

•  Leverage standardized architecture issue tracking and escalation processes which are integrated into the projects

•  Approve mitigation for high impact issues, exceptions and deferrals

•  Manage and approve mitigation for low and medium impact issues

•  Enable integrated blueprint and model repository of business and technology architecture that serves as source of truth

•  Enable governance tool that captures EA issues, exceptions and deferrals

•  Provide capabilities to dynamically create EA effectiveness reports

•  Enable review scheduling tools •  Coordinate with demand management on

gate reviews and aggregate oversight demand to gauge staffing

The future state EAGS model incorporates people, processes, tools, reporting and metrics, policies and

standards

* EAGS = Enterprise Architecture Governance Strategy

1414

EAGS reporting will provide transparency into the governance process, enable better stakeholder communications and drive process improvements

Report Frequency Audience Metrics Objective Value Creation Report (Earned Value Scorecard)

Quarterly CTO •  Linkage of business strategy and objectives to strategic technology investments

•  Number of projects involved with each of the primary program goals

•  Spend amount per program goal •  Blueprints value management •  Quantitative view of advancement towards blueprints

Measures how well architecture investments are made in partnership with business priorities and strategy

Risks Report Monthly CTO •  Severe architecture risks per domain and project Measures severity of risks

EAGS Effectiveness Report

Bi-weekly

CTO BEAGP Team Program Leads Tier 1 Leads BEAGP Value Realization Team

•  Number of exceptions and deferrals by domain •  Number of exceptions and deferrals by project •  Percentage of projects with first pass signoff •  Percentage of fully standards- compliant projects •  Reference material revision count •  Reference material revision approval ratio •  Reference material exception/deferral count

Measures project compliance with: •  Enterprise domain standards •  Enterprise blueprints and standards •  Enterprise architecture reference •  Enterprise architecture reference material

use and effectiveness

EAGS Effectiveness Report

Weekly •  Number of oversights conducted per week •  Time required to close issues at each level at each

project at each gate •  Exceptions/ deferrals per project per gate per level •  Average number of days and number of sessions

required to complete oversight and obtain BEAGP signoff per project per gate

Measures effectiveness of BEAG in terms of: •  Project readiness against blueprints •  Project compliance with standards •  Issue resolution efficiency •  Impacts to project delivery schedules

BEAGP Architecture Issues Report

Weekly BEAGP Team Project Leads BEAGP sub-team

•  Architecture issues aging •  Architecture issues opened •  Architecture issues closed

Measures BEAGP effectiveness in discovering and contributing to issue resolution with Level 1 and Level 2 support

EAGS Reporting Overview

1515

A BEAGP team can be 3+ levels & tightly integrated with project delivery efforts

Oversight Escalation Legend EA Governance Level

* EAGS = Enterprise Architecture Governance Strategy, OBA = Operational Business Architecture

OBA* EAGS* Standards

EA & Program Governance

Enterprise Leadership

Project Architecture Governance

BEAG Team

Directly involved in steering components of the operating model, e.g., Integrated Design, Playbook and Execution

Blueprints, Standards & Best Practices

Enterprise Blueprint

Domain Blueprints

System Blueprints

Level 1

Level 2

Level 3

ownership

ownership

Enterprise

Domain

System

Strategy to Implementation

Mobilization Program: Operating Model

Integrated Design Team

PMO

Execution Teams

GovernanceIDT

PMO

PlaybookExecution Teams

Requirements Review

Architecture Review Board

Program Governance

Business Process

Value Realization

Organization & Change Mgmt.

Technology

integration

integration

1616


Governance Board

EA Governance Levels 1 and 2 provide direct support to a Mobilization BEAGP team


Value Management

Design Effectiveness &

Value Mgmt.

Resource Management

Architecture Issue Management

Blueprints & Standards

Management

Artifact & Milestone Signoff

Exec. Reporting, Stakeholder Comm.


Execution Teams

Coordination Goals,

Metrics, Reports, Issues,

Value-based Design Decisions,

Staffing

Coordination Blueprints, Strategies, Standards,

Compliance, Exceptions, Deferrals,

Gaps

Cross- Team

Integration

Value Realization

Team


Domain Architects

Coordination Design

Support, Vendor

Coordination

Oversight Escalation Legend EA Governance Level

Program & Project

Management Teams

BEAGP Team

Design Guidance & Standards

Conformance

Business Architecture

Technology Architecture

Integration & Information Architecture

Migration Teams

Issues, Key Decisions

Issues, Key Decisions

Integrated Design Team BEAGP and project

Execution Teams develop the

architecture artifacts

1717

The BEAG team is involved across the SDLC, and leverages key checkpoints to review and approve artifacts and escalate issues

!  Business Requirement Documents

!  HL design gap mitigation

!  HL business requirements

!  HL design !  HL benefits & cost

estimates

!  Architecture design (Conceptual, Logical and Physical)

!  Value-based design decisions

!  Build documents and specifications

!  Solution build-out !  Design updates

!  Knowledge transfer !  Launch activities

!  Testing plan design !  Test execution

Mobilization Requirements Solution Design Discovery Build Train & Launch Test

BEAGP & Project Execution Teams

Project Arch. Governance



EA Governance Level

!  HL design gap coordination

!  HL design validation !  Design coordination !  Design validation !  Design exceptions !  Issue mitigation

!  Build validation !  Build compliance !  Build exceptions !  Issue mitigation

!  Launch activities !  Test validation and coordination

* HL = high-level

!  Design signoff !  Exception

management

!  Build signoff !  Exception

management

!  Testing signoff !  Technology requirements signoff

!  Key design decision approval

!  Key exception approval

!  Key build decision approval

!  Key exception approval

Legend

Architecture resource and issue management Architecture blueprinting and reporting

Non-SDLC EA Checkpoints

1818

Mob

iliza

tion

Oth

er M

ajor

* Pro

ject

s

Mobilize against approach Execute EA Governance pilot across Mobilization projects

Define EA Governance

approach

Identify major programs ready

for EA Governance

Mobilize Governance for

Project A

Execute EA Governance processes across program

Q4, 2010 Q1, 2011 Q2, 2011 Q3, 2011

BABW Project A

Identify major programs ready

for EA Governance

Mobilize Governance for

key project

Another Key Project Execute …

The BEAGP team can support mobilization and also other projects through staggered engagement

Enterprise Architecture Governance Rollout for Key Enterprise Projects

1919

Summation There are several benefits that will come with embedding and executing EAGS processes using the BEAG team in the Mobilization effort

•  Ensures ongoing alignment with the strategic vision as well as the more tactical enterprise architecture standards by aligning capability delivery

•  Stewards the vision in downstream delivery and manages departures from the vision as well as feedback on what is actually being delivered against the vision as migration solutions are refined into logical and physical design and implemented

•  Plays a crucial role in coordination, especially as there are rapid increases in spending as projects are mobilized

•  Improves ROI by focusing CTO investment on the correctly prioritized projects

•  Forces explicit decision making so that if exceptions are made, they are elective

•  Ensures compliance with CTO standards and best practices

Transparent Enterprise Architecture Governance…

2020

3 A

Effective Governance Enterprise Architecture Governance Strategy (EAGS)

- Executive Summary - Process Integration - Metrics - KPI Appendix

2121

EAGS Objectives Transparent governance ensures alignment of EA decisions with EA business objectives

•  Ensure future-state architecture diagram and roadmap development is aligned with strategy

•  Ensure enterprise and segment views are balanced in future-state architecture diagrams and roadmaps

Align Roadmaps with Strategy

Focus CTO Investment on the Right Projects

Ensure EAGS Compliance During Delivery

Provide Exception Mechanism for EAGS Issues

•  Incorporate architecture recommendations into CTO funding and project approval processes

•  Ensure funded programs / projects are consistent with future-state architecture diagrams and roadmaps

•  Monitor project delivery to ensure compliance with the agreed-to future-state architecture diagram and roadmap

•  Ensure the right people are involved in the decision making from an enterprise, segment and project perspective

•  Ensure a transparent and consistent exception mechanism for resolution of architectural disputes that cannot be resolved within roadmap or project teams

2222

EAGS Design Elements Transparent governance brings the right people together to make decisions that integrate key investments, delivery processes and metrics

Metrics

Governance Structure Process Integration

! Governance bodies and structure are defined to facilitate effective decision making with minimal administrative burden

! Self-governance on projects

! Exception only as necessary

! Appropriate representation to work issues -- only impacted domains and stakeholders present at meetings

! Required rigor of governance specified based upon architectural impact and financial investment

! Key governance bodies, responsibilities, and scope defined

! Governance must remain transparent in process integration

!  Incorporates architecture governance into existing planning and delivery processes

! Outlines inputs, decision criteria, and outputs for each point

! Pushes decision making down to lowest level of decision right authority

! Enables appropriate balance between enterprise and segment needs through consistent approval and exception processes

! Key metrics monitor effectiveness and enable transparent control of EAGS governance processes through process and outcome metrics

2323

EAGS Key Decision Points EAGS will focus on eight key decision points - outcomes may require updates to be made to the future-state EA or roadmaps

!  Approve business and technology Future-State Architecture

!  Approve roadmaps

!  Capital Planning Portfolio Review Provide architecture recommendation for approval / denial of investments

!  Project Initiation Approve conceptual architecture

!  Approve high-level design !  Approve detailed design !  Validate compliance with post-

implementation review

Exception process

Roadmap Creation Planning Delivery

Development and maintenance of segment and domain roadmaps

Business (BEAGP) and CTO planning of CTO investments

Development of approved CTO solutions

3

4

5 6 7

1

2

8

2424

EAGS Compliance Three levels of governing bodies recommend funding approval, ensure EAGS compliance and approve roadmaps

Responsibility

Approval Level 2 EAGS

EAGS Lead (Chair), Segment and Domain Roadmap Owners,

Architects and Application Owners from Impacted

Segments

Approval Level 1 Project Governance

Project/Program Manager, Delivery Architects

Approval Level 3 CTO Executive Council

IT and Business Leaders

!  Approve prioritization of CTO investments !  Adjudicates on issues that cannot be resolved by Level

2 governance !  Approves policies, future-state architecture diagrams

and standards

!  Recommend funding approval for projects based on alignment to roadmaps and future-state architecture diagrams

!  Approve or reject changes to future-state architecture diagrams and roadmaps

!  Resolves exception issues !  Suggest prioritization of roadmap initiatives

Governance Body

!  Exception issues

Scope

!  Multi-domain and/or multi-segment !  Single domain and/or multi-project !  Exception issues !  Change requests !  Architecture compliance

recommendations during funding

!  Conduct detailed architecture delivery work product reviews for EAGS compliance

! Provides architecture sign off for SDLC gate progression

! Prescribes corrective actions for designs not in compliance

!  Identifies and log architecture issues for Level 1 review and exception

!  Project specific architecture issues !  Does not change roadmap or

Future-State Architecture

2525

EAGS – Engagement Models EAGS will empower decision making at the lowest appropriate level with clearly defined exception mechanisms

Project Delivery Planning Roadmap Creation

!  EAGS governance during roadmap creation has a consistent engagement model across all domains

!  Project Governance (the roadmap project team) provides an initial review and generates a recommendation

!  Enterprise Systems Governance reviews and approves future-state architecture; it reviews roadmaps and generates a recommendation

!  CTO Executive Council reviews future-state architecture on an exception basis, it approves Level 2 roadmap recommendations

!  EAGS governance varies by decision point and project classification

!  Project classification determines the engagement model, the segmentation is based on:

! Project Spend

! Architectural Significance

! Strategic Relevance

!  EAGS governance during planning has a consistent engagement model across all domains

!  Enterprise Systems Governance reviews requests and generates a recommendation, escalating to the CTO Executive Council as necessary

!  CTO Executive Council reviews requests on an exception basis

2626

Notes: (*) Classification is determined by using an “OR” criteria – only one of the

three criteria must be met to warrant the required level of governance

Classification Rationale

Financial > $xx M

Architectural Significance

Strategic Relevance

! Investment, measured by the total project spend, is a proxy for significance to the enterprise

! Higher levels of architectural significance require additional attention (based on cross domain scope and cross segment impact)

! Projects with additional business significance require additional attention: (e.g.; Are required for meeting an external commitment)

Transparency Levels (Increasing need for governance)

End to End Governance

Maximum oversight, thorough

governance, at all gates

Proactive Governance

Moderate oversight, governance at all

gates, but by lower level governance body

Self Governance (Lean)

Provides basic oversight, reviewing projects at

initiation and continued reporting and issue

management

! Creation or major modification of enterprise asset

! Significant cross-domain complexity ! Significant adoption of enterprise

assets expected

! Single domain and/or multi-project complexity

! No enterprise implications

! Project specific architecture

! No segment or domain implications

$xx M – $xx M < $.xx M

! Needed to meet commitments to the street

! Key Initiative ! Major regulatory

impact

! Minor regulatory impact

EAGS -- Delivery Project Classification (*) Projects are classified into varying governance approaches during project delivery

2727

EAGS Engagement -- Required Approval Levels (1) EAGS bodies engage at each decision point as defined by the engagement model and project classification

Level 1 (3)

Planning Decision Points #3,

4

Delivery Decision Points #5, 6,

7

Final Approval

Entry Point

Level 2 Level 2

Level 1

Governance Level

Type of Engagement

End to End

Proactive

Self

Final Approval

Entry Point

Final Approval

Entry Point

Entry Point: Review governance requests, presents recommendation to final approval body; if necessary, escalates decision Final Approval: Final approval body; when same as entry, entry body acts as final approval unless the decision must be escalated

Engagement Type Legend

Note:

(1) Does not represent exception process, only required approvals; (2) Level 2 presents a recommendation to level 3 and level 3 validates; (3) Only applies to decision point #5

Level 1 = Project Governance, Level 2 = Enterprise Systems Governance; Level 3 = CTO Executive Council

Roadmap Creation Decision Points #1,

2

Level 2

Level 3 (2) Level 2

Same as above

Same as above

Same as above

Same as above

2828

Rollout Strategy

EAGS – Process Interfaces and Maturity EAGS will initially focus on “end to end” governance during planning – leveraging mature processes and focusing on high-impact projects

Initial EAGS rollout will focus on roadmap creation and the “end to

end” segment in planning

As governance matures, it will extend to “end to end” delivery

governance and “proactive” planning governance

Over time, EAGS governance will also review the “self” segment

during planning and the “proactive” segment during

delivery

1

2

3

As EAGS is understood in the organization, self governance should propagate to low level

processes 4

Note: Process interfaces are Key ALU processes that interface with EAGS

Planning Decision Points #3,

4

Delivery Decision Points #5, 6,

7

Operational Model process

SDLC, PMO process

Segment Capital Committees SDLC process

SPiCE ISO 15504 SDLC process

Level of Governance

End to End

Proactive

Self

1 2

2 3

3 4

Universal Process – Applies to entire enterprise

Highly Adopted Process – Applies to most segments and domains Fragmented Process – Varies widely

Greater maturity and adoption of process interfaces increases ease of adoption

Process Adoption Legend

Roadmap Creation Decision Points #1,

2

Roadmap Process

1

2929

3 B

Effective Governance Enterprise Architecture Governance Strategy (EAGS)

Executive Summary Process Integration Metrics KPI Appendix

3030

EAGS -- Key Decision Points For each decision point EAGS will define process integration, the decision criteria, and an exception process to ensure that right decisions are made

!  Approve business and technology Future-State Architecture

!  Approve roadmaps

!  Capital Planning Portfolio Review Provide architecture recommendation for approval / denial of investments

!  Project Initiation Approve conceptual architecture

!  Approve high-level design !  Approve detailed design !  Validate compliance with

post-implementation review

Exception process

Roadmap Creation Planning Delivery

Development and maintenance of segment and domain

roadmaps

Business and CTO planning of CTO investments

Development of approved CTO solutions

1

2

3

4

5 6 7

8

Process integration

Decision Criteria

Exception Process

Client processes are referenced to show a clear

integration with EAGS governance

For each decision point, clear inputs, outputs, decision criteria, and

decision process are defined

Process to get the right level of people involved to

approve the final decision or resolve any conflicts

3131

EAGS Roadmap Decision Points At least 2 roadmap decision points ensure Business (BEAG) and CTO

leadership agree with the future-state and proposed plan to get there

! Understand current business environment

!  Identify current pain points and opportunities for improvement

! Capture potential “Quick Win” opportunities

!  Identify Capabilities and Gaps for future success

! Establish strategic direction based on prioritized list of capabilities

! Define target business architecture

!  Identify key technical implications and enablers for target business capabilities

! Define future-state systems architecture based on capabilities and technical enablers

! Understand critical path to reach target architecture

! High-level cost/benefit analysis of initiatives

! Understand plan and transitional architectures along critical path

Portfolio Management

! The proposed roadmap is provided to Portfolio Management for funding approval

! Once funding decisions are made the future-state architecture diagram and roadmaps are updated based on any impacts from those decisions

Business Strategy

Target Vision

Current-State Analysis Future-State Results Roadmap

Strategic Assessment

Business & Technology Future-State Architecture Diagram

Define Initiative Sequences

1 2

Decision Point

! Understand the business strategy and objectives of the enterprise and segments

#

Roadmap Creation

3232

EAGS Roadmap Decision Points - Audit Business (BEAG) and CTO Leadership approve the desired end state after architects validate that the future-state architecture diagrams are reconciled

!  Do the future-state architecture diagrams represent the desired end-state that have been reconciled across the other domain and segment future-state architecture diagrams? Does the business and IT Leadership agree with this desired end-state?

Decision

!  Future-State Business and Technology Future-State Architecture Diagram !  Strategic Assessment Input

!  Business and Technology Future-State Architecture Diagram –  Business and IT leadership approved –  Reconciled across Segments and Enterprise Domains

Output

Decision Criteria

! Business and Technology Future-State Architecture Diagram ! The Future-State Architecture Diagram represents the desired end-state for both business and IT leadership ! The enterprise elements have been identified

! Segment Future-State Architecture Diagram ! Provides a comprehensive view of all domains capabilities, architectural elements and dependencies

! Business and Technology Domain Future-State Architecture Diagram ! The Future-State architecture elements aligns with the objectives defined in the Strategic Assessment ! The business, application, data and technology Future-State Architecture Diagrams are aligned for the business

domain

Business and Technology Future-State Architecture Approval Decision Point

!  Enterprise Domain and Segment Chief Architects !  IT Executive Council Participants

3333

EAGS -- Approve Future-State Governance Decision Point 1

CTO Exec Council (Level 3)

Architecture Governance Management

Requesting Process

Future-State / Roadmap Team

(Level 1)

Architecture Board

(Level 2)

Can Decision

be made?

Additional Information

required

Request Future-State

Modification

Create/ Modify Future-State

Initiate Arch.

Review

Assign to appropriate architecture governance

Evaluate

Y

N

Provide Additional

Info

Evaluate

Exception

Approve future-state

Y

Approve Future-State

Publ

ish

Rec

omm

enda

tion

N

•  New domain •  Significant

updates to existing future-state

•  Check for business driver alignment

•  Check for completeness

•  Check for leverage of enterprise assets

•  Determine trade-offs •  Evaluate business

considerations in making final recommendation

•  Clarify priorities •  Provide business driver validation •  Provide justification for deviations

from approved future-state

•  Try to make recommendation with additional information

•  EAGS to determine impact on other domain future-states and roadmaps

Modify Future-State Architecture

Design

If Changes are

required

1

3434

EAGS Roadmap -- Approve Decision Points Business and CTO leadership approval of the roadmaps represent a reasonable delivery plan consistent with the business capability

! Does the business and CTO leadership agree with the prioritization and roadmaps developed? Decision

Input

!  Business and CTO leadership approved roadmaps Output

!  Is the initiative prioritization aligned with the business capability prioritization? ! Does the prioritization balance quick wins and strategic initiatives? ! Have the dependencies been defined between the programs in the roadmap? ! Are the cost and duration estimates reasonable?

Decision Criteria

! Business Capability Prioritization ! Current-State and Future-State Architecture

Diagram ! Gap Analysis

! Project Prioritization Approach and List ! Project Cost and Duration Estimates ! Project Roadmap

!  Enterprise Domain and Segment Chief Architects !  CTO Executive Council Participants

3535


Architecture Board

(Level 2)

EAGS -- Approve Roadmap Prioritization Governance Decision Point 2


Requesting Process


required

Request Roadmap

Modifi- cation

Create/ Modify

Roadmap

Initiate Arch.

Review

Assign to appropriate

AG

Evaluate

Y

N

Provide Additional

Info

Evaluate

Make Recommendation

Approve Roadmap

Prioritization

Publ

ish

Rec

omm

enda

tion

•  New domain •  Significant updates to existing

future-state •  Changes caused die to

dependencies

•  Check for alignment with future-state and business driver priorities

•  Check for completeness e.g., business case, transitional architectures

•  Check for timing and dependencies

•  Determine trade-offs

•  Evaluate business and CTO considerations in making final recommendation

•  Clarify priorities •  Provide business case

justification •  Provide justification for

deviations from approved future-state / roadmaps

•  Try to make recommendation with additional information

•  EAGS to determine impact on other domain future-states and roadmaps

Modify Future-State Architecture

Design

If Changes are

required

Future-State / Roadmap Team

(Level 1)

2

3636

EAGS Planning Decision Points

EAGS provides input into a projected ALU funding and project approval process, through roadmaps projects and architecture approval steps

Business Programs

SDLC Initiation phase SDLC Planning phase SDLC Execution phase

Segment Capital / Finance

SDLC

EAGS

Decision Point

Business Segment

CTO Group

Senior Management

Enterprise mission defined

Identify business

objectives to meet mission,

capital planning

Establish program

placeholder

Segment Capital /Finance

approval

Create business

case

Update risk assessment

Roadmap Creation

Capital Planning Process Governance

Create the

Program

Update business

case

Update risk

assessment

Segment Capital /Finance approval

Review and approval of $$ to

perform A/Z projects

Project Initiation Governance

Project Life

Cycle

Create the

Project

Lock down estimate & schedule after

detail design

Update risk assessment

Segment Capital /Finance

approval 43

! CTO exception to SDLC if project cost exceeds approved spend

Define Capital Program

Roadmap Projects

! Output is Scope & Approach, solution design and cost profile

! Change execution framework/ 40 Risk Universe

Projects

! Event modeling

! Business reqs. sign-off

! High level design

! For changes after this, CTO group raises change control & SDLC loops it back to CFO

Review and approval of $$ to perform

plan

! Output is Statement of Work with high level solution and cost profile

#

Planning

3737

EAGS Planning Decision Points - Audit EAGS will review projects provided to SDLC management process for compliance with the future-state EA diagrams and roadmaps

!  Are projects provided to SDLC in line with the future-state architecture diagrams and roadmaps? Decision

!  Program details including high level architecture impact !  Business and Technology future-state architecture diagrams and roadmaps Input

!  Architecture recommendation to SDLC/ segment committees - a) Confirm alignment b) Confirm alignment subject to changes in program c) Not aligned – detail out impact due to non alignment

!  Identify changes to relevant roadmaps and future-state architecture diagram (if necessary) Output

! Alignment of program with roadmaps and Future-State Architecture Diagrams – Review the program against roadmap for timing, priority, redundancy (is there any other program in the list doing

the same thing), scope, timeline and cost – Review the program against Future-State Architecture for Business Architecture, Application Architecture, Data

Architecture and Technology Architecture (the relevant ones) – If programs are not aligned to roadmap/future-state architecture diagram, evaluate reason for non-compliance – If there’s a valid reason*, recommend (architecturally approve) the program and identify the changes that need to

be made to the roadmap/future-state architecture diagrams – If not, do not approve the alignment with the future-state architecture diagram and roadmap

Decision Criteria

* Potential reasons for a change to roadmap/future-state architecture diagram

a) Change in business strategy b) Change in regulatory requirements c) Roadmap/future-state architecture diagram is incomplete d) Change in CTO strategy e) Accommodate other CTO activity

!  Enterprise Domain and Segment Chief Architects Participants

3838

Does program owner agree?

N


Architecture Board

(Level 2)

EAGS -- Capital Planning Review Governance Decision Point 3


Roadmap Development

Business

Capital Planning Process

Provide Program

Capital Approval

Request Exception Program Architecture

Approval

Receive Program Architecture Approval

Request

Assign to appropriate

Level 2 members

Evaluate Alignment

Y

N

Provide Additional Info

Evaluate

Make Recommend

ation

Make Recommendati

on

Pub

lish

Rec

omm

enda

tion

Y Additional Information

*E2E – If End to End governance is required

Approve Programs

Modify Roadmaps if

required

Can Decision be made?

N

Y

3

3939

EAGS Planning -- Approve Decision Points EAGS will also evaluate project initiation EA compliance as part of SDLC funding release process

!  Is the project description and conceptual architecture aligned with the Business and Technology future-state architecture diagram and roadmap? Are the appropriate architecture related activities identified and staffed in the project plan? Decision

!  Future-State Architecture Diagrams and Roadmaps !  Original Program description and architecture recommendation !  Project description including the business functionality and architectural impact

Input

!  Architecture recommendation to SDLC/ segment committees for funding release to begin a project - a) Confirm alignment b) Confirm alignment subject to changes in project plan c) Not aligned – describe the impact non alignment Output

!  Alignment of program with roadmaps and Future-State Architecture Diagrams – Review the project scope and plan against the roadmap for timing, priority, redundancy (is there any other program in the list

doing the same thing), scope, timeline and cost – Review the projects functional requirements and conceptual against Future-State Architecture Diagrams for Business,

Application, Data and Technology Architecture (the relevant ones) – Are the appropriate architecture related tasks and deliverables have been identified and estimated in the project plan? – Are the architecture related task and deliverables appropriately staffed

Decision Criteria

!  Enterprise Domain and Segment Chief Architects Participants

4040

Capital Planning Process


Architecture Board

(Level 2)

EAGS -- Project Initiation EA Recommendation Governance Decision Point 4


Requesting Process

Initiate Project

Initiation Request

Capital Approval

Receive Project Architecture Approval

Request

Assign to appropriate BEAG

Evaluate


Make Recommend

ation

Make Recommendati

on

Manage Exceptions


Y

Y

N N Additional Information

Is there an exception?

Does program owner agree?

N

Y

Approve Programs

Modify Roadmaps if

required

Roadmap Development

Publ

ish

Rec

omm

enda

tion

4

4141

EAGS -- Project Delivery Process EAGS will engage through existing ALU project delivery checkpoints - high level design, detailed design and post implementation

Analysis Design Build, Test and Deploy Closure

SDLC Decision Point Source: Client documents, Interviews Notes: Deliverables required at Checkpoint: 1) Walk Through, Project Scope, Business Area Context Diagram; 2) Walk Through, Project Schedule, Approved Business Requirements, Business Process Flow, Workflow, Conceptual Class Diagram, Component Context Diagram, Component Interaction Diagram, Data Flow Diagram, Logical Data Model, Function Data Matrix, Infrastructure Requirements Document, System Logical; 3) Walk Through, Design Class Diagram, Engineering Specification Document; 4) Walk Through, Support Readiness Checklist, Operational Readiness Checklist

Release Planning

Release execution and Control

Test

Deployment

Project creation

Release Closure 7

Requirement analysis Detailed Design High Level

Design Development 6 5

4 3 2 1

Stakeholders: ! Security ! Program

Management ! Client Platform

Systems Analysis and Architecture

Stakeholders: ! Security ! Program Management ! Client Platform Systems

Analysis and Architecture ! Enterprise Application

Architecture ! Client Enterprise Data

Architecture ! Infrastructure Architecture

Stakeholders: ! Security ! Enterprise Application Architecture ! Infrastructure Architecture

Stakeholders: ! Security ! Support Readiness ! Operational Readiness

Checkpoint Decision Point # #

ALU SDLC Process

Controls the introduction of new technology across

Client and drive the use of enterprise

architecture

Checkpoint Process

The EAGS will begin to utilize the Checkpoint process and will leverage this process across all projects

Delivery

4242

EAGS Delivery Decision Points - Audit After high-level design, a compliance review will assess the intended conceptual architecture and determine whether the project can move forward

!  Determine if the project is delivering on the approved conceptual architecture and any additional standards or frameworks that should be followed Decision

!  Project Conceptual Architecture (from Project Initiation request) !  High level design Future-State Architecture Input

!  Recommendations for changes/improvements to the project in order to move into detailed design !  Project team plan for addressing the recommendations (if applicable) !  Identify changes to relevant roadmaps and Future-State Architecture (if applicable) Output

!  Have the high-level architecture deliverables defined in the plan been completed? !  Are the high-level architecture deliverables aligned with the approved project conceptual architecture? !  Determine the impact of any changes required by the project in order to be compliant !  If not determine the impact on the business and technology future-state architecture diagram and roadmaps and any other

initiatives that may be impacted by the change !  Do the high-level designs comply with any other detailed technology standards or frameworks?

Decision Criteria

!  Project team architects !  Impacted Enterprise Domain and Segment Chief Architects Participants

4343


Architecture Board (Level 2)

EAGS High-Level Design EA Checkpoint Governance Decision Point 5


Project Team (Level 1)

Complete High Level

Architecture Design

High Level Design Architecture Request


Evaluate

Y

N


If Big

Evaluate

Make Recommen

-dation

Make Recommen

-dation

Pub

lish

Rec

omm

enda

tion

Exception


required

If E2E* Evaluate architecture

N

Y

Submit for approval

If Major issues

Y

N

Exception / Issues

Architecture Issue Exception Request


Continue Project, modify

design if necessary

Modify Roadmaps if required

Roadmap Development

Make Recommendation

5

4444

EAGS Delivery Decision Point Approval After Detailed Design, a compliance review will assess the approved high-level designs to determine if the project can move forward

Source: Client documents, Interviews

!  Determine if the project is delivering on the approved high-level architecture design and any additional standards or frameworks that should be followed Decision

!  High-level design future-state architecture diagram !  Detailed design future-state architecture diagram Input

!  Recommendations for changes/improvements to the solution in order to move into build !  Project team plan for addressing the recommendations (if applicable) !  Identify changes to relevant roadmaps and future-state architecture diagrams (if applicable)

Output

!  Have the detailed architecture deliverables defined in the plan been completed? !  Are the detailed design architecture deliverables aligned with the approved high-level design? !  Were the agreed to changes from the high-level design review completed? !  Determine the impact of any changes required by the project in order to be compliant !  If not determine the impact on the business and technology future-state architecture diagrams and roadmaps and any other

initiatives that may be impacted by the change !  Do the detailed designs comply with any other detailed technology standards or frameworks?

Decision Criteria


4545





Complete Detailed

Architecture Design

Detailed Design Architecture Request


Evaluate

Y

N


If Big

Evaluate

Make Recommen

-dation

Make Recommen

-dation

Pub

lish

Rec

omm

enda

tion

Exception


required

If E2E* Evaluate architecture

N

Y

Submit for approval

If Major issues

Y

N

Exception / Issues



Continue Project, modify

design if necessary


Roadmap Development

Make Recommendation

EAGS Detailed Design Architecture Checkpoint Governance Decision Point 6

6

4646

EAGS Post Implementation Review Approval As part of Release Closure, the implemented solution will reviewed to measure success of governance

Decision

Input

Output

Decision Criteria

!  Determine if the project was delivered according to the approved detailed and any additional standards or frameworks that should have been followed

!  Detailed design future-state architecture diagrams !  Implemented code and solution documentation

!  Was the agreed-to architecture implemented? !  Did the deployed solution comply with any other detailed technology standards or frameworks?


!  Compliance report !  Identify changes to relevant roadmaps and future-state architecture diagrams (if applicable)

4747




Complete Project

Deployment

Post Implementation Architecture Review Request


Review

Y

N


If Big Produce

Compliance Report

Pub

lish

Rep

ort


required

If E2E* Review architecture

N

Y

Submit for Review

Exception / Issues



Close out project review


Roadmap Development

Produce Compliance Report

EAGS Post Implementation EA Review Checkpoint Governance Decision Point 7

7

4848

EAGS -- Exception Process Throughout the governance process an exception process exists if a decision can not be reached or a decisions needs to be made at a higher level

Exception Process

! Exceptions can happen at any decision point or anywhere throughout the process so that decisions can be made by the right people

! Prior to exception, the group working an issue should provide the next level all the information they need in order to make a decision

! Exception level will take relevant inputs and support from architects to make a final decision based on decision criteria

! If necessary, all the parties involved (e.g. EAGS team and the segment/IT group) may be asked for additional information in order to make a decision

Governance Bodies

Escalation P

ath

8

Approval Level 2 EAGS

EAGS Lead (Chair), Segment and Domain Roadmap Owners,

Architects and Application Owners from Impacted

Segments

Approval Level 1 Project Governance

Project/Program Manager, Delivery Architects

Approval Level 3 CTO Executive Council

IT and Business Leaders

4949

3 C

Effective Governance for Alcatel-Lucent Enterprise Architecture Governance Strategy (EAGS)


5050

EAGS Governance Metric Objectives Monitoring governance processes will help evaluate efficiency and effectiveness of governance

Governance Efficiency

•  How well does the governance process work at each SDLC gate – i.e. planning, funding approval and project execution?

Governance Effectiveness

•  How frequently are the roadmaps being followed – how many projects are compliant?

•  How many issues/exceptions are reported? •  How frequently does the finance committee accept

recommendation from EAGS?

Understand Impact of EAGS

•  How good are the roadmaps? How frequently do they change?

•  What is the project mix and how many domains are impacted by various projects?

Objective Key Questions

5151

EAGS -- Suggested Metrics Approach Metrics, such as % of projects governed by EAGS, number of compliant projects and recommendations followed will assess effectiveness

Goal Performance

Metric Target Description Formula Data

Improve governance process efficiency and effectiveness

% of projects governed by EAGS % of spend governed by EAGS

TBD •  Percentage of projects that went through governance processes during each stage (planning and execution)

(by segment, by budget)

[# of projects reviewed] divided by [total number of projects planned/ executed]

[$ of spend reviewed] divided by [total investment $]

Management / Owner: EAGS Data Source: Database/ tool used to manage governance, annual plan (for number of projects planned), Individual segments/domains (for projects executed) Area: Planning and Execution process Reporting Frequency: Every planning cycle (3 months) Turnaround time

per decision TBD •  How long it takes to turn around a

governance decision [date request decided] – [date request received]

Improve accuracy of roadmaps

% distribution of outcomes at each decision point

TBD •  Number of projects – a) compliant b) needed roadmap changes c) needed change to both

•  Changes made to relevant roadmaps and Future-State Architecture (by segment, at financial level (e.g. for projects >$3M, >$250K), by each stage (planning, funding approval, execution))

•  Post-implementation non-compliance instances

[# of projects recommended as-is], or [# of projects recommended with changes], or [# of projects recommended resulting in changes to roadmap], or [# of projects recommended resulting in changes to future-state]

Divided by [# of projects reviewed]

Understand impact of EAGS

# of exception managed, # of recommendations followed

TBD •  Overall project mix (e.g. (mandatory, maintenance, growth, effectiveness)

•  Number of exceptions / disputes •  Percentage of recommendations

followed by finance committees

# of exceptions managed

[# of EAGS recommendations followed] Divided by [total number of EAGS recommendations]

Management / Owner: EAGS Data Source: Database/ tool used to manage governance, finance committees, segments (project mix) Area: Planning and Execution process Reporting Frequency: Every planning cycle (3 months)

5252

3 D

Effective Governance for Alcatel-Lucent Enterprise Architecture Governance Strategy (EAGS)


5353

Key Responsibilities

!  Conduct detailed architecture delivery work product reviews for EAGS compliance !  Receive requests from project teams during conceptual design and detailed

design !  Review the project against relevant roadmaps and future-state architecture

diagrams using the defined criteria !  Provides architecture sign off for SDLC gate progression !  Prescribes corrective actions for designs not in compliance

!  Assess if projects were architecturally compliant post-implementation (as agreed during design sign-off)

!  If not compliant post-implementation, escalate the exception issue to Enterprise Systems Governance

!  Identifies and log architecture issues for Project Governance decision for review and exception

Membership ! Project/ program manager ! Delivery architects

Charter !  Conduct architecture reviews

during project delivery and provide architecture sign off for project to progress to next SDLC gate

Operating Guidelines

!  Meet as required (whenever there’s a project/program request)

!  Disagreements between architects and project teams to be escalated to Enterprise Systems Governance

Project Governance team (level 1) ensures architecture compliance during project delivery

5454

Key Responsibilities !  Approve or reject changes to future-state architecture diagrams and roadmaps during

roadmap development –  Assess whether future-state architecture diagrams represent the desired end-

state (that have been reconciled across the other domain and segment future-state architecture diagrams) using the future-state architecture diagram evaluation criteria

–  Assess the roadmaps and prioritization using roadmap evaluation criteria –  Suggest prioritization of roadmap initiatives –  Approve or reject future-state architecture diagram/ roadmap changes

!  Recommend funding approval for projects based on alignment to roadmaps and future-state architecture diagram

–  Review requests from EAGS, other committees and project teams and assemble right resources to work on the request

–  Review the program against relevant roadmaps and future-state architecture diagrams using the defined criteria

–  Recommend approval if the program is architecturally compliant –  For programs not compliant, assess whether the program is an exception – if

yes, recommend the program and identify changes to roadmap /future-state architecture diagrams

!  In case of disagreements on compliance between project team and ESS, escalate exceptions to CTO Executive Council (according to exception guidelines)

!  After finance committee has made a decision on recommendation, align the roadmaps and future-state architecture diagrams with the final decision

!  Resolve exception issues - adjudicate on issues during project execution that cannot be resolved at project governance level (Level 1)

Membership ! EAGS Lead (Chair) ! Segment and Domain

Roadmap Owners ! Architects and Application

Owners from Impacted Segments

Charter !  Approve changes to roadmaps

and future-state architecture diagrams during roadmap development

!  Provide recommendation to finance committees, project teams and other requesting Client bodies on enterprise architecture compliance of Client CTO programs


!  Meet as required (whenever there’s a request)

!  Core team meet every 3 months to monitor progress

!  Chair can convene ad-hoc meetings as required, or invite other parties

Enterprise Systems Governance (level 2) reviews requests from EAGS, other committees and recommend programs based on architecture compliance

5555

Key Responsibilities !  Approve prioritization of CTO investments

–  Review the list of programs to be included in annual plan –  Evaluate the programs for alignment with business strategy, enterprise

architecture (inputs from Level 2) and other criteria –  Prioritize the programs for inclusion in plan

!  Adjudicate on exception issues –  Enterprise Systems Governance (Level 2) will address exception issues that

cannot be resolved in Level 2 –  Use references (e.g. future-state architecture diagrams, roadmaps, architecture

diagrams) and inputs from architects, business teams and stakeholders involved to resolve the issue

!  Approve governance processes, policies and standards created/changed by Enterprise Systems Governance team


!  Meet monthly !  Chair can convene ad-hoc

meetings as required !  Enterprise Systems

Governance group will provide guidance and support as needed

Membership !  IT and business leadership

! CIO ! CIO Direct Reports ! BU Segment Leadership ! BU Finance

Charter !  Approve prioritization of CTO

investments !  Adjudicate on exception issues !  Approves policies, future-state

architecture, roadmaps, and standards

The IT Executive Council (level 3) approves prioritization of IT investments, policies and standards, and adjudicates on exception issues

5656

Next Steps for EAGS

The following tasks need to be completed over the next 30 days: •  Refine EAGS team structure, roles and responsibilities and resource

management process •  Further build out the detailed governance process with defined

checkpoints, key inputs, and outputs •  Identify and engage projects with an EAGS pilot (e.g., ALU Mobilization) •  Refine an EAGS staffing model for the ALU Mobilization effort as

charters are developed •  Develop the staffing model for architects needed for the ALU EAGS

execution teams and the BEAG team •  Build out the EAGS repository with necessary forms, architecture

templates and methodology guidelines •  Onboard and train EAGS resources

CMAD Group Workbook 7 Governance

Documents

Transcript of CMAD Group Workbook 7 Governance