Prosaic Times: how enterprise technology will evolve to shape tomorrow’s world

Five optimistic hypotheses crystalized over the break

The theme of these weeks issue? Tomorrow’s world -- how enterprise technology might reshape the companies we work at and the world we live in over the next few years, and how it must change itself.

The main argument provides some hypotheses on the changes we might see. The wire section both touches on how previous generations of technologists built the future and reminds us how much technology innovation contributes to human flourishing.

The main argument: How enterprise technology will evolve to shape tomorrow’s world

---

The takeaway

1. You might spend more on enterprise technology and the CFO should love it. Companies that reinvent their software engineering processes can double throughput, creating incentives for more tech investment as they improve tech ROI.
   What you do about it: Educate your peers on the opportunity to reshape the ROI of technology investments and secure funding to AI-enable enterprise technology
   

2. Third party software will have to be very opinionated or not at all. Improved tech ROI will reduce the penalty for building software in house. You will continue to procure productivity tools and commercial platforms with domain content. SaaS that provides some workflow, a database and UI? Harder to justify.
   What you do about it: Examine your third-party software portfolio to distinguish between the tools and platforms you will bet on and the products that you can replace.
   

3. Your transactions are relational, but your business will be a graph. Semantic layers, manifested in graphs and populated by agents, let you model and optimize value chains in way not previously possible.
   What you do about it: Create a semantic layer to link disparate data sets and build dynamic models of business domains
   

4. Junior knowledge workers will be strats and senior knowledge workers will be Winston Churchill. Early tenure knowledge worker will operate like coders. Senior professionals and executives will command unimaginable leverage in crafting narratives and making decisions. The Jevons Paradox will apply to knowledge work.
   What you do about it: Invest strat journeys and experience, no less than developer journeys and experience -- and play Moneyball for business documents, by creating a DocOps pipeline
   

5. Enterprise technology must run as a platform. Enterprise tech won’t go away, but it must change. It must provide platforms to software engineers, traditional end users and the strats who sit between the two. And it must ruthlessly automate and rationalize its operations and environment.
   What you do about it: Create the technology organizations and environments that will help build tomorrow’s world -- use AI as an catalyst and an opportunity to reinvent enterprise technology no less than any other business domain.

For those of us who grew up in the 1980s, you can divide into the majority who remember the music in terms of Michael Jackson and the tiny minority who think of Joe Jackson. Okay, that’s not true, but too much nuance would diminish the rhetorical zip. [1]

My favorite Joe Jackson track? One of the obscure ones: Tomorrow’s World -- because of its longing for a potential future, which I always thought we might use computers to create. [2]

I didn’t get to go up to Rhode Island and play with my miter saw this break. Matthew’s home from college and Adam will be back from Spain tomorrow, making Amy and me happy to have the litter back in the nest. Both kids wanted to spend the break in New York -- fatherhood implies compromises, but they are good compromises.

So aside from family time (yes, we watched the Stranger Things finale in a movie theater), I spent the break reading, thinking, writing and really getting to know my new Mac laptop (after three decades using Windows as my primary machine). I rebuilt my personal knowledge base in Obsidian, got more comfortable with AppleScript, created a bunch of Raycast macros and tried to use GitHub and Working Copy to synch files from laptop to iPad without violating any security policies.

Based on all this, I developed a few hypotheses on tomorrow’s world: enterprise technology must evolve over the next few years -- and what implications this will have for CIOs and CTOs.

1. You might spend more on enterprise technology, and the CFO should love it

AI-enabled software engineering will reduce the legacy tax, improve ROI for new functionality and, per Jevons Paradox, draw more resources into enterprise technology.

We all know that infrastructure has gotten a lot less expensive since the days of USD 50,000 Unix servers and 10:1 OS image to admin ratios. [3] We all pretty much know that application development and maintenance hasn’t gotten more efficient, because of technical debt, combinatorial complexity across applications and burgeoning non-functional requirements. [4]

We all suspect that at some point in the past decade, software engineering became the rate limited factor not only for enterprise tech, but for business strategies in most corporations. How many new product launches, operational improvements or other strategic initiatives you know of don’t depend on new technology functionality? Back in 2023, some of my McKinsey colleagues demonstrated that, depending on sector, as much as 70 percent of the value in a business transformation might be technology-dependent. These numbers would be higher given the opportunities created by AI and agentic automation.

So why don’t companies just use brute force and hire more software engineers? It doesn’t work. Traditionally, new engineers take a long time to come up to speed on complex corporate environments and, as Fred Brooks pointed out decades ago, coordination costs mean doubling the development team doesn’t double the output.

