Client X IT Services

Operating Model
 Client X IT Capability Model overview
The Client X IT Capability Model has 7 domains and 17 underpinning capabilities.
Business customers End-users

Manage business & customer relationships Manage & control

Identifies and prioritises demand for new IT services and improvements to existing services. Ensures IT Ensures that the IT
teams leverage business expertise and that business functions leverage IT expertise. function’s activities are
aligned to the current
Plan Build Transition Run and future needs of the
Maintains the strategy Identifies and analyses Ensures the transition of Provides and business and balances
for IT to ensures that business requirements, IT solutions into the live continuously improves the requirements for
solutions and services translates them into IT environment with delivery of IT solutions quality against cost of
are delivered effectively solutions and tests the minimal business and services in line with service .
and efficiently. overall capability, disruption. business requirements.
including the systems
and processes to
validate that they meet
requirements.

Manage supplier & vendor relationships

This involves identifying requirements for supplier/partner services, selecting the right supplier and
managing the suppliers/partners to deliver to the requirements.

Suppliers Vendors

2
2
 Client X IT Capability Model overview
The Client X IT Capability Model has 7 domains and 17 underpinning capabilities.

Business customers End-users

Manage business & customer relationships Manage & control

Business relationship Customer service
management management
Workforce
Plan Build Transition Run management
Service portfolio management

IT Strategy and Project portfolio control Technology &

business alignment / assurance Infrastructure
management
Programme & project Service transition
management
Investment portfolio Service operation
management
Quality & assurance
Solution development management
Architecture
management

Manage supplier & vendor relationships

Financial management
Supplier relationship
Sourcing & procurement management
management

Suppliers Vendors

3
3
Client X IT Operating Model
Business customers End-users

Manage business & customer relationships Manage & control

Business relationship management Customer service management
Business Relationship Mgmt Customer Relationship Mgmt
Workforce management

People Performance Mgmt.

Plan Build Transition Run Talent Management

IT Strategy and business alignment Service portfolio management
Service Catalogue Mgmt Service Level Management
IT Strategy Development

Project portfolio control / assurance Service transition Service operation Technology & Infrastructure management
Service Strategy Development
Portfolio Delivery Mgmt Change Management Incident Management
IT Innovation Management Infrastructure Management
Release & Deployment Mgmt. Request Fulfilment
IT Annual Budget & Planning Programme & project management Application Management
Service Testing & Acceptance Problem Management
Programme/Project Mgmt
Investment portfolio management Security Management
Configuration & Asset Mgmt
Business led Demand Management Service Continuity Mgmt Quality & assurance management
Solution development Knowledge Management
Requirements Management Access Management Compliance Management
Resource Management
Solution Design Event Management
Architecture Management Assurance Management
Service Design Service Reporting
Architecture Development

Artefact review and approval Solution Build & Configure Availability Management Continual Service Improvement

Project Alignment and Compliance Capacity Management

Solution Test
Escalation and Exception Mgmt
Financial management

IT Financial Management
Manage supplier & vendor relationships
IT Service Charging
Sourcing & procurement management Vendor relationship management
Supplier Selection Contract Management Sourcing Strategy Mgmt Supplier Relationship Mgmt

Suppliers Vendors

By SBP Go Live By next roll-out On-going optimizations Longer term

4
 Key Design Principles

...
ID Decision Rationale Consequences
To Be Added & Need Linkage to SBP

5
 Key IT Operating Model Design Decisions
...
ID Decision Rationale Consequences
1 IT processes and activities identified in red are When the initial sites (Netherlands and Belgium) for the Some processes and/or activities are defined as
designed to be implemented and ready by the first of Global Platform Initiative go live these IT processes need to out-of-scope because they are either not realistic
February 2013. be operational. for the February 1st 2013 deadline, low value
processes, or currently are in good state

2 Coding of each IT process and activity is present For retrieval and standardization purposes a When a new activity is added this
from level 0 to level 4. coding/numbering scheme is designed and implemented. coding/numbering standard needs to be taken
into account.

