The Irresistible Force Meets the Immovable Object

July 24, 2011

The traditional IT business model has been with us for many decades, creating a vast estate of software, networks, servers and data centres built at great effort and expense by an established food chain of software vendors, systems integrators, consultants and outsourcing businesses.  This is the immovable object: the legacy estate of networks, systems and data managed by organisations with a common interest in maintaining the status quo.  Both customers and suppliers are likely to have an interest in continuing to operate and maintain this immovable object in order to recoup their investment in data centres, tools and capabilities; some customer CIOs may also fear the loss of jobs, budgets and power if their organisations seek to dismantle it.  And now the immovable object is threatened by the irresistible force of the Cloud.[1] 

Historic Challenges 

Before we examine the challenge posed by the Cloud to the traditional IT business model, it’s worth reminding ourselves of some of the historic challenges that still confront customers and their suppliers when undertaking IT projects today (typically, the design, build and operation of IT systems by a supplier of consulting, systems integration and outsourcing services).[2]  In 1997, the authors read Crash[3], a book by Tony Collins, a well-known journalist at Computer Weekly.  Tony Collins describes the ten ‘deadly sins’ that need to be overcome to avoid IT projects becoming a computer disaster.  In order, these sins are over-ambition, pride, presumption, pusillanimity, credulity, consultancy, tailored software, concealment, buck-passing …. and lawyers.

Most of these sins speak for themselves.  In some sense they can probably be attributed to any human endeavour which did not perform as hoped.  But in our world, where IT projects and the law intersect, many of these sins still resonate. We had a cogent reminder in the High Court’s decision in BSkyB v EDS.

Fourteen years after the publication of Crash, its guidance is still relevant.  Some of the sins, such as pusillanimity (ie the tendency of the business buyer of an IT system to be cowed into reliance on the expertise of the service provider to the extent of abdicating project responsibility to the supplier) may not be obviously present in most IT projects.  It is undoubtedly the case that business buyers are infinitely more tech literate now than in 1997. But some variant of pusillanimity may still apply – and indeed the roles may be reversed.  Now it is the supplier who may need to summon up the courage to remind the customer that a project can only succeed if the customer articulates its requirements, adapts its business processes, extracts and cleanses data, writes test scripts and creates test data, trains its users and conducts acceptance testing.  And woe betide the IT supplier who blithely continues to work on a project, purportedly under the project management of the customer, in reliance on time and materials billing, when it is known that the project has gone over budget.  Come the moment of dispute, a court may well allocate blame to the expert IT supplier for not intervening earlier, notwithstanding the basis of the contract.  So the aphorism that customers and suppliers work best in a constant state of ‘noble tension’ may not only be true for the customer, but also for the supplier.

The usual IT project deal review conducted by suppliers follows a familiar ritual: questions are asked about the specification, acceptance, estimation, scalability, service levels, dependencies, etc.  These are all necessary ingredients for successful project delivery.  And they take cognisance of the sins mentioned above.

This approach to risk management has become standard practice across the IT industry.  Nonetheless, based on industry data, only an estimated one-third of IT projects are regarded as successfully completed (not in itself reflective of relative degrees of contractual fault).  Clearly, customers and suppliers need to learn the lessons of history to avoid repeating the same old mistakes.

The Cloud Challenge

But now the IT industry faces an even more serious challenge, and one that affects all suppliers involved in designing, building, integrating, hosting and servicing the IT estate which makes up the immovable object.  The suppliers’ traditional business model is founded on the principle of a one-to-one relationship between customer and supplier, offering a personalised service in return for a respectable profit margin and limited investment risk (note that this model does not preclude elements of the service being delivered in a manner that is commoditised, such as desktop support, help desk and data centre services).  How sustainable is this model in a world where customers can buy commodity services from the Cloud?   

