Prosaic Times: What looks like fiscal responsibility can liquidate enterprise technology

Building a model that shows how tech-for-tech investment increases EBITDA lift from technology over time.

When I wrote code for money as a young man, I loved figuring out the core logic and hated sorted out all the error conditions. Also, I found coding UIs annoying. Cursor allowed me to take things I’ve learned about enterprise technology economics and create the logic for a pretty complex model without getting lost in the scutwork. Where should we pushing ourselves to use tools AI now providers to create deeper levels of economic transparency and insight?

Reader correspondence

Heinz-Peter Sebregondi is on the faculty of Karlsruhe Institute of Technology. He writes: Your story about the billing system replacement inspired this slide

The main argument: What looks like fiscal responsibility can liquidate enterprise technology

The takeaway

1. AI makes it much easier to model enterprise technology value and cost

2. The stock of application functionality drives much of your technology cost structure -- application maintenance, hosting, network capacity and cybersecurity

3. AI-enabled software engineering, tech debt remediation and run automation create the opportunity to get much more EBITDA lift out of your enterprise technology budget -- if you can create the political will to invest in them

Did you ever play the beer game in business school? It modeled interactions between factories, distributors, wholesalers and retailers in supplying thirsty customers. You find that even small variations in consumer demand can create large inefficiencies (e.g. stock-outs or inventory surpluses) further up in the supply chain.

Years ago, I used the beer game to illustrate to executives at a financial institution why they suffered from low storage utilization:

• They had created a laborious process to discourage application teams from ordering more storage

• Knowing how long it took to get storage, application teams padded their estimates to ensure they had spare capacity in case they needed it

• Presto -- excess capacity and low storage utilization!

The beer game illustrated that thinking about how stocks and flows interact in dynamic systems that Jay Forrester laid out in Industrial Dynamics as Major Breakthrough for Decision Makers. Forrester dismissed the work of British scientists and military personnel in World War II on operations research as mechanistic. I think that’s a little unfair. A Game of Birds and Wolves described how the Western Approaches Tactical Unit conducted games to simulate the interactions between Allied convoys and the Kriegsmarine U-boats that hunted them. The insights they developed -- and the resulting tactics adopted by the Royal Navy -- ensured secure sea lines of communication between the United States and the British Isles and eventual allied victory. Simulation -- and the insight it provides -- is powerful!

1 . AI makes it much easier to model enterprise technology value and cost

Enterprise technology economics may be lower stakes than the Battle of the Atlantic, but not less complex. Over the decades I have built tech cost models in spreadsheets, SQL, Quantrix and VBA. More times than I care to admit, with the aspiration of mirroring reality, I built something that started to collapse under its own complexity.

I’ve always aspired to demonstrate that companies under-invest in tech for tech investment. Some executives seemed to think «We just want to build cars. Why would we invest in factories? What customer cares how nice our factories are?»

In a few days this week, with no leverage, I used Cursor to build something better than anything I’ve done in the twenty-five years I’ve spent thinking about the issue.

As always cyborgs beat artisans or androids. There is no model that could summon the context I have from crawling around technology organizations since God wore short pants, or at least the Spice Girls were the latest craze. [1] I sweated the logical equations and let Cursor write the Python code for me.

A note: all models are wrong; some are useful. A perfectly accurate map would need to have a 1:1 scale. For the sake of time, I made some simplifying assumptions (that I could make more realistic later on) e.g.

• 100 percent of existing environment is already hosted off-prem (theoretically possible if unlikely)

• 100 percent of applications development in house (less likely)

• Same average wage rate for tech staff (obviously absurd)

2. The stock of application functionality drives much of your technology cost structure

Here were some of the major assumptions

• Stock of story points accumulated over time drives application maintenance labor, application hosting and cybersecurity cost

• Clean story points much less expensive in terms of application maintenance and cybersecurity than debt story points

• EBITDA lift each year depends on business-driven investment adjusted for poor portfolio management, engineering deadweight loss and insufficient user adoption; diminishing marginal returns apply, on the assumption that companies will the build the highest ROI functionality first

• Tech for tech investment uplifts software engineering capacity (reducing deadweight loss), reduces technical debt (by converting debt story points to clear story points) and automating run activities

• Some investment each year is mandatory (e.g. end-of-life, compliance) and yields no measurable economic benefit

• Reducing deadweight loss increases the impact of any given dollar of business-driven investment, but also in tech debt remediation and run automation

3. Cost control? It may liquidate enterprise technology

If you devote all of the discretionary tech investment budget to business-driven initiatives, you enter an IT doom loop: new functionality creates new support requirements; as that consumes more of the tech budget, EBITDA lift decreases over time:

In contrast, diverting even one-fifth of the technology investment budget for a few years creates a virtuous cycle that drives EBITDA lift upward.

A few more notes:

• Yes I will bang on this a lot more to validate it!

• In this scenario, you can maintain clean story points three-times as efficiently as debt ones. Reduce the improvement to twice as good, and you see the increased pace of new development driving up application maintenance costs quickly.

• I suspect I am being quite conservative about the opportunities for run cost reduction -- will play with these assumptions in coming weeks

• Can feed the logic into an LLM to examine sensitivities

• Maybe I will port this onto a graph database to facilitate scenario and what-if analysis

The wire section

LLMs are lagging indicators, Hollis Roberts

• Sometimes an article can make a good point, but totally miss on the implications

• Yes, LLMs are lagging indicators. Necessarily the weight of their training data will be somewhat outdated -- and also somewhat mid, even when you use RAG. One CEO found no end of frustration in that an RAG-based system his team had built kept making recommendations based on outdated protocols rather than documents they uploaded.

• No, that does not mean companies will hire recent graduates because of their familiarity with the most recent cultural developments. Medical clinics, law firms, investment banks, private equity firm don’t hire recent graduates because they understand vibe. They will probably hire lots of recent graduates to ensure the output from agentic systems is right.

The Bitter Lesson of Agent Frameworks, Gregor Zunic

• Yes! And agent is just a loop. Of course you could argue that most software functionality is just a loop or some sort.

• In some ways, Zunic inverts Roberts’ argument, saying that the more you try to add intelligence around model behavior you make it more brittle because the model was trained on millions of examples, representing millions more use cases than you can think of.

• He also acknowledges that agent infrastructure and context management will be important.

• So, I’m sure we will be arguing about heavy-weight versus light-weight agent architectures for years -- but more than anything isn’t an agent a mechanism for managing context?

Which History has Condescended to Notice: Black Testimony in Antebellum Courts, Bob Pasker, CUNY Department of History

• Bob Pasker was one of the four co-founders of WebLogic, which developed the iconic application service -- and now he is getting a Ph.D. in history at CUNY

• Traditionally, historical researchers required academics to review records in dusty libraries. The recent ability to view scanned document on-line reduced toil only a bit.

• Bob has developed Roscoe, «a machine-learning system designed to perform conceptual searches, generate topical classifications, and produce plain-language summaries of nineteenth-century case law»

• I expect we will see massive insights that had previously been locked up in political, legal and corporate documents unearthed in coming years.

Footnotes

[1] In 1998, I went to go lift with my brother. As I finished a set on the bench, the gym sound system announced, “And that was the Spice Girls.”
I said: “You know I had wondered who the Spice Girls were and what they sounded like.”
My brother replied, “Welcome to Planet Earth. I hope you enjoy your visit here.” Not the first or the last time someone has said something like that to me.