3 The processes will be implemented without a CMS will not be in place by initial Netherlands and Belgium A comprehensive, global CMS will not be in
Configuration Management System. go-lives in February 2013. place by February 1st 2013. However, next steps
will be defined to have a CMS in place at a later
date. This date still needs to be determined.

4 Roles from the ITIL standards will be used throughout Processes are redesigned without adding new roles. Existing roles within Client X that do not appear
all processes and activities. A clear description for Introducing new roles will make the processes unnecessarily in the process-flow diagrams will disappear.
each role needs to be present, as well as mapping to complex. They will either be transformed into a new role or
existing Client X IT roles are completely removed.

5 A Service Catalog needs to be fully in place by July For applications and operations in scope for Scalable
2013. By February 1st a basic Service Catalog needs Platform Initiative we need to have a basic overview of
to be in place limited to the applications belonging to Services presented in a catalog.
the Scalable Platform and defined standard service
offerings

6 Linkage to IT Service Charging process Procurement process and guidelines need to be in place. Lack of clarity within businesses regarding IT
(Procurement) needs to be defined procurement chargebacks.

7 Local IT vs Global scope These IT processes are designed with a global scope in Detail regarding local IT requirements needs to
mind. However, local IT support and processes must be be defined based on agreed upon criteria
taken into account as long as they contribute to the global
process.

6
 SO. Service Operations
Goal .
.
• Provide day to day delivery and support of reliable IT Services.
• Delivers reliable IT services to the business while improving quality and efficiency
through external comparison and an unrelenting focus on continuous improvement

Description
• Develop the service measurement framework. Agree the different levels of measurement and management information
• Define what components to measure to determine service efficiency.
• Develop forward-looking forecasts based on past performance and known future events. Predict if future service performance
continues to fall within acceptable tolerances
• Identify and resolve service disruptions as they arise.
• Address and end users enhancement requests.
• Ensure that any required system changes are planned and implemented before SLAs and service targets are breached
• Tune and optimise deployed IT capacity and seek to improve service performance whenever it is cost justifiable

Process Participants and Owner Inputs, Triggering events

• Owner: Service Delivery Manager • Events, Incidents, security requirements, access requirements,
• Participants: See underlying processes SLA’s, Service reports
• New required capacity
• New Services

Metrics Outputs

• See metrics underlying processes • Incident records

• Standardized reports
• SLA reports

7
7
 Service Operations Overview

L0 SO. Service Operations

SO-01. SO-02. SO-03. SO-04. SO-05. SO-06. SO-07. SO-08.

L1 SO-09. SO-010.
Incident Request Problem Security Service Access Event Service Availability Capacity
Management Fulfillment Management Management Continuity Management Management reporting Management Management
Management Management

SO-01-01. SO-02-01. SO-03-01.

Incident Logging Request Logging Proactive
and and Problem
Categorization Categorization Identification

SO-03-02.
SO-01-02. SO-02-02.
Problem
Pro-active User Request Model
Categorization
Information and Execution
and Prioritization

SO-01-03. SO-02-03. SO-03-03.

Incident Request Problem
Monitoring & Monitoring & Diagnosis and
Escalation Escalation Resolution

L2
SO-01-04. SO-02-04. SO-03-04.
Handling of Major Request Closure Problem Closure
Incidents & Evaluation & Evaluation

SO-01-05.
Immediate SO-03.05.
Incident Major Problem
Resolution 1st Review
Level Support
SO-01-06.
Incident
Resolution by 2nd
level Support

SO-01-07.
Incident Closure
& Evaluation

Must have Out of scope

8
SO-01. Incident Management
Goal .
. IM
• To restore services to normal as quickly as possible and minimize adverse impact on
business operations
• To ensure that the best possible levels of service quality are maintained
• To keep business users informed of relevant incident statuses and progress

Description
• Identify incidents as they arise – this can be automated through event management or manually through an event notification or a
user communication/electronic submission. Log the incident in the incident management tool, assign a date/time stamp and
assign an owner
• Categorize the incident as per agreed criteria. Route the incident to the relevant resolver group
• Prioritize the incident within the resolver group and perform an initial diagnosis. If the incident has been misallocated, route it to
the correct resolver group but do not close the incident in the logging tool
• If necessary, escalate incident either to the next line support (functional) or to management for information (hierarchical)
• Investigate and resolve the incident. Raise a related problem as required. Close the incident

