Overview of what is necessary and sufficient to transform your IT organization to support Infrastructure-as-a-Service technology and model.

1. Managing Your Transformation to Infrastructure-as-a-Service (IaaS)
Introduction
Infrastructure as a Services (IaaS) will transform nearly every role, and most procedures and processes,
within your enterprise’s Information Technology (IT) organization. This seismic change can be difficult
to embrace and accept: people worry about job security; employees and contractors require training;
procedures and processes are added, removed, and modified. Hiccups and false starts may erode
confidence. And, no matter how beneficial the change, you still have to deal with the fear of the
unknown - status quo is a powerful force. The best technologies will not remove these myriad
challenges. Therefore, how you proactively address the change to IaaS will be the biggest factor in
determining the success of your transformation effort.
Organizations can handle the transition to IaaS in a number of ways: They can try to dictate changes
from above, pilot and POC to small groups to gain adoption, or plan out detailed, strategic
transformation plans, activities and initiatives. Ideally, you incorporate all approaches: Create and
execute transformation plans, which include pilots/POCs, with formal, explicit buy-in from IT and
Business leaders. But is there a best way to manage the transformational change to IaaS?
This document outlines the necessary and sufficient conditions for successfully transforming your
organization to IaaS. This document doesn’t offer specific transformation plans. It doesn’t offer an all-
encompassing or best-practice approach. When it comes to change management, I’ve found that
organizations either do too little or too much: Either they don’t do change management at all, or they
plan out a massive roadmap based upon a grandiose strategy that can’t be implemented. Doing what is
necessary and sufficient seems to work well enough to gain momentum and adoption of IaaS. This
good-enough approach results in the expected business benefits of IaaS including reduced OpEx and
CapEx costs, greater speed and agility delivering applications, and improved user satisfaction. So what
changes, at a minimum, do you need to manage when migrating to IaaS? You need to address the
following areas:
1. Stakeholders
2. IaaS Roles
3. IaaS Processes
4. Training
5. Pilots and POCs
6. Marketing

2. Identify Stakeholders and Stakeholder needs
To successfully transform organizations, and therefore members within affected organizations, start
with the question, “What’s in it for me?” The first thing everyone wants to know about IaaS is how will
IaaS help, hurt, or change their job. The following organizations/roles are heavily impacted by IaaS:
 IT Infrastructure (Server, Network, and Storage): Wants to automate mundane, repetitive tasks
to focus on high-level activities including capacity and demand management, technology
refresh, and supporting M&A activities.
 Security and GRC: Wants to protect the entire IT environment including facilities, infrastructure,
applications and data from being compromised. Wants to maintain control of risks and
compliance with external standards and regulations (HIPAA, PCI-DSS, SOX, Meaningful Use, etc.),
as well as internal, organizational standards (RBAC, OS & application hardening, etc.).
 Application Development (VP, teams, leaders, developers, contractors): Measured by how
quickly they offer new applications and features to end-users and markets. Wants agility and
flexibility delivering new applications and features. Highly innovative and very technical; have
little issue with taking hands-on approach to infrastructure when required.
 IT Operations (Tower leads, administrators): Number one priority is to keep the lights on – do
nothing to disrupt production IT operations. Desires simplification in the monitoring and
management of entire enterprise IT infrastructure. Wants proactive identification and
remediation of issues and problems.
 Release Management (Release manager, deployment teams): Introduce planned changes into
production without causing issues, problems, or outages. Minimize dependencies to reduce
complexities involved with deploying new applications and services. Dreams of having
standardization across release life-cycle (Test, QA, UAT, Prod, etc.) I consider ERP and COTS
packages to be included in this category of stakeholder.
Your organization may have different names for the above stakeholders, and may have additional
groups to consider. However, in general, the above stakeholders are of primary IaaS change
management concern.
IaaS groups these stakeholders into three primary categories: Producers, Consumers, and Maintainers
of Services. Applications Development is a major consumer. IT Infrastructure is a producer and, in most
cases, also a consumer of services. IT Operations is a maintainer of services. Most other organizations
play a dual role in helping to produce services as well as consuming services, at least indirectly.
Producers will be responsible for the architecture, design, and maintenance of services. I’ll discuss this a
bit more when I address Service Processes in a section below. From a stakeholder perspective,
deliberate thought needs to be put into how you define Tenants, Divisions, and Groups. How you
demarcate consumers will play a role in how you approach transformational change. Consider each
“level” of the IaaS consumer hierarchy:
 Tenant: A Tenant expects dedicated, if not isolated, infrastructure. The tenant owns (creates,
modifies, retires, governs) all service templates and processes. Often, the only thing a tenant
expects from enterprise IT is that there’s capacity underneath all that Cloud stuff.

