Service Design and Building the IT Service Portfolio

Designing IT Services

Now that IT Transformation teams understand how to structure and approach the overarching development of the Service portfolio, we can examine the design of elements at each level of our Service delivery hierarchy. The following sections describe the considerations and best practices for designing IT Services end-to-end across the enterprise. The goal of the IT Transformation team is to designate a complete set of Services. The proper design of these Services will have profound implications for the long-term success of the transformation program and Service delivery framework. Limited degrees of updates and reworking of this initial set of Services should be expected as the Services Transformation progresses. At the same time, if large groups of Services fail to support the principles of the ITaaS framework from inception, then strategies for communicating Service value and achieving the desired outcomes for Services Transformation will be that much more difficult.

First, we review the general approach and best practices for Service design, and examine common mistakes and lessons learned for IT Service design within the ITaaS framework. We also consider how Service types impact Service design. Finally, we need to consider the enterprise-wide implications, such as gauging an appropriate number of Services for a given enterprise business and how the size and complexity of an enterprise business can influence Service design.

Basic IT Service Design

How does an IT Transformation team go about designing an individual IT Service within the ITaaS framework?

First, recall that we defined an IT Service as a set of technical capabilities, delivered by the IT organization, required to enable customer productivity and the execution of processes that achieve business outcomes, managed in a cost-effective manner while seeking to proactively innovate, transform, and improve business outcomes through the application of technology. This definition provides us with the ITaaS framework’s recommended point for initiating the design of a Service: a set of required technical capabilities.

IT Transformation teams begin the designation of an IT Service with a logical grouping of technical capability requirements and then iterating through a series of considerations that help refine and properly size the proposed Service that will deliver those capabilities. This refinement may include adding additional capabilities or removing an overly complex capability. In some cases, transformation teams may even realize that the original set of capabilities they began working with is more representative of two or more IT Services. Note that this basic approach to Service design applies primarily to the designation of Business Operations Services, as development of Enterprise End-Customer and Technology Foundation Services can leverage the reference portfolio and rarely need to be initiated from scratch. Later sections expand on design aspects unique to different Service types.

Grouping a set of technical capabilities leveraged to enable a single business process is one of the easiest approaches to begin with. Remember, however, that some processes may have limited technical capability requirements. In these cases, consider grouping capabilities that support related business processes, process groups, or major business functions.

One of the most fundamental considerations for IT Service design is the careful balance of justifying the overhead associated with managing an individual Service against the value opportunity its establishment creates. In other words, we want to make sure that the capability set delivered by an IT Service is significant enough to warrant the effort of managing a Service value communication strategy that includes modeling a TCO and developing and maintaining a Service performance strategy. This concept was first introduced in Chapter 4, “Service Delivery Taxonomy and Definition of a Service.” Service designs based too closely on underlying technologies, such as a specific application, or reflecting a request that might be submitted via a corporate e-store often struggle to develop meaningful performance strategies or TCO models. At the same time, we don’t want a Service housing a set of capabilities so large or complex that understanding the associated costs or performance becomes unnecessarily difficult.

Designation of an IT Service results in Service management overhead for the IT organization. Every Service defined in the portfolio is associated with a TCO, performance strategy, capability roadmaps, and other elements that result in Service management overhead requiring a Service Owner and other Service delivery roles. Service Offerings on the other hand have no direct association to these elements or their overhead. This leads transformation teams to favor establishing fewer Services during early design efforts, because they can leverage Service Offerings to differentiate capabilities and can always split these Service Offerings into separate, standalone IT Services at a later date. Design of Service Offerings is explored in a later section, but provides a helpful option for teams struggling to group a viably significant set of capabilities to consider instead grouping as a Service Offering within another Service.

When the team feels they have properly sized a set of capabilities, they can work through several secondary considerations to help refine the Service, highlighting further opportunities to refine the capability set or potentially informing the designation of early Service Offerings. These considerations should never represent justification for initiating a Service but are leveraged instead to inform the best structure of a Service in its infancy.

