Sym14 04C

Building an
Effective IT Operations Architecture
U.S. Symposium/ITxpo Cameron Haight

Kris Brittain
17–22 October 2004
Walt Disney World
Lake Buena Vista, Florida
These materials can be reproduced only with Gartner's written approval. Such approvals must be requested via
e-mail — quote.requests@gartner.com.
Building an Effective IT Operations Architecture
What Is an Operations Architecture?
Operations Architecture: The blueprint embodying an

IT operations organization’s vision and strategy,
supported with a granular description of the technical,
process, organizational and financial components of
the computing infrastructure necessary to meet the
goals of the business.
Many IT organizations talk about having an operations architecture, but there is confusion about what that
term means. To Gartner, an operations architecture is defined as follows: The pre-planned design of a
computing infrastructure describing in detail the required technical, process, organizational and financial
components necessary to meet the needs of the business. An operations architecture is not just something
that describes technology — it needs to put this technology in the context of processes, organization
(people) and how to value it (financials). Finally, and perhaps most importantly, the operations architecture
must describe how it meets the needs of the business. The architecture itself does not stand alone; rather, it
is the outgrowth of an assessment of business requirements — and how technology and other components
can be leveraged to meet them.
Action Item: Treat an operations architecture as you would the blueprints to a new home — plan for
technology (structural), process (electrical), plumbing (organization) and cost (financials).
© 2004 Gartner, Inc. and/or its Affiliates. All rights reserved. Reproduction of this publication in any form without prior written
permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims
all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions
Cameron Haight, Kris Brittain
or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the
selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
04C, SYM14, 10/04, AE Page 1
Client Issues
What are the benefits of and the justification
methodologies used in constructing an IT
operations architecture?
What are the key pieces of the supporting technical
framework or architecture?
How will processes improve the functioning of an IT
operations architecture?
How should IT be organized to facilitate its
development?
We will review the key areas of focus for the technology side of the architecture and describe the primary
“models” that should be implemented prior to IT operations vendor selection. We will then evaluate the key
processes that should be established, with caveats on how not fall into a process bureaucracy. Organization
is our third area of review, where we describe the evolution of the IT organization from a primarily static
concept to one that is more flexible for today’s challenging times. We will end our discussion by focusing
on justification and benefits, and introduce a new concept for IT operations — total value of opportunity
(TVO). We will consider how this can be used for technology investment justification.
04C, SYM14, 10/04, AE Page 2
Client Issue: What are the benefits of and the justification methodologies used in
constructing an IT operations architecture?
Transforming IT Benefits to Business Value

An IT operations architecture should be able to answer the
following questions:
How can we raise IT operations/
infrastructure credibility with the
business?
How can I build an infrastructure
that is responsive to the $ Architecture
business, yet is flexible to Capabilities
changing business needs?

Business
How can process or tool Needs
investment reduce operational
costs without affecting quality of
IT Organization
service?
IT is permeating through the entire business function. It is inextricably linking customers, suppliers,
business partners and government into a seamless continuum of business activity. There are no insulating
layers, where a functional failure in one aspect of the business can be an isolated incident. Not only are
business processes interrelated, they are becoming interdependent. With business process success
depending more on IT, businesses are seeking a more formal relationship or contract to assure the IT
services they need. IT organizations are increasingly moving toward running IT as a business, serving their
customers with competitive and holistic products and services at the appropriate quality level, and with
service-level commitments. Those that don’t move in this direction will find their credibility eroded over
time, and they will be more likely to have infrastructure and operations outsourced. However, outsourcing
often does not necessarily yield the right results. Writing the right outsourcing contract depends on
understanding the business IT services required, and the scope and cost of delivering them. This leads to the
critical requirement for IT organizations to design, document and continuously maintain the IT operations
architecture. To deliver business relevance requires more-granular identification components within the
areas of technology, process, organization and finance.
04C, SYM14, 10/04, AE Page 3
Strategic Imperative: IT organizations must work closely with their lines of business to
deliver the correct services and establish transparent billing methodologies.
Financial: Service-Focused
Management Line of
Basic Business
costs recouped IT Service
Chargeback
in service cost Portfolio

