Re-imagining Business Through Integration

Just a commentary in response to a post I found by by Peter Evans-Greenwood on the potential for business re-engineering based on presence-based technologies such as Apple’s iBeacon. While I don’t want to talk about this subject specifically, Peter uses a couple of very clear examples in terms of retail purchasing that illustrate the power of re-imagining desirable outcomes from the consumer’s perspective – as opposed to a technology perspective – and the resulting need to pursue consumer-focused integration of business capabilities to give them what they need.

These themes resonated with me this morning as I gave a talk at the Eurocloud congress recently in which I berated people for not “thinking big” about the potential of cloud in combination with other technologies. At the moment there is so much discussion and argument about whose VM is better or the benefits (or not) of making VMs more ‘enterprisey’ that everyone seems to be missing the ‘moon shot’ opportunity of integrating, simplifying and putting technology platforms into the hands of everyone. This problem only becomes more acute as you broaden your view to all of the other silo arguments raging across other areas of technology evolution. From this perspective Peter’s examples of design-led, consumer-oriented thinking were very similar to the challenge I tried to lay down to congress attendees.

Effectively I believe that the IT challenge of our generation is to package diverse technologies into much higher level platforms that humanise technology and empower less technical people to solve real problems – i.e. to enable them to use modelling and simplified domain languages to scalably and reliably address the huge opportunities that technology can deliver to science, business and society. It’s a shock to many IT people but more often than not it’s actually other people who have the domain knowledge required to change the world – which is why they don’t have the time to learn the technology. From their perspective everything related to traditional IT is a form of tax, a significant driver of risk and delay and at worst an insurmountable barrier to their activities. These problems become more acute as you scale down the size of organisation under consideration – to the point at which the vast majority of smart people are locked out of the ability to bring their expertise to bear in new digital business models.

If we take Peter’s examples of placing the consumer – rather than technology – at the heart of our endeavours then it feels to me as if many seemingly “hot” IT trends fail on this basic test and are simply a reflection of technology-led thinking. Doing isolated things better because we can – e.g. like Peter’s NFC example – is really just a way of increasing the efficiency of something that brings no benefit to the customer and is therefore just pointless when you step back and reflect. In Peter’s example the ‘customer’ from the technology provider’s perspective may have been the cashiers, the people who support payment systems or even the CIO. When you shift to an outside-in perspective, however, the obvious question is why make payment at the cash desk more efficient when there is no need to queue to pay at all?

I know it’s a difficult discussion but in a similar sense businesses rather than IT staff are the true customers of IT and their intent is ultimately to deliver new and valuable outcomes as quickly as possible – they really couldn’t care less whether your infrastructure is virtualised, what middleware is or whether the pointless technical activity required to undertake these tasks is managed by operations staff or developers. While they still have to ‘queue’ unnecessarily to get their outcomes it makes no material difference to their poor experience or the lack of empowerment offered by technology platforms. By stepping back we can see that most of the activity in cloud at the moment is not focused on re-imagining how we integrate and simplify IT to support the rapid achievement of new and customer-led business models but rather on how we provide tools and approaches to increase the efficiency of the people who have traditionally implemented IT. Again, this might make worthless tasks more efficient but effectively it’s like the payment example mentioned by Peter – in the same way that using NFC misses the opportunity for a wholesale rethink of the customer’s payment experience, I feel that most cloud activity (and certainly noise) is focused on achieving efficiency increases within the vast swathes of traditional IT activity which could be wholly eliminated using a design-led, outcome-centric approach.

In this context I believe that the major responsibility of cloud platform providers is to provide a simplified way of creating business solutions that span all of the different technologies, business capabilities and channels that are meaningful to the creation of business models. Essentially we need to enable businesses to ‘compose’ internal and external capabilities into new value webs supporting innovative new business models – all at a higher level of abstraction. I call this concept of rapid business model creation, integration and adaptation composite business. Essentially there should be no need for anyone other than cloud platform providers to understand the complexity of the different underlying technologies necessary to create, deliver and monetise systems that digitally encode business IP for such composite business models.

Realising a business platform for the support of composite business models requires the consideration of two different dimensions of integration and simplification:

1. Firstly composite business platforms need to provide a cohesive experience to their users by integrating and simplifying all of the technologies, processes and tools required to deliver value outcomes via multi-layer business composition; such platforms cannot simply be a loose and low level collection of technologies and middleware that require ongoing integration, configuration and management by technical users.
2. Secondly the platform itself needs to provide high leverage tools that a range of stakeholders can use to quickly capture, deliver, monetise and distribute their business IP as composite business and technology services.  In this context a composite business platform needs to facilitate the simplified creation of solutions that integrate distributed and heterogeneous assets into new value webs – while hiding the technical complexity required to enable it.