Transformation teams should evaluate the customer base that is likely to result from the current Service design, and consider whether a different grouping of capabilities might consolidate the potential customers that the eventual Service Owner is required to support. Consideration of the Service assets involved in enabling the proposed set of capabilities may also lead the transformation team to update their proposal. Here again, there is the potential that minor updates to the capability set could help streamline the assets involved, which in turn aid Service Owners in managing Service delivery.

When IT Transformation teams consider naming their newly established IT Service, remember that the Service should resonate with the customer and reflect what is being consumed, rather than the underlying technologies leveraged to enable the capabilities. For example, while a large-scale software platform may be leveraged to deliver a wide range of capabilities enabling a business process like “Product Design,” we would not want to name the Service after the platform. Instead, teams should consider a name more descriptive of the actual capabilities the platform is delivering, or even use “Product Design Technologies” or a similar Service name to begin with. The goal is to ensure the customer base is immediately familiar with the capabilities that the Service delivers, independent of any familiarity with the IT assets that may be currently leveraged to deliver the Service.

As a final reminder, we want to once again encourage transformation teams to always refer back to the definition and characteristics of a Service and the guiding principles for Service delivery. IT Services should be initiated only in response to vetted technical capability requirements, and never as a result of the presence of IT resources, assets, processes, or costs.

Service Design by Type

Each of the three Service types referenced by the ITaaS framework can be associated with specific design considerations that can provide invaluable guides for IT Transformation teams. The considerations range from how best to leverage the reference portfolio and the general design approach, and even the likelihood a Service will participate in a Service chain.

The ITaaS framework’s reference portfolio primarily designates Enterprise End-Customer and Technology Foundation Services because many of these are common across industries. This means that Business Operations Services most often need to be created from scratch, leveraging the ETC map as a primary input and closely following the approach to basic Service design described in previous sections. These Services are unique to a given industry and enterprise and are shaped in response to the scale and complexity of the enterprise operations. As such, it is impossible to include them in a reference portfolio such as the one included in the ITaaS framework.

Remember that these Services will participate in three-party Service Reviews and are the most impactful for establishing the IT organization as a trusted advisor to the business. Consideration for the resulting customer base can and should influence the design of these Services, with transformation teams grouping capabilities to support a focus on specific stakeholders, while at the same time ensuring duplication is not allowed into the portfolio for non-unique capability requirements. As an example, technical capability requirements for execution of project management may be specified within an overarching business function, but similar requirements may appear numerous times across the enterprise. These capabilities can be more efficiently delivered by a single IT Service that could leverage Service Offerings to provide differentiated capabilities to different teams.

Service assets associated with these Service types are typically applications, or groups of applications. Hardware assets and infrastructure supporting process control systems and industrial control systems (PCS/ICS) for manufacturing, production, and operation processes may also appear. These Services often participate in Service chains, typically consuming technical capabilities from other IT Services, usually for storage of data and application and platform hosting. Transformation teams can expect names associated with these Services to most often reflect capabilities or technologies delivered to specific processes or functions.

Unlike Business Operations Services, the design of Enterprise End-Customer Services providing productivity and collaboration capabilities directly to end customers across the enterprise is not strictly limited to the presence of documented requirements. While this may seem to abandon key principles for Service design, the reality is that insisting on the designation of Enterprise End-Customer Services based on documented requirements for technical capabilities is unrealistic in today’s enterprise IT organization. Mapping requirements for these types of technical capabilities from individual customers across the enterprise is impractical and unlikely to dramatically alter the resulting landscape of Services.