(with margin for
re-investment)
Chargeback
methodology Application Workplace Document Application
Hosting Support Management Development
must be
transparent
Must continually
benchmark
against external SLA
Monitor
Backup/
Recovery
High
Availability
Bus. Svc.
Monitor
providers
Optional IT Service Add-Ons
An operations architecture that is service-based focuses less on relating the costs of management
technology to improved (business or IT) performance (which is always a difficult thing to accomplish), and
more on the need to offer choice. Management technology costs are accounted for in the services that are
offered. A standard hosting service may, for example, offer SLAs of 98 percent availability and five-second
response time. Premium service, perhaps closer to “5 nines” availability and sub-second responsiveness,
will require substantially more infrastructure — that is, hardware, management monitoring and prevention
technology, and others. There is a cost for this, as there should be; otherwise, every potential IT customer
would request it. The point is that the cost of the added management technology is accounted for in the
service’s price — it’s not tied to some attempt to relate cause and effect (for example, averting downtime)
as the industry traditionally has done. Include some sort of “margin” in the services price for future re-
investment. A service-based approach thus makes comparisons to external service provider alternatives less
difficult for IT’s customers — which is how it should be in a competitive world economy.
Action Item: IT organizations should plan to move to a service-based orientation to improve delivery to
their customers and provide a means for continued re-investment.
04C, SYM14, 10/04, AE Page 4
Strategic Imperative: Business units invariably assert that “IT costs too much” without
evidence to that effect, and IT leaders must effectively address this assertion. Benchmark
service delivery cost to understand how efficient the IT organization is in what it does, and
use the results to drive discussion with business units.
Financial:
Operations-Focused (Benchmarking)
Choose the right Service Desk FTEs
per 1,000 Employees
KPI per Full Cost
30
and Process
functional area Audit 25
20
Compare to 15
industry peers C Detailed 10
IT Service
and averages O Benchmarks
5
0
A B Current
Administration FTEs
per 100 Windows Servers
S Average C With
Investment
30
25
T High-Level IT
Benchmarks Evaluate
20
15 benchmark data
10
IT Spending
trade-offs
5
Surveys Review with lines
0
A B Current
Average C With
of business
Investment
A formalized IT operations architecture that has roles assigned (permanent or virtual) should enable
comparisons to be made in terms of operating efficiency. One method is to perform a benchmark, where
you compare certain support efforts vs. industry standards (when they exist) or commercial alternatives. IT
organizations must become more accountable in terms of costs vs. benefits. Benchmarking is one approach
to making this information more transparent. There are four levels of comparison: 1) published IT spending
survey documents produced by research firms; 2) high-level benchmark offerings delivered by IT
measurement firms; 3) detailed, or drill-down, benchmarks also delivered by IT measurement firms; and 4)
extremely granular process-level reviews executed by management consulting firms. Each method provides
an increasing level of detail, but at an increasing level of cost. For chargeback purposes, a workable
comparison of costs can be established with a high-level benchmark that is readily available from a number
of providers at moderate cost. You only have to establish a cost near the average (rather than “best in
class”) to address the “too expensive” claim, so that dialog can focus on the allocation question without
further distraction. Action Item: Focus your benchmarking efforts initially on mission-critical activities,
such as your service desk, which has touchpoints throughout your organization or key application
environments, such as SAP or even e-mail.
04C, SYM14, 10/04, AE Page 5
Tactical Guideline: TCO has evolved into a complex set of tools and methodologies to
facilitate the collection of company-distributed IT costs, which had been difficult to
identify and measure. Many of these costs were incurred outside of the traditional IT
organization.
Financial:
Cost-Focused (Total Cost of Ownership)
1 Identifying Key Cost Categories
Direct Indirect
Capital Labor Fees/Other Labor
• Hardware • Management • Outsourcing • End user
2 Measuring Cost of Ownership:
• Software • Support • Maintenance • Training
• Acquisition • Development contracts • Satisfaction Direct and Indirect
costs • Outsourcing • Service levels
contract
Indirect
3 Determine Critical Influencers of Costs
Direct
Service Levels Complexity Risk
SLA Assessment
+ +
To understand the relationship between TCO and IT services, it is important to define TCO. TCO is a tool
and methodology that, when used as part of a comprehensive IT strategy, provides enormous insight and
value to an IT operation. It is the holistic view of IT costs and issues (including performance) related to a
company over time. It is important to emphasize that TCO is not a cure-all and is not only a cost-reporting
tool. Many of the components included in the TCO consensus-cost-model relate directly to IT services.
Specifically, those direct costs that support current or proposed technology are separated into three major
areas: hardware/software, operations and administration. Indirect costs are also taken into consideration and
are captured as downtime and end-user operations — the effect of an IT environment on the company from
a user perspective, represented qualitatively and quantitatively. To further understand the environment, two
additional elements are considered: best practices (a measurement of the company’s management practices)
and complexity. This facilitates the ability to understand where you are today and where you can go
tomorrow in a consistent and repeatable fashion.
04C, SYM14, 10/04, AE Page 6
Strategic Planning Assumption: Through 2007, less than 20 percent of IT organizations

