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.
IT Transformation teams now have a clear definition of an IT Service that supports the goals of the Service delivery framework. They also have a multilevel taxonomy providing a structure for the strategic management of the target Services landscape and a complete mapping of technical capabilities required across the enterprise to enable the execution of business processes. With these and other inputs provided in this chapter, transformation teams can now begin the design of IT Services and build the Service portfolio.
Before we begin, however, we should reevaluate the purpose, goals, and value potential of a Service portfolio. The portfolio within the ITaaS framework is no longer a simple listing of IT Services. Instead, the introduction of the Service taxonomy introduces a hierarchy to the portfolio and requires us to designate elements beyond just IT Services; it also enables a number of value capabilities and outcomes for Service delivery. With this in mind, this chapter provides a complete overview of the ITaaS framework’s Service portfolio, including considerations, structure and design, and even the recommended workflow for developing and finalizing.
From there, the focus shifts to designing specific elements of the Service portfolio, dedicating a considerable amount of time to reviewing the various guidelines, best practices, and lessons learned for the successful design of IT Services across the enterprise. We also cover guidance for the design of each Service type, along with the designation of elements at each level of the Service delivery taxonomy. Cisco’s ITaaS framework includes a complete reference portfolio, capable of significantly accelerating this extensive effort, allowing transformation teams to focus on the design of IT Services unique to their enterprise industry and business. The reference portfolio, along with guidance for leveraging it, are included in Appendix A.
Service Portfolio Overview
Service portfolios are far from a novel concept; in fact, IT Service management standards have for years advocated for their use in managing IT Services. Consequently, portfolios can be found in place across most enterprise IT organizations. Cisco’s ITaaS framework also leverages the concept of a Services portfolio, retaining its core intent as an artifact for organizing and managing IT Services while also striving for a more strategic purpose within the framework for IT Service delivery. The following sections ensure that you clearly understand the purpose, goals, and value of the Service portfolio and its impact on Service delivery. Transformation teams should remain conscious of a number of considerations, and they need to carefully review their design approach and general workflow for building the portfolio, which spans gathering all the required inputs to vetting, finalizing, and administering the IT Services portfolio.
Purpose and Value of the Service Portfolio
Many IT Service management standards leverage the portfolio solely as a tool for listing Services. While this basic function will remain the ITaaS framework leverages it as a vehicle for applying the Service taxonomy, allowing for summarization of information at each level of the hierarchy and positioning it as a strategic tool for IT leaders as well. The foremost purpose of the IT Service portfolio then becomes to support planning and execution of strategies at different levels of the Service delivery hierarchy.
As an example of this value potential, say a Service delivery team aligns summarized information for Service costs and performance at the Strategic Service Group level. Recall that Services are aggregated at this level in order to support strategic planning. Simply associating costs and performance with a portfolio listing of over a hundred individual IT Services can provide a valuable reference to specific Service delivery teams but is not conducive to strategic planning. When we summarize Service cost and performance information at higher levels of our hierarchy, however, we effectively create a strategic dashboard for IT leaders. These multilevel dashboards enable quicker assessment and even monitoring over time of strategic segments of the Service landscape, and it is the portfolio that would drive these informational views
While its use as a strategic tool receives most of our value examination, the Service portfolio serves additional purposes within the ITaaS framework. At its most fundamental level, through the application of the taxonomy it helps organize an otherwise cumbersome list of Services, making the portfolio easier to navigate and administer even for those IT organizations that choose to leverage it strictly as a basic reference for IT Services. In practice, it may exist as a reference artifact for Service delivery that additionally feeds a strategic dashboard. Regardless, it will always exist as a primarily IT internal tool. It will also be used to derive the IT Service catalog, which is leveraged to enable customer request portals, such as corporate e-stores as described in Chapter 11, “Completing the Services Transformation.”
The ITaaS framework’s IT Service portfolio still acts as a valuable reference for Services and related information, but it also acts as the point of execution for the Service taxonomy, allowing the portfolio to be organized and administered more easily. Through the association of carefully designed information sets at each level of the Service delivery hierarchy, the portfolio also becomes a multilevel strategic dashboard for IT leaders.
Service Portfolio Considerations
With the purpose and potential value of the Service portfolio clearly established, IT Transformation teams are likely eager to begin designing Services. Before they begin, however, they should remain conscious of a number of considerations, both general and specific, in the design and development of the Service portfolio.
The first general consideration for the portfolio is that it represents a significant effort. Design of a complete Service portfolio is complex and is also likely to represent the largest task that IT Transformation teams will face in the Services Transformation Program. Development of strategies for Service costing and performance represent significant efforts as well, and have the potential to present as much or more complexity, but the breadth of the portfolio design along with its own complexities mean it will typically represent the most time consuming effort, often far in excess of original timeline estimates of most teams. Remember that the team is not only designing a complete set of IT Services capable of delivering capabilities end-to-end across the enterprise business but is also designating elements at each of the additional levels of the Service taxonomy. Be sure that IT leaders, stakeholders, and the transformation team understand the task and be sure to not overcommit on timelines.
The complexity inherent in the effort is another consideration. There are numerous opportunities for proposed designs to veer from best practices or for teams to take different directions, resulting in discontinuity in the designation of elements within a given level of the portfolio. The length of the effort may lead some team members to fall back on historical approaches to IT Service design that contradict the ITaaS framework’s definition of an IT Service and fail to support future strategies for costing and performance. Change leadership is critical in driving consistency end-to-end and ensuring that proposed Services adhere to the established definition and characteristics of a Service and best practices shared later in this chapter, and that they support the guiding principles for Service delivery.
A key advantage for IT Transformation teams is the ITaaS framework’s inclusion of a reference portfolio, which is shared along with guidance for use in Appendix A. This reference portfolio provides transformation teams with an initial set of Technology Foundation and Enterprise End-Customer Services common to IT organizations across any industry. These Services act as a guide for further Service design and can be easily customized and adopted. Doing so can significantly reduce the level and complexity of the overall effort and allows teams to focus the bulk of their energy on the careful designation of Business Operations Services unique to their industry and enterprise business.
Remember that although the bulk of the effort to design the Service portfolio is carried by the IT Transformation team, it does not represent a task that can be completed solely within the team or even internally to the IT organization. The entirety of the portfolio needs to be vetted across relevant stakeholders and refined based on their feedback. Practices for vetting are detailed later in this chapter, but must leverage value messaging and Service transformation educational material managed by the change leadership function. Review and vetting of the proposed portfolio take place across three primary stakeholder groups: IT leadership, IT internal stakeholders, and business stakeholders.
As IT Transformation teams progress the portfolio and begin to review with stakeholders they should consider tactics for effectively presenting and reviewing the appropriate sections of the portfolio. The most commonly used tools for managing in-development Service portfolios are spreadsheets, which can easily capture and sort relevant data but are not always the most favorable method for reviewing a proposed set of Services for input. Cisco recommends leveraging graphical illustrations of the portfolio—for example, simple block diagrams of a specific segment of the portfolio that can be more easily presented and reviewed. An example is shown in Figure 6-1.
)
Figure 6-1 Sample Service Portfolio Block Diagram
Aside from managing the portfolio throughout the design phase, transformation teams should also begin actively considering the requirements and ideal platform for hosting the portfolio in the long term. Remember, the ITaaS framework presents the opportunity to leverage the IT Service portfolio as a multi-level strategic dashboard, but this requires a platform capable of summarizing Service information at different levels for IT leaders. Even if transformation teams opt to initially leverage the portfolio only as a Service reference, they still require a platform that supports remote navigation and administration because the portfolio will not remain static and must be managed over time if it is to evolve with the needs of the business.
Portfolio Design Considerations
Several of the considerations that IT Transformation teams must evaluate are specific to the design and approach to building the Service portfolio. Note that a number of these considerations will echo recommendations highlighted in Chapter 3, “Change Leadership and Ensuring a Successful Transformation.”
Chapter 3 recommended a top-down and end-to-end design of IT Services to ensure complete alignment and the efficient operation of the IT organization. The top-down approach means beginning with Business Operations and Enterprise End-Customer Services types and then designating only those Technology Foundation Services that are required to support them. This approach ensures all of IT’s resources and assets are aligned to justified Services and often leaves IT organizations with opportunities to shuffle or realign those that cannot be, ensuring they are operating efficiently. Portfolio design efforts that begin with Technology Foundation Service types tend to force alignment of IT assets early on and rarely achieve the level of efficiency that a top-down approach does. Separately, the end-to-end design of Services supports the transition to an ITaaSO, allowing for the creation of a parallel view of IT resources, assets, and budgets aligned to Services in a manner that cannot be reflected when only pockets of Services are designated.
The ITaaS framework’s reference portfolio supports this same top-down design approach, allowing teams to focus on Business Operations Services from the beginning. Then, as they transition to Enterprise End-Customer and finally Technology Foundation Services, their work involves aligning the remaining requirements to IT Services listed in the reference portfolio, customizing where needed, omitting where requirements do not exist, and finally designating Services for any capability requirements that have not been accounted for by the reference portfolio.
Portfolio Design Inputs
Before beginning development of the Service portfolio, transformation teams should confirm they have all the relevant inputs available and take time to carefully review each:
Service definition
Service delivery taxonomy
Enterprise Technical Capabilities (ETC) map
ITaaS reference portfolio
Guiding principles for Service delivery
Existing Service management artifacts
While each of these should be familiar to readers, it warrants highlighting the use of existing artifacts for IT Service delivery. The ITaaS framework’s unique and more strategic design of IT Services warrants the development of a new Service portfolio to support the new approach to IT Service delivery. That does not mean that existing Service portfolios, catalogs, and other data and documentation that have been previously leveraged in support of Service delivery are not useful. On the contrary, many of these assets can be leveraged successfully in the design of the new portfolio, often simply mapping to new levels of the taxonomy other than Services. For example, many elements from prior portfolios can often speed the designation of Service Offerings, especially for Technology Foundation and Enterprise End-Customer Service types, or eventually be mapped to IT Service catalog requests as detailed in Chapter 11. The key consideration for transformation teams is knowing what exists and then taking advantage of it whenever possible without sacrificing the guiding principles and future desired outcomes for IT Service delivery.
Portfolio Development Workflow
Following is the general workflow recommended for the development of the IT Service portfolio:
Structuring the Portfolio: Transformation teams designate specific data elements for the portfolio, creating an initial information set aligned to each level of the taxonomy.
Designing the Services: The Service definition, reference portfolio, and ETC map are leveraged to design a complete initial draft of IT Services end-to-end across the enterprise. Note that Cisco recommends conducting initial Service offering design, capturing potential Service asset information, and documenting likely Service chains during this phase as well.
Designing Remaining Portfolio Elements: As the complete set of Services nears completion, the Service taxonomy is leveraged to designate elements for the organizational levels of the portfolio (Service categories and Strategic Service Groups within Cisco’s ITaaS reference taxonomy).
Vetting the Portfolio: Transformation teams begin reviewing the initial proposal for the portfolio across each stakeholder group. All feedback should be carefully considered for potential incorporation and refinement of the proposed portfolio.
Identifying Service Chains: Teams document all Services participating in Service chains, which inform Service cost modeling and Service performance strategies.
Finalizing the Portfolio: IT Transformation teams conduct an end-to-end review of the portfolio, evaluating the design consistency, support of guiding principles for Service delivery, and any remaining requirements to support the IT operating model and enterprise business.
Timeline ranges are not included because they can vary so drastically depending on variables ranging from enterprise size and operational complexity, the inputs leveraged, and the transformation team’s experience and grasp of the ITaaS framework as a whole. As a general rule, the Service design represents the most significant and time-intensive step, with the design of the remaining portfolio elements often completed in one-third or even a quarter of the time. Considering the design activities requirement to span the enterprise end-to-end, even stakeholder availability to engage with transformation teams can have a significant impact on the vetting timeline, but the portfolio can typically be finalized in a matter of weeks.
Although these steps are largely sequential, transformation teams can easily stagger each phase in a waterfall approach, as illustrated in Figure 6-2. The key is to recognize that beginning the next phase in sequence too early before completion of the current phase can both jeopardize the quality of the design and lead to significant rework. As an example, designation of Service categories and Strategic Service Groups often becomes clear after the first rounds of Services are submitted but would represent pure guesswork if begun at the same time as the Service design effort.
)
Figure 6-2 Service Portfolio Development Workflow
Structuring the Service Portfolio
It is important for IT Transformation teams plan the information that will be associated with the Service portfolio, both initially in support of Service design and longer term to support strategic planning. The eventual transition to strategic dashboarding depends on information from Service costing, performance, and other strategies not yet available to the transformation team, but it is important to plan for its eventual adoption into the portfolio.
Following are the most basic data elements for the Service portfolio:
Strategic Service Group
Service Executive: [Name]
Service Category
Service Architect: [Name]
Service
Service Description
Service Owner
Service Delivery Resources
Service Architect: [Name]
Service Offering Manager: [Name]
Service Executive: [Name]
Service Offerings
Service Asset References
Application Set
Product or Device References
Resource References
Service Performance Information/Link to Dashboard
Service TCO Information/Link to Dashboard
Technical Capability Set: [Description of capabilities delivered by the Service, or link to ETC map]
At any time transformation teams engage with a stakeholder group to review segments of the portfolio, they should consider what information the meeting could be leveraged to capture and add to the portfolio. For example, a stakeholder may agree to the proposed Service and then provide an initial proposal for Service Offerings associated with the Service that the transformation team can then refine. Capturing Service Offering and Service asset references whenever possible can save future Service Owners time and help them quickly get the newly initiated Service optimized.
Vetting the Portfolio
As the portfolio nears completion, it is important to review and refine segments with specific stakeholder groups. The complete set of proposed Services along with Service categories and Strategic Service Groups should be reviewed with the IT leadership team. Groups of Services and potentially their aggregation should be reviewed with IT internal communities that ultimately support the architectures, processes, and budgets that enable the proposed Services. Remember that Service Owners and other Service delivery roles will likely be established from this same group of stakeholders. Finally, segments of Business Operations Service types should be reviewed with their associated stakeholder groups across the enterprise.
Initial proposals for Service Offerings and Service asset references can also be reviewed, but newly appointed Service Owners should be encouraged to refine them to support the most efficient management of the Service. Review and finalization of the portfolio are primarily focused on Services, and the most effective aggregation of those Services for IT leaders.
It is important for transformation teams to strike a careful balance for actively gathering input and determining how long to allow the vetting processes to proceed. The goal here is to avoid “analysis paralysis,” or scenarios in which teams allow never-ending serial review of a section of the portfolio, enabling competing stakeholder groups to constantly override one another in a never-ending loop. Chapter 3 called out the “80/20” rule as a best practice for supporting a successful transformation program and also highlighted senior commitment to a “Centralized Authority for Transformation” as a critical success factor. These principles were established specifically in support of allowing transformation teams to gauge when sufficient feedback has been presented, qualified, and incorporated wherever possible and that it is now simply time to formalize a decision to move on with the program.
The general guidelines for IT Transformation teams engaging stakeholders in this critical activity are as follows:
Be Prepared: Transformation teams should have not only a prepared set of material describing the approach to Service and portfolio design but also a firm grasp of the current proposal that is being reviewed, paired with an explanation for how the proposed Service would impact the stakeholder.
Be Patient: Beyond the initial effort to review the Service and portfolio design principles with stakeholders and presenting the initial proposals, transformation teams likely need to host multiple rounds of review across different teams and mixes of stakeholders to collect all relevant feedback. Always listen intently to the feedback from every round of review and then make the best decision in support of the Service(s) in question as well as the broader transformation program.
Expect Change: Transformation teams should never be personally invested in a proposed design but should be ready and willing to update the proposal based on quality input and qualified feedback. Also always be sure to remember that it will not be the core transformation team but likely the stakeholders in the room who will be responsible for managing aspects of the Service in the future.
Remember the 80/20 Rule: Could the current proposal be considered as 80 percent right with the opportunity to optimize the remaining 20 percent in the coming months? If so, then move along and allow the best solution to take shape over time as Service delivery teams put the proposal into practice and refine. Remember that even the best designs have to adapt when put into practice; there will always be opportunity for change over time and continuous improvement. The important point is that the proposal is largely right at the moment rather than perfectly right, which it can be in the future.
Leverage the ITaaS Framework’s Reference Portfolio: While the reference portfolio can accelerate the initial set of Services proposed for the portfolio, it can also be leveraged as a valuable comparison. Transformation teams should carefully consider cases in which there is little in common with reference Services.
Identifying Service Chains
As they begin finalizing the Service and portfolio design, IT Transformation teams should work to identify all Service chain requirements. Service chaining is a critical mechanism within Cisco’s ITaaS framework for modeling the total costs of Service delivery and understanding the impact of Service performance to other Services. Documenting the Services participating in Service chains helps transformation teams more quickly complete the Service cost modeling strategy as well as improve strategies for Service performance, and even support Service Owners in early Service delivery.
Finalizing the Portfolio
Whenever we discuss the effort of finalizing the IT Service portfolio, we do not mean to imply that the Service and portfolio design is completed for good. As we established previously, IT Services and other elements of the portfolio must be adapted over time to drive the most value from the Service delivery function and maintain alignment to changing business needs. In fact, IT Transformation teams should expect some degree of changes to be made even prior to completing the transformation program. This is a result of putting the Service delivery framework into practice through early Service pilots and Service delivery roles such as Service Owners slowly growing more accustomed to the ITaaS framework.
IT Transformation teams finalizing the initial proposed Service portfolio should work through each of these steps:
Accuracy and completion review
End-to-end consistency and quality assurance review
Review against guiding principles for Service delivery
Review and sign-off by CIO and senior IT leaders
The accuracy and completion review is intended as a “did we miss anything obvious?” opportunity. As extensive as the ETC map and efforts to qualify the portfolio have been to this point, something potentially could have been missed, and often it represents a major focus of the IT organization or even an enterprise business strategy. As an example, consider an IT Service portfolio supporting an enterprise that relies heavily on vendors but failed to include a Service delivering capabilities for vendor management simply because the small number of stakeholders who would have identified requirements for such capabilities happened to not have been engaged. Transformation teams should use this as an opportunity to openly challenge themselves with the question “Have we forgotten anything?”
The initial proposal for the portfolio will be built by multiple groups within the IT Transformation team working to incorporate feedback across a wide range of stakeholders; the purpose of the second review is to ensure that the outcome of the design activities is consistent end-to-end. Quality assurance is also considered here—for example, holding up Service proposals against the definition of a Service and ensuring all the requirements identified by the ETC map have been addressed.
The guiding principles review can be conducted quickly but is an absolute necessity and should not be taken lightly. Here again, transformation teams should have high confidence that the outcome of the Service and the portfolio design activity are completely in line with the guiding principles for Service delivery.
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 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.
Designing the Service Portfolio
Chapter 4 provided details on the purpose and value of additional levels in the Service delivery taxonomy. These additional levels created a hierarchy for our portfolio and enabled the aggregation of Services (Service categories and Strategic Service Groups) along with the management of individual Services (Service Offerings and Service assets). The following sections describe the actual design and designation of elements at each level of the taxonomy and provide examples and best practices for each.
Designing Service Offerings
Recall from Chapter 4 that the availability of Service Offerings within the Service taxonomy affords Service Owners a highly flexible mechanism for managing an individual Service. They could be leveraged simply to organize and ease the management of a Service, deliver differentiated capabilities while minimizing resources and assets, and even create levers for use in facilitating desired outcomes. Even more significant was their low overhead and ability to be introduced with little impact to the Service landscape.
The level of flexibility afforded by Service Offerings, their low management overhead, and isolation from impacting the broader Services landscape provide teams with an ideal first option for facilitating delivery of new capability requirements. If it is later determined that the Service Offering warrants its own Service, the capabilities can be spun out and a Service Owner assigned, TCO model constructed, and performance strategy developed. The key is that unless there is an obvious requirement for a new Service, teams should attempt to minimize.
Cisco recommends that IT Transformation teams attempt to designate one to two Service Offerings during the Service design phase. Doing so can help potential stakeholders better envision the future focus and size of a proposed Service during vetting and support newly initiated Service Owners in getting the Service up and running. This is strictly a recommendation and not a requirement, however, because teams can sometimes struggle to define details at the offering level for some Service types and should not allow their Service design activities to be stalled. Even then, transformation teams can expect their initial proposals for Service Offerings to change dramatically through the process of vetting and finalizing the initial Service portfolio, however, and due to their flexibility and low management overhead, they can be leveraged to address the various competing requests from different stakeholder groups. Teams should also anticipate Service Owners making their own changes to proposed offerings soon after taking over a Service. Transformation teams should view this as a Service Owner having gained a working understanding of the ITaaS framework and confidently taking on the responsibilities for driving more value from the Service.
Service Offerings can often be identified by working through the various capabilities they provide for the management of a Service and considering whether they apply. For example, does the proposed Service need to provide any level of differentiation in its capabilities? Can the capabilities be grouped by customer base or underlying Service asset?
In the long term, each Service should ideally define a minimum of two Service Offerings, but this is not a definitive requirement. Remember that many Service Owners find it easier to designate appropriate Service Offerings after several months of managing Service delivery. In general, Service Owners tend to most often leverage three to five Service Offerings. In cases where more than five Service Offerings are required, the Service Owner’s efforts to manage and maintain each can potentially begin to outweigh the value they add. Numerous Service Offerings can also be an indicator that one or more offerings should be considered for their own separate Services.
Capturing Service Asset References
Service assets require little to no “design” work. Instead, IT Transformation teams are required only to identify the different types of Service assets associated with a Service. From there, the real design effort involves how best to reference the often extensive array of Service assets in the Service portfolio while still ensuring that it can be leveraged as a strategic tool for steering the IT organization.
Recall that Service Assets are the various resources, assets, processes, and even budgets that actually enable the capabilities delivered by a Service. Service assets can include everything from standalone applications to large-scale application suites, to hardware spanning everything from servers, storage arrays, smartphones, laptops, network devices, and of course, IT staff (people) resources. Documenting each asset involved in the delivery of a Service would represent a major effort, and IT Transformation teams working through the design of the initial portfolio are likely eager to understand to what degree they are required to identify these many assets.
The short answer is that the IT Service portfolio should reference only the types of Service assets in use and, whenever possible, link or map directly to other platforms such as asset databases, application portfolios, configuration management databases (CMDBs), or even corporate directories. These platforms are purpose-built for the function of managing and documenting specific information, and are better suited for capturing details such as licensing information, serial numbers, or similar data unique to each. The design work focuses on reviewing the structure and organization of these platforms, and determining how best to link information to the Service portfolio, including the appropriate level of detail to associate with each. The following Service asset references might be contained in a portfolio.
IT Staffing Resources: Level 1 Support Desk Team
Hardware: Networking Equipment: WAN Routers
Software: Standalone Licensed Application: [NAME]
Software: Multi-User Hosted Platform: ERP System [NAME]:
Many IT organizations develop solutions for linking to these systems from the Service portfolio, allowing customers to navigate from one platform to a complete listing of applications associated with a Service and to locate detailed data such as cost and licensing information. Successfully linking information between platforms can accelerate multiple strategies and processes for Service delivery and other functions of the IT organization.
Designing Strategic Service Groups
Chapter 4 established the purpose of the top level of Service aggregation within an ITaaS Service taxonomy and portfolio as providing the CIO and senior IT leaders with a strategic view of the IT Service landscape. With this in mind, the specific elements that make up this topmost level of the Service delivery hierarchy depend on the aspects of the enterprise business and IT organization that IT leaders want to establish visibility to.
IT Transformation teams can begin developing an initial proposal for the elements that will populate this level of the portfolio in parallel with initiating Service design. However, they should remain conscious of several considerations. First is that the designation of Strategic Service Groups (SSGs) should not be allowed to influence the design of any individual Services to a significant degree, much less to supersede fundamental Service design principles. In other words, teams should ensure they are foremost designing Services in response to requirements for technical capabilities, and not proposing Services simply to populate a proposed Strategic Service Group. Transformation teams should also anticipate that as the Service design effort progresses and the final landscape of IT Services across the enterprise begins to take shape, they may be required to revisit an earlier proposal for Strategic Service Groups. With this in mind, they may choose to defer proposing SSGs until they have progressed the Service design effort beyond its anticipated midway point. Teams should also always remember that the final design can and should be heavily influenced by the IT leadership team.
Cisco recommends that this level of the taxonomy be populated with no more than ten elements and considers four to six to be ideal for most IT organizations. Designating fewer than four or more than ten Strategic Service Groups begins to strip this level of aggregation of its strategic significance. Cisco’s reference taxonomy designates six Strategic Service Groups.
The best advice when proposing a set of Strategic Service Groups is for IT Transformation teams to consider these questions: What types of questions will the CIO and senior IT leaders have regarding the IT Service landscape? What is the most valuable view of aggregated Services information to support their top priorities and the decisions they will be faced with? Some examples of these may include
Do we have visibility to the technical capabilities the IT organization delivers that have been deemed a competitive advantage to enterprise business operations?
What are the total operating costs for Services supporting common corporate functions and delivering capabilities that are standard requirements across businesses, and are there any emerging trends that these Services could adopt to decrease these costs?
What are the total costs of Services that enable the IT operating model, how have those costs changed over time, and how are they forecasted to change?
What is the high-level performance of core Technology Foundation Services, and how is this impacting Business Operations and Enterprise End-Customer Services that directly enable our customers?
Cisco’s ITaaS framework and reference portfolio contain a set of SSGs based closely on the original organizing principles of Cisco IT’s portfolio and then refined across numerous enterprise businesses of different sizes and industries. As with any segment of the reference portfolio, they can both accelerate and guide the efforts of the transformation team, but should be carefully reviewed and customized when necessary to address the characteristics and goals of each IT organization and enterprise business.
Competitive Advantage Business Services: Business Operations Services that primarily enable processes for enterprise lines of business, including delivery of technical capabilities identified as differentiating the enterprise business in the marketplace, outperforming competitors, or supporting strategies and outcomes driven by the leadership team.
Standard Business Services: Business Operations Services that primarily enable processes for enterprise lines of business via common standard, matured capabilities common within the industry.
Corporate Functions Services: Business Operations Services that primarily enable processes for common corporate functions such as human resources, legal, and finance.
Enterprise Productivity Services: Enterprise End-Customer Services that enable general productivity, communication, and collaboration across the enterprise.
Technical Infrastructure and Platform Services: Technology Foundation Services that enable technical capabilities consumed by other IT Services to deliver capabilities.
IT as a Business Services: Business Operations Services that enable processes unique to the IT operating model and allow the IT organization to run like a competitive business.
Aggregation of IT Services across the Strategic Service Groups recommended by the reference portfolio effectively aligns Technology Foundation and Enterprise End-Customer Service types into different classes, providing IT leaders with direct visibility of and ability to focus on the unique needs of each. From there, Business Operations Service types are categorized by the operations the Service enables, establishing visibility to Services that enable common corporate function BUs, industry and enterprise unique lines of business, and the IT organization itself. For those Services enabling the lines of business, IT and business leaders can additionally distinguish those that provide capabilities that can disrupt the industry and establish the enterprise as a market leader. This differentiation allows the IT organization to subject competitive advantage Services to unique requirements, such as dedicated Service Reviews with business execs, investment prioritization, and increased scrutiny on Service performance.
Once again, the names and guidance for categorizing Services within a specific Strategic Service Group can and should be customized as required to facilitate the purpose and goals of the IT organization. Regardless of how closely the finalized Service portfolio reflects those included in the reference portfolio, the key is that teams remember the name and purpose of establishing this level of the taxonomy. If the designation of elements fails to create a strategic view of the IT Service landscape, this level of the Service delivery taxonomy has failed in its fundamental purpose.
Designing Service Categories
The common role of this taxonomy and portfolio level is to provide an initial step of aggregation for the likely significant set of IT Services defined in the portfolio. Chapter 4 described that it could be leveraged to create opportunities in various ways and for different segments of the IT organization. Services can be grouped by architecture, technology domain, or even by customer base. The key consideration for the IT Transformation team is the opportunity and value it creates for the IT organization.
Cisco recommends transformation teams consider grouping Technology Foundation and Enterprise End-Customer Service types by technology domain, and business operation Services by function. Table 6-2 provides examples.
Table 6-2 Domain and Function Grouping
| Sample Service Categories | IT Services |
| Enterprise Sales Function Services | Revenue Accounting Capabilities, Customer Data Management, Partner Program Management |
| Collaboration Services | Email and Calendaring, Video Conferencing, Messaging Technologies |
| Network and Access Services | Corporate Network, Partner Connections, Home and Remote Access |
| Application Development Services | Enterprise Application Customization and Development, Mobile App Development, Programmable Infrastructure Development |
A second consideration is to allow Service Architects and the EA practices to group Services into share architecture categories. In doing so this option creates an aggregation of Services that better facilitates architectural planning.
A Service category should contain a minimum of two to three Services, and no more than a dozen, beyond which the group of Services can become difficult to manage. Remember, for Service delivery frameworks that have adopted a four-level taxonomy, this is the level that is removed from the Service delivery hierarchy in favor of retaining the functionality of Strategic Service Groups. Transformation teams that initially chose to progress a five-level taxonomy and now find themselves struggling to populate Service categories with more than two Services should consider moving instead to a four-level portfolio.
Summary
Within the ITaaS framework, the purpose of the Service portfolio is to apply the Service delivery taxonomy and create a hierarchy for managing the IT Service landscape, with a goal of creating a strategic tool for the planning and execution of strategies at different levels of the IT organization.
IT Transformation teams begin by considering how to structure and also present the information within the portfolio. From there, they begin the design of IT Services and other levels of the taxonomy to facilitate the technical capability requirements of the enterprise. Once an initial proposal for the Service portfolio nears completion, it should be subject to several rounds of reviews and vetting with all applicable stakeholder groups. After this feedback has been incorporated transformation teams finalize the portfolio by conducting an end-to-end quality assurance review and consistency check, as well as getting sign-off from senior IT leaders.
Basic Service design begins with a logical grouping of related technical capability requirements. From there, teams iterate through a series of considerations, such as the complexity of management and resulting customer base in order to refine the initial proposal. Service types also inform Service design. Business Operations Services leverage the ETC map as a key input, while Enterprise End-Customer and Technology Foundation Services more heavily leverage the reference portfolio.
Initial Service design should also include proposals for Service Offerings, which can help shape the scope of a proposed Service and support informative review with stakeholders. Transformation teams need to review the best approach to documenting Service asset references, and should also capture initial references for each proposed Service. Once they are assigned, Service Owners are responsible for finalizing Service Offerings and Service assets.
Design of Strategic Service Groups should focus on creating strategic visibility of the IT Service landscape for IT leaders. Cisco’s reference portfolio includes a set of SSGs that have been successfully leveraged by IT leaders across different industries that can be tailored by transformation teams. Service categories provide a first level of aggregation and should enable capabilities and create value for other segments of the IT organization. Cisco recommends categorizing Enterprise End-Customer and Technology Foundation Services by technology domain, and Business Operations Services by function or stakeholder group. IT Transformation teams should also consider leveraging the Service categories as architecture groups, creating a distinct point of information exchange with an EA practice.