Archive | Strategy RSS feed for this section

Evolution and the IT Industry – Part I

25 Oct

(I’m cross-posting this from the Fujitsu RunMyProcess blog where I am now a regular contributor).

A few years ago I wrote a (rather long) post about evolution in the context of business and in particular the use of emerging business architecture techniques to increase the chances of successfully navigating its influence.

Prompted by two recent posts on this blog, however – ‘Software Darwinism’ by Malcolm Haslam and ‘The Death and Rebirth of Outsourcing’ by Massimo Cappato – I thought I would simplify my original piece to create a much shorter and more IT-centric two part set of observations on this theme.  I basically wanted to pick up on the concept of evolution raised by Malcolm and use this as a vehicle to explore the potential impact on businesses and IT of the disruption described by Massimo; how have we arrived at the landscape of today and what can we learn from evolutionary processes about the likely impact of the disruption on the businesses paying large amounts of money for ‘artificially alive’ systems.

In part 1 I will introduce some ideas about evolution and discuss the current state of businesses in this context.  In part 2 I will continue the theme to discuss the way in which current disruptions represent a ‘punctuated equilibrium’ that demands rapid business evolution – or creates a high likelihood of extinction.

Evolution as an Algorithm

A fascinating book I once read about ‘complexity economics’ described evolution as an algorithm for exploring very large design spaces.  In this interpretation the ‘evolutionary algorithm’  allows the evaluation of a potentially infinite number of random designs against the selection criteria of a given environment. Those characteristics that are judged as ‘fit’ are amplified – through propagation and combination – while those which are not die out.

In the natural world evolution throws up organisms that have many component traits and success is judged – often brutally – by how well the combination of traits enables an animal to survive in the environment in which it exists.  For instance individuals of a particular colour or camouflage may survive due to their relative invisibility while others are eaten. Furthermore this is an ongoing process – individuals  with desirable traits will be better equipped to survive and the mating of such individuals will combine – and hence amplify – their desirable traits within their offspring.  Over time the propagation and combination of the most effective traits will increase in the population overall and where this happens quickly enough a species will evolve successfully for the environment..

Punctuated Equilibrium

Another interesting aspect of evolutionary systems is that they often exhibit long periods of relative stability until some set of external changes creates a ‘punctuated equilibrium’; that is a change to the environment which brings new selection criteria to the fore.  Such changes can have a devastating effect on species which have evolved successfully within the previous environment and lead to new periods of dominance or success for new or previously less successful species whose traits make them better adapted to the new selection criteria that result from the change.  Such species then continue to evolve towards mastery of their environment while others which are too specialised to adapt simply die out.

A particularly dramatic example of this process was the extinction of the dinosaurs, where a change in the environment lowered temperatures and destroyed the lush foliage they depended upon.  This led them from masters of the world to extinction in a relatively short period – the combination of traits that previously made them highly successful was no longer well aligned to the selection criteria of the new environment.

Markets as Evolutionary Systems

It has been argued that the complexity of markets (in terms of their scale, their breadth of participation and the differing intents of the participants) means that they can effectively be viewed as evolutionary systems.  Markets are essentially an environment in which we participate rather than something that can be clearly understood or designed in advance.  They are effectively a very large design space where the characteristics for success are often not known in advance and must be discovered through experimentation and adaptation.

When we look at businesses in an evolutionary context we can therefore hypothesize that those which converge over time  towards successful combinations of traits – as judged by their stakeholders through a process of interaction and adaptation – will be the ones best adapted  to market needs and thus chosen by consumers.  These traits – whether they are talent strategies, process strategies or technology strategies – are then copied by other businesses, replicating and amplifying successful traits within the economic system.

The Influence of IT

If we focus specifically on IT,  we can see that even today IT systems have a large influence on the quality of the business capabilities that underpin a company’s offerings.  Every business is competing for selection against competitors with other applications – and software is increasingly moving to the core as business becomes ‘digital’; as a result it is clear that IT is a major (and increasing) factor in deciding the ‘fitness’ of any particular business versus another.  In this context we can see that the degree to which IT helps or hinders a business makes a huge difference to the quality of its ‘traits’ – both individually and in aggregation.  IT can therefore be a significant influence on whether a business’s offerings are ‘fit’ when judged by the evolutionary algorithm of the market.

Competition in an Age of Universally Bad IT

Despite the illusion of change over the last 30 years, at the macro level things have actually been relatively static from  a technology perspective.  While we have moved from mainframes to client-server and from client-server to the Web the fundamental roles of business and IT have remained unchanged (i.e. firms exist to minimise the transaction costs of doing business by building scale and such businesses spend a lot of money on owning and operating IT in pursuit of efficiencies and consistency across their large scale operations).  In reality most IT investment has therefore been inward facing and viewed as a cost of doing business (a ‘tax’ as Massimo would describe it) rather than a platform for the delivery of innovation and differentiation from an external perspective.

Under this model we have seen large businesses use their scale to pay for IT products and services that are inaccessible to smaller organisations.  Over time -because the focus has often been on efficiencies and standardisation – many IT estates have tended to converge around similar packaged applications and technology.  This convergence has all but wiped out the flexibility required for business differentiation while simultaneously placing organisations functionally and temporally in lockstep (as a concrete example it is no surprise that all companies are facing huge challenges as a result of mobility or that their challenges are more or less the same).  Together these developments have led to a broadly static business environment in which a smaller number of large companies dominate each market segment, providing mediocre levels of innovation and service while dictating both the shape of industries and the kinds of offerings consumers can expect  from each.

As a result while IT has enabled large scale efficiencies, it has led to the situation outlined by Massimo – a situation in which businesses have huge investment responsibilities, a crushing burden from bloated support and delivery organisations and a limited ability to evolve quickly (if at all).  The irony is that it has done this equally to all organisations who could afford it, however,while simultaneously acting as a competitive barrier by limiting the economies of scale that can be achieved by organisations who could not.  As a result the costs, complexity, inflexibility and balkanisation around industry boundaries – along with a lack of innovation and customer-centricity – have become part of the settled fabric of business.

While this has not been a significant issue for large organisations during an extended period of relative stability, it does however threaten to create significant challenges as a result of any disruption to the status quo.  It is perhaps interesting to think of today’s businesses as the dinosaurs of the modern age – large and perfectly adapted to the warm and plant rich environment in which they exist unchallenged.

A Punctuated Equilibrium for Business?

Over the last few years, however, we have seen the genesis of a major disruption – a disruption that is going to change the evaluation criteria of the market and require the development of wholly different traits to succeed.  As cloud delivery models, large scale mobility and the mass sharing of content in social graphs converge I believe that they herald a ‘punctuated equilibrium’ whose effects on business will be profound.  These are not just technology changes but rather a change to the fundamental environment in which we all work, play and socialise – and a signal that business models and even industry boundaries are up for radical change.

The possibilities that these advances create in tandem are akin to an emerging ice age for large businesses and their technology providers – an age in which businesses must fight for every customer and must mutate their organisations, business models and technology to attain a new definition of ‘fitness’.  The easy days of domination through mass and an abundance of low hanging cash to be grazed are passing.