In stepping back we need to realise the essentially pointless nature of technology implementation and management as an end in itself and focus on the ways in which we can make it disappear behind tools that simplify the realisation of valuable business outcomes. Such a re-imagining has never been more feasible – we now have a foundation of open networks, open protocols and open technologies that enable the creation of new and higher order platforms for value creation. From my perspective this is the responsibility of platform companies in the emerging business ecosystem and we only have to step back to see the opportunities.

In this context ‘cloud integration’ transforms from being a technical issue to an enabler to the rapid linkage of business and technology assets into new, consumer-centric value webs that can span industry boundaries and deliver new personalised services.

Furthermore while I believe that this shift has the short term potential to improve services from companies and organisations operating within settled industry boundaries, the outstanding business opportunities of our age are to put high leverage cloud platforms into the hands of the maximum number of people to democratise technology and allow organisations to pursue wholesale specialisation and the aggressive re-drawing of existing industry and social boundaries around value. I believe that we truly are on the verge of not just a new information industrial revolution that impacts IT companies but rather a whole new business revolution that will leverage the shift to utility platforms to change the basis of on which businesses compete.  As the technology platform coheres,  enterprises will increasingly be able to specialise, integrate and then focus their joint efforts around value to the end consumer rather than on maximising the utilisation of their own capabilities in pursuit of scale and efficiency (something that represents a ‘punctuated equilibrium’ in evolutionary terms – as I’ll continue to explore in part II of my recent post on this subject). As value webs can be quickly created, evolved and realigned to ‘pull’ everything into the experience required by the consumer, the old model of ‘pushing’ industrially or functionally siloed products and services from large and tightly integrated companies becomes insupportable.

So I would encourage you to read Peter’s post – to see some simple and concrete examples of design thinking in action – and then think about the ‘moonshot’ opportunity of a wholesale re-imagining of technology. With all of the myriad technology advances that we are seeing it has never been easier to create a simplified and reliable platform for the modelling, execution and monetisation of new kinds of business.

Finally, also take the time to really reflect on all of these opportunities in the context of your role and the ways in which you can truly add value in this new environment. If you are working in an enterprise then think hard about whether you really need to control the technology in order to realise business value for your organisation (hint – uh, no). On the other hand if you’re working in an IT company then think about how to hide the technology and enable IT groups to focus purely on business IP capture, management and distribution.

Evolution and the IT Industry – Part I

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)

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?

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

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.

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.

Why Amazon Dedicated Instances Is No Big Deal… and Why it Really Is

Why It’s No Big Deal

I was interested yesterday in the amount of excitement that Amazon’s announcement of dedicated instances caused.  To me this seems like a sensible move from a public cloud provider in order to counter the widespread belief in large enterprises that they need to be physically as well as logically separate.  This represents a maturation of public cloud offerings in much the way I’ve discussed in the past and demonstrates that public clouds can evolve to provide the kinds of additional security enterprises (currently) perceive that they require.  This can only be a good thing as bit by bit public cloud companies like Amazon are removing the FUD generated by IT departments and traditional IT service companies and commoditising this completely unimportant stuff so that we can all move on and talk about the real business opportunities of the cloud.

Beyond the satisfaction of seeing another ‘roadblock’ item ticked off the list, however, in technical terms this seems like no big deal to me.  Essentially Amazon are offering you the ability to have a compute instance that takes up all of the resources on a single physical machine (whether you need all of those resources or not) and so fits into their existing framework of differently sized compute instances.  From that perspective it doesn’t feel groundbreaking as it merely ‘tweaks’ their existing model to mark a physical machine as ‘full’ (I’m obviously over-simplifying but intentionally so).

For these reasons I don’t subscribe to the idea that this ‘breaks’ the cloud model or is in some way not multi-tenant since there are no upfront costs for hardware, you still pay for what you use and the whole platform infrastructure is still shared.  The only difference is that you can choose to have some of your compute instances marked as requiring the resources of a complete physical machine.  Interestingly this is also my understanding of how Azure works – their compute instances are broken down into subsets of a physical machine; if you take the biggest instance you’ve essentially got that machine to yourself (although I guess that’s a side-effect of design rather than a conscious offering as per Amazon).