3.  Division: One or more divisions can belong to a tenant. A division will share, with other
divisions, the infrastructure of the tenant. However, divisions usually have reserved, or
guaranteed, amounts of capacity promised to them from the tenant. Divisions typically use
templates and processes provided by the tenant, but may have some divisional unique
differences incorporated into separate templates and provisioning processes.
 Groups: Groups share all infrastructure, processes, and templates within the division and tenant
they belong to. Groups typically do not get reserved or guaranteed capacity. They don’t own
their own templates or provisioning processes. So what exactly is the benefit of a group?
Groups offer a construct for providing granular, role-based access control (RBAC): who has what
access, to what services, using what provisioning processes. In addition, groups may allow for
variations in provision-time configuration requests such as lease times, e.g. development team:
max 100 concurrent instances, max 90-day lease, prod team = max one concurrent instance, ∞
day lease.
As far as I know, there is no standard to the “levels” of an IaaS consumer hierarchy: You may settle on
one tenant, you may have several divisions but no groups, you may even allow capacity reservations
within a group. However, in my opinion, I think the above definitions should be considered a best
practice. They provide flexibility and the right amount of demarcation needed to govern an IaaS cloud.
Ultimately, it’s what makes sense to your organization that matters. Determine the structure,
communicate it, and manage expectations throughout the transformation. For example, if isolation is a
valid concern of a business division, make sure you communicate the intent to make that division its
own tenant.
IaaS Roles
New roles and responsibilities emerge from the transformation to IaaS. Most of what I have seen is a
matter of role convergence. For example, several IT teams may have been involved in determining how
to provision a server (or VM): WinTel team, network, security/AD, storage. They collectively create a
“build script.” No one person seems to have ownership over the build script. IaaS converges the
management of a server build to one role, the service manager. New roles to consider include:
 Services Manager: Responsible for coordinating all the decisions and activities involved with
creating and maintaining services. Optionally, works with Services Liaison to establish Service
Level Agreements (SLAs). Most likely manages, or works with a team responsible for business
process workflow. This team may even be a governance board that defines and blesses
provisioning processes and approvals.
 Services Liaison: Works directly with consumer groups to gather requirements and feedback
regarding services. Works with the service manager to incorporate needs and modifications
based upon consumer needs. Reports issues including usability and functional correctness of
services. Optionally, works with Services Operator to establish Operational Level Agreement
(OLA).

4.  Services Operator: Monitors and manages capacity, performance, and availability of service
from “holistic” approach. Coordinates deep-level diagnoses with server, storage, and network
operations.
 Tenant Manager: Administers all resources within the tenant construct including infrastructure
