The world is disintegrating. Many people realise it’s happening, and a lot are positively encouraging it.

Don’t worry, this isn’t going to be a bit of apocalyptic doom mongering (although, now you mention it, Mr Trump and Mr Kim…). It’s just that business, services and IT have been getting a lot less tightly integrated – disintegrated, in other words – and I believe it’s worth pausing to think about the implications, and why it’s not necessarily the only way to go.

Imagine flying to Paris. Fifty years ago, from the moment you walked into the airline sales office to the moment you lifted your case from the carousel at Orly, most of the touch points on your journey were with a single, tightly integrated, monolithic service provider, namely your airline of choice.

Now you could do that same journey, still on an Air France ticket, and never have contact with an Air France employee or asset. From booking your seat via a web consolidator, to dropping your bag with the ground handling agent, to boarding the codeshare flight, everything is delivered by one of a highly distributed, loosely coupled set of service providers.

The whole experience feels integrated from your perspective as a traveller, but under the covers you’re consuming a bunch of loosely integrated services from a variety of providers.

Of course, this is old news. It’s long been recognised that business efficiency comes from outsourcing non-core functions to providers who can offer economies of scale by focusing on providing that one function to many businesses.

In IT, the principle of performing a process in one place and maximising re-use has shaped how IT systems are delivered, and we have moved increasingly to layered, loosely coupled service oriented architectures, mashups and APIs. Without this IT transformation, it’s hard to see how our world of digital commerce could exist.

So, as Ian Fletcher from W1A would say, that’s all good.

But, if this is such a great model, why do we see businesses who embrace disintegration deliberately moving away from it for some specific use cases? Insurance companies who don’t sell through comparison websites, online retailers who open high street outlets or re-integrate their distribution channels – haven’t they read the manual?

The thing is that, as a wise person once said, there’s no single guaranteed formula for success, and that goes for disintegration. It looks like some businesses are recognising this when it comes to decisions about distributing or consolidating, outsourcing or insourcing and coupling or uncoupling. The smart ones are looking at the trade-offs and deciding based on a full assessment of benefit, lifetime cost and risk, rather than just following the trend.

From my experience, here are the key areas that I think need to be considered to help make sure disintegration delivers value, and to steer us away from it if it doesn’t.

Disintegration is not inherently a good thing or a bad thing – as with any change, we need to assess the full costs, benefits, risk and mitigation, and build our business cases and plans on these.

Is the extra complexity worth it?

Disintegrating a component of your business or IT system adds risk. You’re adding more moving parts, which adds complexity, and complexity can add risk and potentially indirect costs that can impact your business case.

Technology is getting really good at making these interfaces run smoothly, and there are plenty of models and well-off consultants out there to help you smooth the path, but complexity can still grow like topsy and start to bite back if you don’t take it into account and plan for the impact.

For example, I was on the receiving end as an IT manager when a major service provider to me became an early adopter of the Service Integration and Management (SIAM) model, outsourcing management of services to a SIAM provider who in turn engaged several layers of subcontracted service providers.

For several months after that, I would get at least three sets of responses to any service request, each from a different subcontractor, none of whom seemed aware of what the other subcontractors were doing, and somehow nothing actually seemed to get done. They sorted it eventually but last I heard they were starting to re-integrate some service management functions.

I have seen many disintegration efforts fall foul of complexity. I believe one reason for this is that disintegration has become a dogma for business change (‘Outsource your back office or die!’) and we tend to skate over the complexities and risks in our haste to get it done, to satisfy the Board and shareholders. More realistic business cases and plans based on measured assessment of the complexities and risks will, I believe, help us do it better.

Am I adding value in the right place?

Disintegrating services often has tradeoffs – you add value in one place but reduce it in another. For example, whilst outsourcing your contact centre may save costs, it can also impact customer perception and employee loyalty. You need to consider the overall impact carefully and ensure you make a decision that aligns to what your business is about.

Outsourcing your contact centre to a third party may save costs and delight your shareholders, but it will also damage customer and staff relations if it’s not handled effectively. If customer and staff loyalty are less important than cost, that’s not too much of a problem, but if your brand value is built on these, the reputational damage could outweigh the cost savings. This has driven a number of companies to at least locate their contact centres onshore, because the cost benefits of going offshore were outweighed by the poor customer perception.

There have been at least two examples I can think of recently of major brands being damaged by the impact of service disintegration driven by cost cutting. It could be argued that the benefits to the bottom line have been worth it, but it’s questionable how long these benefits can be sustained if the bad press continues, and restoring brand reputation is always an uphill task.

