Assumptions can be expensive, particularly if they lead you to the wrong conclusions. One popular assumption is particular particularly expensive: dependencies are minimal, or inconsequential. Interestingly enough, the business world is only starting to discover what we have known for decades as software developers. Loosely coupled systems, whether in code or in business units, are much more effective than tightly coupled ones. Depedency inversion superpowers your organization to distribute work effectively.
John Hagel, the ex-McKinsey technology consultant, summarizes loose coupling for the business folk:
“Loosely coupled is an attribute of systems, referring to an approach to designing interfaces across modules to reduce the interdependencies across modules or components – in particular, reducing the risk that changes within one module will create unanticipated changes within other modules. This approach specifically seeks to increase flexibility in adding modules, replacing modules and changing operations within individual modules.”
He claims that loose coupling will reshape the business world over the coming decades.
In our industry, loose coupling already has reshaped our world-many times over. Going back as far as the 1960s, IBM 360 operating system in the 1960, it was clear that having a loosely coupled technology spawned a loosely coupled ecosystem of 3rd party component developers. IBM then achieved dominance over the PC market with a loosely coupled system of hardware and software, unlike its primary competitor the Macintosh which tried to make everything proprietary, so that they owned everything. Building on IBM’s success, Microsoft has become a major player-at least financially, because their software had clearly defined interfaces, and because they welcomed cooperating with developers, while charging users where it was appropriate.
More recently, Google’s Android system has slowly become more popular than Apple’s iOS, quite possibly because it was more open and loosely coupled. Even though this openness has caused problems with reliability, viruses and enforcement of standards across specific hardware configurations, users prefer the benefits of using a loosely coupled product, even though they have no idea what the term loose coupling means.
The advantages of loose coupling, whether within technology or software companies, are multi-fold.
- enables scaling, as it doesn’t require detailed specification and monitoring
- can accommodate a larger number of specialized participants easily
- allows individual parts to retain their integrity/autonomy
- flexibility: quickly move in specialized operators based on customer needs (pull not push)
- makes it easier to experiment strategically, in order to learn faster
- create custom combinations of components, i.e. personalization, to maximize customer value
To realize all of these benefits, you need to be really careful about how you do this. The key is having well designed interfaces, i.e. decision rules that enable the people doing the work to make tradeoffs without requiring signoff from someone higher up. Everyone above them resolves and paradoxes and inconsistencies, with each level of management working on inconsistencies at a higher level of abstraction. This ideal is truly a self-managing, learning organization. It also works within a broader business context, because of the flexibility it gives you. You get the ability to change on a dime.
Recently I was chatting with Steve Freeman, the co-author of Growing Object Oriented Software, over beers. He had a striking observation: Most companies are strategic one-hit wonders. They struggle to create additional products which are commercially successful. Once they do create one successful product, they have a hard time ever creating another one. Out of necessity, they often piggy back on the existing product and the existing customers.
As impressive as Google is technically, most of their profits still come from Adwords. Their newer innovations are primarily a delivery mechanism for Adwords, like the Android mobile OS or Google+. From the financial point of view, Google is fundamentally a media company, not a technology company. Keeping their famous test suite revved up, to help ensure their products are loosely coupled, Google is innovating away, in hopes of creating another massively profitable product.
What if you don’t want to grow a new product line, but just acquire it? Do you know how many mergers are typically financially successful? According to Marina Apaydin, “Double-digit growth of merger and acquisition (M&A) deals in the 1980’s and 1990’s had fuelled extensive research, which produced a surprising result coined as ‘the success paradox’: that M&A popularity persisted in spite of the overwhelming rates of failure (60%-90% depending on the industry and the time period).”
Having modelled takeovers in Excel in a previous life as a financial analyst, I know how easy it is to assume that there will be “cost synergies”, without being aware of the operational implications of those synergies. Of course, there are many factors required to pull off a merger successfully, but making sure both sides of the company stay operational are pretty important. And yet, the simple fact of combining or taking apart components of companies assumes they are completely modular, self-contained, and loosely coupled.
Are they? Really?