In 1997, the year in which the authors read Crash, Larry Page and Sergey Brin, founders of Google, were still studying for their PhDs at Stanford University.  Software as a Service and the Cloud would hardly have been puffs on the horizon.  Amazon was a small online book store and would not have been seen as a competitor in enterprise IT.  Nevertheless, it is fair to say that the traditional IT industry has not fundamentally altered its go-to-market strategy and service delivery model since 1997 even though we have now moved to a data-centric, web-enabled world.  We have come to understand that the Cloud is more than a way to switch capital expenditure decisions to operational expenditure transactions.  The Cloud today is a platform for ‘always on’ services and devices.  There is little of value in a network or in a data centre without web services.  As Howard Smith, CSC EMEA CTO puts it: ‘a new services supply chain, not the old product supply chain, is emerging’.  As a result, companies of all sizes, from Fortune 500 to the local corner shop can buy IT services as a commodity.  

Yet the majority of work performed by suppliers today is paid for by individual customers with their own specific requirements, which are met by suppliers using many standard methods, components and tools to build and operate a system or service.  The customers’ requirements and contracts will often compel suppliers to personalise their offering, with payment linked to their success in achieving this.  Although these relationships may create the need for upfront investment by the supplier (usually a transformation project involving the replacement or consolidation of existing infrastructure, necessitating initial capital expenditure and labour costs), the supplier will recoup that investment over time, typically the term of the contract, from the individual customer.     

Compare this model with salesforce.com, whose business model is based on providing 97,000 customers with CRM tools accessed over the web on the basis of pay-as-you-go.  Was this how Salesforce.com was built?  Not at all, says Howard Smith.  As he puts it: ‘The founders of Salesforce did not speak to customers at all!  They studied a market, found an unmet need, and then designed and built a rough-and-ready generic service to test their ideas.  Salesforce then refined that service through a myriad updates over a decade and a half.  They have been successful in dominating their chosen service category.  It’s a product design discipline, applied to the world of service innovation.  Salesforce generalised, not personalised, their offering so that it appeals universally.’  

The traditional IT suppliers have grown up with a different business model.  The requirements come from the customer and are published to potential suppliers at the start of the procurement, using an ITT or RFP.  The potential suppliers respond to the requirements in a procurement process that is invariably complex, time-consuming and costly, leading to the successful supplier signing a ‘bespoke’ contract[4] with the customer.  From the customer’s perspective, the objective is to transfer to the supplier as much of the technical, commercial and financial risk as possible.  Only suppliers with significant scale, capability and financial strength are able to bid for these contracts and deliver them.  Unsurprisingly, the contracts often need a team of lawyers and commercial managers to manage them.   

With Cloud services, where the same service is being supplied to multiple customers, the provider is responsible for specifying the generic requirements.  Again, to quote Howard Smith: ‘There is no RFP.  Afterwards, to scale up, the provider must observe the utilisation of the service as experienced by the end user – aggregating all customer insights into a holistic evolution of the design.  The service must then be adjusted continuously to meet the latent, not stated, needs of the customers.  At the same time the provider must track all competitors entering the field and innovate “frequently and often” to maintain a leadership position.’

With the Cloud, contracts are standardised, not bespoke.  There is no negotiation: customers either accept the terms (often on the basis of clicking a button on screen) or don’t proceed.  The standard Cloud contracts published on the web exclude the provider’s liability for almost every conceivable risk.  It’s a case of ‘take it or leave it’.  How different to the world that many of us are used to.

Since the traditional supplier cannot compete with a commodity provider at scale and still generate a decent profit margin, the role of the former must inevitably change: some will make the leap from being a supplier of personalised services to customers with thousands or tens of thousands of users, to a supplier of generalised services that can be scaled to millions, tens or hundreds of millions of users.  They will be able to build on the Cloud as in the past they built on fixed infrastructure and operations, having decided in which category of ‘Continuous Service’ they are able to compete.  This shift towards Cloud services will require design, contracting and delivery models alien to many suppliers.  Even more important, the culture needed to sell and deliver personalised services successfully is very different to the one needed for generalised services (which as we noted, involves more of a product design discipline).  Yesterday’s world is contract centric, technology driven and one of reactive RFPs; tomorrow’s world is client centric and one of proactive value propositions, industry solutions and service on demand.