And yet! We know that vibe coding will create technical debt with terrifying efficiency. And we all know that simply giving engineers AI tools yields single digit productivity improvement.

But: military history teaches that force employment trumps technology adoption by itself -- think Blitzkrieg, not tanks. Doctrine that integrates AI-tooling into a reinvented product development lifecycle may double engineering throughput, as some other close colleagues point out.

This can change everything for enterprise tech, and for business strategy, at least for those companies willing to make the investments (and operational changes) required to reinvent enterprise technology no less than they might aspire to reinvent any other business domain.

• Doubling engineering productivity allows you to retire much more technical debt

• Retiring technical debt both reduces resources required to run the environment (freeing them up to build new functionality) and reduces the “legacy tax” associated with integrating new code with existing systems

• Doubling engineering productivity also reduces the deadweight loss in new development, resulting in more functionality from each dollar invested in new functionality

The result? Much better ROI on technology investments creating incentives for companies to invest more in technology-enabled offerings, digital channels, automating business processes and sophisticated analytics. All taking us close to Tomorrow’s World.

Implications for CIOs/CTOs:

• Educate your peers on the opportunity to reshape the ROI of technology investments

• Secure funding to AI-enable enterprise technology

2. Third party software will have to be very opinionated or not opinionated at all

Enterprises buy third-party software, because software engineering is expensive. Less expensive software engineering will cause enterprises to turn away from vendors who provide generic automation of business processes.

SaaS is expensive, even beyond the license cost. You have to configure it, integrate it with other software you own, manage access rights, monitor it and provide user support. I’ve had many anguished discussions with CIOs, CTOs and CISOs over the years on topics like authentication, data integration and telemetry for different SaaS products.

We also know that SaaS doesn’t always create great user experiences. Different products have different data models that can be hard to integrate. They have different semantic constructs and different interfaces that confuse the heck out of users, especially me. There’s one tool I have to use a few times per year for a purely administrative function. Invariably, I risk putting my fist through the monitor screen as I click through screens looking for the one field I need to update.

Yes, this product is terrible, but it’s structurally terrible. It’s just a UI with a little business logic on top of a more complex-than-you-would-guess database. In the service of economic viability, the vendor has to adopt a one-size-fits-none strategy, gathering requirements from hundreds or thousands of customers that run their own idiosyncratic business processes. McKinsey procures it even though we only use a small fraction of its functionality and it only incompletely fits with what we’re trying to do. Why? In a world where software engineering (and application maintenance) are expensive, who wants to go to the trouble of maintaining a bespoke solution, especially for an administrative process?

Might companies make different decisions if software engineering and maintenance were less expensive? A couple of centuries of economic logic suggest they would. Will it matter? Hell yes, even for administrative processes. As my experience at the Brown Daily Herald taught me, you get big operational improvements when you evolve the business process and the underlying technology together. All of our talk about “core” versus “context” is an artifact of scarce, expensive software engineering. Being able to deploy and maintain automation at a lower cost per unit will allow us to remember how blurry the line between administrative and value-creating processes can be. How many of your customer-facing processes depend on administrative ones?

So we’ll probably see more companies follow Klarna’s lead when it consolidated its data into a knowledge graph, used automation to automate many of its processes using agentic workflows and rationalized 1,200 SaaS applications. Yes, this saved them an undisclosed large amount in license fees, but more importantly it also created a much more integrated set of user experiences.

Going forward, you may see a SaaS marketplace divided into three parts:

• Non-opinionated tools: Software we use to send emails, build spreadsheets and conduct videoconferences isn’t opinionated. The shape of our idiosyncratic business processes has no impact on how we use these tools, and the external marketplace will continue to have an advantage here no matter what improvements we make in software engineering productivity.

• Heavily opinionated platforms: ERP platforms provide not just code, but also content -- do you want to keep track of how legal or regulatory changes might impact how you account for inventory in any one of fifty different countries? Me neither. Lots of software is opinionated. Sometimes, as for many cybersecurity platforms, this means constantly updated content like indications of compromise (IOCs). Sometimes it means development tools, like version control platforms, that have shaped common operational practices around their functionality. Again, improving enterprise software engineering productivity may not have much impact here.

• Unfortunately opinionated products: Many SaaS products have an implied lowest common denominator business process by default that never quite fits with any of their customers needs. More efficient software engineering means companies can replace many of these (vastly improving user experience) economically -- especially since they may only need 10 or 15 percent of the functionality a vendor must support.

