Making sense of Cloud Computing - Part 1

One of our customers has asked us to produce a short course on Cloud Computing. While it's always easy to chalk this up to yet another round of IT Buzzword BINGO, the business models driving the interest in cloud computing are real, important, and must be understood if you want to be able to sustain your service value for your customers. This week, we're going to look at a number of different aspects of cloud computing and why they matter. We'll also take an honest look at the challenges that these models create, especially for security and privacy.

Today: Financial Models and Utility Computing

Most IT managers and staff are used to working with tangible service assets they own; hardware, software, tools, and other assorted infrastructure, applications, and platforms. Based on our available resources and organizational capabilities (knowledge, skills, processes, etc.), we would design, plan, develop (or buy), and deploy services in support of our clients. This required the IT organization to use the business's capital to invest in IT assets, which may or may not be optimally utilized (consider hardware utilization, applications and associated licenses, data center infratructure and environmentals, etc.). Capital investments require a substantial commitment of time and upfront money to create a capability, long before a payback period begins (when the new service is delivering value in operations). If the business's needs evolve, substantial changes in service warranty are needed (capacity, service continuity, security, and availability) and will require rearchitecture, re-provisioning, and ultimately waste time and resources.

Most businesses seek a different model (and not just for IT!). Businesses generally prefer operating costs (pay-as-you-go) to capital costs, because we can stop buying it if we don't need it, or request more capacity or a different level of continuity or security (availability is a bit messier, as we'll discuss later this week) for an understood price per service. Utility Computing is really nothing more than delivering on the promise of ITIL Service Level Management, where for an understood and agreed price we will deliver an agreed level of service at a defined level of quality. The biggest difference then is WHERE we will deliver it...

In the Cloud Computing context, as with the ITIL Service Model, we seek to deliver value to customers while avoiding the ownership of certain costs and risks. Depending on the level of Cloud Computing your organization may consider, this includes potentially choosing not to own

- Applications - we'll use providers with SaaS (software-as-a-service) models to host and deliver key software applications, especially generic ones like productivity applications (a la Google docs) and ones where access across a number of devices and locations is a strong benefit (CRM applications like salesforce.com)

- (Development) Platforms - we'll count on our cloud providers to provide our developers with rich toolsets for building and deploying cloud applications; for example, Microsoft Azure extends .NET developers tools to build in the cloud.

- Infrastructure - we'll take advantage of the benefits of server virtualization, grid computing use of processing capabiliites, and enormous server farms managed by providers such as Amazon, Google, IBM, and many others to scale our storage, data management, and processing needs as they evolve, and make agility and real Capacity management far more accessible and realistic.

As our ITIL readers know, effective provisioning of whole services to customers involve the correct combination of these three things aligned with the business's needs and managed to deliver a reliable underpinning of their key business processes. Clearly cloud computing has enormous implications for the entire service lifecycle. To deliver "utility" computing, we must do more than just create pay-as-you-go models; we must actually deliver the right level of utility!

Next time, we'll talk about Cloud Architecture

Linking ITIL with Project Management

One of the many issues facing organizations trying to get substantial traction with ITIL initiatives is the incorrect perception that ITIL is "for operations." I can't begin to count the number of developers and project managers who have openly asked in one of my Foundations classes "this isn't for projects, right?" Well, yes, of course it's for projects, since projects are how we perform most activities in IT; design, development, service improvement projects, new service initiatives, and the list goes on.

In many cases, the ITIL community is firmly responsible for this misconception. Asked to describe their ITIL adoption and good practices, they inevitably point to Service Desks, Incident and Problem Management processes, and occasionally Change Management or a CMS tool implementation (often without an underlying CM process to drive its use or efficacy).

With ITIL v3, we have a chance to fundamentally reset everyone's expectations of ITIL. We now acknowledge the whole Service Lifecycle, beginning with Strategy. It's reasonably easy to see the parallels of the activities of Service Strategy and Service Portfolio Management with a PMO; look at business cases, assess ROI and VOI, and approve and charter projects. Likewise, Service Design and Transition provide clear processes and guidance for managing the tactical aspects of capturing functional, nonfunctional, and usability requirements (think utility and warranty), performing service and measurement design, developing or acquiring applications, infrastructure, and metrics management tools, coordinating testing and validation, and overseeing transition planning and execution and operations uptake. These are the fundamental parts of planning and executing any good IT project, and would look very familiar to a PMP. By the way, these models work brilliantly in agile development models as well as more traditional waterfall approaches (which don't work, but that's a different post).

The biggest risk we have for successful ITIL adoption is that very often senior IT management really has no idea what ITIL really is. They think in terms of the most basic Service Operation processes, the Service Desk function, or maybe Change Management, but generally have absolutely no idea how ITIL helps to bridge the yawning cultural chasm in many organizations between Development and Operations. When we teach that Management Commitment is a mandatory critical success factor for ITIL implementation, it begins with basic understanding and clarity of vision across the Service Lifecycle.

