Siebel already did it
In 2006, at the start of my career, I spent months inside Siebel 8. Not using it: programming inside it, in eScript, the contract migration process for the large accounts of a big telco's CRM. Real volumes, real contracts, a system that had to carry the weight of an entire company.
I didn't realize it at the time, but I was working inside one of the most complete software architectures I would ever see. Object Manager, Business Component, Applet, Workflow, EAI: each piece was a pattern, and the pieces talked to one another. There was even, in the Order Manager, an entity-attribute-value model for configurable products, the kind almost nobody stands up today, or stands up badly with a pile of nullable columns. It was all there, by default, twenty years ago.
Since then I've spent my career analyzing and designing architectures, with an eye always on the right patterns for the problem, on performance, on volumes. And it's strange how often my mind goes back to that 2006. Faced with a problem presented as new, the recurring thought is almost always the same: Siebel already did this.
This essay is about that thought, and what it hides. It isn't nostalgia, and it isn't a "things were better back then." It's that mature platforms are crystallized architecture: they embed, as defaults, the solutions to problems the industry learned over decades and one incident at a time. When we rebuild from scratch, or let an AI generate the code, we start further back than we think, from before those lessons, and we quietly buy back the problems those patterns prevented. What gets lost is not the pattern. It's the memory of which problem it solved, and the question that made you look for it.
A catalog of patterns, by default
Let me try to translate those names for anyone who has never touched Siebel, because that's where the point shows. Each of those components is a pattern we chase today, often with three separate tools and less coherence.
The Object Manager was a stateful application server with session and object pooling, and a clean separation between layers. Today you reassemble it by hand, app server plus connection pool plus session management, hoping the pieces get along.
The Business Component was a domain layer on top of the physical schema: the logic didn't talk to the tables, it talked to a semantic model that decoupled it from the database. It's the repository pattern, the domain model, the ORM done right, before any of those became conference talks.
The Applets were interface components bound to their Business Component. Declarative, data-bound UI components, which is what we call React with state management today, except there they were config-driven and coherent with the rest of the system.
The Workflow Manager did declarative process orchestration, not imperative logic scattered across methods. Today, to get that back, you pull in Camunda or Temporal, or you write a state machine by hand.
With EAI, integration went through a canonical model and adapters: the system didn't couple itself to other people's formats, it put a translation in between. It's the anti-corruption layer you reinvent today as an integration microservice with a mapping layer on top.
And then, in the Order Manager, the thing that still amazes me most to remember: an entity-attribute-value model for configurable products. Products and order lines with dynamic attributes, not hardcoded columns. It meant that to add a product variant you didn't run a migration and you didn't stick a nullable column onto the orders table: you configured it. It's a pattern I still rarely see done well, when I see it at all. In 2006 it was a default.
The point isn't that every application should have all of this. In a small system, a lot of that complexity would be dead weight. The point is that those patterns had been thought through, named, and held together by someone who had already paid the price for not having them.
Then simplicity won
Siebel didn't have a happy ending, but not in the way it's usually told. Oracle bought it in 2006, and still keeps it alive as a legacy product. What ate away at its market one piece at a time was Salesforce, with the opposite idea: not a platform that did everything, but a simpler one, in the cloud, that did far less and yet you could have tomorrow morning, without a year-long project.
And it won, largely rightly, because for most cases simplicity was the better answer. But simplicity has a cost you pay later, and quietly: leaving the patterns out. When the default stops containing them, they go back to being your problems, to solve case by case, usually when you discover them in production. None of this is a fault of the people who chose simple. The complexity Siebel kept hidden didn't disappear; it shifted onto the shoulders of whoever builds.
"The AI wrote it, it's fine"
There's a second way, today, to lose those patterns, and it's newer and more insidious. The code is generated by a model.
An AI that generates code or architectures produces, by construction, the median of what it has seen: not the hard-won pattern someone hammered out after three incidents, but the average solution, the one that runs, that looks complete, that passes the first glance. And the first glance is exactly the problem, because the reflex spreading now is "the AI wrote it, it's fine." That reflex removes the one checkpoint that mattered: someone who looked at the result and asked "hold on, where's the pattern here, what happens at volume, who handles the case this doesn't cover."
The value of an experienced person was never in writing the code, but in remembering which problems exist, and so knowing what to look for in what's been produced, by a person or by a model. If that memory doesn't get passed on, because the people arriving have never seen a Siebel and trust the first plausible output, we don't lose a tool. We lose the question.
Every so often, still, I find myself looking at a new architecture, polished, generated in a hurry, and feeling that old thought. It isn't the nostalgia for a tool. It's that twenty years ago a platform kept in mind, on my behalf, a set of problems I now have to remember on my own. Siebel already did them. The hard part isn't finding the patterns again. It's not forgetting the questions.