This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
*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
• 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
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
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
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
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
! 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
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
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
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
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
! 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
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
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
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
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
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
! 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
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
Pub
lish
Rec
omm
enda
tion
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
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
! 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 Architects Participants
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
Pub
lish
Rec
omm
enda
tion
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
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
! 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 Architects Participants
! Compliance report ! Identify changes to relevant roadmaps and future-state architecture diagrams (if applicable)
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
Pub
lish
Rep
ort
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
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)
Executive Summary Process Integration Metrics KPI Appendix
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
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
• 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)
Executive Summary Process Integration Metrics KPI Appendix
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
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
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
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