In part 2 of this post I will therefore talk more about the nature of this punctuated equilibrium and my personal views on the shifts in business and technology models that will be required to survive it.

Why, What, How (or NIST, WTF)

9 Jan

It’s that time of year again where I realise that I need to resolve to start blogging again.  Luckily this year my inspiration was provided on new years day by a conversation on twitter sparked by Randy Bias over whether NIST is a fail or not (contained in his excellent cloud retrospective post).

I completely agreed with Simon Wardley’s view that as a mechanistic description NIST wholly fails to address the fundamental reasons cloud is important, summarised by these two tweets from the discussion:

The definition helped to try and identify what is cloud but did nothing to explain why. It was pure mechanistic drivel…”

“… and that’s the real problem. If you think you understand cloud from reading NIST, you’re going to make horrendous mistakes.”

Falling transaction costs, the melting of enterprise boundaries, the shift to service business models and accelerating commoditisation – as examples of the ‘why’ of cloud – are not covered at all and therefore it would be all too easy to take these mechanistic descriptions and implement something that looks like them but which has not been created to address such wider business imperatives.

Without understanding why you need to address the impacts of cloud it is all too easy to re-name your existing stuff or build something that appears the right shape without actually creating something that meets the extraordinary business challenges that cloud is unfolding.  Such efforts invariably become about polishing existing enterprise IT models and not about a re-evaluation of your enterprise business models backed up by new technology architectures to leverage the fundamental disruption in the way business capabilities are supplied and consumed.  This is also my fundamental issue with many private cloud implementations – most have nothing whatsoever to do with ‘cloud’ as a disruption but are merely mechanistic implementations driven by people who don’t understand the why.

Simon (and indeed Randy in his original post) are completely correct to point out that definitions that purport to ‘define’ cloud without providing the context to enable you to understand the ‘why’ (and therefore the potential impacts and necessary business strategy required to respond) are in my view not just a fail but fundamentally dangerous.  For me this danger exists at both the micro and macro levels – at the micro level single organisations will implement stupid solutions due to misplaced confidence and a  lack of understanding of the forces they are facing, while at the macro level vast numbers of organisations will waste 1000s of years of effort and billions in investment building the wrong things or generating hot air discussing pointless virtualisation and infrastructure topics (often considered de facto as “cloud” due to the lack of a sufficiently multifaceted understanding of what cloud actually represents.)

All of this comes back to the need to think about why, what and how and the interplay between them.  Simplistically we can consider that why shapes what you need to deliver and what shapes the scope of your how.  From my experiences in business architecture I can say that most organisations seem mired in the endless management of hows and have lost sight of both what and why – from that perspective being given a set of abstract whats to fulfil by an organisation like NIST would appear to be a good start as it at least allows people to realign their hows to fit the definition and declare “cloud” success.

This is the overwhelming danger, however, and the reason I would agree that the NIST cloud definition is a fail.  In reality “successes” declared as a result of simply aligning to the NIST definitions will be massive failures of strategy without either an independently developed, deep understanding of the broader disruption or a startling case of serendipity.

The reality of cloud is the accelerating disruption of every industry as commoditisation and a shift to service models plays out; simply rebadging your existing IT or meeting your existing challenges with investment in ‘better’ technology will simply not cut it.

This is why NIST is fundamentally a fail from my perspective – not because of the definitions per se but because they present a structure to act without understanding.  Structuring your cloud efforts around a mechanical definition without fundamentally understanding the wider disruption that makes your existing models obsolete will just consume a lot of expense to deliver outcomes with wholly the wrong profiles – leading me to genuinely question whether some organisations who do this could founder.

I guess in some respects people may feel it is unfair to brand the NIST definitions a fail for these reasons and point to the failure of consuming organisations to properly understand the context in which they should be applied – there may be some truth to this rebuke but organisations are often ‘stupid’ (or at least blind to change) as they were designed for a different purpose.  From this perspective providing a definition that can seemingly be satisfied with a polished status quo  – especially given entrenched interests within the IT department and some suppliers – without forcing people to confront the dire consequences could be considered irresponsible.  Given the state of the art, the position of NIST, the ambivalence of many incumbent technology suppliers and the maturity of adopting enterprises, taking such a position seems to me a little like blaming blast damage on a toddler who is given a gun rather than the adult who hands it over.  With great power does indeed come great responsibility, lol.

So the core lesson for me is that people need models and taxonomies that place the elements of cloud into some kind of framework for describing both why and what in order to enable understanding, reasoned separation of business models and discussions about innovation in the how.  It has saddened me over the last few years how few people – like Randy, Simon and Krishnan in their twitter conversation and wider writings – are truly wrestling with the difficult why of cloud vs the slightly larger number of worthies thinking out of context about the what of cloud vs the vast number of rudderless and noisy idiots who have flooded the web with the half-arsed, contextless how of cloud (which inevitably has something to do with virtualisation, sigh).

UPDATE: After my original post I had an interesting debate with Christofer Hoff who had used the same ‘why, what and how’ structure to argue the complete opposite point in a blog post I missed.  I’d recommend reading his “When A FAIL is A WIN” post as well to see the other side of the argument.

Will CIOs Fail on Cloud?

4 Jul

I’ve been reading a lot of content lately that covers three topics:

  1. What’s the future of enterprise architecture;
  2. How we govern businesses who are increasingly bypassing IT and going directly to the cloud; and
  3. Public vs Private clouds and the IT department’s role in creating FUD.

I think that these issues are deeply related and sadly speak of a lack of leadership and business-centricity in many IT departments.  All three areas give CIOs the opportunity to embrace their businesses and move to the heart of strategic thinking but in each case they have not (and are not) grasping these opportunities.  All share two important dimensions – answering fundamental questions about the way in which a business should be shaped and – as an element of that – how IT is supplied.  In both cases many CIOs seem unable to recognise which one is truly important.  Whilst I want to write a longer piece on the implications of these changes for the future of IT, in this post I just wanted to look at the question of whether CIOs will succeed or fail in finding a future within our organisations.

Enterprise Architecture as IT Architecture

Enterprise Architecture was supposed to give us a view of how the business worked.  Executed correctly it was meant to give us the context required to understand the strategic options available to our business and then understand the potential impact of each across various dimensions.  Most EA efforts originated – not unreasonably – within the IT department, however, because as a horizontal function used to thinking systematically they understood the potential first.  Unfortunately many IT departments have failed to address the business context purpose of EA and have become wholly inwardly focused.  Such groups use technology standards and governance as a proxy for really understanding and shaping the business and its supporting systems, leading them to simplified views of their purpose based on technology ‘standardisation’. Many of the technology standards they adopt are often inappropriate for large areas of the business, however, where business capabilities have business models different to those that drove the adoption of the ‘standard’ solution.  The limited scope of their ambition and understanding, however, leads them to push such technologies forward in any case as the ‘strategic solution’ to every problem that looks similar.  In drifting into this role most EA efforts have unfortunately therefore become a problem rather than an enabler; they have become detached from business realities, focused on internal IT issues and taken on the operation of governance processes that mostly result in delays, cost over runs and inappropriate solutions.  Most tragically in doing this they have spurned a tremendous opportunity to investigate and codify the structure and purpose of the enterprise and thereby find a place at the heart of the strategic processes of the business.

