By Vidar Hepsø
In my previous blog I discussed the importance of capability platforms and presented some of the discussion that we have had with the Professors John Henderson and Venkat Venkatraman at Boston University. The capability stack model that I presented was a layered representation of a complex system, that decouple the complexity of the system by introducing distinct layered activities connected by standard interfaces. In this blog I present how an architecture control perspective allows us to capture the value of an innovation.
The stack model perspective that was presented in my previous blog imposes an ordering or hierarchy, assuming that capabilities at lower level are required to execute capabilities at a higher level. This means that we can use the layers further down to open or close the layers further up. A layer uses defined interfaces that limit the impact of change. As long as the information representing the change can be exchanged across a layer via the standard interface, the innovation within one layer can be decoupled from innovation any other layer. As with any general notion of modularity, this decoupling allows for independent actions and thereby reduces the complexity of coordinating interactions across a system. In this way a stack model reflects the characteristic of ecologies wherein one part of the ecosystem can change without affecting all parts of the system.
A basic feature in Venkatraman’s perspective on stacks is that in each layer it should be possible to see a market. This input can be used to analyze market dynamics and the nature of competition, for example whether we are enabled or threatened by emerging products or services in the industry. The model can also be used to investigate the competitive implications of innovation. Finally, the stack model forces you to look at hierarchical dependencies. This is interesting from a business strategy point of view, because if you control a lower level in the stack you can influence all the levels above. If you want to know more about this I would recommend that you watch Venkatranman’s video presentation from last year’s IO-conference in Trondheim.
An important part of platform design is what decision rights or key influence points a company needs over the architecture in order to capture value. To what extent and how will we influence the platform through design moves (e.g. define and make interfaces available) or contract moves (e.g. acquisition and/or joint industry projects)? For different parts of such a stack, different control strategies can be applied, for example whether the company work with selected partners only or are open to the market. An architecture control strategy influences both the technical platform design and an approach to the market (procurement strategy). In my OCEAN-example in my previous blog it is very clear who benefits financially and has architectural control. Schlumberger opens up the API’s, they facilitate the development of the OCEAN-ecosystem. Still they also control which apps that can be sold in their OCEAN store. They have certain intellectual property rights in the apps that are sold in their store. In addition they receive revenue for each app sold. Schlumberger has architectural control of the ecosystem they have built around OCEAN and has also built a unique capability to increase their understanding of the market. This gives them a unique position to approach the emerging analytics layer in the oil and gas business. Schlumberger has decision rights that allow them as owners of the PETREL/OCEAN- platform to access or reconfigure standards and/or core capabilities. They also have access to the value generated by the others in the ecosystem.
Professor Henderson tells us that architectural control is how we think about control in an organization that is flexible and tries to leverage network effects. Architecture control can therefore be defined as the pattern of decision rights (and key influence points) that enables the firm to capture value. For any important platform in a networked environment Henderson argues we must face two crucial questions:
1. Who has influence (over the platform architecture / in the business network)?
2. Who keeps the value (money) from using the platform?
This is the key issue of architecture control; the potential capacity to enable or constrain the design of one or more system components without necessarily exercising design rights over these components directly.
We see that architectural control can be exercised in various ways, for example through hardware platform, infrastructure, software, methods and work processes, IPR, dominating market position, new business models, branding and corporate social responsibility. OCEAN is a mix of all these and is therefore pretty successful.
It is important to ensure that the architectural control points of any strategic capability or platform are recognized and kept within the enterprise to be able to take the necessary design and contract moves. This will make us harvest the value of the platform. Schlumberger is a large vendor company that has shown a new way to make money here. How do we approach this as oil and gas companies?