Instead, IT Transformation teams are permitted to designate Services based on the capabilities they deliver today, and encouraged to compare these against the ITaaS framework’s reference portfolio. Justifying and right-sizing Service capabilities, ferreting out duplication, and ultimately achieving high levels of efficient operations are achieved over time as Service Owners are assigned and tasked with continuous value creation. These Service Owners will prioritize the Leverage metric category within their Service performance strategy, introduced in Chapter 7, “Service Delivery Roles and Responsibilities,” to help them drive out inefficiencies.

The customer base is also less useful for informing Service design because consumers are literally spread all across the enterprise, even throughout the IT organization. Right-sizing the Service becomes a question of at what level the IT organization wants to align Service performance and costing strategies. The outcome may be limited to an educated guess initially, requiring refinement by the Service Owner at a later date as the full scope and complexity of delivering the Service becomes clear. The reference portfolio can prove invaluable in shaping these Services.

Service assets associated with these Services run the gamut from software spanning standalone to large-scale platforms, to hardware ranging from laptops and desktops, phones, and tablets. Names are easily agreed upon and reflect the grouping of capabilities being delivered, such as “Mobile Devices” or “Enterprise Computing Hardware.” These Services may at times participate in Service chains, either consuming or delivering capabilities to other Services, although not as often as other Service types.

Ideally, Technology Foundation Services should be designed only after Business Operations and Enterprise End-Customer Services have been designated and there is some understanding of the technical capabilities that these Services require. By taking this approach and designating Services only in the presence of these requirements, many IT organizations today can expect to realize opportunities to drive efficiency.

At the same time, IT Transformation teams can in most cases safely assume the presence of many Services encompassing infrastructure and platforms that exist today, such as networking and application hosting. These Services are additionally reflected in the reference portfolio, which again the transformation team can leverage to vet their own Service proposals.

Enterprisewide Service Design Considerations

The size of an enterprise business, along with the complexity of its operations, can influence the design of individual Services while also informing the overall number of Services that transformation teams can anticipate for the portfolio. To begin with, Table 6-1 provides a range of Services likely to result from application of design principles within the ITaaS framework across different size enterprises.

Table 6-1 Enterprise Size and Service Numbers

We should immediately stress that the ranges for Services shown are provided as a reference for IT Transformation teams and are not intended for establishing a target number of Services before initiating Service design efforts. Proper Service design principles should never be sacrificed to result in a preconceived total number of Services in the portfolio. At the same time, if a team completes their initial proposal for the portfolio and the resulting number of Services is far outside the ranges listed, it can be a key indicator that the ITaaS framework’s Service design principles have not been applied consistently. The determining factor in the ranges provided is most commonly the complexity of business operations. It is also important for IT Transformation teams to consider how the size and complexity of business operations can affect the design of individual Services.

As an example of how these factors can impact not only Services but also multiple levels of a portfolio, consider the delivery of technical capabilities supporting the procurement function at two different enterprises. The first is a medium-sized enterprise that provides consulting Services in a central region, so the processes and associated outcomes within the procurement function are narrow and not overly complex. The resulting technical capability requirements are limited and straightforward, and a single Service is established to deliver technical capabilities across the entire function. A potential portfolio including Service, Service Offerings, and aggregation of related Services for this example is illustrated in Figure 6-3.

Figure 6-3 Medium Enterprise Service Design Example

Now consider a larger enterprise that performs manufacturing, where the procurement function is a critical component of supply chain activities that directly impact the enterprise’s success in the marketplace. The processes and desired outcomes associated with the procurement function are much more complex and require a broader range of technical capabilities. The scale and complexity of the technical capability requirements drive the creation of multiple IT Services supporting specific processes within the procurement function. A potential portfolio to support the broader and more complex capability requirements for the same procurement function is illustrated in Figure 6-4.

Figure 6-4 Large Enterprise Service Design Example

These examples demonstrate how individual Services can be impacted by the scale and complexity of enterprise operations, which in turn drive different levels of requirements for technical capabilities. In practice, even similarly sized enterprise businesses may define different Services to support similar processes, assuming that the scale and complexity of requirements for technical capabilities are different.