Why It Really Is a Big Deal

So technically we can consider this move to be a relatively small deal even though it is perceived by many as a potentially game changing additional capability.

And frankly that’s the big deal.

Most ‘private cloud’ initiatives from enterprise IT or traditional IT service vendors start from the perspective of trying to protect existing models by merely adding virtualisation and management to existing estates.  They are trying to extend an old model of enterprise IT in the vague hope that it will give them the same benefits as public cloud.  The two things are not vaguely equivalent, however, and they are hugely underestimating the differences.  There is no way that such efforts will result in something as sophisticated as Amazon’s public cloud, something that has been built from the bottom up as an optimised, integrated and low cost service that commoditises many complex products, processes and infrastructure into a single platform that caters for general usage.  There’s just too much distraction and baggage (systems wise and business model wise) for such efforts to ever succeed.  It’s not even putting lipstick on a pig but more like fluffing its muddy hair a little and half closing your eyes.

On the other hand Amazon have proven that not only are they able to build a platform that can operate at high scale and low cost for a non-enterprise market but that this new model can also be extended to cater for enterprise needs.  And they can do this competitively because they have done the spade work required to serve a lower cost market.  Adding some features to separate tenants using your ability to manage a commodity platform (for example) is much easier than trying to work out how to strip huge costs from traditional models of ownership.  This is the traditional pattern of disruptive innovation where a competitor seen as unfit for purpose by demanding users builds solutions that are far more capable and cost effective for the low end before leveraging these benefits upwards to oust incumbent suppliers at the upper end of the market.

In evolutionary terms cloud is a point of ‘punctuated equilibrium’ where the criteria for fitness to survive changes rapidly – whereas previously an ability to afford the ownership of complex, bespoke IT was a competitive advantage, it has now become a distinct disadvantage for everything except a small set of differentiating processes that represent core capabilities.  Furthermore in such a rapidly changing environment companies like Amazon who are focused around a key part of the emerging value web (i.e. an infrastructural business model focused on a commoditised IT platform) can rapidly evolve based on the selection criteria of the market, leaving traditional participants trapped and encumbered by outmoded business models.

Today this traditional end of the market is populated by enterprise IT departments, software providers, hardware providers and IT service providers – all of whom will increasingly see huge losses of business when judged for fitness against commoditised public cloud platforms.  Essentially many such participants will literally have no competitive offering as they have been prevented from making the shift by their own evolution of traits specialised for a previous environment.  As a result expect to see even more rabid ‘cloud washing’ and pushing of ‘private clouds’ by such vendors as the literal need for them ebbs away – effectively many of them will need to extend existing business for as long as possible while bringing new cloud platforms to market or deciding to cede this business completely.

Effectively companies who to date have been incapable of changing are being eaten from underneath and must decide whether they try to compete (in which case they need significant business, structural and asset realignment) or retreat into other business types that don’t compete with platforms (so consulting or implementation of vertical business services for instance – for IT departments see here for a suggestion).

Why It’s a Really Big Deal For You

For me this announcement is further proof of my long standing belief that you cannot build a successful cloud platform as an extension of old models and from within a business for whom it is not their core concern.  Rather successful providers must be ruthlessly focused on building a new cloud platform that integrates, optimises and simplifies complex technologies into a low cost service.  As a cloud platform consumer you should therefore think very carefully about the implications of this and consider whether buying that hypervisor software, hardware and services for a private cloud implementation will really get you an Amazon of your very own – or just further baggage for your business to drag along.

UPDATE:  Added link to Amazon announcement at the beginning of the post as… I forgot.

Will Private Cloud Fail ?

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

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.

Enterprise Architecture Top to Bottom

JP Morgenthal published an interesting post on his blog recently relating to the futility of trying to map out every facet of an enterprise architecture.  I wholeheartedly agree with his sentiments and have spoken on this issue in the past – albeit in a slightly different context (and also in discussing evolution and IT, actually).  I also feel strongly that EA practitioners should be focused far more on enabling a deeper understanding of the purpose and capabilities of the enterprises they work in – to facilitate greater clarity of reasoning about strategic options and appropriate action – rather than taking on an often obstructive and disconnected IT strategy and governance role (something that was covered nicely by Neil Ward-Dutton last week).  For all of these reasons I totally agreed with JP’s assertion that we should only pursue absolute detail in those areas that we are currently focused on.  This is certainly the route we took in my previous role in putting together an integration architecture for two financial services companies.

