Notes from the DFW Pythoneers meetup

I spoke at DFW Pythoneers on Thursday 6 August. The slides are below, and the rest is a written version of what I said, for anyone who could not make it or who wants to go back over a part of it.

I am an architect. For the last few years I have audited information systems in banking, insurance, healthcare, retail, edtech, industry and energy.

A map is static

Every mission starts the same way. A company wants to know what to do with its information system, so you map it. What the business does. What it runs to do it. How it is wired. A few weeks later you hand over diagrams on slides.

Those slides are the deliverable. They are also my main tool.

They are a strange thing to depend on. They are already out of date when they are shown. And they hold the company still, when the hard parts are all movement: replacing a packaged product, migrating, getting a change into production.

The findings repeat as well. The same anti-patterns come back from one audit to the next, in the organisation, the processes, the vocabulary, the communications and the technical practice. Almost none of them is really about technology. They follow from who owns what, and which way things flow.

We have frameworks for this. TOGAF, ArchiMate, Zachman. I do not think they are wrong. I think they are hard to enter. When I have understood a piece of one, it was never from reading it. It was from recognising something I had already lived through. The experience comes first, and the theory afterwards.

The trouble is that the experience is slow, and most of it belongs to clients you cannot talk about.

Pilots have flight simulators. Surgeons practice on models. Architects mostly have slides.

So the lab makes the experience instead. The same patterns, on a company nobody owns.

The lab

The lab runs a company. TimberWorks sells wood and construction materials online, and it is working its way towards physical stores. It is a fiction. That is the only reason any of this can be published: there is no client to protect, so the storefront, the database and the failures are all public.

You can go and look. The portal below maps every component and opens the public ones; the next section covers what they are.

It gets used three ways, one for each kind of flow inside a company:

• Operational. The integration between packaged products.
• Analytical. The data those products produce, and disagree about.
• Business. The work itself, and how much of it an AI can pick up.

What Archipel Labs is for sets out what each one is meant to reveal.

How it is built

Real products, under real constraints. PrestaShop, MySQL, Matomo, Apache Camel, Redis. And you inherit what they cannot do: PrestaShop will not tell you when its data changes, so a clean event-driven design is off the table. We poll, compute a delta, or reconcile the whole state. Even in a fake company, the architecture bends to the product.

The simulator sits outside the company. One Redis stream is the only contract between them, and the concurrency is handled by archipellabs-runtime.

Every simulated customer runs in a real browser, and it has to. Matomo's tracker is JavaScript. It runs in the page, or it does not run at all. No amount of HTTP traffic produces a single analytics event.

So one order ends up existing three times: a browser session, rows in MySQL, events in Matomo. That is what the next section is about.

Experiments

The company now has staff, and they are AI agents. We are not building agents. We use them as instruments, and what we are studying is the information system. An attempt that fails because the data is not reachable is a finding about the building, not about the analyst.

We are looking for what makes a system robust: legible enough and open enough that someone can do their job inside it. That someone happens to be a model here. It could just as well be a new employee.

Two of the questions we have put to the company.

An ordinary question

"Can you work out our conversion funnel for Saturday 1 August, between 08:00 and 09:00 America/Chicago time? I want it from visits through to paid orders, with the drop-off at each step, so I can see where we lose people."

Nothing is broken. Analytics reports 258 visits, 137 cart pages and 138 checkouts. The shop reports 338 carts.

A funnel cannot widen, and this one does twice: 138 checkouts from 137 cart pages, and more carts than there were visitors at all. Analytics counts visits, the shop counts records, and one visitor makes several carts. There is no shared key, so the right answer is to refuse to divide the numbers and say why.

What is missing is an agreed definition of a visit, and one system allowed to be right about it. No tooling downstream can supply it: you will not fix in a lakehouse a definition nobody agreed upstream.

An incident with no error

"We've had complaints from customers in the last 5 minutes. It seems we have a problem — please investigate."

One row had been removed from the supplier feed: the line for Canada. The integration reconciled, dropped the shipping method that no longer had a carrier, and Canadian checkouts stopped completing. American ones were fine.

No exception, no 5xx, every health check green. Five dashboards, and the incident is on none of them. The system was healthy. The business was broken. The only record is one line at INFO level, and it expires.

So the system is not robust enough for a question like that. The agents that solve it earn it: dozens of tool calls, the supplier feed read line by line, and the cause found by comparing the shop against the file that feeds it. Several never get there.

Both of these deserve more than a paragraph, and they will get a post of their own.

What comes next

The economy is the next real step: stock that runs out, a purchase order with a lead time, a cash ledger, and rivals so that a price means something. After that, procurement end to end. Then accounting, at which point the shop stops being the source of truth for anything at all. Then integrations between packaged products rather than between our own code.

The roadmap is the biography of a company that does not exist.

All of it gets written up as it goes, failures included. The lab is on GitHub and LinkedIn, and the field notes are on this blog.

If you have an incident worth staging, or an argument with any of this, tell me. Every scenario in the lab started as somebody's real one.