capacity, and division, group, and user access and privileges. May be a role within IT itself are it
may be a consumer role. Works with Services Manager, Liaison, and Operator in support of
tenant users.
Service Processes
As you can imagine, the new roles are responsible for managing and executing new IaaS process. Most
of the process change is around service life-cycle activities. Not surprising, it’s also about letting go of
processes made obsolete by automation. You may be surprised at how difficult it is to eliminate a
process within enterprise IT, especially approval processes!
Service Definition: Working with all stakeholders, define what the services are, what catalogs to place
them in, who should be entitled to the service, what meta-information to include with service, the
workflow and approval process, etc. For example, you could create a master Win2012R2 server service
that all Divisions within a tenant can provision. However, you may want to define specific IP address
ranges based upon divisional pools and naming standards. You may require certain configuration
flexibilities at provisioning time. All these choices need to be defined upfront when possible. The
macro processes over all these services should be a governance framework that limits the number of
standardized services so that you don’t end up with services sprawl. It’s easy to get carried away and
end up with a 100 versions of a Linux RHEL v6 server.
Service Design & Deploy: These are the activities required to create a service based upon service
definition. Using virtual, workflow, and automation tools to create the self-service provisioning of IT
services. Much coordination with other IT groups are required at this stage to integrate with
provisioning processes including IP addressing and subnetting, sysprepping servers, updating CMDB
entries and ITSM tickets, etc.
Service Management: Processes involved with determining how to update a service already in
production. I find these processes the most difficult to define and agree upon. For instance, many
organizations want multiple versions of a “gold image” to make sure a server service is always at the
latest patch release or hardening specification. However, that can become a template sprawl
nightmare. Better to avoid the constant patching of a golden image within your service templates and
instead use technologies that keep instantiated services up-to-date, and prevent “drifting” from
acceptable standards. Several products on the market support this including Puppet, Chef, vROps CM,
etc.
Service Retirement: The special case within Service Management. When do you decide to retire a
service and how do you retire it? Communication processes, archiving, replacement, etc. Things like
End-of-Support and End-of-Life become necessary terms to socialize. You need to have perfect visibility
into current the provisioning as make sure consumers have a frictionless upgrade or replacement path.

5. Service Costing: How will you track usage, determine services costs, and report that cost to consumers?
You can do this with systems logs, spreadsheets, and other reporting tools but that requires a full-time
army of analyst. Best to look for a tool or platform that allows you to automatically collect, track and
report usage and cost. Most enterprises would do well to start with a show-back or shame-back model
before moving towards a charge-back model. In fact, I recommend most organizations don’t even worry
about costing until they’ve offer3ed IaaS for a decent amount of time, say 6 – 12 months.
Service Maintenance: Some call this Service Management (and that’s fine but be sure to distinguish
meaning). Maintenance processes manage the deployed service once in production. To me, this is an
extension of traditional operations management but you’re trying to roll-up all the underlying
monitoring, troubleshooting, and management to the service itself. A proper services operations
management tool is critical to supporting this function. These processes should allow for the services to
maintain performance, capacity, security, availability, and other SLA related goals.
Legacy Onboarding: Hardly anyone thinks about this but it’s absolutely critical to success. Yes, you are
providing new services through IaaS, but most of the enterprise is probably made up of legacy stuff that
will be around for years. Putting processes in place to onboard legacy services allows you to reduce
multi-management and multi-operations processes and tools. Processes should include testing and
staging areas, methods for determining placement with tenants, divisions, and groups, and day-2
entitlements, if offered through the self-service catalog.
Training
Ideally, your IaaS offering will be intuitive and easy to use, like most of today’s consumer technology.
Little should be required in formal training. A short document or video should be sufficient to get
consumers started with IaaS. Service Producers and Operators will require substantially more training.
Thoughts on training during the transformation to IaaS:
 Knowledge transfer during on-the-job training is the best training. Not only do people get
insight into what is being created, they get an opportunity to understand the hows and whys. In
addition, knowledge transfer tends to generate buy-in and goodwill from stakeholders. They
become vested in the solution and what to see it succeed.
 Training from vendors and other external sources is fine, but should always be delivered Just-in-
Time (JIT) to use actually use it. I’ve seen too many cases of front-loaded training fading from
people’s memories weeks before actually needing the skills.
 Create run-books, user guides, and tutorials. Document and share necessary procedures and
processes for producing, consuming, and operating IaaS. In my experience, most vendors will
share template or sample guides on how to use their IaaS solutions. Take these vendor offerings
and make them your own.
 Offer a hands-on lab. Perhaps the best training I’ve experience is when I can play with the
solution without worrying that I break something. If possible, take your Pilot or POC IaaS
environment and convert it to a hands-on lab for all to experience.