The one area where I think we can add to JP’s thoughtful consideration of the issues is that of developing useful abstractions of the business architecture as pivotal reasoning assets.  In pursuing the work I allude to we developed a business capability map of the enterprise that allowed us to divide it up into a portfolio of ‘business components’.  These capabilities allowed us to reason at a higher level and make an initial loose allocation of the underlying implementation assets and people to each (and given that both I and EA were new to the organisation when we started I even had to ‘crowdsource’ a view of the assets and their allocation to capabilities from across the organisation to kick start the process).  In this sense there was no need at the outset to understand the details of how everything linked together (either across the organisation or within individual capabilities) but rather just the purpose and broad outcomes of each capability.  This is an important consideration as it allowed us to focus clearly on understanding which capabilities needed to be addressed to respond to particular issues and also to reason about and action these changes at a more abstract level (i.e. without becoming distracted by – and lost in – the details of the required implementation).  In this sense we could concentrate not on understanding the detail of every ‘horizontal’ area as a discrete thing – so everything about every process, infrastructure, data or reward systems along with the connections across them all – but rather on building a single critical horizontal asset (i.e. the business capability view) that allowed us to reason about outcomes at an enterprise level whilst only loosely aligning implementation information to these capabilities until such a time as we wanted to make some changes.  At that stage specific programmes could work with the EA team to look much more specifically at actual relationships along with the implementation resources, roles and assets required to deliver the outcomes.  Furthermore the loosely bounded nature of the capabilities meant that we could gradually increase the degree of federation from a design and implementation perspective without losing overall context.

Overall this approach meant that we did not try to maintain a constant and consistent view of the entire enterprise within and across the traditional horizontal views – along with the way in which they all linked together from top to bottom – but only a loose view of the overall portfolio of each with specific contextualisation provided by an organising asset (i.e. the capability model).  In this context we needed to confirm the detailed as-is and to-be state of each capability whenever we wanted to action changes to its outcomes – as we expended little effort to create and maintain detailed central views – but this could be largely undertaken by the staff embedded within the capability with support and loose oversight from the central EA team.  In reality we kept an approximate portfolio view of the assets in the organisation (so for example processes, number of people, roles, applications, infrastructures and data) as horizontal assets along with the fact that there was some kind of relationship but these were only sufficient to allow reasoning about individual capabilities, broad systemic issues or the scale of impact of potential changes and were not particularly detailed (I even insisted on keeping them in spreadsheets and Sharepoint – eek – to limit sophistication rather than get sucked into a heavy EA tool with its voracious appetite for models, links and dependencies).

I guess the point I wanted to make is that my own epiphany a few years ago related to the fact that most people don’t need to know how most things work most of the time (if ever) and that trying to enable them to do so is a waste of time and a source of confusion and inaction.  It is essentially impossible to create and then manage a fixed and central model of how an entire enterprise works works top to bottom, particularly by looking at horizontal implementation facets like processes, people or technology which change rapidly, independently and for different reasons in different capabilities.  In addition the business models of capabilities are going to be very diverse and ‘horizontal’ views often encourage overly simplistic policies and standards for the sake of ‘standardisation’ that negatively impact large areas of the business.  Throw in an increasing move towards the cloud and the consumption of specialised external services and this only becomes more of an issue.  In this context it is far more critical to have a set of business architecture assets at different levels of abstraction that allow reasoning about the purpose, direction and execution strategy of the business, its capabilities and their implementation assets (this latter only for those capabilities you retain yourself in future).  These assets need to be explicitly targeted at different levels of abstraction,  produced in a contextually appropriate way and – importantly – facilitate far greater federation in decision making and implementation to improve outcomes.  Effectively a framework for understanding and actionable insight is far more valuable than a mass of – mostly out of date – data that causes information overload, confusion and inaction.  An old picture from a few years ago that I put together to illustrate some of these ideas is included below (although in reality I’m not sure that I see an “IT department” continuing to exist as a separate entity in the long term but rather a migration of appropriate staff into the enterprise and capability spaces with platforms and non-core business capabilities moving to the cloud).

In terms of relinquishing central control in this way it is possible that for transitional business architectures – where capabilities remain largely within the control of a single enterprise as today – greater federation coupled with a refined form of internal crowd sourcing could enable each independent model to be internally consistent and for each independent model to be consistent with the broader picture of enterprise value creation.  I decided to do something else before getting to the point of testing this as a long term proposition, however, lol (although perhaps my former (business) partner in crime @pcgoodie who’s just started blogging will talk more about this given that he has more staying power than me and continues the work we started together, lol).  Stepping back, however, part of the value in moving to this way of thinking is letting go and viewing things from a systems perspective and so the value of having access to all the detail from the centre will diminish over time.