will leverage TVO methodologies for IT operations management investments (0.8
probability).
Financial: Business-Focused
(Total Value of Opportunity)
1 Measuring Business Value: Assessing Benefits Dynamic Benefits
Gartner Business Performance 3 and Costs 4 Realization
Framework (Partial) (Quantitative) (Qualitative)
Business Metric
Baseline
Risk
Direct Payback
Architecture
Business Process Impact
Strategic Alignment
Business Metric
Target Values
Confirm IT
Attribute Ratings
TCO minus
Offsets
2 Identifying Technology Impact
TVO is a new model developed by Gartner for determining the overall business value of an IT-enabled
business investment. TVO uses the Gartner Business Performance Framework as a methodology for
measuring the business performance impact of the initiative being modeled. Both tools attempt to answer
questions, such as: 1) What is the initiative? 2) How will business value be measured? 3) What does the
technology do? 4) What are the benefits and costs? and 5) Is the business positioned to exploit these
capabilities? For example, you can identify a need for improving your costs of sales index — from a
(potential) linkage, IT process cost reduction is one (but not necessarily the only) means by which to
achieve this. You can use this to help identify potential vendor solutions. Once done, however, you still
need to audit your performance — hence the baselining activity to the side. Note that offsets in this context
refer to incidental benefits to be derived that are not the primary objective of the initiative. In addition,
assess the impact of this investment against other metrics called the “Five Pillars of Benefits Realization.”
With this tool, assess how strategic will the improvement be, what are its risk characteristics, and so on.
Action Item: Consider a TVO methodology once you have obtained a service-based posture. TVO can be
used to further refine and identify the key services to be offered.
04C, SYM14, 10/04, AE Page 7
Client Issue: What are the key pieces of the supporting technical framework or
architecture?
Strategic Planning Assumption: Less than 25 percent of Global 2000 organizations will
have a companywide configuration management database by 2008 (0.8 probability).
Technology: Configuration Model

The CMDB — key to effective IT Process (Change Management Interface)
service management Request
for Change
Assess
Approved
Change
Implement
Change
Change
Review
Close
Change
Need to gain agreement on

