A brief overview
Service centric, customer focused and hybrid delivered: This paper helps to understand the definition of an IT service, the importance of a portfolio approach, the standardization of processes, the impact of automation and the importance of service delivery architecture. It describes an overview of all important artifacts to have implemented crucial for the journey to make your IT Delivery more acting as a business partner – to evolve to an IT as a Business model.
Services, it’s about how all of the IT infrastructure parts become something truly useful and you have to define them properly. Many IT organizations try to manage their environments without adequate knowledge of what they’re truly doing and why. Services are not about servers, networks, storage arrays, or even applications. Your investment in defining the services is very important. It will pay off in a big way because it establishes a clear purpose and keeps your customers’ needs first.
What is a service?
The exact definition of the services that will be relevant in your enterprise must be defined through collaboration between IT Delivery and business stakeholders. Defining the services your ITD has to provide can be greatly simplified if you practice the most basic of all business functions:
Talk to your business stakeholders – your customers!
If you engage in active dialogue with the stakeholders, you will collectively come to agreement on the relevant services. The true definition of a service is: “Whatever the customer needs it to be.”
While technology is the basic DNA of services, leave the technical specifics out of service discussions. A service definition for an end service should never mention technology details. It doesn’t matter if the service runs on a VMware ESX virtual machine sitting atop a Dell PowerEdge R730, an Oracle SPARCT3-1, an IBM System z13 mainframe. Naturally, such detail is important to the construction of the service at some level, but the final link in the service chain is not at that level.
Services will come and services will go, and they will all continually be phased out over time. IT service portfolio management (ITSPM) has emerged as a best practice to ensure the correct mixture of services. You can’t provide everything. You need to focus and limit the number of IT services to those that matter the most – bring most value to your LoB’s. You must always focus on the right services for your line of businesses (LoB’s).
Service value and performance need to be controlled. Service Level Agreements are defining them. Too often, a reference to a service-level agreement (SLA) is a number (e.g., the dreadfully common 99.999% availability figure). Such numbers are service-level objectives (SLOs) that are detailed within the SLA, but are far from the SLA itself. An SLA is an agreement. It’s a contract that outlines a clear service definition, costs, and penalties for noncompliance, and any other terms and conditions of the service. It’s the formal document agreed upon by both the consumer and the provider of the service.
Services need Governance
Like a product, a service has distinct consumers and a distinct provider. There can be many consumers of a service, but there can only be one provider. If there is more than one provider, those providers are competing for the consumer’s business. (This is an example of bad service delivery architecture and governance practice! – see below)
The collection of various services in active use is the service catalog. The service catalog is a living resource, meaning it will change as business conditions dictate. You must first understand that any service portfolio has a life cycle of three common stages: in development, in catalog, and in retirement. Only the services in the service catalog stage are available for production use. If you’re implementing a self-service request system, the only services available to a specific consumer will be those services in the catalog that are relevant to that consumer.
The components you assemble into services - we call them service capabilities - have to be standardized and are unique. Standard applications, standard infrastructure configurations, and other building blocks are capabilities of IT services to your LoB’s. The more variety you have in these components, the more complexity you have to manage. Services are composed out of multiple service capabilities. Designing your services on capability base allows you the benefit tremendously from high synergy potential.
That’s why you need to architecture and (ITSPM helps) govern your services and service capabilities. You have to reduce the portfolio of service capabilities to be efficient and effective to finally increase service reliability and performance, and – most important - improve customer satisfaction and reduce costs.
Services and Automation
The future of IT is of highly automated service fulfillment and adaptation. Automation tools will accelerate process execution, enforce that execution, and allow for rapid adaption to a change – if proper used. If the process is good, you speed up the good actions and achieve excellence. If the process is poor, you speed up the bad actions and lead to catastrophe.
Automation tools are maturing and getting more integrated. While standalone tools still dominate, suites are improving quickly, driven mostly by a desire for more complete cloud service orchestration. Tools remain in need of much more development, but key task execution and process flow capabilities are now solidly in place. Provisioning servers is now relatively easy, as is making configuration changes to network devices and storage components.
Services Hybrid Delivered
IT process automation is converging from many directions into unified models for capturing processes into software models and facilitating the execution of those processes.
Cloud computing and DevOps are accelerating the evolution of automated service management. Indeed, service management itself is evolving to adapt to automation. There is a symbiotic relationship between these movements. Neither cloud computing nor DevOps is truly feasible without extreme automation, and automation needs the economic force of movements like cloud and DevOps to compel the market investment necessary to deliver capable technology solutions.
It’s becoming increasingly obvious that service delivery and management in any form will be impossible without significant improvements in automation. Automation is more an evolution of trust than an evolution of technology.
Hybrid Service Delivery
With a growth in strategic right sourcing, you will more often be building business services using service capabilities or even complete services that are provided by third parties. These services or service capabilities can be in the form of software components, cloud services, traditional outsourcing, and other services delivered by external providers.
The ability to integrate the delivery of these service capabilities, along with your own internal service delivery, will be a skill set in high demand. It needs a good implementation of the governance and management of the multiple service deliveries – multi provider management.
As you might expect, there is no easy definition of hybrid service delivery as each implementation will depend on the requirements specific to each enterprise. There is no one-size-fits-all hybrid solution. What all hybrid architectures do have in common, however, is the ability to marry the specific advantages of a traditional IT infrastructure made up of dedicated hardware with public and private cloud deliveries.
- The Business Layer is the interface to the Line of Businesses. Services are orchestrated, activated, billed, recorded and provided over this layer
- The Abstraction and Integration Layer is managing the work and data flows to orchestrate the outcomes of the service deliveries
- The Delivery Layer includes delivery the supporting and management capabilities to manage and control the multiple internal and external deliveries.
Need for a right Operating Model
This mix combines the security and customization of in-house hardware and private clouds with the flexibility, scalability and cost-effectiveness of a public cloud to realize the true benefits of a hybrid solution and grow without worrying about the costs and timescales of deploying additional in-house hardware.
Recently, we are starting to see enterprise turn to the cloud to deal with unknown demand as well. In this case, new applications or services are first deployed to a public cloud where fluctuations in demands are easily accommodated. This is a particularly attractive option for deploying Internet-facing applications and services. As the demand for new services stabilizes, the enterprise can then size the requirement for capacity and shift the application to its in-house infrastructure with much less risk.
Which hybrid approach is best for your enterprise largely depends on your business model as well as the maturity of your current IT delivery infrastructure. Of course, choosing the right operating model or models for IT service delivery is only the first step in the transformation.
It is worth considering a proven, well-structured methodology to orchestrating your move to a hybrid solution and allowing users and customers to move between service delivery models to take best advantage of new services. In most case, this transformation will be less about the technology than it is about the organizational structure, business models and the perceived role your IT Delivery within the company.