Process Participants and Owner Inputs, Triggering events

• Owner: Incident Manager • Event Notification

• Participants: 1st level support, 2nd level support, vendor, • User Communication or Electronic Submission
service delivery manager, problem manager

Metrics Outputs

• Resolution and Response within SLA • Incident record

• Customer Satisfaction Rate • Incident resolution
• Number of Requests by Category, Trending Type • Problem record
• Workaround / Known Error
• Training

9
SO-01. Incident Management

10
SO-02. Request fulfilment
Goal .
• To provide a channel for users to request and receive standard services for which a pre-defined .
approval and qualification process exists RF
• To provide information to users and customers about the availability of services and the
procedure for obtaining them
• To source and deliver the components of requested standard services (e.g. licenses and software
media)

Description
• The value of Request Fulfilment is to provide quick and effective access to standard services which business staff can use to
improve their productivity or the quality of business services and products.
• The term ‘Service Request’ is used as a generic description for many varying types of demands that are placed upon the IT
Department by the users. Many of these are actually small changes – low risk, frequently occurring, low cost, etc. (e.g. a request
to change a password, a request to install an additional software application onto a particular workstation, a request to relocate
some items of desktop equipment) or maybe just a question requesting information – but their scale and frequent, low-risk nature
means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident
and Change Management processes.

Process Participants and Owner Inputs, Triggering events

• Event Service Request Model
• Owner: Service Delivery Manager • Service Request Record from Incident Management
• Service Desk/Incident Management
• Participants: 1st level support, Fulfilment Group, User, 2nd • Budget Allocation
Level Support, Analysts, Developers, IT Operators • Request for Service by User or Customer Requirement

Metrics Outputs

 The total number of Service Requests • Completed Service Request

 Breakdown of service requests at each stage • RFC
 The size of current backlog of outstanding Service • Updated Service Request Model
Requests
 The mean elapsed time for handling each type of Service
Request

11
SO-02. Request fulfilment

12
SO-03. Problem Management
Goal .
.
• Problem Management is the process responsible for managing the lifecycle of all
PM
problems (identified as the cause of one or more incidents). The primary objectives of
Problem Management are to prevent problems and resulting incidents from happening,
to eliminate recurring incidents and to minimize the impact of incidents that cannot be
prevented.
Description
• Problem Management includes the activities required to diagnose the root cause of incidents and to determine the resolution to
those problems. It is also responsible for ensuring that the resolution is implemented through the appropriate control procedures,
especially Change Management and Release Management. Problem Management will also maintain information about problems
and the appropriate workarounds and resolutions, so that the organization is able to reduce the number and impact of incidents
over time. In this respect, Problem Management has a strong interface with Knowledge Management, and tools such as the
Known Error Database will be used for both. Although Incident and Problem Management are separate processes, they are
closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This
will ensure effective communication when dealing with related incidents and problems.

Process Participants and Owner Inputs – Triggering Events

• Owner: Problem Manager • Incidents

• Participants: Incident Manager, 1st level Support, 2nd level • Proactive Event & Incident Review
Support, Vendor, Service Delivery Manager

Metrics Outputs

• Resolution and Response within SLA • Problem Record

• Number of Problems by Category, Trending Type • Documented Workaround
• Documented Known Error
• Service Request / Change Record
• Project Proposal

13
SO-03. Problem Management

14
SO-04. Security Management
Goal .
. SM
• Information Security Management aims to ensure the confidentiality, integrity
and availability of an Client X information, data and IT services
• Out-of-scope: physical security of factories

Description
• Focus on SOX: Application level security (IT), emergency admin ID, security patch process
• Apply security framework: ISO27001,27002:
• Patch management
• Credentialing (passwords, default credentials)
• Securing configurations (network etc.)
• Physical security (datacenter security, what’s in scope?)
• Hosted apps
• Information policy (using apps, phone, sharing company information etc.)
• Incident/intrusion detection
• Threat assessment (tooling, antivirus)

Process Participants and Owner Inputs, Triggering events

