The IT Delivery is evolving into a Hybrid Service Delivery Model. Business services use more and more IT service capabilities or even complete IT services that are provided by third parties. The ability to integrate the delivery of these IT services or capabilities properly along with your own internal IT service delivery is crucial. This paper describes how internal and external deliveries can be structured and managed in a hybrid delivery model. The model is more a concept and no standard architecture. Its describes a high level hybrid service delivery architecture and promotes its standardisation using technology neutral service delivery unit definitions.
From Uni and Bi- to a Hybrid Service Delivery Model
Cloud based IT services are paving the way for enterprises to reshape their external proposition to customers. Companies are using the cloud to create new types of products and services; to take offerings to market more quickly; to open up new channels to engage consumers; and flexibly to support new growth areas within the business, rapidly scaling up or down in line with their level of success.
Also your enterprise increasingly seeks to realize the benefits of innovation and modernization that cloud based capabilities can deliver. Your IT Delivery (ITD) organization must ensure it can provide the necessary IT services and support. Your ITD function needs to keep pace with business needs.
With the growth in strategic right sourcing your IT services will also use service capabilities or even complete services that are provided by third parties. The IT services and their capabilities can be in a form of software components, cloud services, traditional services and other services often sourced from numerous providers. The evolution of the ITDs moving rapidly towards reliance on multiple service deliveries are running into complex challenges. These typically fall into three groups: integration, management and control, and evolution of service deliveries.
Where large numbers of delivery technologies are involved, it is no longer viable to link IT services, processes and data through point-to-point integrations. Instead, a more sophisticated solution is required, based on easily configured and open software tools, and which provides an “integration hub” with pre-defined connectors that can be configured quickly without lots of development and engineering expertise.
Accordingly you need a proper plan and architecture of how the multiple service deliveries are managed, evolved and new ones integrated. The architecture requires a holistic development approach and follows your enterprise strategy and your ITD vision, strategy and delivery architecture principles.
Before we go into the model we first describe some basic architectural principles.
As with IT services also an IT service delivery architecture has to meet requirements. The requirements are translated out of the enterprise and business strategies, market and technology trends. The biggest challenge for the architecture and a proper IT service delivery design is to be prepared for the future and its unknown requirements.
The Service-Architecture is defined by Functional (FRs) and Non-Functional Requirements (NFRs)
- Functional requirements: Business capabilities imperative for business operations including business processes, the business and IT services, IT service capabilities, the components, and underlying systems that implement those services.
- Non Functional requirements: security, availability, reliability, manageability, scalability, latency, governance and integration capabilities, etc.
The requirements which determine the capabilities are determined by a set of service requirements which includes business/customer FRs and NFRs on a service. They result in the documented capability that a service is expected to deliver.
The provider view of an IT service requirement is the business and technical capability that a given IT service has to deliver given the context of all of its business consumers. The consumer view of a service requirement is the business and technical capability that the service is expected to deliver in the context of that consumer alone.
The fulfilment of any service requirement may be achieved through the capabilities of one delivery or a composition of service capabilities provided by multiple deliveries. The services or service capabilities can be provided by internal or external deliveries or providers.
Core versus Noncore IT Services
Every service your business needs can be retrieved from any external provider being best service deliverer in class offering better prices or even more effective meeting business needs. Because your business will delegate their cost pressure to you, and in the same time expect more value and agility of the IT services they utilize, you have to understand how to deliver the services needed and generate added value.
Noncore Functions and Workload Characteristics
What is your best way to produce? Internally produced IT services need a competitive advantage compared to potential external providers offerings. You should focus on capabilities and innovations you are best, differentiate and generate most value for your enterprise and lines of businesses – your core functions and IT services. The rest you can get from external providers – your noncore functions and IT services.
A delivery represents an unique "value chain" production according to the specific workload type. It may use service components or capabilities produced by other service delivery units. There is no competition between deliveries. The service components or capabilities are applications, standard infrastructure configurations and other building blocks of IT services. For example each application has specific requirements on the runtime environment and business processes. Requirements on the runtime environment determine the workload type. The overview below illustrates traditional versus distributed cloud workloads:
- Legacy or not fault-tolerant applications
- Static assignment of resources
- Requires high availability of the infrastructure
- Troubleshooting by dedicated support organization
- Dedicated technical service delivery design according traditional infrastructure system design principles
- fault-tolerant applications
- Dynamic assignment of resources
- No need of high availability of the infrastructure
- Reallocation of runtime workloads (workload mobility) across multiple deliveries in case of failure
- Workload can be distributed over brokered multiple deliveries
A Design Process
The architecture development process of a delivery unit (e.g. cloud delivery unit)
- Definition of characteristics of target workloads
- Determine how these workloads will be delivered reliably
- Determine the necessary functionality and performance
- Develop your technical architecture
- Implement your environment
Services are composed out of several capabilities, which are implemented once and re-used many times. The services are composed and orchestrated. The complexity of the service compositions are managed and maintained in the service catalogue.
Our Model foresees 3 layers:
- The Business Layer is the interface to the LoB‘s. Here the services are orchestrated, activated, billed, reports generated and provided. Also functions like customer relation and multi provider management are iimplemented in this layer.
- The Abstraction and Integration Layer is managing the work and data flows and orchestrates the outcomes of the multiple service deliveries. It offers standardized connectors to integrate new deliverables.
- The Delivery Layer includes the delivery units and the supporting management capabilities(service management functions) to control the multiple internal and external deliveries.
Business Layer Characteristics in Detail
- Consumers interaction : The entry point for consumers and customer and services.
- Enabling to support a client-independently, channel-agnostic set of functionality, which is separately consumed by the different business divisions. Each business or customer segment can have it's dedicated service catalogue configuration. The individuality of the customer services is expressed by the composition of the services out of the service capabilities. The compositions are expressed by the parameters and workflow configuration definitions in the catalogue and the services orchestrator.
- Provides the capabilities required to deliver IT services and data to end users.
- Decouples the other layers to provide the ability to support agility, enhanced re-use of service components, and improve quality and consistency of service provisioning.
- Demand encapsulation, product requirement definition, self service capabilities, (self)support, SLA management – order, activate and bill.
- Provider and service management capabilities and functions (service monitoring, KPIs, SLA reporting, billing, request generation, data collection – monitoring, chargeback ...)
- The business and customer service requirement capturing and definitions
The Abstraction and Integration Layer includes:
- The abstraction layer enables the service consumer/requester to connect (and aggregate) to the correct service provider (service delivery unit) in the service delivery layer.
- Decoupling (business and service) allows high reusability of service components (capabilities) by publishing it through API's.
- Offers integration-capabilities of existing and new deliveries (internal, external) and services
The Service Delivery Layer includes:
- The functional and technical components that facilitate a service component to produce one or more services
- All capabilities required to deliver the functional elements of services (components). This includes the orchestration of the components composed into the services, the wrapping and the composition/ decomposition of the underlying services.
- Runtime Environment: Capabilities required for providing a runtime environment. Including capabilities to support both the components required to support service functionality and those required to actually run the components for service value creation.
- Virtualization and Infrastructure Services: This category of capabilities provides underlying infrastructure such as computing power, network, storage, etc. in dedicated/physical or a virtualized manner
- The runtime and deployment infrastructure; the programs, platforms, application servers, containers, runtime environments, packaged applications, virtual machines, etc. that are on the hardware and are needed to support the service.
Hybrid Service DeliveryArchitecture Model
The Service Delivery Unit
A service delivery unit (SDU) represents an unique "value chain" production according to the specific workload type. It may use service components or capabilities produced by other service delivery units (service assembly and hierarchy). Delivery units can be designed according delivery hierarchy or layering.
The production is designed respecting an architectural framework. The service capabilities are uniquely produced and can be composed in existing services or be potential capabilities for future need.
- A Service Delivery Unit includes all runtime capabilities and element for service execution
- Produces individual or standardized services (not both)
- Is workload type optimized for its service value creation
- Represents an APU – Autonomous Production Unit
- Accessed over service interfaces (APIs)
- The technical stack automation manages autonomous the delivery stack. It provides all necessary automation workflows for resource activation (compute, storage and network), configuration and management.
- SdNand SdSt architectures facilitates network and storage virtualization. They support automation, programmabieand resource control, enabling to build highly scalable, flexible services.
- The hypervisor or server virtualization is the abstraction layer of physical computing hardware. We mostly use only one specifically suitable hypervisor per hardware platform.
- Within infrastructure stacks computing, storage and connectivity resources will be provided. They may be provided in form of a “converged system”, or even out of different components.
- API/Automation: For integration into user interfaces (UI Management), or into existing solutions standardized APIs are defined. Analogue technical service orchestrator the interface support at least a minim API for automated service management process handling.
- Metering, Monitoring, and Reporting: Feeding the service management processes (ITSM), which are implemented outside of delivery stacks. These processes get all the necessary data from the delivery stack via well-defined interfaces.
Service Delivery Supporting Services
- Central supporting services take cross-delivery tasks that arise in the context of hybrid service delivery. These are mostly supporting services that can/must be provided centrally for the entire delivery ecosystem.
- Security and Identity & Access Management provide centralized services for the implementation and monitoring of security measures and the management of user data so that only authorized persons have access to delivery services.
- Multi Delivery Orchestration. This important function enables the composition of services out of different (internal and external) delivery units within the hybrid service delivery.
- Remote Infrastructure mgmt. for monitoring and control of the infrastructure.
As you might expect, there is no easy definition of a hybrid service delivery architecture 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 solutions and the integration of other providers.
A hybrid delivery model impacts how you function as an organisation. investing in the right operating model – which includes governance, development processes, operational processes and talent, and the right management and integration tools is a critical priority.
It is crucial to use a proven, well-structured methodology to orchestrate your evolution to a hybrid delivery model.