친숙함의 역설: 60년간 실패한 기업용 시스템

My thoughts on why enterprise knowledge systems have failed for sixty years, and what might finally replace them. A couple of weeks ago I demoed one part of what I have been building to a senior exec at a global enterprise - someone who had been asked to lead and guide AI adoption in their part of this billion dollar company - our conversation was off the record, but what they told me - and why they couldn't buy my product - that is the basis of my essay. First, they told me that what I had shown them was the first time they had seen an AI system for complex enterprise work that looked ready to deploy. Yes, they had familiar reservations: their data had to stay under their control (no problem, my architecture is designed around exactly that). Next, they told me what the large consulting firms had been pitching them: the quotes sat in the hundreds of thousands, spread across a roughly threefold range. The high end was a gold-standard 99.5% accuracy promise while the low end was priced to be a deliberate foot in the door and the common thread was these firms were selling their own learning curve. I had demoed a product that worked, while these behemoths - my competitors - were asking to be paid to build a product that worked. Next I was told that they could not buy from me. Why? Risk And they put it succinctly: buying from a small innovative company is brave while buying from a big, well recognised name is an insurance policy and the risk-averse buyer must have the insurance. That insurance - more than price and more than product - is what enterprise software has always traded on. My conversation was not a one-off - of course - it is the shape of a sixty-year failure the industry has learned to call "prudent". I'm writing this today as a reminder of that failure, and as a public declaration to keep building anyway. It's 2011. Hewlett-Packard acquires Autonomy for US $11.1 billion, then a year later writes off $8.8 billion of Autonomy's value (eighty percent!), blames fraud and sues Autonomy's founder Mike Lynch. Fast forward to June 2024 - after a thirteen-year legal battle - a US jury acquits Lynch on all counts. Lynch's lawyers established that HP executives spent roughly six hours on conference calls with Autonomy before the $11.1 billion decision. Two months after his acquittal, Lynch died when his yacht - the Bayesian - sank off the coast of Sicily. HP, one of the largest enterprise IT customers on earth, paid $11.1 billion for a knowledge-management product after six hours of phone calls with its founders yet a year later it could not tell what it had bought. This is the category I want to talk about - enterprise knowledge management - the software that promises to capture what an organisation knows and make it usable. It has existed for forty years or more, yet it has never delivered the intelligence it pretended to offer. I estimate it has cost something north of a quarter of a trillion dollars US in write-offs, opportunity cost, and honestly-counted productivity losses. And its 2026 incarnation - "just add AI to your wiki" - is the worst iteration thus far. The reason is not that the technology is bad (although there's certainly examples of that too). The reason is that the buyers select on the wrong axis. They select on familiarity . They have always selected on familiarity. Familiarity is the enemy. The enemy, named Twelve years ago I wrote a post arguing that the realised value of an information asset is a function of the technology used to transform it. That the gap between an asset's potential value and what the business actually extracts from it should be the whole economics of the enterprise information management industry. The technology choice isn't decoration on the outcome - it's causal. Of course, nobody read it - though it wouldn't really have mattered if the whole world had - the industry kept buying the same things. The potential-versus-realised gap widened and at some point over the last three years (coincident with ChatGPT) - enterprise knowledge management started collapsing into a final embarrassment so complete it can no longer be hidden. This is my pre-mortem. It is also, at the end, my proposal. In 2011, Rich Hickey - the creator of the Clojure programming language, and arguably one of the most important computer scientists of the last twenty years - gave a talk called Simple Made Easy . He drew the distinction that most of this industry still ignores. Simple is objective : two things are simple if they are not intertwined, if they do not interlock, if removing one does not collapse the other. Easy is relative : something is easy to whom? Easy is near-at-hand. Easy is familiar. Easy is what your team already knows, what your CIO has heard of, what the analyst quadrant showed you last year and will show you next year. Enterprise software has spent decades confusing the two. Hickey's witty rejoinder is "Incidental is Latin for your fault." The entire apparatus of enterprise technology selection - the analyst reports, the RFP scoring rubrics, the CTO dinners, the Gartner quadrants, the AI world tours, the reference-customer asks, the preferred-supplier panels - is a machine for rewarding familiarity. It is not a machine for rewarding correctness. The two are not the same. Every one of the failures catalogued below, and the forty-year graveyard they sit on top of, has the same structural cause: the buyer bought what was familiar to them, not what was right. The vendor who looked safe beat the vendor who was innovative. The language the hiring committee recognised beat the language that would have made the system maintainable. The architecture that appeared on the last three analyst reports beat the architecture that would have actually solved the problem, at a fraction of the cost. Familiarity is the selection criteria that matters, and has been since before I was born. It has cost - on my back of the envelope estimation - hundreds of billions of dollars. This is my essay about why. Five ways familiarity kills enterprise intelligence 1. The familiar vendor Microsoft proudly announced in 2020 that SharePoint had over two hundred million monthly active users. They have every right to be proud of that. SharePoint is deployed in effectively every Fortune 1000 company. It is also, by the testimony of its own users, one of the worst products ever . Forrester's 2012 SharePoint survey measured IT satisfaction at 73% and business-manager satisfaction at 62%. The eleven-point gap is the whole story. Enterprise IT bought SharePoint because it was bundled with Office, but the business tolerates it because the business has no choice. A SharePoint consultant - writing in 2014 - called it "where documents come to die." He meant it affectionately. This is how a product with 200 million users can be universally described as a place documents go to die. In any case, the actual product does not determine the sale - the familiarity of the vendor does. The product is an artefact of the buying signal, not the other way around. 2. The familiar language and the familiar architecture Look at any large enterprise software vendor's technology recruitment page. Count the mentions of Java, .NET, Azure, Oracle, SAP, ServiceNow. Then look for anything that is not one of those. The distribution is not an accident. It is a policy. The language stacks that appear on those job ads are the language stacks that recruitment templates can process, that can be defended in hiring committee meetings, that the Big Four consulting firms are organised around billing for. Java monoliths have made tens of billions of dollars of enterprise revenue not because Java is the right tool (the JVM is impressive as a platform) - but because "Java" is a word that an internal promotions committee, an external auditor, and a departmental procurement officer can all pretend to understand. "Clojure" or "Datomic"? Hah. Instant disqualification. Totally unfamiliar. There is a commonly