As a result of missing this opportunity many CIOs have become confirmed in the role of an operational supplier.  Worse still they are increasingly being seen as a costly and obstructive operational supplier and are therefore constantly under pressure to increase efficiency and reduce cost.  This forces them into a reactive, inward looking position, always looking to cut costs, standardise or begging for investment resources but whose services are still always considered to be decoupled from business value as well as slow, expensive and cumbersome.  Whilst in many ways being in the best position to see opportunities – because of the horizontal role of both themselves and their EA team – they singly fail to take advantage of it because they’re trapped in the wrong conversations by their operational responsibilities.

Enter the Cloud to Cheers from CIOs…. or not.

Despite the failure of IT departments to use the opportunities of EA to help the business gain strategic insights, CIOs have now been offered a golden opportunity to once again take the lead in their organisations.  Cloud computing offers CIOs the opportunity to remove themselves from the operational treadmill and place themselves firmly in the centre of strategic conversations about the future shape of their business.

Cloud is not a technology trend but rather a disruptive change in the way we communicate and consume services.  It will completely reshape organisations and the industries they operate in.  That may sound like hyperbole to some but I genuinely believe it.  History has shown that falling transaction costs make it more cost effective to consume services from partners than to operate them yourself and the pressures of the market will also ensure that these services are much better than those you could build yourself with limited scope.  Furthermore cloud services represent concrete business outcomes that can be aggregated into overall value-webs, moving conversations out of the realm of the bespoke, abstract and technical and into the realm of direct, consumable value outcomes.  Over the coming years every aspect of a business’s operations will be examined, categorised and in many cases outsourced to specialised third parties.  Cloud is the driving force behind these changes by making it inexpensive to connect to other people whilst simultaneously reducing their cost of entry to the market and allowing them to scale at low cost as their business grows.  I repeat – cloud may be viewed as an IT phenomenon currently but the fall out will disrupt every single industry as new specialised companies come rapidly to market with cost and agility profiles that cannot be matched by incumbents.

Many businesses don’t get this yet, however, and while they see the attractiveness of services like Salesforce (indeed are often purchasing them in spite of the CIO) they haven’t yet understood the profound consequences for their organisations in the years ahead.  For CIOs you would think that this is a huge opportunity to take the lead and help their businesses firstly understand and then transform to meet the demands of the new order; essentially someone needs to codify the concrete outcomes required by the organisation (business architecture), source and integrate them together (development and integration) and manage the integrity of the overall value web (business service management).  There is nobody better placed to grasp this opportunity than the CIO, who has an opportunity to lead their companies through a fundamental shift in the purpose and structure of not just IT but also of businesses and their operations.

But. But. But.

The issue is that many CIOs aren’t thinking like this at all.  Many CIOs seem to have come to believe that their job really is operational and therefore see cloud as a threat.  Many CIOs listen to their technologists who fear a loss of control over the way IT is designed and run even though they can’t explicitly relate it to business value.

Enter “private cloud”.  So now the CIO can have their cake and eat it.  They can tell the business that yes cloud is important and – darn it – they’re on top of the whole thing.  But its a big commitment, requires the recruitment of the absolute best technologists in the global industry, will take years to roll out (if it ever gets finished with limited budgets and everything else going on) and will never deliver the instant on, pay as you go model given the retention of a bunch of expensive capital assets and people that can’t be shared.  More importantly it’ll only operate at the – effectively worthless – infrastructure level and won’t provide the business with the opportunity to specialise by consuming world class, multi-tenant services from partners.

It’s Ultimately About Direct Value to the Business, Not Technology

So the business gets fed up with the expense, delay and excuses; they see explicit business value, lower costs, better capability and greater agility on offer externally – and they’re losing ground rapidly against their competitors – and so they go around the CIO and purchase their services directly from cloud suppliers.  Again the CIO has lost the opportunity to lead and has merely been cornered by business and economic reality.  The plain facts are that you can no longer work in isolation from demonstrable business value or put your finger in the cloud dyke to protect your own little private cloud bubble – economically it just won’t work out.  You have to face the fact that you’re not good enough, focused enough or well funded enough to build and operate a large scale cloud platform and that your real value is as a trusted advisor and integrator of services aligned to the business of your organisation.  Worst of all, the CIOs who are currently focused on technology in place of business architecture and sourcing will bring to fruition their own worst fears about losing control and influence – as the business increasingly flows around them they will end up as the dumb guy who missed the – by now obvious – signs about the way in which the cloud was going to affect the business and who showed no leadership.  Most importantly for this discussion the CIO will also be “the guy who runs all that expensive stuff nobody really wants any more with those weird people who talk about the way they used to control things in the old days.  Let’s just keep him out of the way while an external company comes in and helps us to transform our business.” (ironically perhaps the very same consultants and systems integrators who led him down the private cloud route in the first place – and who have been forced to accept their place as advisors and integrators of specialised services from the global market rather than providers and operators of uncompetitive, per-customer technology).

It’s a Combination of Enterprise Architecture and The Cloud That Will Save Those Who Deserve it

Looking at this track record it’s unfortunate that the CIO’s route to salvation requires him to fully embrace enterprise architecture and the cloud.

Essentially every enterprise consists of a number of business capabilities with divergent business models and the first role of the CIO should be to help to visualise these discrete capabilities in order to support higher level thinking about the purpose of the organisation and the best way of delivering each outcome.  Many peripheral business capabilities exist within an organisation merely to support the execution of more business critical core capabilities – such ‘supporting’ capabilities can be outsourced to cloud providers to enable greater specialisation.  It may be that much of the low hanging fruit during the earliest phases of this transformation will be centred around IT applications and services but over time the CIO can facilitate a change in thinking to open the business to the idea of sourcing any kind of business service from external providers in order to integrate successful services and increase the ‘fitness’ of the overall organisation.  Establishing the right to do this first requires the CIO to take a leadership position in early cloud implementations by helping the business deliver in an integrated and compliant way rather than fighting them, losing and further confirming their position outside the strategic tent.  Such an approach can lead to increasing momentum:

  1. On the back of early wins and increased standing CIOs can use the story of the coming disruption to help their businesses understand the exciting wider opportunities and consolidate their strategic leadership role.  Positioning the IT department as the ‘integrator’ and ‘manager’ of a business service portfolio spanning internal and external services provides a sustainable context for the future role of the CIO;
  2. As part of this role the CIO must take on the documentation of the business architecture and use this as a key strategic asset to provide decision support capabilities to the organisation around business models, specialisation and partnerships;
  3. At the same time the CIO should create a process of ‘certification’ based on appropriate criteria to provide an open marketplace of services for capability owners to use.  Informed curation (based on the industry of the company) along with feedback and requests from capability owners for additional applications and services will be a key part of this process and the result should be a portfolio that is open (i.e. not ‘standardised’ and ‘restricted’) but at the same time ‘approved’ to support governance responsibilities;
  4. In going through this transition CIOs have the opportunity to become ever more embedded in the strategic processes of the business – working on business architecture, rapid capability realisation and losing low level operational concerns as they move to cloud providers; and
  5. Most importantly, all of this can be achieved without spending huge amounts of money on non-differentiating technology or becoming more mired in the operational tar pit.  In contrast merely yielding to the changing role of the IT department leads to a virtuous circle of increasing relevance to business value, lower costs, better service and burgeoning innovation.