Implications for CIOs and CTOs: Examine your third-party software portfolio to distinguish between the tools and platforms you will bet on and the products that you can replace in the service of a lower costs and a better user experience.

3. Your transactions are relational, but your business will be a graph

Martin Campbell-Kelly’s book From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry explains how relational database management systems (RDBMS) grew up in conjunction with Enterprise Resource Planning (ERP) software.

As anyone who has marveled at the elegance of Edgar Codd’s thinking knows, highly normalized relational databases are perfect for storing transactions. They don’t excel at modeling complex dependencies (e.g. among products, offerings, customers, and systems) you see in modern enterprises. How well does the relational schema in the configuration management database (CMDB) map into your real-life technology environment?

Google popularized the idea of the knowledge graph in 2012 with their blog post about Things, Not Strings. Graphs represent business elements like products and customers as nodes and the relationships between them as edges. Graphs are intriguing for several reasons:

• They’re easy to understand -- the schema looks like something a business analyst would draw on a whiteboard

• You don’t have to get the schema right at the beginning and can evolve it over time -- I, for one, have never gotten a database schema right at the beginning

• They interconnect disparate data sets more easily than RDBMS

• The relationship is a first class citizen of the database (and can have properties) -- rather than relying on an inner or outer join

• They make recursive search (e.g. show me all the vendors of my vendors) easy

Last month, Jaya Gupta and Ashu Garg from Foundation Capital won the Enterprise Tech internet with their article: AI’s trillion-dollar opportunity: Context graphs. [5] They argue that a context graph that captures “decision traces” about when you decided to prioritize a requirement or grant a customer discount will allow agentic workflows to function reliably in an enterprise environment. Graphlit CEO Kirk Maple explained what type of context you need. And Player Zero CEO Animesh Koratana makes the case that you can use agents to maintain the ontology required to simulate a technology environment.

Imagine the strategic implications in pushing this idea to its logical conclusion. What if you could use a graph to build a systems dynamic model of your value chain? What if you could model the analysis you might perform and the levers you might apply to optimize that value chain? What if you could deploy agents to capture and correlate telemetry and agents to tweak business decisions? You could replicate the closed-loop optimization that e-commerce giants use at other companies that span the digital and physical domains.

There are some very smart technologists out there who express skepticism about using graphs at scale in the enterprise -- performance limitations and the possibility that graphs may be a detour on the way to world models and comprehensive vector search. I’m still optimistic, even though being definitive here is a sucker’s game

On performance, I try never to bet against Moore’s Law. You know what delayed the adoption of RDBMS? Campbell-Kelly points out that many companies stuck to hierarchical databases for several years because of the processing overhead that RDBMS required. Compute power caught up.

The tradeoff between graphs and vector search is more uncertain. As best I can tell, memory constraints will limit the size of context windows for some time to come -- you always run out of memory and I/O before you run out of GPU. And recent Stanford research seems to indicate that RAG collapses past a certain point because vectors start to act like random noise. In contrast, academic research indicates that combining graphs and vector search reduces hallucination, which has also been my personal experience.

Implications for CIOs and CTOs: Examine the opportunity to create a semantic layer to link disparate data sets, where dynamic models of business domains would create economic value and when you might use agents to capture context and evolve ontologies.

4. Junior knowledge workers will be Strats and senior knowledge workers will be Winston Churchill

Knowledge work will evolve, just as it has with the introduction of written language, moveable type, the rotary printing press and the computer. For junior knowledge workers, the line between programmer and not-a-programmer will get blurry, and senior knowledge workers will get leverage only available to giants of the twentieth century.

We’ve all heard the discourse -- that AGI means we can all sit on our deck in Rhode Island drinking coffee while the machines run the economy for us, that there will be an apocalypse in early tenure hiring. I’ve even offered that college graduates may need to “play their way into” institutions which move form a talent pyramid to a talent column.

My experience using Obsidian and Cursor together refined my thinking a bit here. I chair the Board of Trustees for Brown-RISD Hillel. The organization is a giant social graph of staff, students, alumni, parents and faculty. The dozen disconnected spreadsheets we email around started drove me nuts, so I built the graph in Obsidian over the break. Without Cursor to clean the data (and fix my schema mistakes), I would have thrown up my hands in frustration. But now I can tell Cursor “show me all the parents of active students who live in the NY area.” Power!

