By Reginald Lo
A recent Gartner survey[1] revealed that 85 percent of IT departments are pressured by their customers to deploy new or changed IT systems or services faster. As the speed of business continues to increase, IT is having a harder time keeping up. As a result, 41 percent of business leaders attribute faster service delivery time or time to market as the reason they use outside IT service providers[2]. IT must transform itself into an agile organization in order to become a strategic partner to the business.
In the last several years, there have been some key technology and IT management innovations to improve time to market. DevOps, Agile, and cloud computing are all attempts at increasing the speed of IT. However, IT needs to systematically design its services to exploit these innovations.
In this post I’ll explore how to change the way you design IT services so they are optimized for DevOps, Agile, cloud computing, and the service broker IT business model. I’ll also provides suggestions on how to start transforming IT into a nimble organization.
Service Design and DevOps
DevOps describes an approach for re-thinking the collaboration between App Dev, QA, and IT operations. Its purpose is to remove barriers between these teams and align them to the common goal of reducing time to market while maintaining service quality. This alignment sounds easy but is actually difficult because App Dev and IT Ops have traditionally had different objectives: the former strove for innovation and speed, while the later preferred stability.
DevOps focuses on more frequent deployments, lower failure rate, faster mean time to restore and automated processes. In order to design an IT service for DevOps, you not only need to design the system that underpins the service, but also design how the release process will be automated. Nirvana is the ability to perform continuous deployments.
One mechanism you can leverage is the service request catalog and the back-end automation and orchestration. Since App Dev is familiar with provisioning IT services from the catalog, you can also use the catalog as the interface for App Dev to request automated deployments of specific systems. The same automated orchestration capability used to provision IT services, can be used to automate the deployment process by taking the binary outputs from App Dev from the source control system and deploy them into specified environments, such as test, prod, and so forth.
When designing the support process for your new or changed IT service in a DevOps environment, consider a model that integrates both IT Ops and App Dev in the process. In the past, IT Ops shielded App Dev from 24×7 support. However, to reduce failure rate and improve mean time to restore, increasing the App Dev’s role in support creates accountability for App Dev to reduce the number of bugs and develop ways to restore service faster.
Service Design and Agile Software Development
The Agile methodology is characterized by multiple sprints leading to a release. In fact, with DevOps, a single sprint may result in a release. App Dev teams maintain a backlog of stories—a way of describing requirements. It is important to note that the Agile approach is particularly useful when the requirements are not fully known at the start of the project. The implications to service design is that you cannot expect the waterfall approach of having all the requirements upfront and then build the IT infrastructure to satisfy the supposedly stable requirements. The very nature of the Agile approach means that requirements will be discovered or evolve over time. You need to plan and design with the assumption that requirements will change.
This has interesting implications on how infrastructure or supporting services are designed. IT has generally focused on the initial provisioning process when establishing its private cloud services. However, if we know requirements change, we should also invest effort into “day 2” activities, for example, making it easy to expand compute, memory, storage, or change network and security controls sometime after the initial provisioning. Hence, your catalog should not just be an entry point for provisioning requests; it also needs to be the entry point for change requests, continuous deployment requests (as I discussed with regards to DevOps), and retirement requests.
Service Design and Cloud Computing
Cloud computing can be a model for how to deliver business-facing IT services, software as a service (SaaS), or a way to deliver infrastructure and supporting services or infrastructure as a service (IaaS), and platform as a service (PaaS). Cloud-based services have certain characteristics that distinguish them from traditional IT services:
- Self-service: The customer can easily request the service through a portal.
- On-demand: Instantly deliver the service when it is requested.
- Elastic capacity: Dynamically provision more resources (and release those resources when they are no longer required) based on fluctuation in demand.
- Highly available and resiliency: When the underlying infrastructure components suffer an outage, the service is architected in such a way that it is still available to the customer.
- Pay as you go: The cost of the service is linked to the amount of the service that is consumed. This allows the business to make return on investment (ROI) decisions on how much of the service to consume. Contrast this to a cost allocation model for IT, where the business has no incentive to self-manage their demand of IT.
When designing an IT service, whether it is an IaaS, PaaS, or a business-facing service that sits on top of IaaS or PaaS, you should address these cloud characteristics.
Another aspect of service design is “Where is the service going to be hosted?” —in the private cloud, the hybrid cloud, or the public cloud? The answer may not be straightforward. You may want to pilot the service in the public cloud and then when it grows, bring it back into the private cloud in order to manage costs. Or you may have a service hosted in the private cloud but have the ability to burst into the hybrid cloud to handle peaks in demand. These design decisions impact how App Dev might build the application. For example, if an application starts in the public cloud but may be migrated into the private cloud in the future, App Dev cannot use the public cloud provider’s proprietary technologies, such as an AWS NoSQL database, that isn’t available internally.
Service Design and Becoming a Service Broker
If your internal customers or lines of business are using shadow IT—external IT service providers—in order to meet their time to market requirements, instead of taking an adversarial position against using those external cloud services, your IT department should embrace these vendors and leverage the value that they can provide. IT must become a service broker, helping your IT service consumers select the most appropriate platform for the service they require, whether it is private, hybrid, or public.
A service broker is more than just the ability to show VMware vCloud Air, AWS, or Azure services in your catalog. In fact, showing all the offerings and options from these vendors could become confusing to your customer. Instead, the catalog should ask questions about the requirements, such as:
- Is the environment for dev, test, or prod?
- Will the environment store any confidential information, such as PII (personal identifying information), HIPAA, and similar?
- Does the environment need to adhere to certain levels of compliance such as SOX, PCI?
- What service levels do you need?
And the based on the answers, automatically provision the environment into the right cloud—private, hybrid, or public—through the automatic enforcement of policies, as shown below.
Becoming a service broker raises some interesting questions:
- Does supplier management need to be matured in order to manage the cloud providers better and ensure they are meeting their service-level obligations?
- How does IT provide a seamless user experience regardless of the underlying cloud provider? How do you make the user perceive the private, hybrid, and public cloud as “one cloud”?
- What is the support model—for example, are there hand-off points between IT and the cloud vendor? How do you get visibility into the full incident lifecycle as it moves from IT to the cloud vendor?
Where Do You Start?
I’ve introduced how service design needs to change in order to take advantage of DevOps, Agile, cloud, and the service broker model. The next question to answer is: “How do I transform IT so that our services are designed differently?” Here are some suggestions:
- Build momentum and support—First, you need to educate stakeholders on what the vision of success will look like, the problems that this “new IT” will solve, and the value that this “new IT” will deliver. This article is a good starting point but you will need to give presentations, conduct workshops, and continue to provide information to stakeholders on where the IT industry is going.
- Establish new roles—As part of the transformation, you will need to establish new roles such as service architect, service developer, automation engineer, and so forth. And it’s not sufficient just to define their responsibilities. You also need to give the people in these new roles the training and enablement to be successful.
- Pilot the new service design model—It may be easier starting with industry-recognized services to demonstrate how the new operating model will work end to end, such as establish IaaS or PaaS an exemplar of the new way of delivering services.
- Think “service lifecycle”—Traditional IT is project-based. Infrastructure is built in response to specific application projects. In a service lifecycle approach, the infrastructure services are designed and built outside the context of a specific application project. Once the infrastructure service is available, application projects then request the infrastructure service as needed. This challenges the way you fund the infrastructure, as the initial creation of the infrastructure service is not tied to the business justification of the application project.
ITIL presents a service lifecycle, but it does not going into depth regarding the specific activities in each stage of the lifecycle (instead, it focuses on the service management processes in each stage). Your organization will need to develop a methodology that defines the specific activities within the service lifecycle.
Next, you will need to tie together the new roles and the new activities from the service lifecycle. Again, a high-level example is provided below.
Conclusion
I’ve described how service design needs to change to take advantage of the innovations brought about through DevOps, Agile, and cloud, along with tips on how to become a service broker. And, I’ve given pointers on where to start your transformation journey. Ultimately, this transformation will help your IT organization deliver at the speed of business, resulting in exploiting business revenue opportunities earlier or realizing business cost savings sooner.
====
Reginald Lo is Director of Service Management Transformation with VMware Accelerate Advisory Services and is based in California.
[1] Gartner, Inc., “2014 Service Transition Survey”
[2] IDG Research Services , “Dual Perspectives on ITaaS: The World According to IT and Business”
