Sunday, January 27, 2013


When you consider an organization and the value chains that describe it then there are five groups of other organizations and individuals that any company interacts with.

There are the inputs into the value chain (suppliers), the outputs of the value chain (consumers), the people that operate and manage components of the value chain (employees), equivalent organizations that the company competes and co-operates with (competitors and alliances) and sources of learning or potential improvement to the value chain (wider business and academic environment).

These groups are the company’s ecosystem.

Each of these ecosystems provides many opportunities for discovery, improvement and manipulation of the landscape. The techniques of which often change depending upon how evolved the activities, practices and data models are and how they are used.

For example, let us consider a company whose output is more of a completed product (e.g. a Kettle) rather than a component product (e.g. Nut and Bolt) and the product is sold to the public.

The consumer ecosystem (in this case public consumers such as you and I rather than other organizations) can provide information on improvement, quality control, reliability and price sensitivity. This is normally achieved through secondary sources i.e. not directly derived from interaction with the product itself but instead surveys, warranty cards, sales volume, customer services and it can even extend to co-creation of the product.

The ecosystem can also be influenced through marketing, branding and association of the product with other values (e.g. buying this kettle will make you look cool, save a rainforest etc).

An ecosystem of consumers provides ample opportunities for manipulation and learning. There exist plenty of learned tomes on this subject and so I will assume the reader is familiar with this already.

The same opportunities also exist with all the other ecosystems and various models exist for benefiting from this such as the whole Enterprise 2.0 approach, use of wikis and internal social media tools with the employee ecosystems.

In this section, I want to concentrate on four specific issues with ecosystems – one is a model known as ILC, the others are two factor markets, alliances and the focus of competition.

The ILC model
This model is most frequently used when the output of a value chain is a component of other value chains (e.g. in the technology industries - a software development suite used by other companies to develop other software products or provision of a software API which is consumed by multiple other systems).

The operation of the model is fairly simple. The supplier provides the component that others consume in their value chains hence creating an ecosystem. Through efficiency in provision, the provider encourages the ecosystem to create new activities (i.e. genesis) by reducing the cost of failure. Genesis by its natures is highly uncertain and risky; hence reducing the cost of failure becomes a way of encouraging innovation. 

As any of these new activities spread, the supplier can detect this diffusion through consumption of the underlying component thereby leveraging the ecosystem to spot future sources of wealth. The supplier then commoditizes these newly detected activities to components hence enabling the development of new higher order systems. 

In effect, the supplier eats part of the ecosystem (i.e. those diffusing higher order activities) in order to provide new components that help the ecosystem to grow.

For example, the provider of a software development environment as a product can monitor the rapid growth in consumption of the product (i.e. buying licenses) and investigate those industries to identify any new activities being built. This is not actually that effective a technique because the cost involved in monitoring is high and there are significant time delays.

But let us suppose you were a provider of utility computing infrastructure services (e.g. something like Amazon EC2). Then not only does the provision of these services enable rapid creation of higher order systems by encouraging experimentation through a reduction in the cost of failure but also the supplier has direct access to information on consumption.

Let us suppose that one of these new higher orders systems (e.g. “big data” systems built with hadoop) started to diffuse. Through consumption of the component infrastructure service you could detect this diffusion in close to real time and hence rapidly decide to commoditize any new activity to your own component service e.g. in this case by introducing something like Amazon Elastic Map Reduce.

Naturally, you’d be accused of eating the ecosystem if you did this repeatedly but at the same time your new component services would help grow the ecosystem and create new higher order services. 

The operation of the model is shown in figure 36 to 38 and it exploits componentization effects as well as the changing characteristics of activities as they evolve. 

In essence the supplier encourages others to innovate (take the high risk gamble associated with chaotic activities), leverages the ecosystem to spot diffusion of successful changes and then commoditizes rapidly to component services. The cycle of Innovation – Leverage – Commoditise (ILC) is then repeated for subsequent higher order systems.

Figure 36 – A Standard View of Evolution

Figure 37 – Ecosystems and ILC

Figure 38 – A Map View of ILC

The component services are in effect your “platform” (though I prefer the term “garden”) around which you carefully nurture and grow an ecosystem. Like any gardener you’d have to balance this eating (or harvesting) of the ecosystem with the benefits that new components bring in growing it and the overall health of the garden (i.e. level of disquiet over the occasional munching session). 

The effectiveness of this model depends upon a wide range of different factors: -

Scope of the component: how broadly useful the component is. Is it a specialized component (e.g. a software service given train times for a specific train station) or used in a wide variety of value chains (e.g. a nut and bolt or electricity or computing infrastructure). The essential measures here are volume (how much it is used) and variation (i.e. the number of value chains consuming it).

Speed of feedback: ideally information needs to be captured directly on consumption of the activity rather than through secondary sources such as surveys. For this reason, it’s ideally suited to the world of utility provision where the supplier can directly detect the consumption of a component.

Ability of the supplier to act: is the supplier able to capture the information and are they willing to leverage the ecosystem to its benefit?

