In 1966, Karl Popper published Of Clouds and Clocks, which compared systems that can be metered and measured with those that are indeterminate and, to paraphrase, elastic. These analogies can be easily extended into the world of cloud/utility computing, which is setting the standard for expecting the most from abstraction.
Historically, infrastructure has been a coral reef of siloed systems, created by the hunger of the business to deliver product. The shift to cloud superficially presents a framework solution, but only if terms such as ‘utility’ and ‘cloud’ and the enduring landscape for maintaining their advantages can be clearly defined. The opportunity for the CIO and his team is to understand this shift and to plan strategically to maintain the benefits, especially in larger organisations that can benefit massively from industrialising the innovation.
In theory, IT is strategic for most organisations by enabling a level of competitive differentiation. In practice, it is hard to allow this differentiation due to lower IT budgets and higher operational costs; processes and systems are fragmented, lack pattern, and are labour-intensive. To the business, IT is just the face at the window, with as much personality as a paper cup.
Cloud and utility computing are hyped as the saviours of infrastructure sprawl. Even so, seasoned architects have to scratch their heads and wonder which impossible thing to believe before breakfast. It can be harder for the CIO to make practical business sense out of the hype in the midst of blog-driven noise about what ‘cloud’ and ‘utility’ concepts actually are.
Defining the concepts
Utility computing is an approach to running a business that maximises cost control, quality of service and adaptability to change – the ‘Big Three’.
Services are standardised and delivered over a network, consumption is metered (clocked) at unit cost (price per transaction), and consumers are billed for usage and availability. Common examples in the datacentre are managed file transfer and identity management services and, on a broader scale, enterprise application platforms based on – more technically – server and broker farms.
Cloud computing is the architecture that supports the utility approach. Cloud will architect resilience, scalability and security, for example. Crucially, this shift allows the CIO to separate his concerns as metering and self-service are delivered to the business while IT delivers- an implementation through a cloud architecture. The opportunity for the CIO is to export architecture as a commercial behaviour.
In some organisations, business units have a tendency to pulverise attempts to consolidate platforms because they won’t share the pain of service development and it’s hard to test a business case that requires up-front investment in infrastructure. Interestingly, standards consortium the Open Group has a project entitled Cloud Business Artifacts, which aims to moderate cloud technical solutions for business requirements by asking questions like: ‘What is the business pain?’ and ‘How can cloud help?’. Business requirements are grouped into pain points, and aligned with cloud computing technical solution requirements.
An example is the business requirement for timeliness and agility where a lack of IT flexibility results in siloed bundles, high investment and loss of competitiveness.
In brief, cloud can help by freeing the business from infrastructure costing and sizing through implementing portability and elasticity. The CIO can exploit initiatives like this as long as the utility metering model surfaces as a key requirement and cloud service providers can align their solution to it. For insourcing IT departments who want to exploit this model, cloud service providers are internal; a challenge in itself when ‘your mess for less’ – the outsourcing carrot – no longer applies.
There are three big ‘steel threads’ that hold the maturity bridge between dedicated silos and utility-based services:
Cost control – from low asset utilisation and high TCO to fully optimised IT with automated charge back;
Adaptability to change – from dedicated- systems to virtualised platforms;
Quality of service – from silo control to self-service portals.
There are a number of enduring activities that wrap around the steel threads, which have proven useful as part of strategic planning for utilities at each nudge between centralisation and utility services. These are summarised below.
Prioritise lifecycle activities
The CIO should harden the engineering lifecycle in order to inform priorities. Visibility of asset utilisation and cost is key to understanding what you have and who is using it. Consequently, you may be able to prioritise based on cost, time and quality by removing complexity for high-value stakeholders. Standardised templates, rules, catalogues, patterns and practices are important engineering activities, but all sights should be trained on the cost challenges. Think laterally about what may seem obvious. Automation, for example – not just automated builds and environments but also tools to introspect and automate migrations from one software version to another. Like a Richard Rogers architectural outline of the future of Paris, you can identify hotspots across architecture domains without elaborating unnecessary detail.
Exploit utility roadmaps
A utility roadmap binds utility services – portal, security, file transfer services – to key projects in the pipeline, based on priorities and a refactoring of the funding model. A transformation assessment should be performed to look at which elements of the delivery stack – hardware, OS, middleware, networks – can be consolidated and presented back as a service offering with a view to commoditising the interface between service and platform.
Using a vendor consultancy can help, and the least you should expect from them is a list of candidate utilities mapped to the project pipeline. This becomes a strategy map that is important in delivering against the expectation of pay-per-use.
The techniques of ‘Technology Governance’ and ‘Solution Governance’ need to be hardened and infect established governance processes with the singular view of aligning business objectives with utility strategy. This is harder than it sounds, and is a full line-of-sight activity which the CIO leadership needs to manage. Experience shows that the business will simply snatch at what it believes it can achieve regardless of what IT is planning, so the CIO needs to enforce ‘separation of concerns’ – getting engineering out of the way and marketing the business service view.
Funding and marketing
How can utilities be developed when the business can’t wait and shared ownership of the cost of developing services is merely a fantasy to the business? Some organisations work utility development into their annual -remediation plans so money is allocated to upgrade software versions and, providing a roadmap is in place, -remediation takes the form of implementing foundation utilities. For example, upgrading a product can become an upgrade to a product farm. The trick for the IT leader is to exploit this up the stack: consolidating web servers and a portal delivery platform gives you a chance to promote an e-commerce framework -solution blended with metering.
When promoting utility services, the CIO should aim to get out of the way of the business units looking to allocate IT resources for projects and allow businesses to serve themselves. The business units need feedback as to the cost of those resources; one option is to use a ‘Reporting and Cost Recuperation’ model. In the short-term, offer services as a pilot and learn. Once both self-service and metering appear and are used consistently throughout IT, the datacentre starts looking like a utility. The aim is to have the business demand pay-per-use, so the marketing requires careful moderation of expectation via the utility roadmap. A good technique to use is to -establish the role of ‘Utility Champion’ within the business units, to advise and consult on the best way to maximise return on utility investment, forming part of the overall solutions governance activity. The trick for the CIO here is to allow the business to exploit the Itil concept of utility and warranty while leaving IT to commoditise the supporting platform.
By separating the concerns of the utility metering model from the cloud architecture, the CIO can focus on the Big Three advantages of utility computing, moderate cloud solutions and manage a ‘factory’ model that supports these advantages.
About the author:
Graham Harrison is a principal architect at Steria and was previously head of enterprise engineering for Global Retail Banking at Barclays. He can be contacted at [email protected]