• Owner: Director, Global Infrastructure • Intrusion monitoring, security bulletin

• Participants: Security manager, operational support and • Budget allocation
• Security incident, event patterns and records, problems
technology experts • SOX testing
• ISO framework
Metrics Outputs

• Number of major security incidents • Alerts from monitoring tools

• Successful SOX testing • Change requests or service requests
• Newly defined/Revised security policies & procedures
• Compliance to the framework (define metrics) • Testing schedule
• Security reports
15
SO-05. Service Continuity Management
Goal .
. SM
• IT Service Continuity Management (ITSCM) aims to manage risks that could seriously
impact IT services. ITSCM ensures that the IT service provider (Client X IT Services)
can always provide minimum agreed Service Levels, by reducing the risk from disaster
events to an acceptable level and planning for the recovery of IT data and services.

Description
• IT Services Continuity Management includes the processes (Roles and Responsibilities for supporting business continuity,
Systems design, Training and testing and Periodic review of current risk perceptions) which allow IT Services to ensure that
mission critical business data and services are safe.
• IT Service Continuity Management ensures that appropriate continuity mechanisms are in place. The recovery of IT services is
managed through the Incident Management process
• Define Tiers continuity plan plus cost estimation for each tier.

Process Participants and Owner Inputs, Triggering events

• Owner: Director, Global Infrastructure • Declared disaster

• Participants: Business Continuity Manager, 1st level support, • Business continuity test schedule and test
2nd level support, Incident Manager, Problem Manager, • ERM (Enterprise Risk Management) quarterly assessments
system analysts
Metrics Outputs

• ERM Business Continuity risk • Business continuity strategy and Recovery Plan
• Gaps in preparation for disaster events • Test results
• Number of successful disaster practices • Service continuity annual report
• Number of gaps identified during disaster practices

16
SO-06 Access Management
Goal .
.
• Access Management include the following: ability to verify the identity of a user, the AM
identity of the approving person/body, the qualification of a user, the ability to provide a list
of access rights for an individual user, ability to manage changes to access requirements,
the ability to restrict access rights to unauthorized users and to determine the status of a
user at any time (whether they are still employees of the organization).
Description
• Access Management is the execution of both Availability and Information Security Management in that it enables the organization
to manage the confidentiality, availability and integrity of the organization’s data and intellectual property.
• Ensures users are given the right to use a service or group of services, at the same time preventing access to non-authorized
users.
• Ensures users are given the right to use a service or group of services, while also ensuring the appropriate level of permission
within an particular service or application based on their job function or role within the organization as defined within SBP. This
includes Segregation of Duties.
• SBP focuses on policy development and role definitions, Request fulfilment executes access management.

Process Participants and Owner Inputs, Triggering events

• Owner: Access Manager • RFC

• Participants: 1st level support, 2nd level support, Change • Service Request, e.g. new hire
Manager, Incident Manager, Analysts, Security Manager, • Access policies & role definitions (SBP)
business process/policy owner
Metrics Outputs

• Number of requests for access • Service Request Record

• Incidents requiring a reset of access rights • Updated Policy and/or role definition
• Incidents caused by incorrect access settings • Annual budgeting chargebacks
• ITGC / audits

17
 ST. Service Transition
Goal .
.
To ensure that the introduction of new and modified services happens in a planned,
controlled and timely manner so disturbances to day-to-day services are minimised

Description
• Engage with the project teams early to flag when the new/changed service is to be deployed. Ensure that the relevant
stakeholders from Service Operations are engaged and accept the service introduction schedule and actively participate in the
implementation.
• Plan appropriate capacity and resources to build, release, test, deploy and establish the new service in the operational
environment. Perform review and sign off against acceptance criteria. Ensure that transition risks are identified and mitigated and
give a risk assessment for “Go/No Go” of services into the live environment
• Coordinate activities across projects, suppliers, Business Units and countries where required. Provide clear and comprehensive
plans that enable customer and business change projects to align their activities with the IT projects

Process Participants and Owner Inputs, Triggering events

• Owner: Service Development Manager, Service Delivery • Project plans

Manager • Service transition approach
• Participants: See underlying processes

Metric Outputs