The reality is that specialised cloud services are increasingly going to be more competitive than those available within an organisation.  Even more critically, accessing such services allows us to specialise within our own organisations, providing us with the focus required to excel in our chosen areas of expertise.  To unlock the benefits of these synergies, however, enterprises need someone who can help them view their organisation more systematically as a portfolio of business capabilities and facilitate access to external services that can be used to enhance or replace them.  My feeling is that this will either be the CIO – or that the CIO will cease to exist.

The Business Case for Private Cloud

19 Apr
Private Cloud Posts Should Come in Threes

Over the last year I have returned to the subject of ‘private cloud’ on a number of occasions.  Basically I’m trying to share my confusion as I still don’t really ‘get it’.

First of all I discussed some of the common concerns related to cloud that are used to justify a pursuit of ‘private cloud’ models.  In particular I tried to explain why most of these issues distract us from the actual opportunities; for me cloud has always been a driver to rethink the purpose and scope of your business.  In this context I tried to explain why – as a result – public and private clouds are not even vaguely equivalent.

More recently I mused on whether the whole idea of private clouds could lead to the extinction of many businesses who invest heavily in them.  Again, my interest was on whether losing the ability to cede most of your business capabilities to partners due to over-investment in large scale private infrastructures could be harmful.  Perhaps ‘cloud-in-a-box’ needs a government health warning like tobacco.

In this third post I’d like to consider the business case of private cloud to see whether the concept is sufficiently compelling to overcome my other objections.

A Reiteration of My View of Cloud

Before I start I just wanted to reiterate the way I think about the opportunities of cloud as I’m pretty fed up of conversations about infrastructure, virtualisation and ‘hybrid stuff’.  To be honest I think the increase in pointless dialogue at this level has depressed my blog muse and rendered me mute for a while – while I don’t think hypervisors have anything to do with cloud and don’t believe there’s any long term value in so called ‘cloud bursting’ of infrastructure (as an apparently particularly exciting subject in my circle) I’m currently over-run by weight of numbers.

Essentially its easy to disappear down these technology rat holes but for me they all miss the fundamental point.  Cloud isn’t a technology disruption (although it is certainly disrupting the business models of technology companies) but eventually a powerful business disruption.  The cloud enables – and will eventually force – powerful new business models and business architectures.

As a result cloud isn’t about technology or computing per se for me but rather about the way in which technology is changing the economics of working with others.  Cloud is the latest in a line of related technologies that have been driving down the transaction costs of doing business with 3rd parties.  To me cloud represents the integration, commoditisation and consumerisation of these technologies and a fundamental change in the economics of IT and the businesses that depend on it.  I discussed these issues a few years ago using the picture below.

image

Essentially as collaboration costs move closer and closer to zero so the shape of businesses will change to take advantage of better capabilities and lower costs.  Many of the business capabilities that organisations currently execute will be ceded to others given that doing so will significantly raise the quality and focus of their own capabilities.  At the same time the rest will be scaled massively as they take advantage of the ability to exist in a broader ecosystem.  Business model experimentation will become widespread as the costs of start up (and failure) become tiny and tied to the value created.  Cloud is a key part of enabling these wider shifts by providing the business platforms required to specialise without losing scale and to serve many partners without sacrificing service standardisation.  While we are seeing the start of this process through offerings such as infrastructure-as-a-service and software-as-a-service these are just the tip of the iceberg.  As a very prosaic example many businesses are now working hard to think about how they can extend their reach using business APIs; combine this with improving business architecture practices and the inherent multi-tenancy of the cloud and it is not difficult to imagine a future in which businesses first become a set of internal service providers and then go on to take advantage of the disaggregation opportunity.  In future, businesses will become more specialised, more disaggregated and more connected components within complex value webs.  Essentially every discrete step in a value stream could be fulfilled by a different specialised service provider, with no ‘single organisation’ owning a large percentage of the capabilities being coordinated (as they do today).

As a result of all of these forces my first statement is therefore always that ‘private cloud’ does not really exist; sharing some of the point technologies of early stage cloud platform providers (but at lower scale and without the rapid learning opportunities they have) is not the same as aggressively looking to leverage the fall in transaction costs and availability of new delivery models to radically optimise your business.  Owning your own IT is not really a lever in unlocking the value of a business service based ecosystem but rather represents wasteful expense when the economics of IT have shifted decisively from those based on ownership to those based on access.  IT platforms are now independent economy-of-scale based businesses and not something that needs to be built, managed and supported on a business-by-business basis with all of the waste, diversity, delay and cost that this entails.  Whilst I would never condemn those who have the opportunity to improve their existing estates to generate value I would not accept that investing in internal enhancement would ever truly give you the benefits of cloud.  For this reason I have always disliked the term ‘private cloud’.

In the light of this view of the opportunities of cloud, I would posit that business cases for private cloud could be regarded as lacking some sense even before we look at their merit.  Putting aside the business issues for a moment, however, let’s look at the case from the perspective of technology and how likely it is that you will be able to replicate the above benefits by internal implementation.

What Is a “Cloud”?

One of the confusing issues related to cloud is that it is a broad shift in the value proposition of IT and IT enabled services and not a single thing.  It is a complete realignment of the IT industry and by extension the shape of all industries that use it.  I have a deeper model I don’t want to get into here but essentially we could view cloud as a collection of different kinds of independent businesses, each with their own maturity models:

  • Platforms: Along the platform dimension we see increasing complexity and maturity going –> infrastructure-as-a-service, platform-as-a-service, process-platform-as-a-service through to the kind of holistic service delivery platform I blogged about some time ago.  These are all increasingly mature platform value propositions based on technology commoditisation and economies of scale;
  • Services: Along the services dimension we see increasing complexity and maturity going –> ASP (single tenant applications in IaaS), software-as-a-service, business-processes-as-a-service through to complete business capabilities offered as a service.  While different services may have different economic models, from a cloud perspective they share the trait that they are essentially about codifying, capturing and delivering specialised IP as a multi-tenant cloud service; and
  • Consulting: Along the consulting dimension we see increasing complexity and maturity going –> IT integration and management, cloud application integration and management, business process integration and management through to complex business value web integration and management.  These all exist in the same dimension as they are essentially relationship based services rather than asset based ones.