Virtual Course Launch

Today is a big day for Deep Creek. Today we are announcing our very first public schedule for ITIL learning programs, supported by an army of sales partners eager for a consolidated calendar of available ITIL courses. The content of the release is included here...

Deep Creek Center

6609 Blackwatch Lane

Highland, MD 20777

410-456-4217

January 7, 2010

For immediate release

Deep Creek Center launches Industry’s Most Comprehensive ITIL Learning Program

Solution to fix access to ITIL Intermediate and Advanced training programs

Deep Creek Center, a leading provider of ITIL training, mentoring, and consulting services, announced the launch of a global initiative to combat limited access to the skills-based training needed to support industry ITIL initiatives. Deep Creek’s comprehensive ITIL certification programs will be made available in a live-over-the-Web format and will provide a guaranteed way for students looking to get high-quality expert-led training to get the training they need, regardless of location.

“The market has had a difficult time providing access to the Intermediate and Advanced ITIL learning programs that many organizations need to ensure the success of their ITIL adoption activities,” said Patrick von Schlag, President of Deep Creek Center. “Deep Creek has offered accredited private on-site and rich-media self-paced learning options for a number of years, and these options meet the needs of a number of customers. But for small and medium-sized businesses, as well as businesses located outside of major IT markets, access has been very limited. In addition, the needs to consolidate demand have resulted in very high class cancellation rates around the industry. Deep Creek is the first ITIL provider to commit to run all of its courses, and to provide the guarantee that customers need to commit money and time to training their staff in ITIL best practices.”

“Supporting the ITIL training space has been very challenging”, stated Andrew Wight, CEO of CompuWorks, a leading IT training provider in Boston, MA. “While there are many companies with broad needs to train their teams in ITIL Foundations, taking care of students with more sophisticated needs has created a supply/demand problem in many regions. Deep Creek’s instructor-led online live programs help to address this issue and help us meet the needs of our enterprise class customers who are serious about making ITIL work in their organizations.”

Deep Creek and its partner channels train millions of students annually in IT and IT management disciplines. Deep Creek Center is a leading provider of IT skills development, certification, and learning consulting services. We help organizations plan, build, and validate effective, integrated learning solutions that provide demonstrable, tangible business results.

Picked up

Happy to note that our recent post on Change Management was released to the larger ITIL community as this week's DITY by ITSM Solutions.

http://www.itsmsolutions.com/newsletters/DITYvol6iss1.htm

Amazing how they can photoshop my picture...better than plastic surgery.

ITIL Hands make light work...

Today's post really is meant to remind all of us (myself very much included) why ITIL and IT service management matter. 20 years ago, if my e-mail service went down, hardly anyone even noticed (On my BITNET account, I probably could send e-mail to about 5 people). Now, an e-mail outage can disrupt world commerce (ask anyone who has a Blackberry). Over the last 20 years or so, IT has transformed from a nice-to-have business enhancement to truly a utility - something that is basic and mandatory to operate virtually any aspect of a business.

This means that IT/business integration and alignment aren't hackneyed buzzphrases, but absolutely necessary to the organization's survival. We shouldn't use the ITIL framework or any other frameworks, models, or quality systems to add certificates to the wall, but to enable our businesses to meet their mission. If our IT teams understand services and service culture at its most basic level as our role in enabling the business to achieve its goals, we will be much more effective, and a much more powerful asset for our business partners.

Request Fulfillment is really obvious...and really important

One of the new processes in ITIL V3 is the Request Fulfillment process. The premise is simple enough; we get a number of routine service requests from users, so how do we deal with them and get them taken care of in a way that minimizes the pain? Users want us to facilitate the approvals process and cut red tape, and we in IT want to automate as much of the workload as possible so that we can invest more of our resources and capabilities in other activities that may deliver higher business benefits. The part a number of organizations struggle with is exactly how this works, and here is where we need to look at linkages across the lifecycle.

Back in Service Design, we describe the process of Service Catalog Management and the notions of the Business Service Catalog and the Technical Service Catalog. Business Service Catalogs describe the menu of service options available to customers, and Technical Service Catalogs describe the "cookbook", or procedures to provision and deliver the service. By publishing the Business Service Catalog, we make the services more transparent and available to the users. By publishing the Technical Service Catalog to our technical/functional teams, we provide the basis for consistent policies and procedures in deploying these standard services.

The role then of the Request Fulfillment process is to facilitate using these. A heavy emphasis in the books is on automating workflow activities; automating service requests and Financial and Compliance approvals on the client side, and automating provisioning and configuration management activities on the IT side. We can then use our understanding of lifecycle management to break down the process activities, and then look to leverage workflow management and automation tools to speed these through.

