Loosely coupled vs tightly coupled is no longer much of a debate in software. There are debates about how to do it well, but it is generally recognized that loose coupling is more robust to failure (even anti-fragile) and more scalable. The best example is the Internet itself. Imagine a version of the Internet controlled by a single big company or government. You would get something like Prestel or Minitel. If you have not heard of either, I rest my case.
This debate becomes relevant to business strategy and digital transformation, as many of the most valuable companies are simply software systems with an economic model attached – think of Google, Facebook, Alibaba, Amazon etc. When we talk about digital transformation of incumbents, we are really talking about turning industrial era companies into software systems with an economic model attached.
The question then is how should the components in that software system interact with each other? Or to put it in more MBA terms, how do business units work together to create synergistic value (aka one plus one is more than two).
This is not an academic debate for bankers. The question today is less about “too big to fail”. Governments do not have the cash for a bailout (with the possible exception of China). The debate is now more about “too big to manage”, or to put it more accurately “too complex to manage” (because big is good as long as it is robust). Tightly coupled is complex and fragile.
To understand how bad tight coupling is, try fixing one line of code in a legacy system. For the non-technical subscribers let me walk you through that one.
Try fixing one line of code in a legacy system
Many enterprise systems have thousands of components. If you ever wondered why big banks with lots of legacy systems are not agile, try fixing one line of code in one of those legacy systems. You will see what it looks like when a butterfly flapping its wings in China creates a hurricane in Florida. Developers have a term for how to deal with this – dependency management. If you fix one component you must know how it will impact related components and any change needs lots and lots of testing (failure to do so is career threatening).
Stack, platform, ecosystem and other faulty analogies
This is from one of my favorite thinkers about the future of software called Jon Udell:
“Here are some analogies we use when talking about software:
Construction: Programs are houses built on foundations called platforms.
Ecology: Programs are organisms that depend on ecosystem services provided by platforms.
Community: Programs work together in accordance with rules defined by platforms.
Architecture: Programs are planned, designed, and built according to architectural plans.
Economics: Programs are producers and consumers of services.
Computer hardware: Programs are components that attach to a shared bus.”
Analogies are useful to introduce a subject to a lay audience, but they can get in the way when trying to get to the next level. I tend to prefer “Ecosystem” as the analogy because the APIs do not only work up or down the stack. For example, one consumer-facing application could interact with another consumer-facing application without necessarily going through a layer below them in the “Stack”. I also try to avoid the Architecture analogy because that implies a level of rigidity which is dangerous. In an ecosystem we have emergent behavior. When one releases an Open API to the outside world, a good result is the unexpected, serendipitous application that nobody had planned for but which totally changes the game.
Applied to digital transformation, all of these are a form of systemic innovation.
He told us:
“The system threatening innovation is coming from outside the industry, from China tech companies, which have quite different balance sheet constraints, and as ever the open source community. Banks don’t understand system innovation. They think in terms of product. Compare this to what the Chinese technology platforms are doing. I think western banks will be swamped by system level innovation soon and FinTech investments won’t provide an answer to that. The change is not just about digital and the start ups we see right now are just not scaling fast enough. The change is about new skills, new processes, new services and new business models. Digital is the wrong war cry and the start-up is not a big enough axe.”
The way Steve Jobs created a product like the iPod is by assembling it from lots of loosely coupled components. Of course they were tightly integrated within the product, but via well-defined interfaces so that one vendor can easily be replaced by another vendor. Apple is the opposite of open. They like secrecy and control. Today’s consumer electronics business in China works more like an open ecosystem. Branded, consumer facing companies such as Xiaomi emerge from this ecosystem, but it is the ecosystem that is more interesting than any single company. Like Silicon Valley, this is an ecosystem that rapidly creates big companies, but it is a fundamentally different ecosystem.
Chinese business ecosystems
John Hagel, one of the leading business strategists, is author of The Only Sustainable Edge where he describes how Chinese tech companies are partnering to build products way more efficiently than they could by creating everything in-house.
This is an example of necessity being the mother of invention. Chinese companies have grown despite lacking two critical things that we take totally for granted in the West:
- Intellectual Property (IP) protection
- Well-developed capital markets.
The Chinese firms turned these weaknesses into advantages through their approach to partnering – classic Jiu Jitsu.
Enterprise vs Silicon Valley vs Shanzhai
Traditional 20th century enterprises are tightly coupled. That is the essence of vertical integration and it worked well when the challenge was the manufacturing and distribution of physical products. This changes in the digital era, when the winners are companies that create digital ecosystems such as Google, Amazon, Alibaba and AirBnB.
Digital transformation does not just mean adding a digital front end – however mobile savvy it is. It means re-engineering the company from the ground up to create a digital ecosystem. That re-engineering has to be based on loose-coupling.
The Silicon Valley ecosystem has been much studied. The Chinese electronics ecosystem dubbed Shanzhai is less well known. For a good description of Shanzhai, go to this article in The Atlantic.
Both Silicon Valley and Shanzhai ecosystems work on loosely coupled principles and that means that the companies that emerge from those ecosystems are loosely coupled in their DNA. Partnering is not an add-on, it is a core competency.
A bank is a tightly coupled enterprise ecosystem
A traditional Bank is a tightly coupled enterprise ecosystem comprising these 4 different accounts each serving a different need:
- Current/Checking account (payments in and out).
- Deposit/Savings account (having some spare cash for emergencies without any risk to capital).
- Wealth Management Account (earning money on longer term savings using fixed income, equities and other assets, earning more return by taking some risk).
- Loan account (borrowing money).
The only new account innovation in hundreds years is the Lending Account from Marketplace Lending. This the Loan account in reverse.
Startups are unbundling this tightly coupled enterprise ecosystem of accounts. They do one thing and one thing only. Regulatory innovation is keeping up, so that you can now for example just get a Payment License to use as Current/Checking account and a different license for a Deposit Account.
This is great for innovation. It does however leave the consumer to become their own systems integrator, using a lot of sneaker net and spreadsheets. As most consumers don’t want to do this, traditional banks are OK for now with their tightly integrated offerings.
The next wave of innovation is about “rebundling” and this is done using loose coupling. The Fintech Rebundling can be done by startups or by Banks. It is a genuinely level playing field enabled by Open APIs. It is perfectly suited to Red Ocean markets. In Blue Ocean markets, the “do one thing and one thing only” startup mantra is more appropriate. Startups tend to go for Blue Ocean markets and banks tend to fail at Blue Ocean markets due to organizational forces that attack such a radical idea. So Banks tend to operate in Red Ocean markets where they need to innovate in order to counter moves by traditional competitors and Fintech ventures to capture Millenials and other parts of the market that are up for grabs. Rebundling is a strategic response by Banks in these Red Ocean markets and a way to create new competitive moat.
The Unbundled Bank looks like this (replace those HiFi components with standalone accounts):
Digital transformation is about building something more like this:
If you want to see these insights before your competitors, join over 16,600 of your global peers who subscribe by email and see these trends reported every day. Its free and all we need is your email.