All of these are independent cloud business types that need to be run and optimised differently.  From a private cloud perspective, however, most people only think about the ‘platform’ case (i.e. only about technology) and think no further than the lowest level of maturity (i.e. IaaS) – even though consulting and integration is actually the most likely business type available for IT departments to transition to (something I alluded to here).  In fact its probably an exaggeration to say that people think about IaaS as most people don’t get beyond virtualisation technology.

Looking at services – which is what businesses are actually interested in, surprisingly – this is probably the biggest of the many elephants in the room with respect to private cloud; if the cloud is about being able to specialise and leverage shared business services from others (whether applications, business process definitions or actual business capabilities) then they – by definition – execute somewhere beyond the walls of the existing organisation (i.e. at the service provider).  So how do these fit with private cloud?  Will you restrict your business to only ever running the old and traditional single-tenant applications you already have?  Will you build a private cloud that has a flavour of every single platform used or operated by specialised service providers?  Will you restrict your business to service providers who are “compatible” with your “platform” irrespective of the business suitability of the service?  Or do you expect every service provider to rewrite their services to run on your superior cloud but still charge you the same for a bespoke service as they charge for their public service?  Whichever one you pick it’s probably going to result in some pain and so you might want to think about it.

Again, for the sake of continuing the journey let’s ignore the issue of services – as it’s an aspect of the business ecosystem problem we’ve already decided we need to ignore to make progress – and concentrate where most people stop thinking.  Let’s have a look at cloud platforms.

Your New Cloud Platform

The first thing to realise is that public cloud platforms are large scale, integrated, automated, optimised and social offerings organised by value to wrap up complex hardware, networks, middleware, development tooling, software, security, provisioning, monetisation, reporting, catalogues, operations, staff, geographies etc etc and deliver them as an apparently simple service.  I’ll say it again – cloud is not just some virtualisation software.  I don’t know why but I just don’t seem able to say that enough.  For some reason people just underestimate all this stuff – they only seem to think about the hypervisor and forget the rest of the complexity that actually takes a hypervisor and a thousand other components and turns them into a well-oiled, automated, highly reliable and cross functional service business operated by trained and motivated staff.

Looking at the companies that have really built and operated such platforms on the internet we can see that there are not a large number due to:

  1. The breadth of cross functional expertise required to package and operate a mass of technologies coherently as a cost-effective and integrated service;
  2. The scarcity of talent with the breadth of vision and understanding required to deliver such an holistic offering; and
  3. The prohibitive capital investment involved in doing so.

Equally importantly these issues all become increasingly pressing as the scope of the value delivered progesses up the platform maturity scale beyond infrastructure and up to the kind of platform required for the realisation and support of complete multi-tenant business capabilities we described at the beginning.

Looking at the companies who are building  public cloud platforms it’s unsurprising that they are not enthusiastically embracing the nightmare of scaling down, repackaging, delivering and then offering support for many on-premise installations of their complex platforms across multiple underfunded IT organisations for no appreciable value.  Rather they are choosing to specialise on delivering these platforms as service offerings to fully optimise the economic model for both themselves and (ironically) their customers.

Whereforeart Thou Private Cloud?

Without the productised expertise of organisations who have delivered a cloud platform, however, who will build your ‘private cloud’?  Ask yourself how they have the knowledge to do so if they haven’t actually implemented and operated all of the complex components as a unified service at high scale and low cost?  Without ‘productised platforms’ built from the ground up to operate with the levels of integration, automation and cost-effectiveness required by the public cloud, most ‘private cloud’ initiatives will just be harried, underfunded and incapable IT organisations trying to build bespoke virtualised infrastructures with old, disparate and disconnected products along with traditional consulting, systems integration and managed services support. Despite enthusiastic ‘cloud washing’ by traditional providers in these spaces such individual combinations of traditional products and practices are not cloud, will probably cost a lot of money to build and support and will likely never be finished before the IT department is marginalised by the business for still delivering uncompetitive services.

Trying to blindly build a ‘cloud’ from the ground up with traditional products, the small number of use cases visible internally and a lack of cross functional expertise and talent – probably with some consulting and systems integration thrown in for good measure to help you on your way – could be considered to sound a little like an expensive, open ended and high risk proposition with the potential to result in a white elephant.  And this is before you concede that it won’t be the only thing you’re doing at the time given that you also have a legacy estate to run and enhance.

Furthermore, go into most IT shops and check out how current most of their hardware and software is and how quickly they are innovating their platforms, processes and roles.  Ask yourself how much time, money and commitment a business invests in enabling its _internal IT department_ to pursue thought leadership, standards efforts and open source projects.  Even once the white elephant lands what’s the likelihood that it will keep pace with specialised cloud platform providers who are constantly improving their shared service as part of their value proposition?

For Whom (does) Your Cloud (set its) Tolls?

Once you have your private cloud budget who will you build it for?  As we discussed at the outset your business will be increasingly ceding business capabilities to specialised partners in order to concentrate on their own differentiating capabilities.  This disaggregation will likely occur along economic lines as I discussed in a previous post, as different business capabilities in your organisation will be looking for different things from their IT provision based on their underlying business model.  Some capabilities will need to be highly adaptable, some highly scalable, some highly secure and some highly cost effective.  While the diversity of the public cloud market will enable different business capabilities within an organisation to choose different platforms and services without sacrificing the benefits of scale, any private cloud will necessarily be conflicted by a wide diversity of needs and therefore probably not be optimal for any.  Most importantly every part of the organisation will probably end up paying for the gold-plated infrastructure required by a subset of the business and which is then forced onto everyone as the ‘standard’ for internal efficiency reasons.

You therefore have to ask yourself:

  1. Is it _really_ true that all of your organisation’s business capabilities _really_ need private hosting given their business model and assets?  I suspect not;
  2. How will you support all of the many individual service levels and costs required to match the economics of your business’s divergent capabilities? I suspect you can’t and will deliver a mostly inappropriate ‘one size fits all’ platform geared to the most demanding use cases; and
  3. How will you make your private infrastructure cost-effective once the majority of capabilities have been outsourced to partners?  The answer is that you probably won’t need to worry about it – I suspect you’ll be out of a job by then after driving the business to bypass your expensive IT provision and go directly to the cloud.
Have We Got Sign-off Yet?

So let’s recap:

  1. Private cloud misses the point of the most important disruption related to cloud – that is the opportunity to specialise and participate more fully in valuable new economic ecosystems;
  2. Private cloud ignores the fundamental fact that cloud is a ‘service-oriented’ phenomenon – that is the benefits are gained by consuming things, uh as a service;
  3. Private cloud implementation represents a distraction from that part of the new IT value chain where IT departments have the most value to add – that is as business-savvy consultants, integrators and managers of services on behalf of their business.

To be fair, however, I will take all of that value destruction off the table given that most people don’t seem to have got there yet.