Historically, businesses selling IT products and services have been like chalk and cheese, and those which have sought to change their business model have met with mixed success.  Different investment, pricing and contracting models need to be deployed for generic offerings.   Under the traditional business model, the supplier recovers its costs and overhead from the customer (even if the supplier makes the upfront investment, eg towards transformation projects).  But in this data-centric, web-based world we are confronted by the reality of suppliers building their infrastructure in the expectation of future contracts, not funded by existing customers.

Challenges for All – Suppliers, Customers and Lawyers

If the Cloud presents many challenges for suppliers, then so too for their customers.  CIO’s still like the idea of controlling their own systems and data, even if those systems have been outsourced.  Potentially, private clouds provide the answer, where large organisations or communities of interest such as healthcare, police forces and local authorities share secure infrastructure managed and operated by a supplier.  However, the obstacles are as much cultural as technological, as these new arrangements will work only if organisations are prepared to work towards a common goal.

So back to the place of projects in this new world.  Projects are pivotal for the traditional IT business model. IT is delivered by way of projects, and projects entail extensive and often contentious customer-supplier inter-action throughout the contracting lifecycle. This is different for Cloud services, being a one-to-many model. It is not yet clear where projects will fit into the next waves of services built around Cloud infrastructure.  They may at best be building blocks, but not the pivot point, for how technology is procured or provided; projects may evolve into journeys, involving multiple suppliers providing best-of-breed solutions but not joined under a traditional prime-subcontractor model.  In some form the need for the disciplines that make the difference between a successful and unsuccessful project will survive.  Moreover, what is clear is that behind the simplicity of the Cloud service model lies hidden complexity.  Surely the deeply-embedded project expertise of traditional suppliers will be of great value in helping to dissect this complexity and provide solutions.

Just as the confrontation between Cloud and the traditional IT business model has implications for the role of projects, it has implications for the role of IT lawyers too. Most IT lawyers have developed core capabilities in advising, negotiating, contracting and dealing with disputes relating to projects, as lawyers play a central role in the delivery of IT via projects. The potentially subsidiary place of projects for next generation IT therefore raises questions about how the legal community will respond to this shift.

This shift will involve pervasive complexity.  Like our business colleagues, we lawyers need to anticipate the inhibitors and facilitators that will affect Cloud services.  Government regulation relating to standards, interoperability, net neutrality and personal data are all examples where lawyers can help to create a competitive differentiator.  As noted previously, the delivery and commercial models will be different, and lawyers can play an important role in shaping them.  

It is against the backdrop of the rapidly evolving and unstoppable force of the Cloud that we must now exert our minds, our innovation and our creativity.  Our ‘imagineering’ muscles will no doubt be tested to the full, and our commercial models the same.

___________________________________________________________________________________________________

 

Gawie Nienaber is Vice President and Associate General Counsel (International) at CSC, a global IT service business. 

John Yates runs consulting business v-lex, specialising in complex technology and outsourcing contracts.  He is a Fellow and past Chair of SCL.  John started his career with IBM.



[1] Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (eg networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction (US National Institute of Standards and Technology). 

[2] The traditional IT business model is characterised by suppliers offering a range of services capable of meeting the tailored needs of their customers: projects & consulting, systems integration, and outsourcing (IT and business processes).  These services are sold by a sophisticated sales force and delivered using methodologies for managing complex projects and services.  IBM, CSC, Capgemini, Fujitsu, Atos Origin, Accenture, Hewlett Packard and others operate in this market place.  We use the terms ‘traditional IT business model’ and ‘supplier’ as shorthand to describe them.  

[3]  Crash, Tony Collins.  Published by Simon & Schuster Ltd (1 July 1996).  ISBN-10: 0671511793; ISBN-13: 978-0671511791.  

[4] Many readers will be familiar with the manner in which the public sector procures IT services.  UK Central Government uses the OGC model ICT services agreement.  However, the terms and conditions are often tailored by the departments’ advisers, and schedules for requirements, security, service levels & performance management and testing are frequently created from scratch or recycled from other projects.