• Publications

    Publications

  • 1

Experiences and thoughts to share

Our publications provide deep insight and practical advice across a variety of subjects in ITD Transformation. Whether you are looking for big-picture ideas or tactical applications of proven strategies, let our expertise and thought leadership guide you to evolve your ITD organization and IT services.

Do you want to know more? Contact Us

White Papers

Read more

Use Cases

Read more

References

Read more

  • Service Centricity – 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.... Read More

  • A Hybrid Service Delivery Model +

    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.... Read More

  • IT Service Process Management - ITSPM +

    IT Service & Product management is a cross-functional discipline for managing an IT service throughout all phases of its lifecycle. These phases consist of strategy & planning, design, transition, operate, improve and retirement. Service Product Management requires a comprehensive understanding of the key organizational, business, customer and market aspects. To govern and manage IT service through their lifecycles, ITSPM uses a series of toll-gates. A proper implementation of a framework as described in this whitepaper including the corresponding roles, processes and boards is crucial to evolve your ITD to as a business model.... Read More

  • Hybrid IT Glossary +

    In this paper you find the key terms of the hybrid IT language. The IT Delivery is evolving into a Hybrid Service Delivery Model, the more it is important you speak the same language.... Read More
  • 1

A Hybrid Service Delivery Model

Download 

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.

Introduction

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.

Basic 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.

Workload Characteristics

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:

Traditional:

  • 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

Distributed workloads:

  • 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)

  1. Definition of characteristics of target workloads
  2. Determine how these workloads will be delivered reliably
  3. Determine the necessary functionality and performance
  4. Develop your technical architecture
  5. Implement your environment

The Model

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.
delivery layers

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

HDS architecture 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)
Service Delivery Unit
  • 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

Supporting Services delivery unit
  • 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.

Conclusion

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.