So let’s recap again just on the platform bit.  It’s certainly the case that internal initiatives targeted at building a ‘private cloud’ are embarking on a hugely complex and multi-disciplinary bespoke platform build wholly unrelated to the core business of the organisation.  Furthermore given that it is an increasing imperative that any business platform supports the secure exposure of an organisation’s business capabilities to the internet they must do this in new ways that are highly secure, standards based, multi-tenant and elastic.  In the context of the above discussion, it could perhaps be suggested that many organisations are therefore attempting to build bespoke ‘clouds’:

  1. Without proven and packaged expertise;
  2. Without the budget focus that public cloud companies need merely to stay in business;
  3. Often lacking both the necessary skills and the capability to recruit them;
  4. Under the constant distraction of wider day to day development and operational demands;
  5. Without support from their business for the activities required to support ongoing innovation and development;
  6. Without a clear strategy for providing multiple levels of service and cost that are aligned to the different business models in play within the company.

In addition whatever you build will be bespoke to you in many technological, operational and business ways as you pick best of breed ‘bits’, integrate them together using your organisations existing standards and create operational procedures that fit into the way your IT organisation works today (as you have to integrate the ‘new ops’ with the ‘old ops’ to be ‘efficient’).  As a result good luck with ever upgrading the whole thing given its patchwork nature and the ‘technical differentiation’ you’ve proudly built in order to realise a worse service than you could have had from a specialised platform provider with no time or cost commitment.

Oh and the costs to operate whatever eventually comes out the other end of the adventure – according to Microsoft at least – could potentially be anywhere between 10 and 80 times higher than those you could get externally right now (and that’s on the tenuous assumption that you get it right first time over the next few years and realise the maximum achievable internal savings – as you usually do no doubt).  To rephrase this we could say that it’s a plan to delay already available benefits for at least three years, possibly for longer if you mess up the first attempt.

I may be in the minority but I’m _still_ not convinced by the business case.

So What Should I Get Sign-off For?

My recommendation would be to just stop already.

And then consider that you are probably not a platform company but rather a consultant and integrator of services that helps your business be better.

So, my advice would be to:

  1. Stop (please) thinking (or at least talking) about hypervisors, virtual machines, ‘hybrid clouds’ and ‘cloud bursting’ and realise that there is inherently no business value in infrastructure in and of itself.  Think of IaaS as a tax on delivering value outcomes and try not to let it distract you as people look to make it more complex for no reason (public/private/hybrid/cross hypervisor/VM management/cloud bursting/etc).  It generates so much mental effort for so little business value;
  2. Optimise what you already have in house with whatever traditional technologies you think will help – including virtualisation – if there is a solid _short return_ business case for it but do not brand this as ‘private cloud’ and use it to attempt to fend off the public cloud;
  3. Model all of your business capabilities and understand the information they manage and the apps that help manage it.  Classify these business capabilities by some appropriate criteria such as criticality, data sensitivity, connectedness etc.  Effectively use Business Architecture to study the structure and characteristics of your business and its capabilities;
  4. Develop a staged roadmap to re-procure (via SaaS), redevelop (on PaaS) or redeploy (to IaaS) 80% of apps within the public cloud.  Do this based on the security and risk characteristics of each capability (or even better replace entire business capabilities with external services provided by specialised partners); and
  5. Pressure cloud providers to address any lingering issues during this period to pave the way for the remaining 20% (with more sensitive characteristics) in a few years.

Once you’ve arrived at 5) it may even be that a viable ‘private cloud’ model has emerged based on small scale and local deployments of ‘shrink wrapped boxes’ managed remotely by the cloud provider at some more reasonable level above infrastructure.  Even if this turns out to be the case at least you won’t have spent a fortune creating an unsupportable white elephant scaled to support the 80% of IT and business that has already left the building.

Whatever you do, though, try to get people to stop telling me that cloud is about infrastructure (and in particular your choice of hypervisor).  I’d be genuinely grateful.

Will Private Cloud Fail ?

28 Jan

A recent discussion on ebizq about the success or failure of private clouds was sparked by Forrester analyst James Staten’s prediction late last year that ‘You will build a private cloud, and it will fail’.  In reality James himself was not suggesting that the concept of ‘private cloud’ would be a failure, only that an enterprise’s first attempt to build one would be – for various technical or operational reasons – and that learning from these failures would be a key milestone in preparing for eventual ‘success’.  Within the actual ebizq discussion there were a lot of comments about the open ended nature of the prediction (i.e. what exactly will fail) and the differing aims of different organisations in pursuing private infrastructures (and therefore the myriad ways in which you could judge such implementations to be a ‘success’ or a ‘failure’ from detailed business or technology outcome perspectives).

I differ in the way I think about this issue, however, as I’m less interested in whether individual elements of a ‘private cloud’ implementation could be considered to be successful or to have failed, but rather more interested in the broader question of whether the whole concept will fail at a macro level for cultural and economic reasons.

First of all I would posit two main thoughts:

1) It feels to me as if any sensible notion of ‘private clouds’ cannot be a realistic proposition until we have mature, broad capability and large scale public clouds that the operating organisations are willing to  ‘productise’ for private deployment; and

2) By the time we get to this point I wonder whether anyone will want one any more.

To address the first point: without ‘productised platforms’ hardened through the practices of successful public providers most ‘private cloud’ initiatives will just be harried, underfunded and incapable IT organisations trying to build bespoke virtualised infrastructures with old, disparate and disconnected products along with traditional consulting, systems integration and managed services support. Despite enthusiastic ‘cloud washing’ by traditional providers in these spaces such individual combinations of traditional products and practices are not cloud, will probably cost a lot of money to build and support and will likely never be finished before the IT department is marginalised by the business for still delivering uncompetitive services.

To the second point: given that the economics (unsurprisingly) appear to overwhelmingly favour public clouds, that any lingering security issues will be solved as part of public cloud maturation and – most critically – that cloud ultimately provides opportunities for business specialisation rather than just technology improvements (i.e. letting go of 80% of non differentiating business capabilities and sourcing them from specialised partners), I wonder whether there will be any call for literally ‘private clouds’ by the time the industry is really ready to deliver them. Furthermore public clouds need not be literally ‘public’ – as in anyone can see everything – but will likely allow the creation of ‘virtual private platforms’ which allow organisations to run their own differentiating services on a shared platform whilst maintaining complete logical separation (so I’m guessing what James calls ‘hosted private clouds’ – although that description has a slightly tainted feeling of traditional services to me).

More broadly I wonder whether we will see a lot of wasted money spent for negative return here. Many ‘private cloud’ initiatives will be scaled for a static business (i.e. as they operate now) rather than for a target business (i.e. one that takes account of the wider business disruptions and opportunities brought by the cloud).  In this latter context as organisations take the opportunities to specialise and integrate business capabilities from partners they will require substantially less IT given that it will be part of the service provided and thus ‘hidden’.  Imagining a ‘target’ business would therefore lead us to speculate that such businesses will no longer need systems that previously supported capabilities they have ceased to execute. One possible scenario could therefore be that ‘private clouds’ actually make businesses uncompetitive in the medium to long term by becoming an expensive millstone that provides none of the benefits of true cloud whilst weighing down the leaner business that cloud enables with costs it cannot bear. In extreme cases one could even imagine ‘private clouds’ as the ‘new legacy’, creating a cost base that drives companies out of business as their competitors or new entrants transform the competitive landscape. In that scenario it’s feasible that not only would ‘private clouds’ fail as a concept but they could also drag down the businesses that invest heavily in them(1).

