A Cloud Journey to Deliver Business Outcomes
Surveys of industry executives show that the majority of cloud journeys & digital transformations fall short when it comes to delivery of business outcomes
A cloud journey to deliver business outcomes
Alice: "Would you tell me, please, which way
I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where –" said Alice.
"Then it doesn't matter which way you go,"
said the Cat.
Alice’s Adventures in Wonderland
With thanks to Chris Daniel,
Chris Swan and Dave Wilson
for their contributions to this paper.
The Wonderland conversation between Alice and the Cheshire Cat has echoes for many discussions about cloud strategy. “We need to move to cloud” is a constant refrain. Less often does one hear the question why? The truth is that before you can answer the how, the where, or indeed the if of cloud, you need to be clear about where you want to go and where cloud can take you.
Surveys of industry executives (for example, by BCG, McKinsey, Accenture and KPMG) show that the majority of cloud journeys and digital transformations fall short when it comes to delivery of business outcomes. A principal cause of this failure is lack of clarity around business outcomes; either outcomes are not clearly defined in business terms to start with, or such clarity as exists for the CEO and CIO is watered down as the ‘imperative’ to adopt cloud is cascaded through layers of the organization. As a consequence, too many cloud journeys end up as ‘IT for IT’s sake’. The only variation on the adage about ‘a hammer in want of a nail’ is that in this case there happens to be more than one hammer (IaaS, PaaS, cloud-native and so on). People just want to know which hammer to use. To extend the metaphor, you should first be asking where to hang the pictures, or perhaps even whether to move the walls.
Leading Edge Forum is producing a series of papers on Leveraging the Hyperscalers. The first paper explored how enterprises can build business capabilities in a new way by assembling components from the cloud. The aim of this paper, the second in the series, is to explain how business leaders – CEOs, COOs, CFOs and business unit heads – can ensure that their journey to cloud is focused right from the start on delivery of business outcomes. In addition, this second paper provides a structured approach (see next page) to ensure you never lose sight of these business outcomes when designing and executing your cloud programme.
Decide where you want your business to be in, say, five to ten years. Which markets do you intend to enter or exit? What cost structure, fixed vs. variable, do you want the business to have? Read >
Identify how cloud can support delivery of your business outcomes:
Cost: Where is your priority, reducing costs or shifting from Capex to Opex?
Agility: Where do you most need agility to speed up the release of new features & products?
Innovation: What new business models can you create for yourself or for your customers? Which new customers can you find & which markets can you be the first to discover? Read >
Determine which of the various cloud strategies will best meet your cloud objectives: IaaS, PaaS, cloud-native applications, SaaS, business services & cloud-native business capabilities Read >
Develop a map for your cloud journey that aligns business goals & cloud strategies Read >
Ensure that your cloud projects add up to a coherent programme that will take you to your destination Read >
Establish the enabling non-technology workstreams that must be in place for a successful cloud programme since cloud is as much about culture, organization & new operating models as it is about technology Read >
Looking to the horizon
In deciding where you want to get to, it is of utmost importance to set your destination in terms of business outcomes, not IT goals. For instance, you might ask:
- Which markets do we intend to enter or exit?
- What cost structure, fixed vs. variable, do we want the business to have?
- Where do we most need agility to speed up the release of new features and products?
- What new business models can we create for our enterprise, or (more radically) for our customers?
- Who are the new customers that we can create and the new markets that we can be the first to discover?
Define the outcomes for your cloud journey in business not IT terms, using a long-term horizon of, say, 5-10 years
The reason for framing outcomes in business terms instead of IT terms is that, as we will show, cloud has the potential to contribute so much more than just enhanced IT.
Set your future vision by looking to the horizon, taking a long view where cloud is seen as a multi-year journey that takes you to where you want to be as a business in, say, five to ten years.
Cloud has the potential to contribute so much more than just enhanced IT."
This long-term perspective is vital for several reasons:
- It’s a journey of a thousand steps. View your journey as not a revolution but an evolution, made up of countless small steps. Benefits will be delivered along the way, but if you are demanding rapid break-through results, look elsewhere.
- “There are problems that are impossible to think about in two-year terms – which everyone does – but they’re easy if you think in fifty-year terms”1 . The inventor and scientist Daniel Hills had in mind some of the most challenging problems in science, but this fundamental observation is true for cloud if one substitutes fifty years with five to ten years. The series of steps that make up a journey to cloud can only be mapped out if one knows the destination.
- You will have to burn your boats. Disposing of your IT assets (hardware, data centres and investment in legacy applications) amounts to burning the boats: does everyone accept there is no turning back?
- Perseverance will be needed. The journey will require sustained funding and senior management focus. Moreover, cloud entails experimentation and since not all experiments work you will encounter a few blind alleys. Are you prepared to stay the course?
- “The future is a foreign country: they do things differently there” (with apologies to L.P. Hartley). Cloud operates according to fundamentally different models that can often prove uncomfortable. Security and control form particular stumbling blocks: automation takes humans out of the loop; you will depend on very few vendors; your data will be off-premises; if there is an IT failure, business continuity relies on recovery that is based on software not hardware; and many security decisions are outside your control – in good hands, but outside your direct control. There is no point in starting the journey if, when the time comes, you are not ready to let go and cross over into unfamiliar territory.
Make sure the destination is worth the journey. The most fundamental reason for taking the long view is that, as we will show, cloud has the potential to alter the trajectory of your business, by creating value for customers in new ways. Why settle for less?
Make sure the destination is worth the journey."
1. Cited in Michael Nielsen, Reinventing Discovery: The New Era of Networked Science, Princeton University Press, 2012
Defining the destination
To follow the reasoning of the Cheshire Cat, the starting point for any cloud journey should be an assessment, not of applications, nor of IT infrastructure, but of your strategy to compete and create value. In practice, so many cloud journeys fail to get off the ground, or later fall apart, because objectives were not clear at the start and stakeholders were not aligned, in particular across business and IT. Moreover, without objectives, progress and milestones cannot be measured.
Cloud can create value in three main areas: cost, agility and innovation. As a first step, you need to decide, for the enterprise as a whole and for individual business areas and applications, your cloud objectives in terms of cost, agility or innovation
At a high level, cloud has the potential to create value in three areas: cost, agility and innovation. Cloud can bring other benefits (for example, strengthened security and increased visibility of IT resources) but these by themself do not justify a move to cloud. The ways in which cloud impacts cost, agility and innovation, together with associated metrics, are described in the table below.
The business impact of cloud & associated metrics
Cloud reshapes costs, changing them from Capex to Opex and from fixed to variable. In addition, cloud can reduce Opex in the form of hardware, software, facilities and people required for IT management and administration. And developers and IT staff save time and effort through self-service provisioning.
Metrics for cost include: for Capex, cash from asset sales and forgone capital spending; for Opex, spend on data centres, hardware, software and people (IT operations and administration, data centre and facilities management, vendor management, business operations and security). Depreciation and write-offs will often be an important factor in calculations.
Cloud brings business agility through flexibility, ability to scale up or down (often termed elasticity), speed of experimentation and throughput of software delivery. Moreover, cloud supports and reinforces other changes that engender agility, such as Agile and DevOps. Above all, cloud democratizes change, by empowering architects and development teams to operate at a speed that is impossible in a traditional, more controlled, top-down model.
Agility translates into business impact through ability to deliver incremental change fast (based on a short release cycle), whether the goal is to create customer value through rapid iteration of product and service features, or to drive efficiency in operations. Companies that have adopted cloud platforms report that they can bring new capabilities to market about 20 to 40 percent faster (e.g. Cameron Coles).
One way to think about the business value of agility is in terms of options. Through ability to source components quickly and to swap them in or out based on market feedback, the modular component-based design philosophy of cloud creates options. Critically, the value of modular approaches and the options that they create increases as the rate of industry change increases.
Finally, agility builds resilience by enabling a rapid response to shifts in the environment.
Metrics for agility include the number of added product features per year, the length of release cycle for product features, burn-down rates, the number of products or services per customer, and percentage improvement in business metrics such as operational efficiency and customer satisfaction. There are also many valuable metrics of IT agility, such as the average time to resolve incidents.
A useful source of measures of agility is Accelerate, which lies at the heart of the DORA (DevOps Research and Assessment) programme. Accelerate encompasses metrics across four dimensions: speed to market, future-oriented outlook, regulation, and compliance and security.
That said, however hard you try to measure agility, something will always be left out. Much of what agility brings comes in the form of options whose value cannot be priced until they are exercised.
By allowing new systems and capabilities to be built rapidly and then tweaked or scaled according to customer feedback, cloud can power entry into new markets and the launch of completely novel products and services. For a business, this innovation can translate into step changes not only in revenue but also other important business goals. For example, in a bank, reducing risk exposure in order to minimize capital; and in a public sector entity, policy outcomes such as improving public health.
Metrics for the impact of cloud innovation are likely to take the form of top-level enterprise measures such as revenue, capital, policy outcomes and measures of the innovation process itself. As an example, in pharmaceuticals the length of the product lifecycle to get new drugs to market is one of the most fundamental drivers of long-term success.
You need to decide cloud objectives in terms of cost, agility or innovation, for the enterprise as a whole and for individual business areas and applications. A top-down view sets the overall direction for your journey, while a bottom-up perspective will reflect the starting point, identifying constraints and immediate priorities that shape the route to be taken. To ensure that business outcomes and cloud objectives are clear to all, encapsulate them in a charter against which the programme and each project can measure success.
Cloud strategies: Understanding the journey
Different cloud strategies contribute towards cost, agility and innovation to varying degrees. The key is aligning these distinct cloud strategies to your objectives
Once you have established clear cloud objectives, you can identify the right cloud strategy for each part of your business. The issue is that cloud comes in several ‘flavours’. These contribute to cost, agility and innovation to a varying extent and in distinct ways.
When deciding which cloud strategy provides the best match, it is helpful to distinguish between two strands within cloud computing, with different antecedents. On one side are the hyperscalers: in the West, AWS, Google and Microsoft; and in China, Alibaba and Tencent. In essence, the hyperscalers offer IT components at different levels of abstraction that you can use to assemble capabilities. At the lowest level, Infrastructure-as-a-Service (IaaS) provides infrastructure on demand on a pay-per-use basis. Platform-as-a-Service (PaaS) represents a higher level of abstraction by including a software layer on top of the infrastructure to form an IT platform. The third level of abstraction is cloud-native applications, where developers design applications to operate in the cloud, making full use of a wide range of development tools, methods and processes that foster agility.
Although the hyperscalers attract most attention in discussions about cloud, the other side of the cloud landscape, which consists of ‘ready-made’ components in the form of Software-as-a-Service and business services, is arguably of equal importance. Ultimately, the philosophy of cloud is to create value for customers by enabling them to consume services externally over the internet, whether IT or business components. SaaS can support horizontal functions (e.g. customer relationship management) and vertical functions (e.g. core banking). In addition, business services, often available via Application Programming Interfaces (APIs), offer ready-made business components, typically for a narrow slice of capability such as a credit check. Here the lines have started to blur because the hyperscalers have stepped out of their IT niche and now offer business services, such as payment fraud APIs.
The most recent addition to the cloud landscape is cloud-native business capabilities. They represent a higher level of abstraction because they deliver a business capability as opposed to an application. Cloud-native business capabilities are envisioned, designed and delivered on the basis of sourcing from the cloud, and assembled from cloud-native applications (underpinned by IaaS and PaaS), business services and even SaaS. The potential for these distinct cloud services to create value is shown in Figure 1.
Figure 1: The impact of different types of cloud services on business performance
Over the rest of this section we explain how these various cloud services impact cost, agility and innovation, as well as factors to consider in deciding which option is best suited in your circumstances.
In 2006, when Amazon Web Services began marketing Elastic Compute Cloud (EC2), the value lay not in the actual compute or storage, but in the service model, providing Infrastructure-as-a-Service (IaaS), on-demand, self-service, elastic and pay-per-use. The as-a-Service model enabled agility because developers no longer had to wait while infrastructure was provisioned, and infrastructure could be scaled to meet peaks and troughs of demand. However, there was no direct impact on innovation, and thereby on revenue and other business outcomes, since IT infrastructure (and still less a new service model for IT infrastructure) brought no advantage in the eyes of customers.
Clearly, by its very nature as a rental or leasing model, IaaS will reduce Capex, but the Opex picture is more complex. The catch with IaaS is that, like most on-demand services, you pay for the luxury of instant access. It is this pricing premium that allows the hyperscalers to sustain profit margins of more than 40 percent. As with other premium on-demand services (such as car rental), whether renting will cost more or less than buying outright will come down to how much you use it. If you drive to work every day, renting a car is unlikely to save you money; if you are a Sunday driver, rental may well work out cheaper. Likewise, if you like to upgrade to the latest model every few years then leasing may well be a better option. Of course, the equation will be different if you already own a car, especially one that has been depreciated.
In the context of IT infrastructure, this means that for most workloads that run all day, every day, it will be hard to make a financial case for moving to IaaS, once the cost of migration is taken into account. Nevertheless, there is typically a positive business case for workloads that can be readily switched off and on, such as development and test. Similarly, enterprises typically keep a lot of compute capacity ‘just in case’, for example, for disaster recovery/
business continuity and to handle cyber attacks, and here cloud’s ability to burst instantaneously removes the need to keep these idle resources. Moreover, IaaS may well deliver cost savings for workloads that are only required periodically, such as monthly billing processes, seasonal peaks, or compute-intensive calculations (for example, risk modelling for regulatory and control purposes). In this instance, serverless computing may also offer a good fit; it is a step further than IaaS towards a pure utility model, in which the cloud provider runs the server and dynamically allocates machine resources.
An important caveat is that the cost savings that you actually achieve will depend on how you implement your IaaS solution. For instance, if the application is simply moved to a like-for-like infrastructure, so-called ‘lift-and-shift’, then savings will be substantially lower (potentially by up to 50 percent) than if you change the way you manage the infrastructure through right-sizing, auto-scaling, real-time monitoring to adjust usage and charging costs accurately back to business units to influence consumption. Your choice of pricing plan (on-demand, reserved, spot, etc.) will also have a major bearing on the savings delivered. The final step in realizing the benefits of IaaS is exiting datacentres and decommissioning legacy systems. Since many savings are not realized until the last system is switched off, detailed planning of system migration is vital to deliver the business case.
Platform-as-a-Service (PaaS) adds a software layer on top of the infrastructure to form an IT platform. PaaS gives developers on-demand access to pre-built components, for example, databases (DBaaS), integration services, containers in which to run applications, software development toolkits and artificial intelligence tools (AIaaS). Reducing toil (defined in the Site Reliability Engineering Book as “work that tends to be manual, repetitive, automatable, tactical, devoid of enduring value”) allows developers to concentrate their effort on developing code that delivers business value. Consequently PaaS has a strong impact on developer productivity and throughput, enabling rapid release and iteration of new product and service features. In addition, using standard platforms leads to greater agility across the enterprise by designing out much of the complexity that ties large organizations in knots.
Although the principal impact of PaaS is on agility, PaaS also delivers lower operating costs: some routine system administration tasks (such as patching) are redundant as the cloud platform will be constantly updated to the latest version; over-provisioning of software licences is minimized because software is purchased on a pay-per-use basis as part of the PaaS charge; PaaS can reduce infrastructure usage since this is scaled across the whole platform, rather than for each application or virtual machine; and finally, by enforcing standards (for example, of software versions) PaaS strips away the cost associated with a profusion of software products and versions.
Ultimately PaaS is all about standardization and, as with any strategy to standardize, your success in harnessing the potential benefits of PaaS depends first on universal adoption of PaaS solutions so that legacy systems are decommissioned and costs released; and second, on standard PaaS solutions remaining standard, by avoiding the temptation to customize, which would build in variation and manual processes that negate the benefits of PaaS.
As cloud computing matured, new ways of developing applications emerged to take advantage of cloud’s inherent flexibility. Cloud-native applications, so-called because they are ‘born in the cloud’, are built using a range of complementary techniques that facilitate agility: infrastructure and developer tools are rapidly provisioned using DevOps to minimize down-time; code is checked and integrated on a continuous basis to cut out rework; continuous delivery and deployment gets code into production faster; microservices that deliver a tiny slice of functionality shorten time-to-market because the scope of development and testing is reduced; and code libraries enable developers to re-use artefacts. In theory, greater developer productivity can translate into lower cost, but in practice the impact is always ‘cashed in’ as higher throughput.
In addition to describing the services that the hyperscalers offer to build natively in the cloud, the term cloud-native can also refer to the wide range of solutions now being developed on an open source basis by the Cloud Native Computing Foundation (CNCF). Some of the CNCF components have actually been contributed by the hyperscalers, notably Google’s Kubernetes for containerization.
Cloud-native approaches add most value in supporting experimentation and iteration around product and service features. This is most likely to come into play where competition consists of ‘keeping up with the Joneses’, as opposed to breakthrough product and service innovation.
The challenge is that, while a cloud-first stance makes sense for new projects, large enterprises have substantial value trapped in legacy applications that were not designed and built for the cloud. To unlock the value, they have to be transformed to operate cloud natively and provide the required agility, on a sliding scale with re-factoring at one end and re-architecting/
re-engineering at the other. The key to getting this right is identifying which cloud features – and which consequent changes in the application – will have the greatest impact on cost and agility. The level of agility that is possible through re-engineering will in most instances fall short of what can be achieved by building applications cloud-first, as you will reach a point of diminishing returns on investment or fundamental architectural barriers.
Software-as-a-Service has a different origin to the hyperscalers. From the earliest days of computing when capacity was in short supply, time-sharing has appealed. Firms such as IBM and EDS established service bureaux, though arguably the underlying technology barely changed, amounting to “batch-processing by telephone wire”2. Then the idea emerged of sharing applications as well as compute resources. The so-called Application Service Provider (ASP) model was cumbersome, however, with ASPs responsible for setting up new users and environments. As with AWS in IaaS, innovation came in the service model, when Salesforce.com introduced pay-per-use access to an application via a web browser and self-service for onboarding new users.
2. Margaret O’Mara, The Code: Silicon Valley and The Remaking of America, Penguin Random House USA, 2019
The SaaS market has expanded from its beginnings in horizontal functions (HR, Finance and Customer Relationship Management) to embrace countless vertical functions, for example, in the banking industry, core banking, collateral management, cash management and reconciliations. Furthermore, horizontal SaaS solutions (such as Salesforce, Microsoft Dynamics and Workday) have evolved to become platforms surrounded by rich ecosystems of partners that offer countless pre-built applications. For example, the Salesforce App Exchange now contains more than 5,000 applications.
Since SaaS is provided as a utility, allowing only minor scope for configuration before upgrades become impractical, it cannot enable organizations to differentiate. That said, SaaS allows organizations to focus investment on areas that do bring differentiation instead of reinventing the wheel. SaaS solutions frequently offer lower cost since SaaS companies function at tremendous scale and so can spread development costs over a wide base. Moreover, SaaS brings agility by offering a steady stream of enhancements and permitting customers to flex the number of users or add new product modules with ease. Especially in greenfield situations, you need a strong argument to justify building a differently shaped wheel.
In parallel to the hyperscalers, niche companies have sprung up to provide business services in the cloud. Examples in banking include market reference data and checks for credit, anti-money laundering, and know-your-customer. Nowadays, most such services, sometimes labelled Function-as-a-Service, are consumed via APIs. The range of business services is extending rapidly owing to investment in Fintech, Regtech, Adtech, etc. and the low entry barrier implicit in a service that delivers just a narrow slice of functionality. Moreover, the gap between the effectiveness of business services and in-house solutions is growing. Specialization coupled with global distribution via APIs makes greater investment possible, while providers of business services can draw on a large customer base to inform product development. The hyperscalers now include many business components in their catalogues, often by commercializing functions that were built for their own use. For example, AWS provides the payment fraud checks that were developed for its online marketplace as an external service.
Just as with SaaS, however, business services by their nature can offer agility and lower cost, but cannot bring differentiation and innovation unless they are combined with other cloud services to form cloud-native business capabilities.
Enterprises embracing a cloud style of thinking should consider the mirror strategy of opening up their own applications, typically via APIs, to provide business services for partners and customers to use. This unlocks new distribution channels (for example, embedded banking in business processes) and is a step towards becoming a platform that connects customers and partners.
Enterprises embracing a cloud style of thinking should consider the mirror strategy of opening up their own applications, typically via APIs, to provide business services for partners and customers to use."
Cloud-native business capabilities
Besides adding business services to their catalogues, the hyperscalers have released infrastructure services targeted at almost every emerging trend in computing: blockchain, Internet of Things, edge computing, 5G, streaming and visualization, machine learning and artificial intelligence, image and text analysis and digital identity management. These additions, coupled with the rich range of components from the partner ecosystems that leverage the hyperscaler platforms, open up fresh possibilities for enterprises to acquire capabilities. Instead of building capabilities in-house they can assemble business capabilities by sourcing business and IT components from the cloud. We call these cloud-native business capabilities because they are conceived, designed and delivered on the basis of sourcing from the cloud. They represent a higher level of abstraction than cloud-native applications because they deliver a business capability, as opposed to an application. Innovation comes from two angles: business vision sees the potential since “Functional combinations are unconstrained in the imagination”3; while technology insight defines what is possible in practice, through knowledge of what components can be sourced from the cloud and understanding of how they can interoperate.
3. Carliss Y. Baldwin, The Value Structure of Technologies, Part 1: Mapping Functional Relationships, Harvard Business School Working Paper, Rev. September 2020
A classic example is Uber, which was created by bundling external business services accessed via APIs from the cloud. Geo-positioning was possible via the operating system (iOS or Android); route calculation and maps were provided by MapKit and Google Maps; Google Cloud Messaging enabled push notifications; payment was handled by Braintree; receipts were sent via Mandrill. Little of Uber’s service was delivered through Uber-owned systems. The point is not that Uber chose to construct its business largely through external services, but that Uber was only possible because these cloud services existed; Uber was imagined and conceived based on the possibilities of accessing services via the cloud.
Many cloud-native business capabilities will be platforms. For instance, a cloud-native omni-channel consumer platform (whether for retail, telco or banking) may incorporate AI/ML to act on analysis of customer sentiment and behaviour; data-streaming to respond in real-time to events such as customer location and transactions (as opposed to waiting for a batch operation); intelligent agents that increase the range and quality of the self-service experience; a seamless experience through integration with a single unified contact centre for voice and chat; and freedom for customers to choose to give and receive information in text or speech (and to move seamlessly between them). Of course, you can develop individual parts of your digital customer experience using cloud-native applications, but the potential will fall short of what you can achieve if you re-think your digital customer experience as a platform assembled from internal and external components that at its heart contains essential cloud attributes such as AI/ML, real-time and omni-channel (voice, text, speech, image).
Uber was imagined and conceived based on the possibilities of accessing services via the cloud."
Since the diversity and richness of today’s cloud services create such ample scope for differentiation, constructing business capabilities ‘cloud natively’ is the preferred strategy where you aim for clear competitive advantage, say, by entering new markets, or launching products that are two steps ahead of your competitors. In addition, cloud-native business capabilities are a natural fit for innovation because they minimize capital outlay while maximizing agility, experimentation and scalability. Through its on-demand and pay-per-use model, cloud brings the accountability, freedom and speed of action that are the essence of entrepreneurship and intrapreneurship: “You make the decisions”; “You get what you need when you want it”, and, of course, “You pick up the bill”.
Just because a business capability starts cloud-native does not mean that it has to stay that way. For instance, as a business matures it may decide to invest in acquiring differentiation in what were originally ‘good-enough’ commodity services. Uber, as an example, has increasingly built out its own payments and GPS solutions. Likewise, once infrastructure usage has become stable and predictable, it may be cheaper to bring compute or storage on-premises.
Charting the Course for
Cloud mapping provides a practical way to decompose the processes and applications in a business domain and identify where new cloud components can be deployed to meet your cloud objectives
Whenever you go on a journey you will want a map. In order to chart your course, we recommend a technique called Wardley Mapping. A Wardley map shows the structure of a business or service, mapping the components needed to serve the customer or user on two axes. The vertical axis reflects the degree to which a capability adds value to end customers; the horizontal axis shows the evolution of technology as it passes through stages from genesis, to custom-built, product and commodity. The various ways in which a Wardley map can be used are set out in the appendix of our report The Renaissance of the IT Organization, and you can find examples of Wardley maps for cloud in Reaching Cloud Velocity: A Leader’s Guide to Success in the AWS Cloud4.
4. J. Allen & T. Blood, Reaching Cloud Velocity: A Leader’s Guide to Success in the Amazon Cloud, AWS, 2020
Let’s see how they work in some banking examples. The Wardley map in Figure 2 depicts bank lending and shows how the cloud can be deployed to increase agility. The typical ‘as-is’ components are shown in purple, while in pink are components that can be introduced to increase agility. For example, a number of companies (including Accelerize360, Prizm Lending Suite, Northteq and VERiPARK) offer pre-built lending solutions developed on top of the Salesforce and Microsoft Dynamics SaaS platforms. These SaaS solutions enable banks to keep up with the highly dynamic lending market by bringing regular enhancements to improve the customer experience. A feature of Wardley maps is that they document significant barriers to change (shown in a black rectangle). One example is reluctance to jettison customized process flows in favour of the standard SaaS processes, which forms a barrier that must be overcome in adopting a SaaS lending solution.
Figure 2: Wardley map illustrating potential moves to increase agility in bank lending
Since the cost of money and demand for lending fluctuate according to economic conditions, flexibility is a valuable characteristic in a credit-decisioning engine so that banks can pre-empt competitors in adjusting lending rates and other product terms. Re-engineering the application so that it is cloud native can deliver this flexibility, but will in turn require supporting IT infrastructure to operate as IaaS or PaaS.
A critical point in the lending journey (where a small difference in performance can have a significant profit impact) is the final step in the process, customer agreement to the loan offer. A SaaS-based digital signature solution can reduce abandonment rates by making it as easy as possible for customers to consent to a loan. A specialist in this space will introduce a stream of enhancements, stemming from the investment and learning that only a large customer base can bring.
Alternatively, a bank may determine that instead of agility, the principal cloud objective for lending is innovation. Figure 3 illustrates (in pink) how a bank can employ cloud to innovate around lending products and services. For example, artificial intelligence and machine learning (AI/ML) can be used to cluster data to identify new market segments or to devise new ways of assessing creditworthiness. Using the Model Lifecycle Management services of the hyperscalers reduces the effort and time needed to build, train, tune and deploy AI/ML models. But if AI is employed to assess loan applications then a barrier to be overcome is satisfying regulators’ requirements for ‘explainability’ of lending decisions, given that many types of AI operate as ‘black boxes’ and are opaque to non-specialists.
Figure 3: Wardley map illustrating potential moves to increase innovation in bank lending
An innovation in the lending process itself is embedding loans in the customer’s online purchasing journey, thereby making loans through new channels and reducing friction in the loan application process. To achieve this, banks can split out micro-services from their lending application and expose these as business services (APIs) that a retailer can call when a customer is buying a product online. Since the micro-service is used for just a moment, serverless will likely make a good fit for computing power. In this case, the barriers to be surmounted include negotiation of contracts with retailers and the simplification of lending criteria to facilitate seamless lending embedded in a purchasing process.
Wherever you go on a journey, you will want a map."
Planning the journey
Potential cloud initiatives should be considered in the context of an overall programme that is more than the sum of its parts and that ensures that the business goals of the journey are reached
The next step in developing your cloud journey is to assess how candidate projects come together as a coherent programme. As with any programme, there should be benefits from managing projects collectively rather than individually and the programme should deliver a combined set of objectives. Useful questions to validate the coherence of your programme include:
- Will the journey take us to the destination that we set? What is the overall business impact of the programme across cost, agility and innovation?
- How are benefits delivered over time in a way that ensures our journey is financially self-sustaining and meets the demands of stakeholders for business impact along the way?
- How do the various elements fit together as a sequence of interlinked projects, whether because there are logical dependencies or because a learning curve implies that certain competences need to be acquired before more challenging projects can be started?
Figure 4 provides a framework for assessing how your cloud journey delivers benefits over time in terms of cost, agility and innovation. The vertical axis shows relative time to implement the distinct cloud strategies, while the horizontal axis reflects the business impact.
Figure 4: Cloud strategies & their business impact over time
The sections below explain some of the factors that you should consider for each of the distinct cloud strategies when you design a coherent and balanced cloud programme.
Although IaaS cannot deliver innovation and will bring agility only in your IT infrastructure, if your strategy does not include any adoption of IaaS you are probably leaving money on the table. This is because you are likely to have some workloads that can be run at lower cost in public cloud and can be moved relatively quickly and cheaply.
An additional consideration is that conducting IaaS projects early in your cloud journey releases funding for the rest of your programme. Furthermore, IaaS offers an undemanding learning ground for adopting cloud models and can lay the foundations for further moves to cloud by providing greater visibility and control of IT infrastructure. As discussed earlier, you will need to transform how you manage infrastructure as a second or parallel step if you want to maximize cost savings.
However, if IaaS and lift-and-shift are all, or even most, of what you do, then you have missed the point of cloud. You will have pursued a narrow cost objective, while your competitors will have worked out how to use cloud to build agility and innovate in new products and markets. No cigar!
If your strategy does not include any adoption of IaaS you are probably leaving money on the table."
Since PaaS is a key foundation of cloud-native development, a cloud programme that lacks a workstream to build out PaaS services will not deliver change at speed and scale. Your PaaS workstream needs to be driven by an architectural approach that identifies the platforms needed for the applications that have been prioritized for cloud-native approaches. For example, applications will need a database, and perhaps a web hosting service, or content-management. PaaS projects need to be sequenced so that PaaS services are available in a timely fashion; otherwise development teams will be held up (creating expensive work in progress!) or invest effort in building makeshift services that will soon be bulldozered by industrial-strength enterprise-wide PaaS services.
An important qualification, however, is that although PaaS can reduce costs, it delivers most of its benefit indirectly through cloud-native application development. Moreover, it takes time to refactor applications to consume PaaS services. The indirect and delayed impact of PaaS brings the danger of misaligned expectations, with business stakeholders anxiously awaiting projects that bring value to customers. Consequently, a PaaS strategy needs to be tempered with cloud-native development projects that consume PaaS services to deliver business impact.
A cloud programme that lacks a workstream to build out PaaS services will not deliver change at speed and scale."
The essence of cloud is agility, so cloud-native application development must be central to your cloud journey. Furthermore, some exploration of cloud native should be one of your first steps. This is because so much of the challenge in adopting cloud-native development lies in overhauling organization, culture and working practices. Such deep-seated change can only be achieved through evolution and experimentation, so the sooner you start down the learning curve the better. Moreover, expertise in cloud-native application development is an essential stepping-stone in developing cloud-native business capabilities that represent a higher level of abstraction and complexity.
When it comes to seizing the potential of cloud-native approaches to boost agility, it is essential to recognize that cloud-native development is not just about new technical tools, but also entails new architectures, culture and ways of working. Agile, DevOps, microservices, serverless and Continuous Integration and Delivery (CI/CD) all drive agility. Unless these changes are brought in alongside cloud-native tools, the potential of cloud-native to deliver agility will be greatly diminished.
Recognize that cloud-native development is not just about new technical tools, but also entails new architectures, culture and ways of working."
Cloud-native applications: Re-engineering business systems & single applications
Since your application landscape will have evolved over time, with numerous dependencies, points of integration and shared data sources, the task of transforming applications for the cloud is inherently complex. For example, a recent Flexera Report found that 63 percent of respondents reported understanding application dependencies as the top cloud migration challenge.
Most businesses will have a few (though not many) ‘Goldilocks’ applications that provide just enough business impact to merit moving but have sufficiently few dependencies that they can be moved in isolation. For instance in banking, assessing credit risk for consumers or small businesses is a discrete process where a single credit decision engine makes a decision (yes/no/we need extra information) that is fed into a broader lending process.
The alternative to moving single applications is to re-engineer business systems. A business system is where applications support a common business function, share data sources and have interwoven dependencies. In banking, examples include risk, regulatory reporting, and lines of business such as mortgage lending. For most large enterprises with complex application and data landscapes, the majority of their historic investment is wrapped up in business systems so they must decide where they want to build new cloud-first applications/cloud-native business capabilities and where they intend to re-factor or re-architect/re-engineer. Both approaches take time and money, which is why the cloud journey of a large enterprise will take five to ten years. The complexity of re-architecting, transforming and moving interlinked systems inevitably entails prolonged timescales and substantial investment. As a result, overly ambitious re-engineering can create a mismatch with stakeholder expectations: cloud is expected to bring speed, but it takes time.
Cloud is expected to bring speed, but it takes time."
Software-as-a-Service & business services
So many SaaS and business services are now available that any cloud programme that does not factor in consumption of business capabilities reflects a mind-set of building things in-house that has not evolved to harness the potential of cloud. Rather than asking whether applications should be lifted and shifted to the cloud or re-engineered to operate cloud-natively, the starting point should be to question whether an application is actually required at all. Why spend money moving or transforming an asset that is not ultimately required? Initiating a cloud journey should be a trigger to review the application estate, identifying opportunities for simplification through converging on common systems and adopting SaaS and business services.
Cloud-native business capabilities
The greatest potential for cloud to alter the trajectory of your enterprise and catapult it into new markets comes from cloud-native business capabilities. This logic will strengthen, as more and more components with ever-richer functionality are made available by the hyperscalers and specialist providers of business services. This means that a strategy for cloud that does not plan to develop some cloud-native business capabilities will have drastically curtailed its potential to create value for customers and alter market position.
The starting point should be to question whether an application is actually required at all."
Enabling workstreams: Making sure you stay on course
Cloud requires fundamental change in organization, process and culture. Architecture is a vital discipline in defining the standards and frameworks that are needed to prevent cloud sprawl. A Cloud Business Office aligns support functions behind the cloud journey to ensure delivery of the business case
In addition to projects that execute on the cloud strategies defined for individual applications and business areas, a number of cross-cutting workstreams are essential to steer the journey and make sure the programme stays on course.
Ironically, though cloud brings greater agility and freedom to experiment, it actually requires more architectural discipline not less. The ability to move fast comes from the stipulation of standards, templates and blueprints. Since cloud entails decomposing applications and infrastructure into numerous components, there is a risk of creating a sprawl that is even more complex than the proverbial legacy ‘hairball’ from which organizations are trying to escape. Initial rapid progress can inadvertently lead to a quagmire created by individual development teams taking decisions based on their immediate needs rather than the broader purposes of the enterprise. Architectural discipline is of particular importance in the early stages of a cloud journey when foundational decisions around security, networking, blueprints and data have to be made, and the enterprise will have to live with their implications or make very expensive modifications. In this sense, organizations should consider their cloud journey as the progressive construction of a single platform that has to be designed and engineered as such.
Organization, culture & process
Becoming a cloud-native business is not just about adopting new technology. It also entails new ways of working and ways of thinking, many of which run directly counter to traditional models. To give just a few examples:
- Empowerment instead of hierarchy: Agile development entails adaptive planning, evolutionary development and early delivery. Unless product owners and development teams are empowered to make decisions, the notional agility of becoming cloud-native will remain out of reach.
- Governance through automation, not approvals: Traditional approval processes revolve around periodic releases, which are geared to minimize risk. Cloud-native techniques (such as continuous integration and microservices) reduce the headache of merging multiple lines of code prior to release, but unless there is continuous delivery of code into production then you will have succeeded only in increasing the value of work in progress. The solution here is automation: automation of testing reduces deployment risk; automated pre-approvals embed controls; and automation of infrastructure provisioning through templates enforces cost, architecture and security controls. Automation of governance (where governance is designed in rather than applied) is very challenging to a traditional mindset that regards governance as a control framework based on human approvals.
- Full-stack teams vs. silos: Integral to the concept of cloud-native development is the idea of combining application development and IT operations to shorten the development lifecycle. The complication is that a multi-disciplinary or full-stack team cuts across the usual split in accountability between applications and infrastructure, and often between change and run. In many instances, these silos are reinforced by separate outsourcing contracts.
Cloud Business Office
Just as full-stack teams are required for IT development and operations, a comparable, more integrated operating model is required across support teams (finance, procurement, security, compliance/legal and architecture). A Cloud Business Office (CBO), in addition to performing the role of a programme office, brings these support functions together to ensure that multiple perspectives are brought to bear on key decisions, especially with regards to cloud economics. This is critical since surveys have found that organizations on average spend 23 percent over their cloud budget. Integrated thinking is of particular importance in cloud economics because decision-making requires apples and oranges to be compared: IT performance, future run costs, reliability of operations, regulatory compliance and sourcing of cloud services. As a result, the CBO is the custodian of the business case for the journey to cloud, safeguarding not only the financial case but also ensuring that sight is never lost of the ultimate business destination.
The CBO is the custodian of the business case for the journey to cloud."
Too many cloud programmes are guilty of being ‘IT for IT’s sake’, failing to meet stakeholder expectations because business goals were not clearly defined or reinforced. The result is expenditure on lots of IT but not much by way of business outcomes; while, arguably, the opportunity cost of failing to keep up with competitors by maximizing the value of cloud represents the most expensive failure.
The business needs to take control of the cloud journey. Defining clear business outcomes for your cloud journey, aligning the organization behind this direction and ensuring that there is always a clear line of sight to cloud objectives is ultimately a job for the C-suite. The stakes, in terms of investment and the potential of cloud, are too high for it to be otherwise. For most CEOs this will be one of the handful of initiatives that will determine whether their time at the helm is seen as a turning point for success or for failure.
The business needs to take control of the cloud journey."