Why enterprise technology is so bloody difficult

From October 2025

Why is it so hard for established companies to get enterprise technology right? The answer is structural – there are a set of factors inherent to automating business processes that make the economics tricky.

Estimating ROI is a guess. Imagine this hypothetical, but likely all too real scenario, from a few decades back. The CEO of a cable multiple systems operator (MSO) confronts his CIO about the coming year’s budget projections.

“Why can’t you get project estimations right?” the CEO thundered. He continues: “When we build a headend, I know exactly how much it will cost and how much revenue it will generate. But investment estimates for your CRM platform have a range of tens of millions of dollars. And you admit the calculation of benefits is pretty much a guess!”

The benefits of a new headend in a neighborhood were simple to calculate. Each installed box could serve a known number of households. It provided new services for a set cost per month. The MSO had good data about expected take rates for new cable subscribers — do the multiplication. In contrast, the MSO had never built a CRM system before. It didn’t know what offering the data collected in the platform would inspire, or what the take rate would be. The costs for a new head-end were equally simple. The MSO had a bill of materials they had used many times before and regularly set prices with their vendors. In contrast, the time and effort required to set up and integrate a CRM platform with dozens of the companies’ legacy systems? A guess.

Capturing value requires magic. The MSO would not derive any value from the CRM system itself, but from behavior change among dozens of marketers, hundreds of salespeople, and thousands of call center representatives. It would have to make a bet that some people would enter accurate data into the system, that other people would use that data to formulate insights, and that still other people would apply those insights in thousands of customer interactions each day. Like any other new system, the CRM platform would need to interact with organizational dynamics in non-linear and unpredictable ways to improve business performance. No wonder the CEO didn’t like the bet!

Business complexity is immense and dynamic. Back in 2010, New York City faced a scandal over CityTime, its attempt to create a single system to track employee timecards across dozens of agencies. It had spent more than half a billion dollars, with little to show for it. How could the city spend that much money on a time tracking system? Sure, it didn’t seem complex—until you realize that the file cabinets holding all the contracts the system needed to incorporate filled an entire floor in a downtown office building. (Smerd, Jeremy, “Clocking CityTime, the craziest contract ever,” Crain’s New York Business, June 13, 2020) The terms and conditions about vacation, overtime, seniority, and dozens of other issues across 85 different bargaining units recognized by the city’s Board of Certification represented millions of business rules that CityTime developers would have needed to implement and validate.

The Cable MSO described above pretty much built all of its head-ends the same way. In contrast, the business variation enterprise technology teams must build into systems s immense. The telecom carrier that eventually acquired the MSO would have faced hundreds of products, thousands of pricing plans, thousands of vendor arrangements, and thousands of contracts with corporate customers — all frequently changing and all of which its systems must support in order to keep the business running every day.

Automation is brittle. Wizened old architects like to tell each other that a system is just an automated process—you just need to anticipate every idiosyncrasy in the process to automate it. Developers love the “happy path,” with normal and expected conditions and easily predicted user behavior. (Shah, Darshit, “What is the difference between happy path testing and normal testing,” Medium, November 25, 2023) Wizened old architects know that the happy path is by no means the only path: users do unexpected things, enter invalid data, or have unusual requests — sometimes reacting to business conditions that have changed radically since they described their requirements to developers. This means that most automated systems are ”brittle,” or prone to failure when encountering even minor changes. These systems lack resilience, requiring frequent and costly maintenance to keep them running.

In 1975, Fred Brooks explained in his book “The Mythical Man-Month” that developers cannot plan for every edge case because complexity grows exponentially with more features and scope. What happens when developers fail to implement an edge case? Either the system crashes or the process breaks. This is why robotic process automation (RPA) failed. It just could not reflect all the twists and turns user journeys might follow. (Brooks, Fred, The Mythical Man-Month, Addison-Wesley Professional, 1995) To date— there has been no shortcut emerged for enterprise software development. Anticipating, modeling, implementing unhappy paths often consumes more than half the effort in a software project. (Brooks, Fred, The Mythical Man-Month, Addison-Wesley Professional, 1995)

Resiliency is essential and expensive. A senior technologist at one of North America’s largest health networks observed that clinicians could fall back to clipboards for a few days in providing care as recently as 2010. It would be inefficient and unsustainable, but everyone would receive treatment. By 2015, hospitals at the network so depended on computerized physician order entry (CPOE) and electronic health records (EHR) systems that outages of even more than a few hours would be devastating for patient care.

Wizened old architects know that systems can be cheap, but only if you don’t need scalability, security, resiliency and compliance. In reality, resiliency is hard. Companies must devote time and resources to scale architectures, conduct extensive testing, ensure high availability, and implement cybersecurity controls and disaster recovery fallbacks. For cloud-based systems, high availability can increase both up-front development and ongoing infrastructure costs by 20-30 percent. (Gartner Magic Quadrant for Cloud Infrastructure Service providers

)