Reference Architecture

The purpose is to stop each team re-deriving the same answers. If the organisation builds event-driven integrations regularly, the questions of which broker, what the message envelope looks like, how schemas are governed, how errors and retries are handled, and how it is monitored should be answered once.

What makes one adopted rather than shelved: it must be specific enough to follow, naming technologies and configurations rather than describing boxes; it must state when it applies and when it does not, since a reference architecture presented as universal will be misapplied and then discredited; and it must be implementable — ideally backed by templates, modules and a paved road, so following it is the fastest route rather than an additional obligation.

The failure mode is the reference architecture as an aspirational diagram produced by a central team with no implementation behind it. Teams read it, find it does not address their constraints, build something else, and the artifact quietly becomes evidence that architecture is disconnected from delivery.

The maintenance obligation is the part rarely funded: a reference architecture reflects the technology and constraints of the moment it was written, and one that has not been revised in three years is actively harmful, because it directs teams towards decisions the organisation has since learned are wrong.