configuration item scope and
service management life cycle CMDB
process interfaces
Development Production
Most Global 2000 organizations Adapted from “ITIL: Best Practice for Service Support”
will require an independent CM
Sample CMDB Configuration Item Attributes
team and process owner
Category (hardware,
Start with new projects, Server software, documentation,
other)
then convert legacy data Version number
Location
Need to consider tools that Hardware Software
Owner
manage/audit the data (and Status
relationships) as well as enable Configuration item
configuration item discovery “parents/children”
Link to other repositories: RFCs, incident
records, release records, asset info
The cornerstone of the technical component of the operations architecture is the configuration management
database (CMDB). It is the key to effective IT governance because everything else rests upon it. Change
management, problem management, incident management, event management, capacity planning and
others are more fully enabled with the knowledge of the objects and their inter-relationships within an
infrastructure. Many IT organizations have some form of a CMDB, but most of them lack formalized
processes for their maintenance, auditing and management. The most common CMDB is a Microsoft Excel
spreadsheet that clearly has limitations in terms of describing complex relationships, being able to be
shared among many users and others. While many service desk vendors provide life cycle asset
management repositories that are morphing into configuration databases, there are firms such as Troux
Technologies that are providing CMDBs from the ground up. Even traditional systems management firms,
such as BMC Software, have announced plans to introduce a CMDB (based on Remedy Service Desk
technology).
Action Item: Start CMDB planning now. Even if you don’t know all of the different types of configuration
items to use, develop an schema that can be expandable.
04C, SYM14, 10/04, AE Page 8
Strategic Planning Assumption: IT organizations that take the time to develop a

transaction model will reduce problem isolation time by greater than 50 percent (0.8
probability).
Technology: Transaction Model

The “radio isotope” or trace view
User or Web Application Database Key requirement for
Program Server Server Server problem resolution and
change management
Team effort needed to
develop
Limit exercise only to
mission-critical
transactions
Vendor tools enabling
transaction tracing are
increasing
Service Service Service Service

Requester Provider 1 Provider 2 Provider X
architecture?
A CMDB typically provides static relationships — that is, a server is connected to a specific switch port or
other. Transactions are transient, and so they often are not included in the composition of a CMDB. A
transaction model needs to considered after the development of an initial CMDB schema. Transaction
models describe the “paths” that a transaction flows over the IT infrastructure. They identify the nodes
visited and even the component interactions within, for example, a J2EE application server. Why do this?
How many times have you and your colleagues gathered into a war room to determine where a transaction
is failing? It often takes hours, if not days, to figure out where the breakage occurred. A transaction model
can help to reduce this activity significantly. The caveat is that it will take a great deal of upfront work to
develop necessitating working with colleagues in other parts of the organization — development,
architecture and others.
Action Item: Don’t boil the ocean — start with perhaps your top 10 mission-critical transactions. This will
allow you to develop a process that can be leveraged in subsequent discoveries.
04C, SYM14, 10/04, AE Page 9
Strategic Imperative: Developing the metrics model will require communication and
coordination across operations, development and architecture organizations.
Technology: Metrics Model

Likely to be a combination of
SLA/Stakeholder Requirements
vendor and internal activities
Instrumentation Plan Develop listing of key parameters
needing measurement (per
Internal stakeholder), including sampling
Vendor Products frequency, error conditions,
Development
Contact insurance Wait for delivery
change Receive change Complete change Wait for change
alerting criteria, others
Business
company packet packet forms Send to insurer processing
Include the “owner” of each

Receive change Send change Receive Copy info to Verify information
request packet completed change member form (if necessary)
information
Process Enter info into

central database
Prepare & mail
confirmation letter
Send info to
imaging center
Image center
scans & indexes
documents
Receive
confirmation letter
metric to ensure consistency

Transaction during infrastructure updates
Service Internal applications will require
APIs (Application Response
Measurement and others) to
Presentation
Data Access
Database
Busines
Logic
s Logic
Logic
Application
provide exception and
Infrastructure
performance data, as well as
control
Instrumentation vendors: AdventNet, Computer Associates, Microsoft, tang-IT and others
architecture?
A metrics model describes the necessary data types to enable management of your IT infrastructure. This is
an expandable listing, because it will reflect changes to your environment — for example, adding a new
application. Each metric must have a description of why it needs to be collected, how often it needs to be
collected, an identification of an error condition when certain values are obtained and an owner (to ensure
that the information remains valid). Metrics can be obtained through available programming interfaces (for
internally developed applications) or they can be surfaced through third-party management agentry. Metrics
need to be thought about at several levels — from the business process to the hardware infrastructure. The
benefit of a metrics model is that it offers a degree of vendor independence — that is, if you know what
data you need, you may be able to substitute the means of obtaining it (in other words, the use remains the
same — but the access mechanism or product can be interchangeble).
Action Item: As with a CMDB, start small. Start developing a metrics model for new applications and
services, and gradually incorporate legacy systems when resources (and demand) permit.
04C, SYM14, 10/04, AE Page 10
Strategic Imperative: While operations is in charge of the construction of an events model,

