Why We Publish Our Engineering Patterns

Every consultancy describes its methodology. Ours is published as engineering patterns : the actual architectures, what they cost, what they’re bad at, and when you should use something else.

The library is free, requires no email address, and is written to be useful to people who will never hire us.

This is a slightly odd thing to give away, so it’s worth explaining the reasoning — including the self-interested part, which is most of it.

Methodology claims are unfalsifiable and everyone knows it

Read the services page of any technology consultancy, including the large ones, and you will find a methodology described in adjectives.

Rigorous. Collaborative. Outcome-focused. Proven. Agile but pragmatic.

None of these claims can be checked before you have signed a contract, and the firms making them know that, which is why the claims are phrased that way.

The result is a market where the primary signal available to a buyer is how confidently a firm asserts things about itself — which is a poor signal, because assertion is free and correlates with sales capability rather than engineering capability.

A published pattern is a different kind of object.

It commits to a specific architecture for a specific problem, states what it costs, and names the conditions under which it is the wrong choice.

An engineer on your team can read it and form a view. If the reasoning is shallow, that is visible. If the tradeoffs are wrong, someone will say so.

We didn’t invent this and we’re not pretending to

Documenting recurring solutions as patterns is an old idea, borrowed from building architecture.

Christopher Alexander’s A Pattern Language (1977) established the form; the Gang of Four brought it to software with Design Patterns in 1994; Martin Fowler’s Patterns of Enterprise Application Architecture catalogued the enterprise layer in 2002 and still has its catalogue online.

Every major cloud vendor now runs an architecture centre on the same principle.

What that tradition established is a structure: a recurring problem, the context in which it recurs, a solution, and the rationale connecting them.

Our Pattern Library follows that structure deliberately, including the part most vendor architecture content quietly drops.

Every pattern has a mandatory When NOT to use this section, and those sections name real disqualifiers — permission models too disputed to encode, corpora too small to justify the machinery, teams with nobody to own the alerting.

They are the most useful part of each page and the part we would remove if we were optimising for sales rather than for being right.

The honest self-interest

Three reasons, in descending order of how flattering they are.

Better-informed buyers are better clients

Someone who has read a pattern and then calls has already worked out roughly what they are buying and whether it fits. The conversation starts several steps in.

The opposite conversation — where a prospect has an idea of what they want assembled entirely from vendor marketing — takes longer and ends worse for both parties more often.

Criticism improves the patterns

Publishing an architecture invites people who disagree with it to explain why.

Some of them are right. That feedback is more useful than internal review, because internal review is conducted by people who already share the assumptions.

It filters

A firm that publishes its tradeoffs is unattractive to buyers who want to be told that everything is straightforward.

That is a feature. Those engagements go badly regardless of who runs them.

The part where we’re new

We are a new firm. That has an obvious consequence for a page like this: we cannot point at a decade of named clients and measured outcomes, and we are not going to imply otherwise.

This is exactly why the library exists rather than a case study page with three logos on it.

Engineering reasoning is available to be evaluated on its own terms — you can read a pattern, check the architecture against your own knowledge, follow the references, and form a view about whether the people who wrote it understand the problem.

That evaluation doesn’t require a track record. It requires that we put something checkable in front of you, which is a higher bar than a testimonial and a lower one than a case study, and it is the honest position for a firm at this stage.

So the patterns carry no maturity badges and no “proven in production at [client]” claims, because those would be false today.

When they become true they will be added, one at a time, attached to specific work.

In the meantime the arguments stand or fall on their own, which is the correct arrangement.

What’s in there

Eight patterns, spanning generative AI, data platform engineering, and analytics.

Permission-aware retrieval over enterprise documents. Evaluation harnesses that catch regression before users do. Change data capture into a lakehouse without the replication slot filling a production disk. Semantic layers. Human-in-the-loop approval gates. Parallel-run migration. Cost-tiered model routing. Data quality monitoring that routes to someone who can act on it.

Each one covers the problem, when to use it, when not to, the architecture, the components, the tradeoffs in a table, and implementation notes — the things that cost a sprint to learn the first time.

Each carries real references so you can go past our summary to the primary material.

You can browse the full DataBridgeCrux Pattern Library without signing up or providing an email address.

References

• Catalog of Patterns of Enterprise Application Architecture — Martin Fowler’s catalogue, still online and still a useful model for what a pattern entry should contain.
  martinfowler.com/eaaCatalog/
• Patterns of Enterprise Application Architecture — the book, and Fowler’s own framing that he is documenting old ideas rather than inventing new ones. Worth reading on the purpose of a shared vocabulary.
  O’Reilly
• Pattern Views: concept and tooling for interconnected pattern languages — an academic paper whose reference list is a useful map of the pattern-language lineage from Alexander through Gamma, Fowler and Hohpe.
  arXiv
• Our Pattern Library — DataBridgeCrux engineering patterns covering generative AI, data platforms and analytics.
  Explore the Pattern Library