For many many years, I've talked about the evolution of activities (from innovation to commodity), how this enables further innovation (componentisation) and why organisations compete in ecosystems (Red Queen Hypothesis). I've also hypothesised an S-Curve of ubiquity vs certainty to describe this evolutionary change, demonstrated techniques to manage such activity life-cycle, shown how Gartner's Hype Cycle can be derived and catalogued the underlying interconnection between Enterprise 2.0, cloud, SOA and web 2.0.
Rather than bore you with the details again, I thought I'd concentrate on a couple of diagrams to explain many of the structural aspects of this.
Figure 1, provides an overview of how activities changes from innovation to commodity, and more importantly how techniques, focus and strategy changes.
Figure 1 - Lifecycle (click on image for higher resolution)
All business activities exists somewhere on this S-Curve and all of them are moving from innovation to commodity. Hence any organisation can be characterised as a network of people interacting with a network of constantly evolving activities, with the organisation itself simply being the intersection between activities and people. You can actually visualise this, though I tend to focus on the network of activities rather than people. By mapping out lines of business against state of evolution, I've found useful tricks for managing activties along with patterns for competing with others.
Learning how to manage activities at their different life-cycle stages and hence knowing how to drive innovation, leverage emerging activities and commoditise that which is cost of doing business is essential for any company. This act is one of balancing the old innovation paradox between survival today (efficiency through co-ordination, coherence & hence order) and survival tomorrow (innovation of new activities, hence deviation, serendipity & disorder).
Since I've often talked about the organisational details of managing life-cycle (the use of pioneers, colonisers and town planners), I thought I'd instead just concentrate on the basic structure. Figure 2 provides the structural elements that are important:-
- Core services : these are core services that the organisation provides, in the I.T. world this is the area where SOA, cloud and other "service" concepts are most relevant.
- Ecosystem : this is the ecosystem that an organisation creates around its core services including workforce, partners, community, channels, customers etc.
- Innovation at "the edge": in general, the larger the ecosystem then the greater the potential for innovation to occur. The concept of innovation at the edge simply refers to expanding the ecosystem as wide as possible.
Figure 2 - Ecosystem (click on image for higher resolution)
In a typical example (e.g. Salesforce & Amazon), the company providing the core services enables and encourages a wider ecosystem to develop around it.
By monitoring new activities (i.e. innovations), and the early adoption of new but similar activities (copying is one of the many signals of success), the company can look to leverage any innovation for the benefit of the wider ecosystem. Methods which can help enable this vary from the provision of an application store to increasing awareness of innovations through the use of Enterprise 2.0 techniques.
By monitoring signals of wider adoption (i.e ubiquity) and early formation of standards (increased definition and certainty of the activity), the company can elect to drive an activity towards commoditisation and provision as a core service. This correspondingly completes the circle and encourages further innovation in the ecosystem through componentisation.
Quite simply put, the structure is simply designed to feed off and accelerate the normal process of evolution of activities (technical or otherwise). This results in a situation where apparent innovation (others are innovating for you), customer focus (leveraging of consumption data to deliver what people want) and efficiency (economies of scale) can all increase with the size of the ecosystem.
I mention this because the centralist approach is to provide all activities at the centre as opposed to "crowdsourcing" both creation and identification of innovation to a wider ecosystem built around a core of common services. Whilst centralisation is not an invalid approach, it is generally highly ineffective when competing against a company which creates a broad ecosystem. This is shown in figure 3.
Figure 3 - Competitive Landscape (click on image for higher resolution)
So with this in mind, I turn to the U.K. Government cloud efforts. It's worth remembering that the U.K. Gov I.T. currently employs over 35,000 people and outsources nearly 65% of its budget (from a total figure of £16bn+). This pretty much makes the internal part of U.K. Gov I.T. equivalent to Google PLUS Amazon whist the outsourcing part is far bigger.
The approach of providing standardised & centralised core services for commodity activities (such as computing infrastructure) is fine. However, as there is no actual competitive utility computing market, an approach of outsourcing to a group of vendors would be unwise (it's worth noting that both Google & Amazon adopted to build in-house). Fortunately, one set of standards - EC2 & S3 - are emerging.
Given this, a sensible strategy would be to adopt these emerging standards, consume conforming external services and where needed build using an open sourced technology (
there are several to choose from, Ubuntu Enterprise Cloud would be one). Design for a mix of private / public (hybrid) with a near future view of using multiple public providers. Develop any needed new elements in-house whilst outsourcing standard components i.e. data centre floor space, power provision etc.
The second area of concern is the Government Application Store. Whilst providing a centralised mechanism of application fulfillment is a sensible approach, the concern should be how those application are developed and provided to the store. Whilst some applications have become commoditised enough to be provided as centrally managed applications or services, it is absolutely essential that the application store should encourage a wider ecosystem (especially at local government level and within communities) for the development of new applications.
A fairly sound approach would be to combine the above with mechanisms of ecosystem monitoring and encouragement for the wider adoption of successful activities. An alternative centralist nightmare, would be where the core (i.e. some form of centralised council) attempts to predict the future whilst defining and developing activities to be adopted (a dis-functional programme management approach). This will lead to the normal flurry of massive development costs, vendor dependency and lock-in.
So why should I care? Well, I live in the U.K. and our Government exists in a wider competitive ecosystem of national governments. The role of U.K. Gov I.T. is to get this stuff right, the same with any other Government.
