Home > Articles > Service Design and Building the IT Service Portfolio

Service Design and Building the IT Service Portfolio

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Apr 6, 2018.

Chapter Description

In this sample chapter from IT as a Service (ITaaS) Framework, The: Transform to an End-to-End Services Organization and Operate IT like a Competitive Business, examine the purpose, goals, and value potential of a Service portfolio. You’ll also explore how to design specific elements of the Service portfolio and review various guidelines, best practices, and lessons learned for the successful design of IT Services across the enterprise.

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

Enterprise Size Details Total Number of Services
Small 100–5,000 employees, low-complexity operations in limited markets 10–40
Medium 5,000–20,000 employees, operations across multiple markets 40–80
Large 20,000–100,000+ employees, complex global operations across multiple markets and business types 80–150

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

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

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.

3. Designing the Service Portfolio | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020