In capital markets businesses, the line between “coder” and “banker” gets awfully fuzzy. Strats sit on the trading floor and update models intraday. Bankers who build structured products create incredibly sophisticated models, sometimes in Excel sometimes in more robust tools. In all cases they draw on both technological sophistication and deep market insight. The ability to use Gen-AI based tools to clean data and to provide guidance on building algorithms will create an opportunity for many more people at many more businesses to adopt this (dynamic!) operating model.

In some ways, it could be a return to the past. The 1980s and 1990s were a special time in technology, with users just figuring out how to do stuff. It was simpler then -- who knew what cybersecurity was? Questions for the technology graybeards out there: how many corporate systems can you recall that started out as Clipper databases created by a frustrated user? (For our younger readers...oh, never mind.)

Let’s think about the impact of AI for senior knowledge workers in terms of a question: How did Winston Churchill, a 73 year old man who was also leader of the Conservative Party, assemble the 2 million words in the six volumes of “The Second World War” in seven years? He didn’t, at least not by himself. He built a near-industrial writing process, staffed by a team he called the The Syndicate that collected documents, structured chapters, developed drafts and ensured editorial consistency. Churchill remained the architect, specifying the narrative he wanted. [6]

I could not have attempted Prosaic Times even two years ago -- I have a day job, and I don’t do hot takes, so the research would have killed me. But the ability to use GenAI tools to figure out what data exists to support or disprove a hypothesis or to red-team my thinking makes me feel like Winston Churchill (minus the whole saving Western CIvilization part.)

The result? There are an endless number of things to figure out in this old world, so you get the Jevons Paradox applied to knowledge work.

Implications for CIOs and CTOs:

• Just as you have started to improve developer experience, create a “strat experience” -- how do you create tooling to support knowledge workers who sit at the seam between “coder” and “operator?” Cybersecurity (especially IAM) will be essential here. We need a model that involve less pasting of keys into different web pages.

• Play Moneyball for business documents, by creating a DocOps pipeline

• Build an operating model that uses strat-created data and capabilities as a farm team for enterprise data and capabilities. How do you evaluate things strats create for enterprise applicability? What investments will be required to become enterprise-grade?

5. Enterprise technology must run as a platform

Is any discourse more tiresome than breathless predictions about the demise of IT? Desktop computing, client-server computing, the internet, cloud computing and now AI were all going to eliminate the CIO and put paid to enterprise technology organizations? Has it happened yet?

Enterprise technology is protean -- it has evolved through generations of technology disruption rather than disappeared. Why? Because technology is cheap and easy, and technology at scale, with resiliency, security, performance and compliance is expensive and difficult. Enterprise tech organizations foster the capabilities required for resiliency, security, performance and compliance at scale. But they must evolve, as they have evolved in the past.

A few months ago some colleagues and I published on the six imperatives for enterprise technology in the age of AI -- I think of it as a doctrine for enterprise technology. [7]

• Recalibrate to the new economics of IT – mature product operating models

• Rebuild technology platforms – use AI to reduce technical debt and build AI platforms for scale

• Renovate enterprise data – use AI to improve data quality and built semantic layers to maximize the impact of AI

• Redesign the talent model – build engineering capabilities around human-agent collaboration

• Revamp the vendor equation -- understand where the leverage is and use it

• Remodel risk and resiliency: Use AI for resiliency and build for safe AI at scale

I continue to believe in these imperatives. [5] A few weeks ago I synthesized a bit further to present the basic ideas to a non-technical CEO.

• From: pilots for individual use cases -- to: reimagination of business domains

• From: fragmented, hard-to-trust data -- to: semantic layer that creates meaning from data across domains

• From: bespoke technology stack for each project -- to: reusable platforms, with dedicated funding

• From: manual IT activity -- to: use of GenAI and agentic technology to automate IT no less than any other domain

Without getting too Orwellian, I suspect I could further synthesize this thinking to one word: platform. British computer scientist David Wheeler famously said “All problems in computer science can be solved by another level of indirection,” meaning (more-or-less) abstraction.

Enterprise technology organizations will need to use abstraction to manage a portfolio of platforms for a range of consumers -- their own software engineers, traditional end users and increasingly the “strats” who sit at the seam between a business domain and technology creation. And they need to use flexibility that abstraction creates to automate and rationalize their organization and environment.

Implications for CIOs and CTOs:

• Create the technology organizations and environments that will help build tomorrow’s world: use AI as an catalyst and an opportunity to reinvent enterprise technology no less than any other business domain.

• Prepare your people for the organizational and operational change required

The wire section: what I’m reading, watching and listening to