So I believe the full value impact needs to be considered in the disintegration business case too, and for all stakeholders, not just the board and shareholders. It’s tempting to dismiss customer or staff dissatisfaction, nod sympathetically and start talking about inevitable emotional resistance to change, but I think this is dangerous. It needs to be given appropriate weight alongside all the other costs, benefits and risks to drive the right decisions.

Am I messing with the heavy lifting?

Clearly, the more critical the business process, the higher the risk of change, and this applies to disintegration as much as anything else.

This is a particular challenge for businesses who need to replace monolithic, inflexible old IT systems with flexible, state of the art, service based platforms. There are always risks in migrating critical IT platforms, and there are specific additional risks associated with moving from a tightly integrated platform to a loosely coupled service architecture.

I’ve already touched on the risk from disintegration creating more moving parts: this risk is compounded by the business impact if some of those moving parts stop working nicely together.

I was the IT networks manager for a company that replaced its old core selling and order management system with a new, service based platform. The new platform relied on separate services carrying on hundreds of thousands of conversations per second across the network.

We discovered that even a brief interruption to the network led to services effectively getting confused and failing in a way that was difficult to recover.

In the old, tightly integrated system, there were many fewer conversations involved; it still failed, but when it did, the smaller number of moving parts made it much more recoverable.

Of course, good design should avoid these issues, and once again technology is coming to our rescue by enabling us to model complex platforms like this exhaustively and iron out that kind of bug.

But it doesn’t alter the principle that disintegration creates more interfaces, which generate more complexity, which increase risk, which leads to more chance of a meltdown.

One way to mitigate this requires a small diversion to talk about the inventor of Agile, battleships, balloons and papier mache.

Back in the 80s I was privileged to attend a session by Tom Gilb, a pioneer of what became the Agile approach to software development. Like many, I ended up on the wrong end of an argument with Mr Gilb when I suggested that, while his methods were great in their place, you couldn’t use them to build a highly complex entity which relies on integrity to deliver its fundamental purpose, for example, a battleship.

He insisted that you could – you just needed to break it down into a set of separate minimum functional units (gun turret, lifeboat, bridge, hull,…), design and develop each of these using an Agile approach, then stick them all together. This could still be done much more rapidly than the traditional approach of designing and building the whole battleship as an integrated entity.

I wasn’t convinced, as I believed this approach would just rapidly create a bunch of components and a giant integration headache.

Then it struck me that you still apply Agile techniques to build a new battleship if you have just one thing – an old battleship to start from.

You’d still need to start in an un-Agile way by updating its power and other services, but once you’d done that you could develop the functional units incrementally, even replacing the superstructure and ultimately the hull, plate by plate.

If you want a more visual image, imagine being tasked to make something balloon shaped from papier mache. If you already have an old balloon, you can gradually build up your structure of new services like layers of papier mache on an old balloon, and when you’ve got the whole thing you pop the balloon. Harder if you don’t have a balloon to start with.

So, what if you don’t already have your battleship or balloon?

These days, I think you will find you usually do, and if you don’t, you don’t need one.

Manufacturing and service provision processes are pretty mature and it’s rare to find any business process that isn’t supported by an IT system. If there is a truly novel business model or IT requirement, it’s generally one that can and should be developed using Agile principles anyway – if it’s new, you want to start with a minimum core function then build it up incrementally.

I believe that the drive to disintegrate sometimes leads us to take unacceptable risks, and that replacing a large and complex core business function or system in one go is pretty likely to be an unacceptable risk. Much better if you can make a case that builds up your disintegrated services piece by piece, like papier mache on that balloon. It reduces the risk of killing the business, you get incremental benefits sooner, and one day you still get to pop the balloon.

Which brings us to the Pot Noodle

Innovation – Am I creating a Pot Noodle?

In Ben Elton’s play ‘Gasping’, one of the characters uses ‘Pot Noodle’ as a term to describe a new product or other innovation that creates its own market without impacting any other. Apparently, when the Pot Noodle was introduced it generated huge sales without impacting any other product market.

When it comes to disintegrating services, there may be a case for keeping something integrated even if its basic function duplicates a disintegrated service, if it does it in a way that gives competitive advantage.

Hence, whilst Amazon have historically disintegrated their distribution process, they might re-integrate it if they can get a feasible drone-based process, because it creates a new model.

So, keep your mind open to innovations which may swim against the disintegration tide, if they deliver value.

This disintegrating world is a good thing – we can get much more powerful and versatile services quickly and with much less effort and duplication than in our old, tightly integrated world. But disintegration is not a panacea; we need to remain clear eyed where it adds complexity, impacts value to key stakeholders, introduces risk or stifles innovation, and be prepared to remain integrated if that’s where the business case takes us.