• See underlying processes • Formal service handover materials(e.g. checklist) and

training
• Acceptance risk plan
• Service Operation guide

18
 Service Transition Overview

L0 ST. Service Transition

ST-02. ST-03. ST-04

ST-01. ST-05
L1 Release and Service Configuration
Change Knowledge
Deployment testing and and asset
Management management
Management acceptance management

ST-01-01.
ST-02-01.
RFC Logging and
Release Planning
Review

ST-01-02
Assessment &
ST-02-02.
Implementation
Release Build
of Emergency
Changes

ST-01-03.
ST-02-03.
Change
Release
Assessment by
Deployment
the Change Mgr.
L2

ST-01-04. ST-02-04.
Change Post Go-Live
Deployment Support

ST-01-05.
Post
ST-02-05.
Implementation
Release Closure
Review & Change
Closure

Must have Out of scope

19
ST-01 Change Management
Goal .
CM
.
• Respond to the customer’s changing business requirements while maximizing value
and reducing incidents, disruption and re-work
• Respond to the business and IT requests for change that will align the services with the
business needs.

Description
• Changes should be managed to:
• Optimize risk exposure (supporting the risk profile required by the business)
• Minimize the severity of any impact and disruption
• Be successful at the first attempt.
• Such an approach will deliver direct benefit to the bottom line for the business by delivering early realization of benefits (or
removal of risk), with a saving of money and time.

Process Participants and Owner Inputs - Triggering Events

• Owner: Change Manager • Service Request / Incident Management

• Participants: CAB, Change Initiator, Users, Analysts, IT • Budget Allocation
Operator • Request for Service by Customer
• RFC Record
Metrics Outputs

• Percentage of successful changes • Updated RFC Record

• Percentage of Emergency/Expedite Changes • RFC Reporting
• Percentage of Rejected Changes • Implemented Change
• Number of changes that not deliver expected results • Updated SOG/Knowledge Base

20
ST-01 Change Management

21
ST-02 Release and Deployment Management
Goal .
RDM
.
The goal of Release and Deployment Management is to deploy releases (defined as new
or enhanced packages) into production and establish effective use of the service in order
to deliver value to the customer and be able to handover to service operations.

Description
• Release and Deployment Management aims to build, test and deliver the capability to provide the services specified by Service
Design and that will accomplish the stakeholders’ requirements and deliver the intended objectives.
• The scope of Release and Deployment Management includes the processes, systems and functions to package, build, and test
and deploy a release into production and establish the service specified in the Service Design package before final handover to
service operations.
• Well-planned and implemented release and deployment will make a significant difference to an Client X service costs. A poorly
designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems
and managing complexity. At worst, it can cripple the environment and degrade the live services..

Process Participants and Owner Inputs - Triggering Events

• Owner: Release Manager • Project plan/ status reports

• Participants: Project Manager, Change Manager, Service • Change records (RFC), Service Requests
Owner, Process Owner, Business Sponsor, Incident Manager, • Solution designs
1st and 2nd Level support, Business stakeholders • Test plans
Metrics Outputs

• Number of incidents and RFC’s related to new or enhanced • User Manual/ use training material
release • Service Operation Guide / updated DML
• Duration of needed post production time. • Updated project plan/ transition plan
• Number of end user training sessions • Updated service request
• Number of rejections by Operations or Business stakeholders

22
ST-02 Release and Deployment Management

23
ST-03 Service Testing and acceptance
Goal
.
.
The goal of Service Testing and Acceptance is to assure that a service will provide value to
customers and their business. STA

Description
• Service testing and acceptance contribute to quality assurance.
• It provides confidence that a release will create a new or changed service or service offerings that deliver the expected outcome
and value for the customers within the projected costs, capacity and constraints.
• It validates that a service is ‘fit for purpose’ – it will deliver the required performance with desired constraints removed.
• It assures a service is ‘fit for use’ – it meets certain specifications under the specified terms and conditions of use.
• It confirm that the customer and stake holder requirements for the new or changed service are correctly defined and remedy any
errors or variances early in the service life cycle as this is considerably cheaper than fixing errors in production.

Process Participants and Owner Inputs, Triggering events