it will require coordination with development and lines of business to establish event
severity.
Technology: Events Model

Key to Automation: Standardization Eclipse Hyades
Project
Infrastructure and events! IBM CEI/Autonomic
Computing Toolkit
Analysis Automation
Engine Engine
Common Event Format

Detecting Affected Situation Message
Severity
Component Component Category Text
*Influencing
Adapter Adapter Adapter Organizations:
DMTF, DCML
OASIS
Event
Sources
Custom Packaged Infrastructure Management
Applications Applications Components Agents
architecture?
An events model is designed to improve an IT organization’s ability to filter, correlate and automate
responses to alerts and indications of performance degradation or failure. Devices, applications and other
pieces of the IT infrastructure signal events in a variety of formats — SNMP, Windows Event Logs, JMX
Mbeans and others. It becomes extremely difficult to manage the handling of this information when the
data that an operator would be searching for can be found in variable locations in the notification.
Normalizing the event into a standard format enables more-rapid identification of the related indications,
and enables the IT organization to more-effectively script a response. Standardization will also enable
another degree of vendor independence as the scripts can be tuned to an appropriate company format —
and not to a vendor-specific layout. Vendors are starting to get in the act themselves — IBM has an
initiative to develop “common event indications” as a means by which to better manage an IBM
environment.
Action Item: Operations and development need to work together to enable this capability as many in-house
applications have varying ways that information is written to system logs.
04C, SYM14, 10/04, AE Page 11
Strategic Planning Assumption: More than 30 percent of Global 2000 companies will
internationalize management information for regional stakeholder consumption by 2007
(0.7 probability).
Technology: User Model

Quality
IT operations architectures Service

Assurance
Development
Desk
need to be developed with
the (data) user in mind
Application Line of
IT operations data is not Support View Business
only for operations —

Controller
many stakeholders have Operations
Customer/
Partner/
(vastly) differing needs Vendor
User
In addition to raw data, Model
consider presentation
interfaces, access control,
availability, localization and
other factors Transaction
Model
Configuration
Model
Events
Model
Metrics
Model
architecture?
So far, we have identified metrics, transaction and events models (in addition to the CMDB). But what of
the users of this information? Too often, management systems are acquired without significant thought
given to (all of) the stakeholders that will want or need access to this data. Who are the stakeholders?
Operations, but also application support, the service desk, quality assurance, development and, of course,
the more common payer for these systems — the line of business. Also, you might want to provide access
to your systems to third-party management vendors to assist in problem diagnosis. Thus, beyond what
information do they want to see, consideration needs to be given to its format, currency and, because we are
becoming a more interconnected world, language. Take a page out of programmers’ approach to Model
View Controller, where the data is separated from it’s access mechanism, which is separated from its view
or presentation.
Action Item: Identify the information requirements of your company’s stakeholders prior to the acquisition
of management technology.
04C, SYM14, 10/04, AE Page 12
Client Issue: How will processes improve the functioning of an IT operations architecture?
Tactical Guidelines: Individual process frameworks are useful, but a broader holistic
approach to process and quality improvement offers a more complete impact.
Process: Models Impacting the Market
Process Model Selection Framework Anticipate leverage