Whilst going out of business completely may be an extreme – and unlikely – end of a spectrum of possible scenarios, the basic issues about cost, distraction and future competitiveness – set against a backdrop of a declining need for IT ownership – stand. l therefore believe that people need to think very, very carefully before deciding that the often short-medium term (and ultimately solvable) risks of ‘public’ cloud for a subset of their most critical systems are outweighed by the immense long term risks, costs and commitment of building an own private infrastructure. This is particularly the case given that not all systems within an enterprise are of equal sensitivity and we therefore do not need to make an inappropriately early and extreme decision that everything must be privately hosted.  Even more subtly, different business capabilities in your organisation will be looking for different things from their IT provision based on their underlying business model – some will need to be highly adaptable, some highly scalable, some highly secure and some highly cost effective.  Whilst the diversity of the public cloud market will enable different business capabilities to choose different platforms and services without sacrificing the traditional scale benefits of internal standardisation, any private cloud will necessarily operate with a wide diversity of needs and therefore probably not be optimal for any.  In the light of these issues, there are more than enough – probably higher benefit and lower risk – initiatives available now in incrementally optimising your existing IT estate whilst simultaneously codifying the business capabilities required by your organisation, the optimum systems support for their delivery and then replacing or moving the 80% of non-critical applications to the public cloud in a staged manner (or better still directly sourcing a business capability from a partner that removes the need for IT). In parallel we have time to wait and see how the public environment matures – perhaps towards ‘virtual private clouds’ or ‘private cloud appliances’ – before making final decisions about future IT provision for the more sensitive assets we retain in house for now (using existing provision). Even if we end up never moving this 20% of critical assets to a mature and secure ‘public’ cloud they can either a) remain on existing platforms given the much reduced scope of our internal infrastructures and the spare capacity that results or b) be moved to a small scale, packaged and connected appliance from a cloud service provider.

Throwing everything behind building a ‘private cloud’ at this point therefore feels risky given the total lack of real, optimised and productised cloud platforms, uncertainty about how much IT a business will actually require in future and the distraction it would represent from harvesting less risky and surer public cloud benefits for less critical systems (in ways that also recognise the diversity of business models to be supported).

Whilst it’s easy, therefore, to feel that analysts often use broad brush judgments or seek publicity with sensationalist tag lines I feel in this instance a broad brush judgment of the likely success or failure of the ‘private cloud’ concept would actually be justified (despite the fact that I am using a different interpretation of failure to the ‘fail rapidly and try again’ one I understand James to have meant). Given the macro level impacts of cloud (i.e. a complete and disruptive redefinition of the value proposition of IT) and the fact that ‘private cloud’ initiatives fail to recognise this redefinition (by assuming a marginally improved propagation of the status quo), I agree with the idea that anyone who attempts to build their own ‘private cloud’ now will be judged to have ‘failed’ in any future retrospective. When we step away from detailed issues (where we may indeed see some comparatively marginal improvements over current provision) and look at the macro level picture, IT organisations who guide their business to ‘private cloud’ will simultaneously load it with expensive, uncompetitive and unnecessary assets that still need to be managed for no benefit whilst also failing to guide it towards the more transformational benefits of specialisation and flexible provision. As a result whilst we cannot provide ‘hard facts’ or ‘specific measures’ that strictly define which ‘elements’ of an individual ‘private cloud’ initiative will be judged to have ‘succeeded’ and which will have ‘failed’, looking for this justification is missing the broader point and failing to see the wood for the trees; the broader picture appears to suggest that when we look back on the overall holistic impacts of ‘private cloud’ efforts it will be apparent that they have failed to deliver the transformational benefits on offer by failing to appreciate the macro level trends towards IT and business service access in place of ownership. Such a failure to embrace the seismic change in IT value proposition – in order to concentrate instead on optimising a fading model of ‘ownership’ – may indeed be judged retrospectively as ‘failure’ by businesses, consumers and the market.

Whilst I agree with many of James’s messages about what it actually means to deliver a cloud – especially the fact that they are a complex, connected ‘how’ rather than a simple ‘thing’ and that budding ‘private cloud’ implementers fail to understand the true breadth of complexity and cross functional concerns – I believe I may part company with James’s prediction in the detail.  If I understand correctly James specifically advocates ‘trying and failing’ merely as an enabler to have another go with more knowledge; given the complexity involved in trying to build an own ‘cloud’ (particularly beyond low value infrastructure), the number of failures you’d have to incur to build a complete platform as you chase more value up the stack and the ultimately pointless nature of the task (at least taking the scenarios outlined above) I would prefer to ask why we would bother with ‘private cloud’ at this point at all? It would seem a slightly insane gamble versus taking the concrete benefits available from the public cloud (in a way which is consistent with your risk profile) whilst allowing cloud companies to ‘fail and try again’ on your behalf until they have either created ‘private cloud appliances’ for you to deploy locally or obviated the need completely through the more economically attractive maturation of ‘virtual private platforms’.

For further reading, I went into more detail on why I’m not sure private clouds make sense at this point in time here:

http://www.ebizq.net/blogs/ebizq_forum/2010/11/does-the-private-cloud-lack-business-sense.php#comment-12851

and why I’m not sure they make sense in general here:

https://itblagger.wordpress.com/2010/07/14/private-clouds-surge-for-wrong-reasons/

(1) Of course other possible scenarios people mention are:

  1. That the business capabilities remaining in house expand to fill the capacity.  In this scenario these business capabilities would probably still pay a premium versus what they could get externally and thus will still be uncompetitive and – more importantly – saddled with a serious distraction for no benefit.  Furthermore this assumes that the remaining business capabilities share a common business model and that through serendipity the ‘private cloud’ was built to optimise this model in spite of the original muddled requirements to optimise other business models in parallel; and
  2. Companies who over provision in order to build a ‘private cloud’ will be able to lease all of their now spare capacity to others in some kind of ‘electricity model’.  Whilst technically one would have some issues with this, more importantly such an operation seems a long way away from the core business of nearly every organisation and seems a slightly desperate ‘possible ancillary benefit’ to cling to as a justification to invest wildly now.  This is especially the case when such an ‘ancillary benefit’ may prevent greater direct benefits being gained without the hassle (through judicious use of the public cloud both now and in the future.)

Cloud is not Virtualization

12 Jan

In the interests of keeping a better record of my online activity I’ve recently decided to cross-post opinions and thoughts I inflict on people via forums and other technology sites via my blog as well (at least where they are related to my subject and have any level of coherence, lol).  In this context I replied to an ebizq question yesterday that asked “Is it better to use virtualization for some business apps than the cloud?“.  This question was essentially prompted by a survey finding that some companies are more likely to use virtualisation technologies than move to the cloud.