• Owner: Test Manager (QC Manager) • Project Plan / Service Requests

• Participants: Project Manager, Solution Development • Service Design Documents
Manager, Process Owner, Business Stake Holders, Change • Test Plans
Manager
Metrics Outputs

• Reduction in the impact of incidents and errors in live that are • Test results
attributable to newly transitioned services. • Updates to Service Design, User Manuals, & Service
• Effective use of resource and involvement from the customer / Operation Guides
business.

24
TI-01 Infrastructure Management
Goal .

• Ensure that the delivery of IT services is enabled by the right infrastructure components
having the agreed performance and stability.

Description
• Infrastructure Management supports all processes in the delivery of the end to end service, they will ensure that the right
technological components (such as hardware, operating systems and networks ) are used in the delivery of the services and will
use a range of management tools to maintain the quality of service delivery through the monitoring and control of the IT
Infrastructure.
• As services may be provided, in whole or in part, by one or more partner/supplier organisations, the Technology and Infrastructure
Management view of end-to-end service must be extended to encompass external aspects of service provision – and where
necessary shared or interfacing processes and tools are needed to manage cross-organisational workflows.

Process Participants and Owner Inputs - Triggering Events

• Owner: Director Global Infrastructure • System-Network Outages/Performance issues (Incident and

• Participants: 1st level support, 2nd level support, system Problem tickets)
analysts, security manager, incident manager, problem • IT blueprint or future roadmap
manager • Service requests
Metrics Outputs
• Delivery time for infrastructure requests • Effective technology that delivers the proper value at the
• Cost per end user computing device (Cost per Laptop, Cost right price.
per Desktop) • Improved customer satisfaction through rapid response to
• Cost per Service (by server type) user requests.
• System Availability • Early identification of faults or potential faults resulting in
• MTTR reduced downtime.

25
TI-02 Application Management
Goal .

• Enable the optimum performance and stability of applications for end-users and
business stakeholders assuming the underlying infrastructure is performing according to
expectation.

Description
• Application Management is the technical management of running applications making sure performance and functionality of the
applications is according to expectations.
• This is often supported by application management solutions that enable organizations to find and fix application problems faster
to reduce downtime, gain end-to-end operational visibility of their key performance indicators.
• Application management becomes more crucial if core processes are run on dispersed applications that need regular upgrades.
By properly monitoring these applications major disasters within these mission critical processes can be prevented and damage to
the company can be minimized.

Process Participants and Owner Inputs - Triggering Events

• Application performance/stability issues
• Owner: Director Global IT Operations • IT blueprint or future roadmap
• Participants: Operational support, Application experts • Software installation/upgrade
• Service requests

Metrics Outputs
 % Incidents as a result of application failure • Effective applications that deliver the proper value at the
 Average time taken to resolve Incidents with applications right price.
 % of unplanned downtime due to application failure • Improved customer satisfaction through rapid response to
user requests
 Delivery time for software upgrades (average time per unit) • Early identification of faults or potential faults resulting in
reduced downtime

26
Demand Management
Goal .
. SM
• Determine the proper projects and prioritize on an annual basis. Are we doing
the right things at the right time?

Description
• ITDMSC interviews business leads to collect their forward looking wish list for next fiscal year.
• ITDMSC evaluates project requests and remove undesirable requests
• ITDMSC with list of projects budget estimates and durations are defined and projects are mapped to strategic
programs.
• ITDMSC present project proposal selection to GITSC for decision making.
• ITDMSC manages the approved portfolio.

Process Participants and Owner Inputs, Triggering events

• Owner: GITSC • Annual project wish list

• Participants: ITDMSC, GITSPMO, SBPPMO, IT experts • IT capacity
• Funding
• New project requests
Metrics Outputs

• Ratio between planned and unplanned work • Quarterly portfolio status

• Execution metric: performance to plan • Escalation to GITSC
27
• Book of work for next year

27
 EA-01 Architecture Development Process
