Laying the Groundwork for Cloud

Chapter 1. Establish Your Starting Point

All journeys begin at the starting line. Having a crystal-clear picture of your business’s starting point and the challenges you’re facing will motivate you and your team throughout your transformation. In this chapter, I’ll explain how transformation horizons can help you pinpoint where you are on your journey, so you can set your sights on the right target. We will identify the aspects of your starting point you need to define, in order to establish the motivation to change. We will look at setting transformation objectives and handling both future performance and past legacy investment.

Define Your Transformation Horizons

“Horizon” implies that your focus is on what you can see ahead, and as a result, what you will implement next. Defining transformation horizons will help align your business benefits by unlocking value with efficient investment in change, which avoids stranded investments that do not yield benefit. Horizons should be aligned to increasing performance targets.

Each horizon should be manageable, focusing on achieving small but meaningful targets. Later horizons should reflect longer term goals, strategies and targets. Let’s look at four possible transformation horizons you may be working toward.

Cloud Ready

The cloud is operational and ready to either build new services or migrate old ones.

Cloud Enabled

The cloud operating model has been optimized for agility aligned to DevOps and efficiency using automation to improve key performance metrics (e.g., fulfillment and assurance).

Digital Ready

The cloud is extended to handle a partner ecosystem and engage customers in different ways.

Digital Enabled

The service and application experience has been optimized with more advanced processes and tools (e.g., analytics driving service optimization). Figure 1-1 shows the alignment of key projects by scope and horizon.

This report is designed to support you on your entire journey but assumes that you are either about to start or are some way toward the cloud-ready horizon.

Figure 1-1. Transformation horizons with a cloud-ready initial target

Establishing your target transformation horizons will define the scope of the transformation layers, modules, and low-level capabilities. One challenge in defining the horizons is establishing what related projects need to deliver within the same horizon.

Note

Remember to highlight and communicate your successes but accept that there will be some failures along the way. In the event that you fall short of a goal, adjust your transformation plans and establish new goals as needed.

For a robust plan and effective transformation governance,¹ you need to align the business drivers to the transformation horizons. Include an ongoing benefits assessment against performance expectations. Benefits will often depend on related projects across your operating model transformation. Technology-driven projects, which without operating model and service performance alignment, are likely to isolate benefits with limited traceability to the business drivers (something most organizations have experienced and must now actively seek to avoid).

In Chapter 2, we will discuss accelerators, which are designed to speed up the definition of your current state, but also to help plan your future horizons.

Establish Your Transformation Objectives

In today’s digital economy, business-to-technology alignment is becoming a key differentiator, as the pace of change accelerates along with the broadening of consumer expectations. Historically, technology organizations sought financial investment and aimed to create capabilities that the business needed, without always building a direct relationship between business strategy and performance. But as business needs have evolved, the cost and time lag of technology change opened up an even larger expectations gap. Your technology organization needs to lead the change in becoming service driven, but your supply chain also needs to become service rather than support focused. Although your supply chain may already deliver to established service levels, the supplier’s focus needs to move away from the support wrapper² around what you need and toward the service itself.

The rapid growth of public cloud providers, such as Amazon, Microsoft, and Google, reflects the need for technology to provide a service, rather than just technical capabilities. Still, many in-house technology teams see public cloud as a threat, and some that have resisted change have been bypassed as business groups buy cloud services directly (often referred to as shadow-IT). Organizations that experience this must recognize that this is a symptom of the problem with the business relationship and focus on the strategy to solve it. The solution must embrace a governance model that allows supply chain diversity, and positions internal technology as an effective and competitive provider. Teams that feel threatened need to be supported by competence models that help adjust their function. For instance, if you introduce automation to eliminate repetitive tasks, redirect those staff members to design the automation.

Technology has faced pressure to optimize cost for many years—deliver more for less is a common theme. If technology constraints are impacting business markets and revenue, then this only intensifies the problem and increases pressure to reduce costs further. For technology organizations, this cycle needs to be broken or the business will seek services elsewhere, and in doing so, reduce demand without necessarily reducing dependencies and the ability to reduce costs. The net result can lead to new cost centers for the business outside of the technology organization and even greater pressure to justify collective technology spend.

Your target operating model and transformation objectives must face up to this cycle and address it; your need to transform is not just driven by internal business partners, but by consumers and the competition. Make sure you capture the baseline and benchmark performance along with targets and use them to measure future success (or deviation from target).