Specific attributes from
TCO
several models
ITIL CMM
IS/IT
ITIL provides
Relevance guidance on
CobiT
taxonomy and
Misc. Maturity and coordination of core
General Capability Models processes (but it is
(e.g., People CMM)
not prescriptive)
Six Sigma
ISO9000 Measurement and
National Awards
baseline!
(e.g., Baldridge) This is an evergreen
Holistic Scorecards activity, not a one-
time exercise
Low Moderate High
Level of Abstraction
In adopting process-based service management principles, IT organizations face a variety of choices for
developing continuous-improvement competencies and managing a transformation to a process-oriented
culture. There are frameworks, models, standards, methods, practices and tools — each of which has been
considered at some point to be the panacea that will bring predictable performance, guaranteed service
levels and demonstrable cost optimization to the IT organization. The truth is that none of them offer an
end-to-end solution to help the IT organization institutionalize and systemize process management
disciplines for delivering quality service. The models in the upper right are extremely relevant to the IT
organization, and they can be powerful tools for improving performance. But the tools themselves will have
little meaning to anyone outside the IT organization. The models in the lower right have achieved high
degrees of credibility with business people, so the IT organization that can employ them successfully will
earn credibility. However, the models are significantly less helpful in determining what the IT organization
must do to improve performance. The answer concerning which approach to take — that is, highly specific
and prescriptive, or generic and abstract — will depend on a variety of cultural factors.
04C, SYM14, 10/04, AE Page 13
Strategic Planning Assumption: Through 2007, 50 percent of enterprise-level process and

organizational change will fail as a direct result of ineffective or insufficient executive
sponsorship and leadership (0.7 probability).
Process: IT Governance
Senior leadership mandate Key Functions
required
Develop recognition of success IT governance vision/charter
Process policy and procedure
Meaningful enforcement of
Roles and responsibilities
policy
Workflow and status
Emphasis on communication
Approvals and notifications
Engage tools for automation Interfaces to other processes
process Dependencies
Metrics/reporting
Project management, prioritization and
scheduling
Funding and infrastructure investment
Standards, tools and vendor criteria
Governance is the mechanism for assigning decision rights and creating an accountability framework that drives
desirable behaviors. It brings order to chaos by clearly delineating who gets to decide. Furthermore, governance
provides a channel for resolving the inherent weaknesses of the organizational chart, which delineates the formal
decision-making process. IT governance must deal with cross-boundary issues, such as companywide project
prioritization, infrastructure evolution and funding, and sourcing strategy. Moreover, governance must overcome
personal agendas (corporate politics) to instill a culture of discipline. These complex issues and the multitude of cross-
boundary relationships that must be traversed to reach decisions drive an increasingly complex model of IT
governance. Governance isn’t really about auditing. Rather, governance specifies the constraints in which the IT
organization must operate. It creates a playing field in which the rules are known. For business leaders who want to
step into the driver’s seat, IT governance represents their new “rules of the road.” This discipline isn’t the imposition
of a tyrannical leadership team with absolute decision-making authority. Instead, it’s an orientation toward processes
for decision making, along with requisite knowledge and experiences for informed decisions. The more a company
sticks with its three disciplines — people, decisions and action — the more opportunities there will be for growth.
Effective IT governance provides the basis for disciplined decision making within the realm of IT. This discipline will
translate into maximizing the business value of IT and, potentially, sustainable growth for the company.
Action Item: Disciplined people are a necessary ingredient for sustainable growth. Use the competency model for IT
organizations to ensure that the right people and skills are available for effective IT governance and disciplined
decision making.
04C, SYM14, 10/04, AE Page 14
Strategic Planning Assumption: Through 2007, companies embarking on an IT operations

architecture standards will have a 60 percent greater success rate in re-engineering and
maturing key process areas (0.7 probability).
Process:
Core Problem, Change and Configuration
Customers
Defined processes create LOB

VISA
MasterCard
American Express
a common nomenclature SLA
Document workflows and