Goal .
.
• Develop Current, Target Architecture and migration paths that enable Client X to
implement IT transformation projects like SBP in an effective way.
• Provide structure and guidance on the architecture development process in all the
domains and views of the EA Content Framework including Processes, Application,
data, infrastructure, security, IT Operations and governance.
Description
• Review the Request for Architecture work coming out of a Service request and/or a project.
• Review and validate the Enterprise Architecture Principles for each domain such as Application, Technology and Data and ensure
all standards/design are aligned with principles.
• Refer to the published content within Architecture Repository
• Identify building blocks such as existing standards and portfolio
• Develop Baseline Architecture description and Target Architecture description and address gaps, if any and develop the
Roadmap and plan
• Finalize Architecture and Architecture Description document

Process Participants and Owner Inputs, Triggering events

• Owner: Enterprise Architect • Request for Architecture work within SBP and other initiatives
• Participants: Document Owner/Other delegate , EA board • Change to existing architecture
members, Solution Architect • Scope of organization
• Enterprise Architecture Principles and Architecture Repository

Metrics Outputs

• Overall time taken to produce the Architecture • Validated Enterprise Architecture principles
Description/Definition Document • Architecture Description/Definition Document(for each domain)
• The level of usage of Architecture Artefacts by members within • Enterprise Standards (Application/Technology)
the organization. • Technology Portfolio

28
2
 EA-02. Artefact Review and Approval Process
Goal .
.
• Provide clarity about current situation or desired situation
• Provide consistent and understandable documentation
• Provide a way for artefacts to be reviewed for quality control
• Provide an easy way to find artefacts

Description
• Assess the artefacts pertaining to EA coming out of project and initiate the review process
• Establish a periodic review cycle and initiate the review process on or before the review date
• Initiate the review process for documents on an ad-hoc basis or as a request coming from a project.
• Assess these documents for EA Scope and reject if not within scope
• For documents in scope, determine if the document fit within the EA Content framework and apply the criteria for
selection such as ownership, target audience etc.
• Approve the document and publish within the EA Content framework.

Process Participants and Owner Inputs, Triggering events

• Owner: Enterprise Architect • Project Delivery

• Participants: Document Owner/Other delegate , EA board • Document review cycle date
members, Solution Architect • Ad-hoc events

Metrics Outputs

• Time taken to review the document after it is triggered for • Published document
review • Handover session to Solution Architect/Project members
• Overall time taken to review and approve documents
• Compliance with project delivery agreement

29
2
 EA-03. Project alignment and compliance review process
Goal .
.
• Agree on how projects, large and small, will adhere to the EA SRGs and how EA can
provide efficient support to the project
• Catch any deviations early in the project architecture
• Ensure standard architectures are followed in projects with only approved exceptions

Description
• Agree on how projects will adhere to EA SRGs by creating a contract between EA and Solution architects for
application and Infrastructure.
• Agree on architectural roles within project
• Agree on EA standards to be applied
• Agree on processes to validate, escalate and request exceptions
• Review compliance during the execution of the projects and at the end.
• Typically the contract is part of the project design and plan. Revision assessment every three months

Process Participants and Owner Inputs, Triggering events

• Owner: Enterprise Architect • New projects, SBP and others including roll-outs
• Participants: Solution Architects • Infrastructure initiatives

Metrics Outputs

• No of Projects adhering to the EA SRGs • Project contract

• Compliance review

30
3
 EA-04. Escalation and Exception Management
Goal .
.
• Provide a controlled way for any projects that cannot follow established Principles,
rules and guidelines and grant exceptions
• Provide a way to adhere to the established framework within the time allotted.

Description
• Review the exception requested for correctness against EA content framework
• Do an assessment regarding the exception for any impacts and consequences
• Ask for opinion from SME’s regarding the exception
• Agree with the SME opinion and grant the exception
• EA Board approves the exception
• Reject the exception
• Amend the rule based on exception

Process Participants and Owner Inputs, Triggering events

• Owner: Enterprise Architect • Exception requests originating from projects, artefact selection
• Participants: Requestor, SMEs , EA board members process
• Information Missing in SRGs needed to execute projects
• SRG cannot be followed or conflicts with the project requirement

Metrics Outputs

• Time taken to decide on the exception • Published document with Amended Principles, Rules and
• No of Exceptions trend Guidelines
• Approved or rejected Exception request

31
3