We Live Like Royalty and Don’t Know It, Charles C. Man, The New Atlantis
I started cooking more during the quarantine in 2020. During the height of the lockdown, I would walk across the street pretty much every day to buy food for a dinner I could cook on my beloved Breville electric grill. One day I stopped and looked around the product aisle and thought to myself: “I’m standing in the middle of fresh vegetables stacked to the ceiling. On a chilly April day. Surrounded by miles and miles of asphalt. In the middle of a pandemic. Modern supply chains are a miracle.” This article thoughtfully highlights the wonders of the modern, global economy. To which I would only add the importance of building and maintaining all those technology systems that keep the world’s supply chains running. The trucks, trains and ships don’t help very much without the systems that direct what they will carry and where they will go.

Why aren’t smart people happier? Adam Mastroianni, Experimental History
I disagree with this piece in so many ways. Happiness not the same thing as meaning and self-worth. Intelligence is not the same thing as wisdom or judgement -- intelligent people do dumb things not because of a lack of smarts, but because we’re all primates who wear business casual and sometimes make emotional decisions. But it has one paragraph I love:

“If you booted up a super-smart AI in ancient Greece, fed it all human knowledge, and asked it how to land on the moon, it would respond ‘You can’t land on the moon. The moon is a god floating in the sky.’ How would you get it to realize the moon is actually a big rock? That’s a great, poorly defined problem, and I don’t expect AI to solve it anytime soon.”

That’s why I think the Jevons Paradox applies to human endeavor (including knowledge work). We always see things and want to do things not in the training data!

From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry, Martin Campbell-Kelly
Finally finished it, after a few weeks. The last few chapters were less insightful than the earlier ones because the “Rise of the Valley” has been told many times previously. Interested in that story? Read Accidental Empires by Robert X. Cringley and Fire in the Valley by Paul Freiberger and Michael Swaine. From Campbell-Kelly, a few indications of how far we have come:

• MS-DOS 1.0 contained only 4,000 lines of code

• By the 1980s more than 300,000 programmers held jobs developing applications for CICS.
  Given enough time, the world does change!

Footnotes

[1] Probably not the right forum to map out the U2 fanatics at Northern Valley Regional High School - Old Tappan from the Rolling Stones fans from the guys in M-C jackets and Bon Jovi tour shirts. And that’s without getting into the puzzling nexus between hair mousse and the New Order.

The album Night & Day was a gateway drug for the Great American Songbook. The songs Steppin’ Out and Breaking Us in Two hinted to me that there might be more sophistication in the world than could be found at Nanuet Mall.

[2] Joe Jackson drew inspiration from the song from the BBC’s long running show of the same name. And that program drew inspiration from Prime Minister Harold Wilson’s speech on the “white heat of techology.” Techno-optimistic is essential, but not novel.

[3] In 2000, a new Sun server could run to tens of thousands of dollars. A Sun Enterprise 450 server with one 300MHz UltraSparc chip and 512Mb RAM listed for USD 17,235, or about USD 34,000 in current dollars. Richer configurations could triple or quadruple that price. More expensive models could cost ten times as much. Often to run one application. And a single sys admin (sometimes paid USD 100,000 or more) might manage 10 or 15 servers.

Since then we’ve not only surfed Moore’s Law, but also consolidated data centers, moved support activities to low-cost locations, used x86 CPUs, gotten in Linux, adopted first virtualization then containers and migrated to the cloud -- and infrastructure costs have plummeted. (If anyone wonders where I was 2001-2012, other than raising children, now you know.) Even the smallest cloud instance that would cost about USD 100 per year has two orders of magnitude more processing power.

Comparing historical and modern performance is inexact, but fun. In 2000, the Standard Performance Evaluation Corporation (SPEC) selected a 300 MHz UltraSPARC-II system as their “reference machine,” with a baseline score of 100. A Great Financial Crisis-era single CPU server (based on a Xeon 5160) would have had 30 times the performance of an E450. A modern cloud instance would have three-four times the performance of a GFC era server, according to Geekbench analysis.

Sys admins in the financial services, retail and manufacturing sectors now manage 50-500 server images. Many of these people are off-shore -- you don’t see many sys admins making hundreds of thousands of dollars per year in banks today.

[4] QSM research found that function points per developer hour decreased between 2000 and 2010

[5] The Enterprise Tech internet may not be as big as, say, Swiftie Twitter, but it’s home.

[6] He expected history would be kind to him because “I propose to write that history myself.”

[7] Just to be clear: the alliteration was not my idea.