TL;DR: When you want to build one platform for all your lines of businesses: stop. Don’t. Build systems for each instead. Keep the integrated parts as small as possible. This minimizes costs, while enabling change.
A global, unified platform to support all our lines of business! Doesn’t that sound glorious?
CIOs puff out their chests. Architects stand up tall. Developers cringe and cover their heads.
Why?
First, why it sounds glorious: Let’s pretend that systemsthinking.dev is a global company, with several retail arms. It sells courses, of course: both live workshop tickets and access to online content. It sells physical objects like tee-shirts, immediate downloads like e-books, recurring subscriptions like newsletters, and services like corporate consulting. Each of these is its own organization, with its own business model suited to its product and customers. All of it rolls up into one brand identity.
Our CIO, Sean, has plans to make a single retail platform for the whole company. It’ll create a unified experience for customers, support all the lines of business, and report overall results to leadership. He has friends at Indolensys, a systems integration company that has done this before for big-name companies.
The architecture diagrams look great: a shared platform made up of many common services, like catalog, inventory, pricing, and payments. There’s one front end platform. Each line of business has its own configuration and customization, a thin layer.
Value grows linearly
The value in this system accrues to each line of business, plus some extra for having it all together, that unified customer experience. (Is that value entirely positive? No, but for now assume it is.)
Write this as: total value is the value of each line of business plus one multiplicative term.
V = vA + vB + vC + vD + U vA vB vC vD (where U is not far from zero)
This grows linearly with more lines of business, plus the unified-customer-experience term which is nonlinear but small.
Costs grow nonlinearly
How much does this cost to build? … or to integrate, if you believe that starting with COTS (commercial “off-the-shelf”) software will help?
Each line of business inside our company has its own business model. One has physical inventory. Another grants access to online content. Some are B2C, another B2B. Every one adds its own set of features to shared services. We’re going to accommodate all of them in one inventory system, in one pricing system, in one retail platform.
The cost of software is the cost of change. The cost of change depends on the number of features already in the system, since that determines the amount and complexity of existing code and tests. This means that the cost of adding features goes up (very) nonlinearly with the total number of features. Every line of business is harder to accommodate because of every other line of business included.
If the cost of implementing one line of business is CA, then the cost of implementing all of them in one system doesn’t add them together. It multiplies them.
C = Z cA cB cC cD + F (for some multiple Z and some fixed costs F)
Complexity in software is nonlinear. It goes up way, way faster than value. This integrated architecture looks lovely in the picture, but implementing it is going to be ugly. And every modification forever is going to be ugly, too.
This is why experienced developers cringe.
It is more expensive to build one big system than several small ones.
Here’s the alternative: integrate enough to get the extra value we want. Keep the other systems small and specific to the line of business.
Give the customer a unified experience with shared account creation and maintenance. Meanwhile, let customers buy their newsletter subscription, and let companies invoice for their consulting services. Let physical inventory SKUs be separate from the online product catalog.
Each line of business now has its own software costs. We can add them together to get the total cost, plus a smaller multiplicative term for the shared services like account creation.
C = cA + cB + cC + cD + Y cA cB cZ cD (where Y is much smaller than Z was)
Now costs scale the same way as value.
If that’s true, Jess, why don’t companies do it that way?
I observe that giant system integrations are common in enterprises. There are good and bad reasons for this, and a few I even understand.
Bad reason: they think it’s cheaper.
Multiple software systems to do the “same” thing sounds wasteful. Shouldn’t it be cheaper to add features to an existing system than to operate a whole ‘nother piece of software?
Only in a linear-growth model, where complexity is not a factor. And no, you’re not gonna “keep it simple,” because this isn’t technical complexity, it’s business complexity. Because these things (inventory, pricing, checkout) are not the same thing in each line of business. They share a name, and that can fool us.
In software, every detail matters. You can’t hand-wave away the difference between a subscription renewal for newsletters, a charge on shipment for tee-shirts, and an invoice-on-completion for services. You can only dig in and define behavior for each case and every combination.
Four implementations are cheaper than one.
Good reason: the business needs to understand its workings at the higher level.
So far I’ve talked about customer value, but customers aren’t the only people using this software. People within our company look at the reports. They need to evaluate the results at a high level. The executive team really does need to consider all four lines of business together. (This is called “legibility,” [link to something] making the system understandable at a high level.)
In the one-giant-system architecture, that falls out. Each line of business is pushed into the same structure of reporting; it’s extra effort to do anything different. Legibility is built in from the start.
In the federated architecture, we have to add another shared module for executive reports. It needs an integration layer specific to each line of business. We have to add legibility on separately.
This is fair. There is a real coupling of the lines of business at the top level. That means we should have some re-use there, and each line of business needs to integrate with the API that the overall company requires of it. This is an extra cost that directly corresponds to value, internal value this time. You can add legibility on.
Bad reason: it is easier for us to understand.
If I were a CIO, maybe I’d like the idea of this big centralized project. It looks important, and I’ll be in charge.
As an architect, maybe I’d feel satisfied by this clean drawing, and how much they’ll need my help to coordinate all these requires from the different business units.
If we let each line of business have its own software systems, with only the integrations necessary for shared customer experience, I won’t fit all of that in my head. It’s too much.
Is it my job to keep all that in my head? No. It is my job to help it fit together — to define the shared interfaces that add customer or executive value. It is my job to give background information and context to the teams that are keeping each line of business system working. And then mostly stay out of it.
That’s not easy. It means trusting the smaller development units to do their work.
There is essential coupling at the customer (if they use more than one line of business) and at the executives. Any other coupling — infrastructure, shared business services, standards — is our own creation. Maybe it’s worth it, maybe not.
Choosing to couple your software architecture into one glorious integration, to pile the complexity into one system, is expensive and risky. When the project goes off schedule (and it will), every line of business is s delayed. When the system ossifies because every change leads to surprises elsewhere, every line of business is stymied.
If my job is harder but the rest of the company runs more smoothly, I’m gonna do the harder job.
Don’t make the whole company center architect aesthetics or executive reporting needs.
Let the newsletter business serve its subscribers, and the e-book providers deliver new formats; the consulting services integrate with invoicing, and the tee-shirt sales accept Amazon Pay. Each line of business can model its own domain, without upping the complexity of everyone else’s. Centrally, we will specify the API they need to meet for company-wide reporting.
Add legibility last, sacrifice that feeling of understanding, and let many smaller glories shine.