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

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

3. 33
1
Governance
EAGS Framework

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

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

6. 66
EAGS Framework - Components 2
EA Governance Framework
Governance Component Architecture Sub-component Scope
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

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

8. 88
EAGS Framework - Components 4
EA Governance Framework
Governance Component Architecture Sub-component Scope
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

9. 99
9
Suggested EAGS Discovery Timing
*Timing is estimated since this is a new processWeek 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

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

11. 1111
2
Governance
EAGS Approach

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

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

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

15. 1515
A BEAGP team can be 3+ levels & tightly integrated with project
delivery efforts
Oversight EscalationLegend 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
Playbook
Execution
Teams
Requirements
Review
Architecture
Review Board
Program
Governance
Business
Process
Value
Realization
Organization &
Change Mgmt.
Technology
integration
integration

16. 1616
EA & Program Governance
Governance Board
EA Governance Levels 1 and 2 provide direct support to
a Mobilization BEAGP team
Enterprise Leadership
Value Management
Design
Effectiveness &
Value Mgmt.
Resource
Management
Architecture Issue
Management
Blueprints &
Standards
Management
Artifact &
Milestone Signoff
Exec. Reporting,
Stakeholder Comm.
Integrated
Design Team
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
Integrated
Design Team
Domain
Architects
Coordination
Design
Support,
Vendor
Coordination
Oversight EscalationLegend 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

17. 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 DesignDiscovery Build Train & LaunchTest
BEAGP &
Project
Execution
Teams
Project Arch.
Governance
EA & Program
Governance
Enterprise
Leadership
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

18. 1818
MobilizationOtherMajor*Projects
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

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

20. 2020
3 A
Effective Governance
Enterprise Architecture Governance Strategy (EAGS)
- Executive Summary
- Process Integration
- Metrics
- KPI Appendix

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

22. 2222
EAGS Design Elements
Transparent governance brings the right people together to make
decisions that integrate key investments, delivery processes and metrics
Metrics
Governance StructureProcess 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

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

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

25. 2525
EAGS – Engagement Models
EAGS will empower decision making at the lowest appropriate level with clearly
defined exception mechanisms
Project DeliveryPlanningRoadmap 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

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

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

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

29. 2929
3 B
Effective Governance
Enterprise Architecture Governance Strategy (EAGS)
Executive Summary
Process Integration
Metrics
KPI Appendix

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

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

32. 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 AssessmentInput
! 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 CouncilParticipants

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

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

35. 3535
CTO Exec
Council
(Level 3)
Architecture
Board
(Level 2)
EAGS -- Approve Roadmap Prioritization
Governance Decision Point 2
Architecture
Governance
Management
Requesting
Process
Additional
Information
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
PublishRecommendation
• 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

36. 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
Updat
e risk
asses
sment
Roadmap Creation
Capital Planning
Process Governance
Create
the
Program
Update
business
case
Update
risk
assess
ment
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

37. 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 roadmapsInput
! 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

38. 3838
Does
program
owner
agree?
N
CTO Exec
Council
(Level 3)
Architecture
Board
(Level 2)
EAGS -- Capital Planning Review
Governance Decision Point 3
Architecture
Governance
Management
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
PublishRecommendation
YAdditional
Information
*E2E – If End to End governance is required
Approve
Programs
Modify
Roadmaps if
required
Can
Decision
be made?
N
Y
3

39. 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 alignmentOutput
! 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

40. 4040
Capital Planning
Process
CTO Exec
Council
(Level 3)
Architecture
Board
(Level 2)
EAGS -- Project Initiation EA Recommendation
Governance Decision Point 4
Architecture
Governance
Management
Requesting
Process
Initiate
Project
Initiation
Request
Capital
Approval
Receive Project
Architecture Approval
Request
Assign to appropriate
BEAG
Evaluate
Provide
Additional Info
Make
Recommend
ation
Make
Recommendati
on
Manage
Exceptions
*E2E – If End to End governance is required
Y
Y
N N
Additional
Information
Is there an
exception?
Does
program
owner
agree?
N
Y
Approve
Programs
Modify
Roadmaps if
required
Roadmap
Development
PublishRecommendation
4

41. 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
65
4321
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

42. 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 followedDecision
! Project Conceptual Architecture (from Project Initiation request)
! High level design Future-State ArchitectureInput
! 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 ArchitectsParticipants

43. 4343
CTO Exec Council
(Level 3)
Architecture Board
(Level 2)
EAGS High-Level Design EA Checkpoint
Governance Decision Point 5
Architecture
Governance
Management
Project Team
(Level 1)
Complete High
Level
Architecture
Design
High Level Design
Architecture Request
Assign to appropriate
architecture governance
Evaluate
Y
N
Provide Additional Info
If Big
Evaluate
Make
Recommen
-dation
Make
Recommen
-dation
PublishRecommendation
Exception
Additional
Information
required
If E2E*
Evaluate
architecture
N
Y
Submit for approval
If
Major
issues
Y
N
Exception /
Issues
Architecture Issue
Exception Request
*E2E – If End to End governance is required
Continue
Project,
modify
design if
necessary
Modify
Roadmaps
if required
Roadmap
Development
Make
Recommendation
5

44. 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 followedDecision
! High-level design future-state architecture diagram
! Detailed design future-state architecture diagramInput
! 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
! Project team architects
! Impacted Enterprise Domain and Segment Chief ArchitectsParticipants

45. 4545
CTO Exec Council
(Level 3)
Architecture Board
(Level 2)
Architecture
Governance
Management
Project Team
(Level 1)
Complete
Detailed
Architecture
Design
Detailed Design
Architecture Request
Assign to appropriate
architecture governance
Evaluate
Y
N
Provide Additional Info
If Big
Evaluate
Make
Recommen
-dation
Make
Recommen
-dation
PublishRecommendation
Exception
Additional
Information
required
If E2E*
Evaluate
architecture
N
Y
Submit for approval
If
Major
issues
Y
N
Exception /
Issues
Architecture Issue
Exception Request
*E2E – If End to End governance is required
Continue
Project,
modify
design if
necessary
Modify
Roadmaps
if required
Roadmap
Development
Make
Recommendation
EAGS Detailed Design Architecture Checkpoint
Governance Decision Point 6
6

46. 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?
! Project team architects
! Impacted Enterprise Domain and Segment Chief ArchitectsParticipants
! Compliance report
! Identify changes to relevant roadmaps and future-state architecture diagrams (if applicable)

47. 4747
Architecture Board
(Level 2)
Architecture
Governance
Management
Project Team
(Level 1)
Complete
Project
Deployment
Post Implementation
Architecture Review Request
Assign to appropriate
architecture governance
Review
Y
N
Provide Additional Info
If Big
Produce
Compliance
Report
PublishReport
Additional
Information
required
If E2E*
Review
architecture
N
Y
Submit for Review
Exception /
Issues
Architecture Issue
Exception Request
*E2E – If End to End governance is required
Close out
project
review
Modify
Roadmaps
if required
Roadmap
Development
Produce
Compliance Report
EAGS Post Implementation EA Review Checkpoint
Governance Decision Point 7
7

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

49. 4949
3 C
Effective Governance for Alcatel-Lucent
Enterprise Architecture Governance Strategy (EAGS)
Executive Summary
Process Integration
Metrics
KPI Appendix

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

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

52. 5252
3 D
Effective Governance for Alcatel-Lucent
Enterprise Architecture Governance Strategy (EAGS)
Executive Summary
Process Integration
Metrics
KPI Appendix

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

54. 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
Operating Guidelines
! 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

55. 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
Operating Guidelines
! 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

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