6. Pilots and POCs
Without question, I don’t think any enterprise organization should jump blindly, and with both feet, into
the IaaS pool. Either pilot (a very small project [subset of the desired solution] that could be put into
production), proof-of-concept (POC) (something considered throw-away after it’s proven the entire
solution is viable), or both. It’s worth taking 30 – 90 days to pilot a couple services your organization
finds valuable and/or interesting. The idea of the pilot is to demonstrate you can remove the
complexity, wait-time, and labor effort involved with provision a service into production. This may be as
simple as providing a standard Linux RHEL server or a Windows 2012 R2 server. Avoid the complexities
involved with provisioning multi-node or multi-tiered environments, or environments with middleware
“baked-in.” The keys to making an IaaS pilot a success are:
 Find a consumer group excited about change and willing to deal with the risks and frustrations
of issues and setbacks. In my experience, your organization’s internal web development team is
a great candidate for a pilot: they require fast provisioning to dev/test, often use homegrown
tools, and often have already moved to “shadow IT” and public cloud solutions.
 Define the goals and expected outcomes of the pilot. If you take 10 weeks to provision a
production server, set a goal of 5 days. If you are trying to standardize server builds, attempt to
reduce the number of versions from 50 to 5. If you know it costs $12,000 to provision a server,
try to provision one for $1,200. You get the idea! You need to have goals to strive for and prove
that IaaS is valuable to your organization. Meeting or exceeding these goals during a pilot also
offers great marketing material.
 Go all the way! The goal in the pilot shouldn’t be to produce a service that can’t be used. A
server (or Virtual Machine) without IP connectivity, un-joined to an AD domain, with no
performance and security monitoring is not much of a service. The end result of the pilot
should be to repeatedly deploy a service (server) into production, fully ready for operations if
you so choose.
 Document everything! Document how you defined a service, built the service, offered it to
consumers. Document feedback from producers and consumers. Record all the issues you
encountered. Make a “parking lot” of service features and functions you would incorporate into
your production IaaS offerings. Lastly, document the time, effort, and cost expended to create a
service so that you can estimate bigger IaaS projects going forward.

7. Marketing
Lots of IT folks cringe when I use this word. But hey, enterprise IT is becoming very much like consumer
IT in that enterprise users now have choices. The users also have expectations driven by consumer self-
service usage and are comfortable paying for services, not assets. Most people outside of enterprise IT
do not see IT as being an agile provider of services. IT is viewed as more of an owner of expensive
monolithic assets with long, archaic processes for acquiring, installing, and managing stuff. You’ve got
to communicate the great stuff you’re offering with IaaS; the benefits to each stakeholder. Here are
several successful ways to market your IaaS solution:
 Demonstrations. At a recent client, we offered weekly demonstrations at set times. We also
offered highly tailored demonstrations to specific stakeholders at specific times. Keep
demonstrations short and to the point by answering the following questions: What’s the
solution? What’s the benefit to the stakeholder? How does it work? Do this in less than an
hour, ½ being preferred with time for Q&A.
 Offer hands-on access to pilot/POC. The pilot is not only a training tool, it offers you a chance to
market the IaaS solution. Use branding and personalization to make it feel real to the
consumer.
 Town Hall or group meetings to provide solutions overview. Show progress by demonstrating
solution on actually production systems.
 Occasional email flyer. Don’t spam but do send out infrequent notice of progress and available
features. Offer link to access pilot system or instructions on how to gain access to production
system. Offer contact information and announce dates of demonstrations and town hall
meetings.
One Last Point
Gather and incorporate feedback as you advance along the path towards IaaS. I’ve seen clients have
initial success but fail to follow through on ideas, complaints and criticisms of stakeholders. I have yet
to see a linear experience going from IT asset based provisioning to IaaS based provisioning; there’s
usually a few zigs and zags along the way. Moving to IaaS means moving towards a services-based
business model. Customer satisfaction is the life-blood of any services business, so seek out customer
feedback early and often. Good luck!
About Digital Peak Consulting, LLC
Digital Peak Consulting focuses on helping clients leverage the Cloud, in all its, flavors, shapes, and sizes,
to lower TCO and improve your mission capabilities.
Mel Stockwell
Principal Consultant
720.624.9087
mel.t.stockwell@gmail.com