Efficiency of provision: how efficiently is the underlying component provided? Critical to this game is reducing the cost of failure within the ecosystem and hence encouraging experimentation and creation of new activities by others. Certainly provision of a former products as utility services will gain benefits for reduced capital expenditure by consumers, however efficient provision will also exploit volume effects and the larger the ecosystem the higher the rate of genesis.

Management of the ecosystem: the act of commoditizing to new component services is one of eating the existing ecosystem (either through acquisition or copying). The purpose is to provide new component services that help the ecosystem to grow and increase the usefulness of the entire range of components provided by the supplier.  Care should be taken not to too aggressively eat the ecosystem otherwise organizations may become wary of developing with the components.

The effects of this model are extremely powerful but it needs to be managed carefully. For the supplier, the rate of innovation (i.e. genesis of novel activities) is no longer dependent upon the physical size of the supplier but the size of the ecosystem of consumers. 

Equally, the ability to spot new and useful activities is extended beyond the supplier and its interaction with its consumers to an ecosystem of consumers who in turn supply activities to other consumers i.e. this much wider ecosystem are all consuming the base component activity and providing information on diffusion. Finally, the efficiency of provision depends not only on the volume required by the consumers but also this wider ecosystem where consumers themselves are suppliers to other consumers.

Hence the rate of innovation, customer focus (i.e. spotting new and useful trends) and efficiency of the supplier all increase with the size of the ecosystem itself rather than the physical size (as in number of employees) of the supplier. 

Through the use of a model like ILC, it’s entirely possible for a company to appear to be simultaneously innovative, customer focused and efficient which is counter to the popular management doctrine of choose one. Furthermore the rates of each (if properly managed) can increase with the size of the ecosystem which itself can increase at faster rate than the physical size of the company. 

In other words, the bigger the company gets the more innovative, efficient and customer focused it becomes.

For many of the followers of my writings over the last decade this will be a “where’s the good stuff?” moment. However, for others this model might be quite surprising and hopes of competitive advantage might appear. So, I want to once again bring things down to earth because ILC can overexcite some people.

The origin of the technique above started around 2002. It was an essential part of the Zimki strategy in 2005 and so well described by 2010 that I included it in part in “The Better for Less” paper that in turn had some influence in formulating UK Government ICT strategy. ILC and techniques of exploiting ecosystems are powerful but becoming increasingly common. Using and growing them is more of survival today, not of gaining advantage. 

There are three other aspects of ecosystems that I also want to mention.

Two Factor Markets
The two-factor market is a special case of ecosystem that brings suppliers and consumers together (hence two factor). Examples would include a farmers market, an exchange and Amazon’s online retail site. These not only provide ample opportunity for exploitation but they have powerful network effects as the consumers attract suppliers and the suppliers attract consumers.
In the cases where you’re either competing or may compete against a large and threatening ecosystem or if you simply want to prevent this scenario occurring or want to nullify any advantage then the only way to do this is to build a bigger ecosystem. However, you don’t have to do this alone but can operate in an alliance with a view of taking a “small piece of a big pie” rather than a “big piece of a small pie”.

In the case of Zimki, the stated purpose of open sourcing the technology was to create a large pool of suppliers that competed on service with switching between them in order to overcome consumer concerns on lock-in. The focus for Fotango was to take “a small piece of a big pie” whilst building an exchange (a two factor market) of Zimki suppliers and consumers.

Now, creating such alliances can be tricky because individual suppliers (especially those with a product mind-set) will attempt to differentiate on features rather than service which in turn will limit switching hence raising consumer concerns whilst weakening the overall ecosystem. Equally suppliers will also be concerned over any loss of strategic control or dependency upon a third party i.e. a captured rather than a free market.

Hence with Zimki, the technology could have been provided as a proprietary offering but each Zimki supplier would then have been dependent upon Fotango. We would in effect have exerted a tax on the market both in terms of the licensing of the technology and also in controlling the future direction, furthermore we would increase barriers to adoption due to the constraints. The upside is we would limit any differentiation by suppliers.

By open sourcing the technology, we would remove the constraints, barriers to adoption and any tax on the market. However, we would open the door to differentiation by the suppliers on feature rather than service thereby weakening switching and the overall ecosystem.

To balance this, we needed to use a technique of assurance through trademarked images.

By open sourcing the entire platform technology, we would enable other competitors to become Zimki providers, remove barriers to entry and help establish a market. The trademarked image was only to be available for those who would comply with our monitoring service and hence we could provide assurance that this provider hadn’t differentiated the service by function in a way that any consumer would now be unable to switch.

This mix of open sourced technology and assurance through monitoring and a trademarked image is a way of balancing the needs of suppliers (i.e. low barrier to entry, a free rather than a captured market controlled by one player), the needs of consumers (a competitive market with switching) and the needs of the company forming the market (a wide and healthy ecosystem which can compete against alternatives).

Recently, similar examples of such play have appeared e.g. CloudFoundry, a platform as a service offering provided by VMware, is not only open sourced but provides a trademarked assurance service through CloudFoundry Core. 

Equally, Google whose value chain around data was under potential threat from Apple and the walled garden created by IOS has an open source technology (Android), a trademarked image on Android, the Open Handset Alliance and a mechanism of assurance through Android’s compatibility test suite. The Android ecosystem has rapidly risen to now dominate the smartphone market.