In the broader sense, though, whilst I first had a low grade ‘business services as organisation’ epiphany whilst working at a financial services company in 2001 most of this thinking and these ways of working were inspired not by being inside an enterprise but rather subsequently spending time outside of one.  Spending time researching and reflecting on the architectures, patterns, technologies and – more importantly – business models related to the cloud made me think more seriously about the place of an enterprise in its wider ecosystem of value creation and the need to concentrate completely on those aspects of the ecosystem that really deliver its value.  In the longer term whilst there are many pressures forcing an internal realignment to become more customer-centric, valuable or cost effective, the real pressure is going to start building from the outside; once you realise that the enterprise works within a broader system you also start to see how the enterprise itself is a system, with most of its components being pretty poor or misaligned to the needs of the wider ecosystem and its consumers.  At this point you begin to realise that you have to separate the different capabilities in your organisation and use greater design thinking, abstraction and federation, giving up control of the detail outside of very specific (and different) contexts depending on your purview.  At that stage you can really question your need to be executing many capabilities yourself at all, since the real promise of the cloud is not merely to provide computing power externally but rather to enable businesses to realise their specialised capabilities in a way that is open, collaborative and net native and to connect these specialisations across boundaries to form new kinds of loose but powerful value webs.  Such an end game will be totally impossible for organisations who continue to run centralised, detail-oriented EA programmes and thus do not learn to let go, federate and use abstraction to reason, plan and execute at different levels simultaneously.

What’s the Future of SOA?

EbizQ asked last week for views on the improvements people believe are required to make SOA a greater success.  I think that if we step back we can see some hope – in fact increasing necessity – for SOA and the cloud is going to be the major factor in this.

If we think about the history of SOA to date it was easy to talk about the need for better integration across the organisation, clearer views of what was going on or the abstract notion of agility. Making it concrete and urgent was more of an issue, however. Whilst we can discuss the ‘failure’ of SOA by pointing to a lack of any application of service principles at a business level (i.e. organisationally through some kind of EA) this is really only a symptom and not the underlying cause. In reality the cause of SOA failure to date has been business inertia – organisations were already set up to do what they did, they did it well enough in a push economy and the (understandable) incentives for wholesale consideration of the way the business worked were few.

The cloud changes all of this, however. The increasing availability of cloud computing platforms and services acts as a key accelerator to specialisation and pull business models since it allows new entrants to join the market quickly, cheaply and scalably and to be more specialised than ever before. As a result many organisational capabilities that were economically unviable as market offerings are now becoming increasingly viable because of the global nature of cloud services. All of these new service providers need to make their capabilities easy to consume, however, and as a result are making good use of what people are now calling ‘apis’ in a web 2.0 context but which are really just services; this is important as one of the direct consequences of specialisation is the need to be hooked into the maximum number of appropriate value web participants as easily as possible.

On the demand side, as more and more external options become available in the marketplace that offer the potential to replace those capabilities that enterprises have traditionally executed in house, so leaders will start to rethink the purpose of their organisations and leverage the capabilites of external service providers in place of their own.

As a result cloud and SOA are indivisable if we are to realise the potential of either; cloud enables a much broader and more specialised set of business service providers to enter a global market with cost and capability profiles far better than those which an enterprise can deliver internally. Equally importantly, however, they will be implicitly (but concretely) creating a ‘business SOA catalogue’ within the marketplace, removing the need for organisations to undertake a difficult internal slog to re-implement or re-configure outdated capabilities for reuse in service models. Organisations need to use this insight now to trigger the use of business architecture techniques to understand their future selves as service-based organisations – both by using external services as archtypes to help them understand the ways in which they need to change and offer their own specialised services but also to work with potential partners to co-develop and then disaggregate those services in which they don’t wish to specialise in future.

Having said all that to set the scene for my answer(!) I believe that SOA research needs to be focused on raising the concepts of IT mediated service provision to a business level – including concrete modelling of business capabilities and value webs – along with complex service levels, contracts, pricing and composition – new cloud development platforms, tooling and management approaches linked more explicitly to business outcomes – and which give specialised support to different kinds of work – and the emergence of new 3rd parties who will mediate, monitor and monetise such relationships on behalf of participants in order to provide the required trust.

All in all I guess there’s still plenty to do.