What the Builders Know
The first two essays in this sequence spoke to the people who buy and operate enterprise software. This one speaks to the people who build it, and to those positioned to describe the building in public.
Part I: The Shape of the Discourse
1. Who Is Speaking
Spend a month reading everything the enterprise software industry produces about itself. Read the Gartner Magic Quadrants and the Forrester Waves. Read Constellation Research, IDC, Ventana, ISG. Read Diginomica, ERP Today, CIO.com, TechTarget. Watch the keynotes from SAP Sapphire, Oracle CloudWorld, Microsoft Ignite, Workday Rising, Salesforce Dreamforce. Scroll the LinkedIn commentary that follows a major product announcement. Attend three analyst briefings and two partner-channel webinars. Read the Reddit threads in r/SAP and r/Oracle. Read the ten most-shared think pieces of the quarter on “the future of ERP” and “the AI-ready enterprise.”
Catalogue who is speaking. The speakers are, in overwhelming majority, vendor executives, vendor marketing, vendor product management, implementation consultants, channel partners, industry analysts whose research is funded by the vendors they cover, and a long tail of commentators whose professional position is downstream of the commercial layer’s continued health. These voices perform real and necessary work. They translate capability into language that buyers can act on. They identify the commercial differentiators that distinguish one platform from another. They narrate the quarterly rhythm of the industry in a way that allows the industry to coordinate around its next move. That work is legitimate, and this essay is not a complaint about it.
The complaint is about what is missing. The people who designed the systems under discussion — the engineers, data architects, transaction modelers, schema designers, integration architects, database specialists, and domain experts who made the decisions that actually determine how the system behaves — are almost entirely absent from the public conversation that describes those systems. They did the work. Their decisions are the load-bearing intellectual content of every product the commercial layer is selling. They will be responsible for whatever evolution the product is or is not capable of over the next decade. And they do not speak.
This is not a small absence. It is the defining feature of the field’s public discourse, and it is the reason the dysfunction the previous two essays described has been allowed to persist through a period in which any comparably-sized field would have self-corrected. The Cost of Convenience described how the debt was accumulated. What We Take to the Moon described what the debt is now costing and what it will cost at scales that are not forgiving. This essay describes the mechanism by which both of those prior arguments have remained invisible to the organizations that needed them most: the layer of the conversation at which they could have been said plainly has, for thirty years, been silent.
2. What a Stratified Conversation Looks Like
In a healthy technical field the public conversation stratifies, and the stratification is the feature that lets the field diagnose itself.
Practitioners talk to each other about implementation, at implementation’s level of detail. Architects talk in public about design trade-offs at a level above implementation, producing the body of writing and talks that practitioners reach for when they hit the edges of their tools. Researchers and theorists talk about the abstractions that underlie both, producing the papers that define what the field knows. Analysts and commercial voices translate the outputs of these layers into language that buyers and operators can use.
Each layer informs and corrects the others. When a commercial claim drifts too far from what the architectural layer knows to be true, the architectural layer pushes back in writing the commercial layer has to respond to, and the claim is either refined or retired. The conversation stays anchored because the deeper layers are present and audible. Category terms have to be defended at technical depth or they become unusable. Product claims have to be defended at technical depth or they become embarrassing to repeat. The discipline of the stratified conversation is the mechanism by which a field collectively decides what is real.
The enterprise software field does not stratify in this way. The commercial tier is loud, continuous, and well-resourced. The architectural and engineering tiers are effectively silent in public. There are exceptions, and they deserve to be named. The Kimball Group’s body of dimensional-modeling writing, of which the 2010 critique cited in The Cost of Convenience is one example, has been a small architectural voice inside the discourse for decades [1]. Martin Kleppmann’s Designing Data-Intensive Applications, while not focused on enterprise software specifically, is the closest thing the field has to a foundational architectural text that practitioners reach for [2]. Chad Sanderson’s data-contracts writing and Benn Stancil’s commentary on modern data infrastructure have, over the last five years, produced something that is beginning to look like a practitioner-led architectural voice, though their readership comes largely from the data-engineering community rather than the enterprise-software buyer ecosystem [3, 4]. A handful of database researchers — Michael Stonebraker, Pat Helland, C. J. Date — have written carefully about issues adjacent to the enterprise problem for decades. These exceptions are precious. They are also few enough to be named exhaustively in a paragraph, which is the indictment.
The discourse that actually shapes procurement, implementation, and industry narrative in enterprise software runs through the commercial tier, and the tier below it — where the systems actually live — does not speak. The silence is the subject of this essay, because the silence is the mechanism by which the discourse has been unable to diagnose, for thirty years, the problems that the people inside the silence have understood in detail the entire time.
Part II: The Transformation That Happened Elsewhere
3. Infrastructure Software, 2004–2015
To see clearly what enterprise software has not done, it is useful to look at the adjacent field that did.
Twenty years ago, the public discourse of infrastructure software looked very similar to the public discourse of enterprise software today. Databases, operating systems, networking equipment, and the storage industry were described primarily through vendor marketing, analyst reports, and trade press. The engineers at Oracle, Microsoft, IBM, EMC, NetApp, Cisco, and Sun did not write publicly under their own names. The technical detail of how their products were built was classified as competitive information. Buyers evaluated systems through RFPs and Magic Quadrants. The architectural tier, insofar as it existed in public, was the academic database-research community, which was largely disconnected from the industry’s procurement conversation.
The transformation began in October 2004, when Jeffrey Dean and Sanjay Ghemawat published “MapReduce: Simplified Data Processing on Large Clusters” at OSDI [5]. The paper was short, readable, and described a specific technical mechanism in enough detail that an engineer at another company could reason about it. It was followed in 2006 by “Bigtable: A Distributed Storage System for Structured Data” [6], in 2007 by Amazon’s “Dynamo: Amazon’s Highly Available Key-value Store” [7], in 2010 by Google’s Dremel paper, in 2012 by Spanner, and by a cascade of similar publications from Facebook, Microsoft, LinkedIn, Netflix, Twitter, and a dozen smaller companies whose engineers had decided that publishing was part of what they did.
What was happening was that large technology companies, in a handful of carefully-chosen moments, decided to have their senior engineers write papers about how their systems worked, under their names, with enough technical specificity that the papers could be read and argued with by engineers elsewhere. The papers were not exhaustive. They revealed what the companies wanted revealed and protected what the companies wanted protected. They were substantive enough, nonetheless, to constitute real architectural content, and they produced a body of public literature against which the commercial claims of infrastructure vendors could, for the first time, be evaluated technically.
The second element of the transformation was the engineering blog. Sometime between 2007 and 2012, the practice of maintaining a company engineering blog, written by engineers under their own names, with substantive technical content reviewed lightly rather than sanded to the marketing layer, became standard at serious infrastructure companies. The AWS blog, the Netflix Tech Blog, the Airbnb Engineering blog, the Stripe Engineering blog, the High Scalability community — these were not marketing. They were engineers describing, in public, what they had learned. The aggregation of that writing, read daily by practitioners across the industry, became the architectural tier of a newly-stratified public conversation.
The third element was the public postmortem. When Amazon S3 experienced the 2017 outage, the postmortem Amazon published [8] described what had happened at a level of specificity — a command was typed incorrectly during a debugging operation, a subsystem was taken offline, a dependency that was supposed to tolerate the loss did not — that would have been unthinkable for any enterprise-software vendor to release about a major incident. The postmortem was read, was taken seriously, was adopted as a model by other companies, and became part of a shared practice. Google published the SRE book in 2016, based on a decade of internal practice around exactly this kind of public and semi-public technical writing [9]. Gremlin, PagerDuty, and Honeycomb built businesses partly on the assumption that this culture of public technical honesty was now the default in infrastructure software.
The fourth element was the shift in vendor behavior. Sometime between 2012 and 2018, the major cloud infrastructure vendors — AWS, Google Cloud, Microsoft Azure — realized that publishing substantive engineering content under their engineers’ names was good for them. Snowflake, Databricks, MongoDB, Confluent, Cockroach Labs, Stripe, HashiCorp, and a long list of newer infrastructure companies were explicitly founded with public engineering contribution as part of their commercial strategy. A vendor whose engineers wrote well in public, whose papers were cited, whose postmortems were studied, had a credibility advantage in buyer decisions that the old generation of vendors did not have. The incentive had flipped. Silence, which had been the commercial default, became a competitive liability.
By 2020, the transformation was complete. The public discourse of infrastructure software is now stratified. Engineers at every serious infrastructure vendor publish under their own names. Papers, conference talks, blog posts, postmortems, and books form a continuous architectural layer. Commercial claims are evaluated against this layer in real time. The analyst tier still exists, but its relative weight in the discourse has declined; its function has been absorbed by the practitioners who read and write the architectural tier directly.
Three things are worth observing about this transformation. The first is that it took roughly a decade, not a generation. The second is that it was unevenly adopted — the first movers benefited asymmetrically, and the late movers were forced to catch up by the market rather than by their own instincts. The third is that, at the moment it began in 2004, nothing about the incentive structure of infrastructure software had suggested that it was about to happen. The transformation was not determined by the economics. It was initiated by a small number of specific decisions at specific companies, and the economics caught up.
4. What Made It Possible
The infrastructure transformation had three structural preconditions, and it is worth naming them precisely because they map directly onto the question of why enterprise software has not made the same transition.
The first precondition was that the engineers and architects at the companies producing the systems were permitted — and, in the critical early cases, encouraged — to write publicly under their own names, with enough technical specificity to constitute architectural content. This required a deliberate decision at the institutional level. The MapReduce paper did not leak out of Google; it was published because Google’s leadership decided that publishing it was in Google’s interest. The Amazon S3 postmortem was not a response to regulatory pressure; it was released because Amazon’s operational culture treated transparency as a load-bearing commitment. These decisions were, in each case, costly in specific ways — they gave away information competitors could use, they exposed the company to technical criticism, they required review processes that consumed engineering time — and the companies made them anyway, because they had concluded that the long-term returns exceeded the short-term costs.
The second precondition was the presence of a readership capable of evaluating what was being written. The engineers at Google who wrote MapReduce could assume an audience of engineers at Facebook, Microsoft, and elsewhere who would read the paper, reason about it technically, and push back where the argument was thin. The engineering blogs produced a readership that the papers helped calibrate. The academic database community, which had been producing this kind of readership for decades, provided a model and a reservoir of people who already knew how to read architectural writing carefully. The readership was not built in a day, but the preconditions for it existed, and the arrival of public writing allowed the readership to form and sustain itself.
The third precondition was the competitive advantage of participation. Once a handful of vendors had established that public engineering writing was possible and valuable, the vendors who did not participate were visibly disadvantaged in buyer decisions. Practitioner-led procurement, which became dominant in infrastructure software in the 2010s, rewarded vendors whose architectural positioning could be evaluated directly by the buying engineers. Vendors whose only signal was marketing and analyst coverage lost deals to vendors whose engineers had been writing publicly for years. The silence became, over time, evidence of absence rather than evidence of discretion.
All three preconditions are absent in enterprise software. Each is absent for specific structural reasons. The next section describes why.
Part III: Why the Same Transformation Has Not Happened
5. Three Institutional Silences
The architectural knowledge of the enterprise software field exists. It exists, in considerable volume, in the heads of the people who designed the systems, implemented them, operated them, and migrated them. What is absent is not the knowledge. What is absent is the writing. And the writing is absent for three specific institutional reasons, each rooted in a different part of the field’s structure, and all three of which reinforce each other.
The first silence is vendor silence. ERP and enterprise-software vendors classify architectural detail as competitive information. The decisions that SAP, Oracle, Workday, Infor, Epicor, IFS, NetSuite, and their peers have made about how their schemas represent a customer, how their transaction logs propagate state, how their customization frameworks interact with their upgrade paths — these are treated as proprietary, not because the decisions are genuinely novel, but because the vendor’s commercial position depends on buyers not being able to compare products at that level.
The engineers who made the decisions are generally not permitted to discuss them publicly. When they are, the permission arrives with marketing review, which sands the writing down to the level of the commercial tier by the time it is published. The rare exception — a senior engineer at a major vendor who publishes a substantive technical post under their own name, usually near retirement, usually with tacit rather than explicit approval — proves the rule. The vendors’ engineering blogs, where they exist, publish case studies and integration tutorials rather than architectural discussions. The vendor conferences feature sessions led by product managers and solution architects, not by the database engineers and schema designers who would actually know. The silence is deliberate, it is enforced, and its purpose is to prevent the kind of cross-vendor technical comparison that would erode the pricing power the commercial tier currently enjoys.
The second silence is consulting silence. Deloitte, Accenture, IBM, Capgemini, KPMG, PwC, and the long tail of SAP, Oracle, and Workday implementation partners have strong incentives to keep architectural knowledge inside the firm. The consulting economy that The Cost of Convenience described — the one that grew to a three-to-five-times multiple of license revenue on the back of customization work — depends on the information asymmetry between the firm and the client. A consultant who publishes the cross-engagement patterns they have observed is publishing away the firm’s competitive position. The firms understand this clearly and structure their employment agreements, publication policies, and knowledge-management practices accordingly. Partners are permitted to publish thought leadership, which is sanded to the marketing layer and rarely contains technical specificity. Senior architects at the firms are permitted to publish internally, where the knowledge stays. Junior consultants are permitted not to publish at all.
The result is that the best-informed architectural observers in the field, the people who have seen fifty ERP implementations and can describe what actually happens versus what is sold, are by institutional design the ones least able to write publicly. The occasional exception — a partner-track architect who negotiates sanction for a book, a senior consultant who writes a personal blog under their own name, a retired principal who publishes memoirs — is individually valuable and collectively insufficient. The firms have produced, across decades, almost no public architectural writing about enterprise software commensurate with what they know, and this is not a failure of their writers. It is a structural feature of how the firms capture value.
The third silence is customer silence. In-house architects at enterprise customers are bound by a different mechanism, and in some ways the most restrictive of the three. The specific details of how an enterprise’s SAP or Oracle instance has been customized, the pathologies that have accumulated, the ways in which the vendor’s promises have or have not held up in practice — these are classified as confidential both by custom and by employment agreement. An architect at a Fortune 500 manufacturer cannot write publicly about how their company’s master data is actually structured without violating their employment terms, because that description would reveal operational detail the company considers sensitive, and because the vendor may object to any public characterization of how its product has performed.
Customer architects can write anonymously, and some do. Anonymous writing does not aggregate into a body of work that carries reputational weight, does not produce a citable architectural literature, and cannot be defended when it is challenged. It is better than silence, and it is not sufficient. The people best positioned to describe how enterprise systems actually behave in production are the people least able to attach their names to the description, and the writing that does exist, because it is largely anonymous, does not accumulate into the kind of public corpus that changes what the field can reason about.
A fourth silence is worth naming briefly, though it is more a function of the other three than a structural silence of its own. Academic database researchers have, for most of the last four decades, focused on the problems their field considered theoretically interesting — query optimization, concurrency control, distributed consensus, streaming systems — rather than on the problems the enterprise software industry was producing. The academic and industry conversations have run on parallel tracks, with only occasional contact. Academic work that engaged with enterprise-software realities would have been hard to publish in top venues; enterprise-software practitioners who wanted to engage with academic work found the vocabulary, pacing, and abstraction level unreadable for their operational context. The bridge between the two communities has been thin and has not reliably transmitted correction in either direction. The academic tier exists, but it has not, in this domain, done the work that equivalent tiers do in other fields.
6. What the Silence Is Worth
It is worth being honest about whose interests the silence serves, because the honesty is a precondition for understanding why the silence will not dissolve on its own.
A stratified conversation in enterprise software — one in which vendor engineers could describe the trade-offs baked into their data models, customer architects could describe the pathologies they have observed in production, and consulting-firm architects could describe the patterns they have seen across engagements — would be structurally catastrophic for the commercial tier’s current operating model. It would make comparable claims across vendors possible, which would collapse the premium that vendors charge for products that sound different in marketing and behave identically in operation. It would expose the gap between what was promised at sale and what was delivered at go-live, which would restructure the economics of implementation. It would produce a body of public architectural criticism against which vendor product decisions would have to defend themselves, which would shift the balance of power in the procurement cycle away from the commercial tier and toward the technical tier that, in most enterprise buying decisions, has traditionally been denied purchasing authority.
The commercial tier understands this, in the same way the protagonists of any extraction-based market understand the preconditions for their extraction. The silence of the architectural tier is not an accident of culture. It is a precondition of the current commercial model, and the institutional structures that enforce it — NDAs, non-disparagement clauses, marketing review, competitive-information classifications, partnership-program speech restrictions, customer reference-program contractual limits — are the mechanisms through which the precondition is maintained. This is the point at which Cory Doctorow’s framework, cited in What We Take to the Moon, becomes precise rather than metaphorical [10]. The silence is not incidental to the extraction; the silence is the mechanism that makes the extraction possible. A tier that cannot speak cannot correct, and a market in which the correcting tier cannot speak is a market in which the commercial tier can charge for the absence of correction.
The valuation of that silence is not hard to estimate. The gap between the cost of an enterprise-software implementation as sold and as actually delivered, across the industry, has been well-documented by Panorama Consulting, Gartner, and a decade of academic studies of ERP project outcomes [11]. The standing gap is, depending on how it is measured, something between 30% and 300% of the original contract value, distributed across cost overruns, timeline overruns, and functionality shortfalls. Part of that gap is irreducible project risk; part of it is honest learning that could not have been anticipated. A substantial portion of it is the cost of information asymmetry that a stratified architectural conversation would have closed. Across the installed base of enterprise software globally, that portion represents hundreds of billions of dollars per year of commercial value that the silence defends. That valuation is why the silence has been maintained with such consistency across so many institutions for so long.
7. What the Discourse Cannot Do Without the Architectural Tier
A conversation composed only of one tier cannot do what a stratified conversation does, and it is worth being specific about the capabilities the enterprise software discourse has been missing.
It cannot diagnose its own premises. The arguments made in The Cost of Convenience — that thirty years of extensible custom fields have produced a data-model debt that cannot be refinanced, that the commercial tier’s incentive structure is specifically aligned against the properties that would make a canonical model work — are not novel observations. Every serious data architect at every major ERP customer has thought some version of them. The arguments have been available, in the private thoughts of the people who would know, for decades. They have not been public because the tier at which they can be made is silent. And because they have not been public, the field has been unable to operate as if they were true. Premises that cannot be examined cannot be revised.
It cannot evaluate competing solutions on their merits. When SAP, Oracle, and the major ERP alternatives describe their approaches to the same problem — master data management, integration, AI-readiness, migration tooling — there is no architectural tier capable of evaluating the descriptions side-by-side. The comparisons that do exist are produced by analysts, whose work product is shaped by the vendors they cover, or by consulting firms, whose incentives are downstream of implementation revenue, or by buyers, whose internal reviews are confidential. A buyer deciding between platforms has access to vendor claims, analyst summaries of vendor claims, and anecdotal experience from peers. None of these is the architectural comparison that a stratified discourse would produce, and the absence of that comparison is a significant part of why enterprise software procurement decisions have such a high variance of outcome.
It cannot distinguish a substantive advance from a repositioning. The category-level claims that define the annual industry vocabulary — composable ERP, intelligent ERP, agentic ERP, AI-ready data, data mesh, data fabric, unified data platform — cycle through the discourse at a rate that has no architectural discipline behind it. A vendor introduces a term, the analysts adopt it, the trade press picks it up, implementations are scoped around it, and three to five years later it is retired in favor of a successor term that describes mostly the same underlying capability with different marketing packaging. A stratified discourse would have evaluated each of these terms at the level of the schema, the transaction, and the semantic model, and would have either refined them into specific architectural commitments or retired them immediately. The cycle time from buzzword to correction, which currently runs at five to ten years per term, would drop to months. The commercial tier understands this and structures its output accordingly; the absence of correction is the product, not a bug.
It cannot frame architectural crises as architectural. The substrate crisis that What We Take to the Moon described — the inability of most enterprises to maintain coherent definitions of customers, products, or obligations across their own systems, and the consequent gating of AI, analytics, and migration outcomes on the quality of that underlying substrate — is fundamentally architectural. In the current discourse, it is framed as a governance problem, a change-management problem, a culture problem, a data-literacy problem, an AI-readiness problem. Each of these framings has some partial truth. None of them is the architectural frame, because the architectural frame requires the architectural tier to speak, and the architectural tier is silent. The crisis is therefore discussed in vocabularies that do not reach the level at which it exists, which means the solutions proposed — more governance, more training, more tools, more AI — address the symptoms rather than the cause. This is not because the people proposing them are unserious. It is because they are operating with the vocabulary the discourse makes available, and the discourse, absent the architectural tier, does not make the correct vocabulary available.
The accumulated effect of these four incapacities is what the enterprise software industry currently is. It is a field that describes its own surface with fluency, and that has been unable, for thirty years, to diagnose the structural problems under the surface, because the tier at which diagnosis would be possible has not been present in the discourse. This is the mechanism by which the dysfunction persists. It is not persistence by inertia. It is persistence by design.
Part IV: What Changes
8. The Individual Decision
The institutional structures that produce the silence are not going to dissolve on their own. The NDAs will continue to be signed. The non-disparagement clauses will continue to be enforced. The consulting firms will continue to classify their architectural knowledge as billable methodology. The customer organizations will continue to treat their implementation reality as confidential. These structures serve the interests of the people who maintain them, and they will be maintained until the equilibrium shifts.
The equilibrium shifts, in every field where it has shifted, through the accumulated action of individuals who decide to publish despite the structures. The infrastructure-software transformation described in Part II was not the product of a centralized decision. It was the product of a small number of engineers at a small number of companies who decided, in specific moments, that the writing was worth doing and who then did it. Jeff Dean did not require the entire Google organization to rearchitect its publication policy before he wrote the MapReduce paper. He wrote it, and the paper existed, and the field had to respond. Amazon did not reform its entire culture before publishing the S3 postmortem. It published the postmortem, and the postmortem became a model, and the culture adjusted to accommodate it. Werner Vogels, James Hamilton, Kelsey Hightower, Charity Majors, Martin Kleppmann, and a few hundred other people at the edges of infrastructure software decided, one piece of writing at a time, under their own names, to say what they knew. The accumulation of their work is what the stratified discourse of modern infrastructure software is built out of.
The enterprise software field has the same possibility available to it. The decision is individual. The structures can be navigated. The professional standing that makes it possible to navigate them can be built. If you are an engineer at an ERP vendor, your trade-offs are worth writing about, and the professional cost of writing about them responsibly is lower than the institutional structures around you have taught you to assume. If you are an architect at a customer organization, your production reality is worth describing, and the standing to describe it can be built deliberately over the course of years. If you are a consultant, your cross-engagement patterns are worth publishing at a level of abstraction that respects your clients’ confidentiality, and doing so will differentiate your practice in a market where most of your competitors are committed to saying nothing. If you are an academic, the applied problems the enterprise software industry has produced are among the most interesting in your discipline, and the field’s unwillingness to engage with them is a research opportunity rather than a disqualifier.
The writing does not have to be definitive. It does not have to be a book. It has to be honest about the architectural reality you have observed, technically specific enough that a peer can evaluate it, and willing to name what is working and what is not in terms that the commercial tier cannot absorb into its own vocabulary. A few hundred people producing that kind of writing, consistently, over a decade, would change the discourse. A few dozen people producing it over the next three years, as the 2027 migration wave forces the substrate problem into the open, would change the trajectory of what the industry does next.
9. The Window
The next three years are the window. The substrate crisis that What We Take to the Moon described is about to surface in executive boardrooms whose previous relationship to the architectural tier has been to ignore it. The AI pilot failure rate that MIT has documented [12] is about to translate into a set of corporate decisions that will require some account of why the pilots failed. The SAP ECC migration deadline at the end of 2027 will force, for every company that goes through it, a public or semi-public explanation of what is being inherited and what is being left behind. In each of these cases, the organizations making the decisions are going to reach for whatever architectural commentary is available, and they will make their decisions in whatever vocabulary that commentary provides.
If the only commentary available in that moment is produced by the commercial tier — by the vendors whose migration paths are being evaluated, by the consulting firms whose engagements are being scoped, by the analysts whose research is funded by the vendors they cover — then the decisions will be made in the commercial tier’s vocabulary, and they will produce the outcomes the commercial tier’s vocabulary has always produced. The three-to-five-times budget overruns. The eighteen-to-thirty-six-month timeline slips. The arrival at the new system with most of the old system’s data pathologies intact. The AI roadmap that continues to be optimistic by a factor nobody has quantified because nobody has written down what the substrate actually is.
The organizations that survive the next three years well will be the ones that had access, at the moment of decision, to a layer of architectural commentary that the commercial tier does not control. That layer does not yet exist in the volume it needs to exist in. It can be built. The people who build it will be the ones whose work the next generation of enterprise software is built on, and whose professional reputation will be, a decade from now, the reputation of having spoken when it mattered.
This is the stake of the moment. Not whether the enterprise software industry can be improved in the abstract. Not whether a better vocabulary would produce better outcomes over some indefinite future. Whether, in the specific window between now and the 2027 migration deadline, enough architectural commentary can be produced, in public, under the names of people who can defend it, to shift what is possible for the organizations that will make architectural decisions in that window.
The engineers know. The architects know. The consultants know. The academics know. What is missing is the writing. The writing is produced, in every field that produces it, by individuals who decide that the silence has gone on long enough and who then say what they know. There is no other mechanism. There has never been another mechanism. The silence ends, if it ends, the way every silence of its kind has ended: one person at a time, publishing one piece at a time, under their own name, saying what the room has known and not said.
This essay is one of those pieces. It is not the most important one. The most important one is the one you write next.
This is the third essay in a sequence. “The Cost of Convenience” describes how thirty years of convenience-first architectural decisions produced the current enterprise data crisis. “What We Take to the Moon” describes why the substrate those decisions produced is now a civilizational rather than a quarterly concern. This essay describes why the diagnosis has taken so long to surface and what it will take for the diagnosis to become action. Subscribe for the rest of the sequence.
About the author. Chris Gaither spent fifteen years in manufacturing operations before founding Mimir Labs, where he and his team build the tools referenced in the prescriptive sections of this series: a deterministic, vendor-neutral governance platform (Ratatosk) for the semantic audit, a migration engine (Ragnarok) for when the audit results justify movement, a canonical reference model (Mimisbrunnr) as the neutral vocabulary everything maps to, and an integration layer (Bifrost) for ongoing interoperability. Reach him at [email protected] or learn more at mimirlabs.net.
Sources
Kimball Group, “Industry Standard Data Models Fall Short,” September 2010. Sharp practitioner critique of vendor-supplied canonical models; cited also in The Cost of Convenience and What We Take to the Moon. ↩︎
Martin Kleppmann, Designing Data-Intensive Applications (O’Reilly, 2017). Second edition in preparation. Author site: martin.kleppmann.com. ↩︎
Chad Sanderson’s data-contracts writing is accessible through his Substack and at datacontract.com. ↩︎
Benn Stancil writes at Every; archive at benn.substack.com. ↩︎
Jeffrey Dean and Sanjay Ghemawat, “MapReduce: Simplified Data Processing on Large Clusters,” OSDI 2004. The canonical example of a large-technology-company research paper that reshaped an industry’s public discourse. ↩︎
Fay Chang et al., “Bigtable: A Distributed Storage System for Structured Data,” OSDI 2006. ↩︎
Giuseppe DeCandia et al., “Dynamo: Amazon’s Highly Available Key-value Store,” SOSP 2007. ↩︎
AWS, “Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region,” February 28, 2017. Exemplar of the industry-standard public postmortem. ↩︎
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems (O’Reilly, 2016). The book that consolidated a decade of internal Google practice into a public-facing architectural literature for operations. ↩︎
Cory Doctorow, Enshittification: Why Everything Suddenly Got Worse and What To Do About It (Farrar, Straus and Giroux / Verso, October 2025). ↩︎
Panorama Consulting Group, ERP Report (annual; most recent editions 2023–2025). Gartner and Standish Group research on ERP project outcomes across the 2000s and 2010s is widely cited; the 60–70% failure-rate figure referenced in The Cost of Convenience is drawn from this body of work. ↩︎
MIT NANDA initiative, The GenAI Divide: State of AI in Business 2025 (July 2025). Cited also in What We Take to the Moon. ↩︎