Monthly Archives

One Article

Posted by on

Stratification: Has the Integration vs Specialisation Question Been Answered for Tomorrow’s Business?

In the future, if you want a big and profitable business, are you better served focusing on your core value or owning every step in the supply chain, operating every component? It’s an age-old question, the answer to which has been subject to wide debate and big swings in fashion, probably since the earliest enterprises began.

Each time the issue is raised it comes with new buzzwords, different components having their own terminology for moving in or out of the organisation. Call centres (‘outsourced’), development (‘offshored’), telephony (‘hosted’), software (‘SaaS’), hardware (‘cloud’), etc. Logistics, marketing, finance, property, retail, manufacturing, design, and even the original product and service concepts themselves can all be offloaded.

In the 90’s and early noughties it was all about moving functions out of the business, like call centres and software development. And then came the turning of the cycle, the inevitable backlash. Companies now make a big point of having ‘UK call centres’. I’m hearing grumblings about outsourced development that may see similar slogans slapped on locally-built software.

Purity of Principle

The reality is that few businesses can exist in either ‘pure’ state: entirely lean and focused, or monolithic and integrated.

Take Apple, for example, a famously vertically-integrated business and one that bucked the trend through the 90s and noughties. Apple owns and controls a large number of the steps in the content supply chain. The design and manufacture of the devices, the software that runs on them, the shops that sell them and the online shops that sell the content for them. But it still outsources large parts of its manufacturing. It has to source components from a wide number of suppliers, some of them competitors elsewhere in the market. And it opens up its own software and content marketplace to a large number of suppliers.

Tiers of Business

It is this tier of the business that I find most interesting. Because Apple both competes in this marketplace with its own applications, and allows others to enter — even if the applications compete directly.

Amazon does the same, operating a vertically integrated business but allowing others — even competitors — access to certain tiers. Take the layer diagram I use to break down so many things into manageable chunks.

Action Layer: This is the consumer.
Presentation Layer: This is Amazon.com/.co.uk, the online shop with which so many consumers are now familiar.
Processing Layer: This is Amazon Web Services. What few consumers know is that Amazon allows other companies, including other online retailers, to use its incredibly powerful and cost-effective computing platform to host their shops, applications, databases, and files.
Connection Layer: Amazon’s logistics operation is enormous and expanding. It doesn’t serve other retailers today, but it could.
Collection Layer: Likewise Amazon’s procurement operation is not yet open to others. But could it be?

This situation is replicated across technology businesses in hardware and software alike. Companies are increasingly tiering their organisations and recognising that those tiers have to be treated as standalone markets. There is no problem dealing with suppliers or customers in one tier who might be competitors in another. Witness Samsung making screens for itself and Apple. Intel fabricating chips featuring arch rival ARM’s core processor designs. Microsoft finally releasing Office for iPad.

Low Friction Interactions

What’s most interesting about this ‘co-petitive’ trend is not that it is happening in these different layers. This has been the case for some time — for example, Microsoft has long made software for, and been an investor in, Apple. What I find interesting is how the layers interact.

To give a practical example, I’m building a dashboard for my business. This will show me the key performance indicators for my weird hybrid of a business, at a glance. To do this I’m using a very nice framework called Dashing, built by techies at the ecommerce platform Shopify (a company which itself could be a nice case study in stratification). Because Dashing is built in a particular language (Ruby), that my usual web hosts don’t support, I had to try an alternative. Having heard good things I checked out Openshift.com. I set my application up on Openshift and got it running before I’d really read around what it is.

Put simply, OpenShift acts as a smart management/integration/user interface layer over Amazon Web Services — Amazon’s web and application hosting platform. When I add my application to OpenShift what it actually does is set up hosting for me on Amazon’s platform. It can do this, seamlessly and transparently, because the interface between the two systems is entirely automated and programmatic. Even though a new order potentially means the reconfiguration of physical hardware, the conversation happens entirely in data.

This interface between the two companies and the two systems is incredibly low friction. Commands flow in one direction, costs and services flow back in the other. It means Amazon can afford to sell its services to lots of people in lots of ways, because the cost of reaching them and supporting them is incredibly low, further enhancing (or at least maintaining) the low prices. Because interactions happen in real time, and are data driven, monitoring and resolving any breakdowns in the service is quicker and if not easier, then at least based on good evidence — not always the case in human to human interactions.

People as a Service

Stratification typically applies to business units or functions. These can be neatly packaged with an interface on the outside that allows the relevant information and resources to be passed back and forth. But increasingly people are becoming package-able units too.

Through my conversations with Tim Lovejoy on the future of work, I’ve been looking a lot at the increasing drivers towards self-employment. At one end of the economy, self-employment is almost being mandated. Under-employment and zero hour contracts are driving people to juggle multiple ‘clients’, and supplement their income with other work. At the other end self-employment is ever more appealing: software and web-based services take much of the pain and cost out of running your own small business, and it remains highly attractive from a tax perspective. Businesses are even encouraging senior employees to move to more flexible working, recognising the potential cost savings on both sides and more importantly the valuable learning that executives bring back from other businesses.