establish appropriate
escalation road map
End Users
Establish postmortem and
reporting
Change
Management requires Problem
Control
evergreen culture
Change
Incident
Execution
Configuration
Many IT organizations struggled in the 1990s with defining processes. Using process models, such as ITIL help jump-
start that effort as IT maturation requires defining and documenting core processes. IT change management is a
process that enables a company to modify any part of its IT and communications environment, and supports the
documentation, approval, prioritization, implementation and review of the modifications. The goal is to enable
controlled changes while preserving the integrity and service quality of the production environment. Change execution
provides guidance successful rollout of software and related hardware. Configuration management is integral to
change management. By definition, configuration management is the identification and maintenance of the IT assets
and the relationships and dependencies among them. This enables IT organizations to address proactive tasks of
change planning, risk assessment and impact analysis. Problem and incident management are associated with how to
handle breach of service to the IT organization’s constituency base. Problem management is the detection of the
underlying, root causes of incidents, thereby resulting in their resolution and prevention, while incident management is
to restore normal service operation as quickly as possible and minimize the adverse effect on business operations. All
are affected by the level of maturation of change and configuration, so in the broadest context, these core processes
are inextricably linked.
Action Item: Process changes are inseparable from organizational and automation changes. Work them holistically
on a service-by-service basis.
04C, SYM14, 10/04, AE Page 15
Tactical Guideline: To meet the business demand for SLAs, IT organizations must work
with their business units to establish metrics that provide business value, but that can be
measured by the IT organization and that demonstrate the commitment to the business.
Process: Develop Service Levels

Establish Recognition
1 Know Your Business Value Keys 2
and Acceptance
Solution Sh Business
ar
Va eho IT organization
lu lde
e r
Integration
ROT External service providers

Business
ROA
ROI 4 Link Service to Business Value
TCO
Service-Level Linkage
Business Value
Cost
Support Optimum Service Level
Product Utility Price
Technology
Integration
Underpaid
Overpaid
3 Balance Needs to Technology Capability Performance
Quantitative Business
Service Levels
Measures Value
In the “big picture,” the company gains revenue, profits and shareholder value by providing competitive
products and services to its customers. To fulfill promises made to customers and build customer
satisfaction, each business unit must work with the others. This also is true for the IT organization, which
must convey the value of the services that it delivers to business units. The business processes often are
enabled by the IT organization (with an integrated set of applications atop the IT infrastructure), and it must
provide the quality of service (QOS) required to reach the overall business objective. QOS goals are defined
with SLAs between the business units and the IT organization. Implementing these SLAs fosters greater
business/IT alignment by setting expectations and directing each business unit and IT organization toward
meeting those expectations. That is, SLAs help to direct each business unit, department, vendor or
employee’s contribution to the business goals. Thus, business goals are broken down and become people
goals. The missing step is that often, the IT organization has not reviewed SLAs with the business units, nor
has it tried to adjust these SLAs into meaningful metrics that the company can understand to appreciate the
services provided by IT. Hence, it is the IT organization’s responsibility to meet with the business units and
listen to their concerns as they jointly agree to the SLAs.
04C, SYM14, 10/04, AE Page 16
Client Issue: How should the IT organization be organized to facilitate its development?
Strategic Planning Assumption: Through 2007, IT organizations that do not adopt
process-based delivery models will have their service portfolios outsourced at a rate of 25
percent per year (0.8 probability).
Organization: Processes and Structure

Siloed Structure Integrated Structure
silo silo silo silo
Multidisciplinary Team
? ?
Disconnected Activities
Coordinated Processes
Focused on technical Focused on outcomes and

activities or platforms the end-user experience
Functional Alignment Process Alignment
Worst Practice Best Practice
All IT service delivery models are process-based. Process organizations are focused on the outcomes of a
collection of steps, rather than the steps themselves. By treating all activities associated with a process
holistically, the IT organization can optimize performance, reduce latency and cost, and drive service-level
predictability — all of which reduce reactionism and complexity. Processes also create the foundation for
business-based service-level metrics and are the first prerequiste for answering the question, “What
business value does IT deliver?” They are key to managing complex outsourcing relationships and global
delivery structures, providing the common performance framework that all participants are accountable to,
irrespective of their organization or location. After work is aligned around processes, structures also
change, migrating from functional silos, where individual resources are accountable only for their steps in a
chain, to multidisciplinary teams who collectively succeed or fail based on the process and service
outcomes they deliver. This restructuring eliminates handoffs and finger-pointing, replacing it with
collaborative, innovative, customer-centric behaviors.
Action Item: Adopt processes as the primary workflow and organizational framework.
04C, SYM14, 10/04, AE Page 17
Tactical Guideline: IT organizations should map their service strategies to the

