Sipahi Demir
Enterprise AI4 min read

We Built Enterprises Around Software

For thirty years the answer to every business problem was to buy software for it. It worked. And it left the business living in the gaps between the pieces.

For the last thirty years, enterprise technology has followed a very simple idea. If a company wanted to become better at something, it bought software for it.

Finance got an ERP. Sales got a CRM. Human resources got an HR system. Procurement got procurement software. Operations got workflow software. Customer support got another system.

And then, because none of these systems were designed as one system, we built integrations between them. APIs. Middleware. Data warehouses. ETL pipelines. Custom applications. Consultants. And thousands of people whose job, in one way or another, was to make different pieces of software work together.

The scale of this is measurable. Salesforce's MuleSoft benchmark counts an average of 897 applications inside a large enterprise, with 71% of them not fully connected to the others. That share has not moved in three years of surveys.

This was not a failure

It was actually one of the greatest productivity revolutions in business history. Software took companies from paper to digital. It standardized processes. It created systems of record. It made information searchable. It made transactions programmable. It allowed companies to operate at a scale that would have been impossible before.

But there was a fundamental constraint hidden inside the model. Every piece of software was built to solve a particular problem. So the enterprise gradually became a collection of optimized pieces. Finance could be optimized. Sales could be optimized. Procurement could be optimized. Manufacturing could be optimized. Customer support could be optimized.

But the business itself was not one of those pieces.

The business lives between the systems

A customer request might begin in CRM, move into email, require a decision from an experienced employee, trigger something in an ERP, require procurement, return to operations, and finally end up back in the CRM. The software captured the transactions. It rarely captured the entire intelligence of the process.

Thomas Davenport documented a case in 1998 where processing a single order took four days and seven handoffs. The actual work inside those four days was about four hours. The rest was waiting, between systems and between people.

So enterprises spent enormous amounts of money trying to connect the pieces. And this created an architectural reality that most people have simply accepted as normal: applications connected by integrations, with humans filling the gaps.

The problem was not that enterprises had too little software. In many cases, they had too much. The problem was that the pieces were never designed to fit perfectly together.

Why the company adapted to the software

And there was a very good reason for that. The economics of traditional software made customization expensive. If a company wanted software built exactly around the way it operated, somebody had to discover the process, translate it into requirements, design it, engineer it, integrate it, test it, deploy it, and maintain it. So the rational economic decision was usually the opposite. Instead of making the software fit the company, the company adapted itself to the software.

That decision shaped enterprise technology for decades. Davenport wrote it down in Harvard Business Review in 1998: with an enterprise system, the sequence reverses. The business must be modified to fit the system. It also created one of the most important rules of enterprise software: don't customize too much. Adapt your processes to the software.

There is a famous example from the ERP era. Lidl tried to adapt SAP to the way it already operated. It kept its own way of valuing inventory, had the software adapted instead of the company, and ultimately abandoned the implementation after seven years and hundreds of millions in reported costs. The lesson became part of enterprise folklore. Don't make the software fit the company. Make the company fit the software.

And for a long time, that was rational. Because customization was expensive.

Until something changed. That is the next part.

Sources

Every link goes to the original source. Figures are quoted with the denominator and the caveat they were published with.

ShareXLinkedIn

Get the next essay by email.

Roughly one every two weeks. No other email, ever. Unsubscribe in one click.

Sipahi Demir

Written by Sipahi Demir. contact@sipahidemir.com