The importance of the control mechanism and careful management is in negating any effective “collective prisoner dilemma” when the members of an alliance in act of self-mutilation attempt to differentiate in their own immediate interests weakening the entire ecosystem and their own long term interests in the process.

The game is also highly nuanced. For example, when facing an existing and effective competitive ecosystem it is often better to co-opt rather than differentiate from it in the first place, a model of “embrace and extend”.

Hence in the case of utility infrastructure provision, if you were to go up against Amazon and its well-developed and highly effective ecosystem then co-opting the ecosystem would be the first order of the day. Since the ecosystem (and all the higher order activities created) are built upon the standard interfaces (APIs) of Amazon this means in effect providing identical APIs in both form and function.

Fortunately, under both European and US Law, APIs are not currently copyrightable (being principles) whereas the code that implements it is (being expression). Hence APIs can be re-implemented through reverse engineering. This practice we’ve seen with groups such as Eucalyptus and CloudStack (a Citrix project which is part of the Apache Foundation) who have both clearly stated directions of emulating the Amazon APIs.

Creating a competitive alliance is not a simple task neither is competing against an established ecosystem. There are plenty of pitfalls including the breakdown of an alliance through a collective prisoner dilemma. However, as in the case of Android, when it works it’s a highly powerful tool.
The focus of competition
The last thing I wish to mention is the focus of competition. The process of evolution is driven by consumer and supplier competition and those consumers and suppliers can either be individuals (as in the general public) or companies. This is not a static situation but it is fluid.

For example, let us consider the use of computers. To begin with both the suppliers and consumers of computers were companies. The sale, provision and competition around computers with the first products (such as the IBM 650) were all focused on business to business (B2B).

However, computers were made of components such as processing, storage and then networks that were evolving and becoming more of a commodity. The rate of evolution of those different underlying components affected the path that computing took. For example, because processing and storage commoditized faster than the network, the industry went through a transition of Mainframes to Mini computers to PCs to Tablets. However, had networks commoditized faster relative to processing and storage then an entirely different path of Mainframes to Personal Terminals to Tablets would have been possible. The rate of evolution of components can alter the path that higher order systems take.

However, what also happened is that the focus of competition in part shifted from being governed by B2B to being governed by Business to Public Consumers (B2C) as companies sold personal computers. In the same way, email (which started as primarily an academic and then business focused tool) shifted to the public consumer market with the introduction of services such as AOL.

What is important to understand is the rate of evolution is not uniform between the business ecosystem and the public consumer ecosystem. Hence as the competition around email shifted to the public consumer market (with the introduction of services such as Yahoo and Google Mail) then the public consumer market developed highly commoditized email services. In many cases these were vastly more commoditized and efficient than the equivalent activity in the business ecosystem, which was often provided by products.

Pressure mounted for those business consumers of email to adapt (and in many cases adopt) these more “consumerized” services available to the members of the public. 

This shift of competition and hence evolution from being governed by B2B, where companies represent both the suppliers and consumers of the activity, to one governed by competition in the public consumer space is known as “Consumerization” (as described by Doug Neal, LEF in 2001). See Figure 39.

Figure 39 Consumerization

Now, not all activities undergo this process. Many activities remain governed by competition in one ecosystem i.e. between companies with companies representing being consumers and suppliers. An example of this would be Financial ERP systems.

Equally, consumerization is not a one-way street. Activities that evolve and are governed by competition in the public consumer space can be forced into the business ecosystem. An example of this would be radio broadcasting equipment, a once vibrant and rapidly developing activity in the public consumer space with many public hobbyists creating and sharing capabilities which was forced under the control of companies through the legislative control of the radio frequency spectrum. 

The point to note is that the rate of evolution can rapidly change if competition around an activity switches focus from the business to public consumer ecosystem. Now, I won’t detail all the aspects of ecosystems mainly because there are numerous books covering Enterprise 2.0, use of Social Media, Supply Chain relationships and the above should provide the reader with the basics for the mapping exercises latter in this work.

It’s enough to be aware that various forms of ecosystem exist, exploitation can have powerful effects, the rate of evolution of components can effect the path that higher order systems follow and the rate of evolution can rapidly change as the focus of competition around an activity switches from one ecosystem to another. By now, if you've followed the entire series, you should have a good appreciation of the complexity of change and also why without maps it's no wonder that strategy becomes vague hand waving.

One final note, you should also have some understanding of the difference between the terms Consumerization (the process by which the focus of competition shifts from business to consumer ecosystem), Commoditisation (the process of evolution for activities) and Commodification (the process by which an idea with social value becomes instantiated as an activity with economic value, an idea from Marxist Political Theory). Endless confusion abounds because those entirely different concepts are constantly jumbled together as though they were the same.

Since I’ve already mentioned open source in this section, I will now turn our attention to the use of open as a competitive weapon and then finally, we can get back to maps.


Post 16 of 200 on the Management and Strategy series.

Next post in series ... Open

Previous post in series ...  The Next Generation

Beginning of the Management and Strategy series ... There must be some way out of here