Establish Your Performance Benchmarks and Targets

Building a hierarchy of services and value is not easy, but if a performance-driven transformation is to be successful, the parent services must see an improvement based on investment and improvement to the contributing child services. While your target strategy and use of horizons may help schedule change in the transformation plan, the business management teams are typically driven by performance benchmarks and targets. There could be a significant time lag from investment to operation to benefit which needs to be accounted for in any business case forecasts.

Case Study: Performance Alignment

A large global telecommunications organization I worked with had a strong and very public focus on customer performance and cost (what quality of service they received from the fixed and mobile networks). This was a very important measure against their competitors who are all fighting for market share, primarily based on the customer experience. They had much less performance visibility of the internal technology organization (how efficiently the service was delivered) other than the headline total costs.

It’s easy to deliver a high-quality service with unlimited funding, but the reality is that customers want more services for less money, which forces the focus onto the cost of delivery. What they needed was the same internal focus on performance as they already had in place publicly.

To solve this in a sustainable way (rather than a one-off audit) they needed to set up a hierarchical view of services (what are all the building blocks we need that deliver the end service to our customers?). Then each building block needed ongoing performance measurement and scrutiny (using industry benchmarks to understand just how efficient they were at delivery). They could then prioritize and improve the least efficient services.

The advantage of defining services is your ability to test if performance targets are realistic, by comparing with available industry benchmarks for performance and cost. In a service-driven supply chain, the contracts can then focus on rewarding target performance improvement by measuring the baseline and benchmark performance metrics (or penalty if the trend opens up a larger performance gap).

Although looking to the future performance is key, you must also define your historical technology investments that will now be considered legacy.

Define Legacy

Internal technology organizations generally consider themselves in a challenging position, with higher expectations set against commercial pressure to reduce cost, and the increased overhead of managing several layers of legacy technology. Here are some considerations for handling the challenge:

• The goals of the service portfolio and service definitions should help the business consumer understand what they are buying and at what service level. To do this, your technology organization needs to align the service strategy and investments to a service roadmap (this should help you define legacy). This may lead you to do a discovery exercise if your inventory is not in good shape.

• You need an approach that decommissions and releases the costs of your services (and legacy) when they are near end of life. Be sure to handle this roadmap with strong governance as it drives change and commercial impacts to the business and related services.

• You must take a pragmatic approach to phase out, rather than rapidly decommission. You can correlate this to a phased reduction in service level, or increase in cost to encourage change.

In some complex environments, it might not be strategically or economically viable to transform a legacy platform or technology capability. Legacy can, however, hold a value in terms of accounting book value or a technical dependency for a service. The roadmap for moving legacy systems to the cloud often depends on a slow removal of dependencies as application services transform. From a target operating model³ perspective, the goals for operational agility probably do not apply to legacy—it’s not likely to be changing much. As a result, there can be an advantage in outsourcing legacy support. When you consider how to transform the service support wrapper, focus on how the legacy platform can best be consumed by related services.

If outsourcing your legacy capabilities is not appropriate, perhaps due to scale or timelines, then consider an internal service support wrapper that prevents legacy constraints from blocking the overall goals of the operating model. While service orchestration and automation may not apply as much in legacy, the interfaces to legacy process need to support the target operating model. This may mean that an automated parent service depends on an interface or process that wraps around the legacy technology capability.

If you need to retain legacy for a longer period of time and it’s holding back the operating model or performance goals, then you should undertake a broader transformation. This situation can be a difficult business case to make, and you’ll need to define the performance and economics along with the cost of change. I strongly recommend taking all opportunities to transform your legacy systems as part of lifecycle events, including technology refreshes and application upgrades.

Summary

• Start to shape your future transformation horizons in context with your current state of operation.

• Use your current challenges to help drive transformation objectives and measure success on your journey.

• Apply performance analysis internally using service benchmarks to establish improvement opportunities and priorities.

• Have a strategy for your legacy technology investments, including outsourcing.

¹ Governance relies on broad organizational empowerment to set and adjust the direction of the transformation management and delivery teams.

² A support wrapper typically focuses on the support levels around a service rather than the service itself.

³ The target operating model (TOM) defines the strategic goals for the organizational structure, in addition to outlining services and how they are delivered. In the context of cloud, the target operating model should reposition from technical and organizational silos to service layers.