Whilst I was only vaguely interested in the facts presented per se, I often find that talking about cloud and virtualisation together begs people to draw a false equivalence between two things that – at least in my mind – are entirely different in their impact and importance.

Virtualisation is a technology that can (possibly)  increase efficiency in your existing data centre and which might be leveraged by some cloud providers as well.  That’s nice and it can reduce the costs of hosting all your old cack in the short term. Cloud on the other hand is a disruptive shift in the value proposition of IT and the start of a prolonged disruption in the nature and purpose of businesses.

In essence cloud will enable organisations to share multi-tenant business capabilities over the network in order to specialise on their core value. Whilst virtualisation can help you improve your legacy mess (or make it worse if done badly) it does nothing significant to help you take advantage of the larger disruption as it just reduces the costs of hosting applications that are going to increasingly be unfit for purpose due to their architecture rather than their infrastructure.

In this context I guess it’s up to people to decide what’s best to do with their legacy apps – it may indeed make sense in the short term to move them onto virtualised platforms for efficiency’s sake (should it cost out) in order to clean up their mess during the transition stage.

In the longer term, however, people are going to have to codify their business architecture, make decisions about their core purpose and then build new cloud services for key capabilities whilst integrating 3rd party cloud services for non-differentiating capabilities. In this scenario you need to throw away your legacy and develop cloud native and multi-tenant services on higher level PaaS platforms to survive – in which case VMs have no place as a unit of value and the single tenant legacy applications deployed within them will cease to be necessary. In that context the discussion becomes a strategic one – how aggressively will you adopt cloud platforms, what does this mean for the life span of your applications and how will it impact the case for building a virtualised infrastructure (I was assuming it was a question of internal virtualisation rather than IaaS due to the nature of the original question). If it doesn’t pay back or you’re left with fairly stable applications already covered by existing kit then don’t do it.

Either way – don’t build new systems using old architectures and think that running it in a virtualised environment ‘future proofs’ you; the future is addressing a set of higher level architectural issues related to delivering flexible, multi-tenant and mass customisable business capabilities to partners in specialised value webs. Such architectural issues will increasingly be addressed by higher level platform offerings that industrialise and consumerise IT to reduce the issues of managing the complex list of components required to deliver business systems (also mentioned as an increasing issue in the survey).   As a result your route to safety doesn’t lie in simply using less physical – but equally dumb – infrastructure.

What Does it Mean to Think of Your Business as a Service?

10 Nov

Just read a really interesting post from Henry Chesbrough about what it means to think about your business as a service.  It touches on something that has always seemed obvious to me but which also seems to be not well understood.  It’s important as it’s both subtle but ultimately highly disruptive.

In order to set some context about how businesses typically think of services, Henry first points to an illustration of the value chain model and the place of ‘services’ within this illustration:

image

He points out that services are often thought of as a second-class citizen in this view of the world, merely being tacked onto the end of the process to assist customers in adopting the ‘real’ value – i.e. that which has been designed to be pushed at them through the tightly integrated value chain.

He then goes on to suggest that this isn’t the best view of what services should be in reality and that there is immense value in thinking about – and delivering the value of – a business as a service.

I have been arguing on my blog for a long time that the challenge facing most organisations is to reimagine themselves as a set of ‘business services’ (or business capabilities) that are organised around value rather than customer segments, functional disciplines or physical assets.  Such a move can make them more adaptable, help them to specialise by disaggregating non-core capabilities to partners and unleash innovation on a scale not possible in today’s internally focused and tightly coupled organisations.  Looking at different kinds of value can also help us to sustainably disaggregate and then re-aggregate the organisation based on cultural and economic differences (so based around relationship management business models, infrastructural business models, IP development business models or portfolio management business models).

90% of people I talk to still equate services with the value chain definition highlighted above, however, and miss the core point that a move to a ‘services based world’ isn’t that the small area of the traditional value chain called ‘services’ becomes the most economically attractive (i.e. consulting is better than product development and so we should concentrate more there) but rather that every participant in the traditional value chain has to realign themselves to take responsibility for ‘hiding’ the assets needed to deliver their outcome.  In doing this they simplify consumption for their customers and create an ability to work with far more value web participants outside the boundaries of a single organisation.  Equally importantly such a realignment sets the scene for them to participate in pull-oriented value webs rather than merely being a dumb participant in a pre-set and push-oriented value chain.  This does not mean that they are only specialising on the traditional ‘services’ part of the value chain and sourcing all the non-services parts from partners – rather it means that every organisation has to identify the correct business model for each component and then increase the scope of each to wrap up whatever physical, human or information assets are required to deliver that as a specialised service.  As an example manufacturers (an infrastructural business with heavy dependency on physical assets and hence far from the definition of services we started with) will still need manufacturing capability, but they will ‘expose’ the whole capability (i.e. people, processes and technologies) as a service to others (who follow different business models related to IP development or relationships).

Such a shift to greater specialisation around the delivered value whilst simultaneously extending the required scope of expertise required to deliver that value as a service is an important point; more often than not such realignments will cut across settled business boundaries and drive ‘mini-vertical-integration*’ within the context of a particular business type and outcome.

We could therefore consider a reorganisation of businesses for a service economy as a move away from the value chain model we started with to one in which:

  • ‘services’ become core offerings rather than merely a value add and represent both the external boundary and a definition of the specialised outcome delivered.  Internally the service will be implemented by a ‘mini internal value chain’ tightly optimised to deliver its differentiating IP through the appropriate combination of physical, information and human resources; and
  • a ‘value web’ coordinates services into broader networks by aggregating value via the coordination of outcomes from many specialised service providers.

Effectively you could say that the ‘value chain’ (i.e. explicit, known implementation) becomes internal to the service provider whilst the ‘value web’ (i.e. external coordination of outcomes) becomes the external expression of how value is aggregated.

Either way there is an important mind shift that needs to be made here – moving to a model in which you make your business available as a service has profound implications for what does or does not constitute a specialisation for your organisation and on how you organise.  You may find that many things you have traditionally done internally actually have no intrinsic value and can be ceded to specialised partners, whereas subsets of many of the things that have over-simplistically been considered ‘horizontal’ (and thus easily outsourced – so for example HR, Marketing or IT) come to represent significant value when you look to optimise against outcomes.  Only be re-orienting around value will we gain the insights necessary to understand the nature of the services we wish to offer, the optimum business model to adopt for each and the skills and assets required by the cross-functional teams who will deliver it.

P.S.  As an example – I briefly discussed how moves to specialise around value might affect IT departments last week.

*I should also state that when talking about ‘vertical integration’ in this context I mean within a particular business type (i.e. relationship management, infrastructure, IP development or portfolio management) rather than _across_ business types – such horrific ‘vertical integration’ across the whole value chain of different kinds of value (as beloved by traditional telecoms incumbents and, it seems, Apple) creates walled gardens that restrict consumer freedom, create asymmetrical power relationships and inhibit innovation.  As a result I believe that this is something to be strictly avoided if we want open and competitive markets (and increasingly enforced by regulation if necessary).