expectations and funding of chief IT stakeholders to maximize credibility and support
investment.
Organization: Service-Based Design

Senior Manager
Relation- Service Process Quality

ship Mgmt. Mgmt. Mgmt.
Mgmt.
Process Integrated
AE Service Service A
Owner Process
Cust. 1 Mgr. A Auditor
“Red” Team “Red”
Process Integrated
AE Service Service B
Owner Process
Cust. 2 Mgr. B Auditor
“Blue” Team “Blue”
AE Process Integrated
Service Service C
Cust. 3 Owner Process
Mgr. C Auditor
“Green” Team “Green”
Client Issue: How should IT be organized to facilitate its development?

With an IT services provider business model, siloed organizational structures are replaced by a
service/process-based structure. Four management roles are essential: 1) Relationship or account managers
facilitate the realization of service value relative to expectations. They are the communication bridge
between specific clients and the IT service provider’s broadly managed services. As such, these managers
are pivotal to a given customer’s satisfaction with the services it receives, and the managers should be
empowered to make reasonable commitments on behalf of the service organization to resolve problems and
enhance value. 2) Service managers are responsible for the effectiveness, efficiency and value of a given
service across the customer base. This includes managing gradations in service-level offerings. 3) Process
owners ensure process efficiency and reliability across the range of services supported, and supervise day-
to-day process execution via integrated process teams. 4) Quality assurance managers monitor service and
process outcomes in relation to service contract conditions and self-imposed performance goals. They
facilitate process efficiency through pattern recognition feedback to process and service owners. All four
roles fundamentally require good business judgment to ensure that the value of a service does not exceed its
delivery cost.
Action Item: Organize around services and processes, and create appropriate management roles.
04C, SYM14, 10/04, AE Page 18
Recommendations
Correlate key business drivers to prioritize project
phases within the IT operations architecture blueprint.
Develop a CMDB by establishing a project road map
that breaks configuration management adoption into
digestible phases.
Develop a process model that synthesizes the best
practices among proposed standards with a critical focus
on documentation, communication and benchmarking.
Tribal knowledge-based silos are no longer sufficient to
manage complex environments — leverage processes
to create flexible, virtual teams.
Be accountable — develop a rigorous book-keeping
methodology for IT services and implement consistent
review with all stakeholders.
04C, SYM14, 10/04, AE Page 19
This is the end of this presentation. Click any
where to continue.
These materials can be reproduced only with Gartner’s written approval. Such approvals must be requested via
e-mail — quote.requests@gartner.com.

Sym14 04C

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sym14 04C

Uploaded by

Copyright:

Available Formats

Building an

Effective IT Operations Architecture

U.S. Symposium/ITxpo Cameron Haight

What Is an Operations Architecture?

Operations Architecture: The blueprint embodying an

Transforming IT Benefits to Business Value

changing business needs?

in service cost Portfolio

Strategic Planning Assumption: Through 2007, less than 20 percent of IT organizations

2 Identifying Technology Impact

Technology: Configuration Model

Need to gain agreement on

Strategic Planning Assumption: IT organizations that take the time to develop a

Technology: Transaction Model

Service Service Service Service

Technology: Metrics Model

Include the “owner” of each

Process Enter info into

metric to ensure consistency

Strategic Imperative: While operations is in charge of the construction of an events model,

Technology: Events Model

Common Event Format

Technology: User Model

IT operations architectures Service

only for operations —

Process: Models Impacting the Market

Process Model Selection Framework Anticipate leverage

Strategic Planning Assumption: Through 2007, 50 percent of enterprise-level process and

Strategic Planning Assumption: Through 2007, companies embarking on an IT operations

Defined processes create LOB

a common nomenclature SLA

Document workflows and

Process: Develop Service Levels

ROT External service providers

3 Balance Needs to Technology Capability Performance

Organization: Processes and Structure

silo silo silo silo

Focused on technical Focused on outcomes and

Tactical Guideline: IT organizations should map their service strategies to the

Organization: Service-Based Design

Relation- Service Process Quality

Client Issue: How should IT be organized to facilitate its development?

You might also like