This is essentially stratification of the workforce. Employees are becoming thin layers, or segments of layers in their own right. Via corporate collaboration software or virtual work exchanges, each has their own low-friction, data-driven interfaces to the other layers.

What is crucial in an arrangement like this is ensuring that the business retains access to the workforce that it needs, when it needs it. And that the workforce maintains a relationship with the business that supports their loyalty and motivation. Achieving this in a flexible role for a senior executive is one thing. Achieving it for a large workforce on zero hour contracts, quite another.

Advantages of Stratification

I believe that stratification via a low friction, programmatic interface between networked business units right down to the individual scale, is becoming an increasingly visible trend in the structure of business. And for good reason. It improves the interaction between layers in an organisation, and it allows those layers to be opened up to third parties. This approach, and the business philosophy attached to it, has a role to play in the development of many organisations across the public and private sectors.

Some of the key advantages it offers are:

Agility: One of the most common questions I am asked in consulting engagements is how companies and organisations can become more agile. By codifying and streamlining their interactions, stratification allows the different parts of an organisation to be move around more easily. New interactions with other departments or third parties can quickly be added to support new products, services or enhancements.

New Revenue Streams: In the organisations I deal with there is often untapped value, in various repositories of data or well-developed internal processes. Stratification appears to increase the visibility of these hidden treasures but also creates the means by which they can be accessed.

Reporting: Stratifying the organisation forces the automation of certain systems that may have held out until now, including reporting. I haven’t encountered many organisations where good quality performance data is reaching the people who need it in a timeframe that many would consider ideal — i.e. real-time.

Disadvantages of Stratification

By its very nature stratification lays bare the inefficiencies in a business and drives automation. As many people are noting now, digital automation may drive productivity but it doesn’t create jobs. Like any business change, stratification will encounter resistance and this resistance will be reinforced by the level of transparency it creates around the activities of departments and individuals.

Principles of Design

Where organisations have succeeded in stratification there seem to be some clear design principles emerging.

Codify Inputs and Outputs: The first step is to break an operation down into clear units that have defined and repeatable inputs and outputs. This won’t be possible with all pieces of the business, but in some cases this may highlight where one unit is being tasked with multiple jobs that ought to be split. For example, it can be hard to operate efficiently when one team is tackling parallel work streams with very different work flows, time scales and deliverables.

Systematise Processes: While most of our work (though not all) may be computerised, much of it is not systematised. The work flow in departments is not a defined, documented process. Instead knowledge is locked in people’s heads. Processes are carried out using general office software packages and email, rather than tools that encapsulate the process in themselves. These tools can guide users through a process and check for errors along the way, increasing quality, reducing completion time and enabling new staff to be trained very quickly. Most importantly systematising the process automates the production of performance data, giving management much clearer insight into each corner of the business.

Open Data: Data is the language of stratification. This is not a diminution of the importance of human relationships in minimising the friction in a business, but a recognition of the fact that the speed and precision of data can overcome some of the limitations in a purely ‘meatspace’ process. Opening up restrictions and overcoming fears about the publishing of data, internally and externally, privately and publicly, is a huge part of the stratification process.

Publish APIs: An API is an application programming interface. It is the means by which commands and data can be sent and received from a piece of software by another piece of software rather than a human user interface. Think of it like the pins and holes on a piece of Lego that allow it to connect to others. Just like Lego, with an API to your software — or your departments — it is much easier to rearrange the building blocks of business into new configurations, supporting new processes or creating new services or products.

Applying Stratification

Stratification is not a wholly original idea, more a synthesis of some key trends in the development of organisations and businesses over the last thirty years. It is in itself a ‘re-combinatorial innovation’. That gives us confidence that even though the idea is at an embryonic stage, at least its component parts are sound.

Where stratification perhaps most extends existing thinking is in the idea of applying the principle of an API to a department or even a person, rather than just a piece of software. This will not be universally popular. But it’s important to repeat: this is not about valuing computers over people, or diminishing the role of people in an organisation. We are not expecting people to behave like software. Rather as has been pointed out in multiple books and studies (see, ‘The Second Machine Age’), there are things that machines do better and there are things that people do better. Recognising this and separating the work accordingly has long been a recipe for increased productivity.

Capturing process in software, using that captured process to handle inputs and outputs, and deliver good performance metrics makes a lot of sense. Using this capture process to create a wrapper around departments that can then be understood and manipulated as logical blocks in the organisation makes sense. Allowing third parties to access the now open, standard interfaces that connect these blocks together also, we believe, makes sense. Inside that well-defined framework should be greater, rather than lesser, opportunity for people to do the things that people do best: interact, innovate and improve the business around them.

Tom Cheesewright