Even though Incident Management gets all the press (after all, it's when fires happen that people actually notice IT), Request Fulfillment is the key to maturing your provisioning activities and ultimately in freeing up Operational resources that can be reinvested in more proactive service activities such as Problem Management, Testing and Validation, and Service planning.

Common Sense isn't so common

Sounds like we're having a few of the usual pseudo-debates on a number of the LinkedIn groups again...I always hesitate to get involved in these conversations because so much of this is comon sense, but then again, perhaps common sense isn't so common.

Certification v Experience

Isn't this silly? It was silly for CNAs, MCSE's, CISSPs, and every other certification too (would you like a lawyer who has passed the bar but never tried a case before? A doctor with no experience treating your illness?). Certifications are independent acknowledgements of certain knowledge...and perhaps some developed skills. Coupled with expertise, a bit of wisdom, and the ability to work well in teams, you may have the makings of a good teammate or team leader. People or employers who expect certifications to be a magic bullet are likely to get what they deserve...

Is ITIL a panacea?

People have religious-level discussions over whether "the book" (should we add holy?) says we ought to do a particular thing or follow a particular procedure. All manner of consultants, technical wannabes, and other pretenders pose as oracles interpreting the "word". The ITIL describes a set of good practices that are demonstrated to work well in a variety of environments. Please understand that in no way does this mean that there are no other ways to do the same things well...or that all the "answers" will be found.

"The ITIL requires that we..."

ITIL is a set of books on my (and hopefully your) shelf, sometimes gathering dust, sometimes being very useful. The ITIL doesn't require anything...but our management should require that we use well-tested, validated policies and procedures for how we design, provision, and deliver services.

Be pragmatic, everyone. The goal is simple...help our organizations and customers achieve their mission by providing effective, efficient, and well integrated IT services to support the business.

Changing how we think about Change Management

One of the more challenging problems with deploying ITIL processes is our desire to make workflows linear. We teach the lifecycle one domain at a time, and teach processes in association with the book in which they are described. Reality is seldom so tidy, however. Processes like Change Management, Service Asset and Configuration Management, and Knowledge Management have a much broader scope; they span the entire service lifecycle and can become confusing if we try to limit them to a particular lifecycle domain. In this post, we’ll discuss the reasons why Change Management needs to be “liberated” from Transition, and how this simple idea will improve your organization’s ability to manage change.

Considering Change

Service Strategy describes the notion of managing a Service Portfolio. Our Resources and Capabilities define a set of Service Assets to be invested, with the goal of maximizing returns for our customer (Value Creation) and for the Service Provider (Value Capture). While many of these resources are invested in ongoing Operations activities (somewhere between 60-70%, depending on whose data you see), much of the remainder is invested in new or changed services in our Service Pipeline. The job of Service Portfolio Management is to define the Portfolio, analyze Business Cases for new or changed services, approve a new future state (in other words, choose the business cases we’re going to commit to doing), and charter the new portfolio (which has the effect of establishing projects to proceed to design and build the new or changed service in the business case).

While some Business Cases are requests for entirely new services, most come from different RFCs. Alignment between the Change Management process and what happens in Service Strategy and Design simplifies this workflow a lot. If we consider Change Management to begin in Strategy, RFCs begin with goals and objectives (e.g. removing a Known Error, implementing a CSI recommendation, etc.). By categorizing the Change, Standard Changes are weeded out and pre-approved, Emergency Changes are quickly driven to an ECAB for assessment, decision, and action, and Normal Changes are assessed by the appropriate CAB for cost, risk, impact, and business value. Given the scope of the Change request, some change requests can be handled at lower levels of the organization (though still through formal change management) where larger scope and resource-impacting changes should have Business Cases developed and these considered together as part of the overall Service Portfolio Management process. As a result, we have consistency in our Change Decision Authority, resource alignment and allocation across projects, and a consistent means of prioritizing the work to be done.

Once an RFC is approved, Service Design describes how we build the change, with the Change Management process continuing to coordinate multiple changes and working with other processes to prepare for effective Transition. This could include planning testing and validation windows, scheduling access to build and test environments, planning how changes will be packaged for release and deployment, and verifying business fit. “Coordinating Change” then largely is described by monitoring status of change build, ensuring proper Service Transition and Operational Readiness Plans are in place, and ensuring that communications is maintained among the various technical, process, and business stakeholders. Once the Service Design Package is complete, Release and Deployment Management can take the change and its associated documentation into the DML and coordinate appropriate packaging, build, test, and deployment/installation of the change according to our transition plan. Once deployed, Change Management finishes its workflow as always with a Post Implementation Review confirming technical success and business outcome (based on the Evaluation Report’s assessment of Change Acceptance, Predicted, vs. Actual Performance, and “unexpected side effects”). Assuming we’re good to go (with other remediation as necessary), we can close the Change at this point.

By thinking of Change this way, it’s easier to see how to use groups like PMOs to help adjudicate how projects align to new and changed services, portfolio management goals, and how to align Change authorities more sensibly. Most importantly, it improves our likelihood of delivering well designed, planned, and effective changes more quickly, improving our ability to adapt IT services to meet our customers’ changing needs.