When I first began thinking about a Product Reference Model, I imagined it as something new. Over time, I have become less convinced that it is.
Perhaps I have simply been rediscovering ideas that Enterprise Architecture has explored for decades—but applying them at a different scale and with a different objective. Enterprise Architects rarely begin with source code. They think about relationships. Business capabilities support strategic objectives. Applications realize capabilities. Technology supports applications. Information flows between systems. The architecture is not merely a collection of artifacts. It is the set of relationships that makes those artifacts meaningful.
That sounds surprisingly familiar. My Product Reference Model has gradually evolved into something that also emphasizes relationships. Business objectives relate to capabilities. Capabilities relate to features. Features relate to requirements. Requirements relate to BDD scenarios. BDD scenarios relate to implementation. Implementation relates to architecture. Architecture relates to operational procedures. Assessments relate back to business outcomes. Rather than replacing individual artifacts, the Product Reference Model attempts to make those relationships explicit.
Perhaps that is exactly what Enterprise Architecture has always tried to achieve—only at enterprise scale. If that is true, then perhaps the Product Reference Model should not be viewed as a competing framework. Instead, it may simply be Enterprise Architecture viewed through the lens of a single product.
The emphasis is different. Enterprise Architecture asks:
How does this product fit within the enterprise?
The Product Reference Model asks:
How does every important aspect of this product fit together?
That distinction may appear subtle, but it changes the audience. Enterprise Architects often think across portfolios, organizations and technologies. Product Owners, developers, testers and operations engineers think about one product. The underlying architectural principles remain remarkably similar.
What also changes is the purpose. Traditional Enterprise Architecture often focuses on describing structure. The Product Reference Model attempts to preserve understanding.
Every relationship should ultimately help answer one of the questions future teams inevitably ask: Why does this capability exist? Why was this architectural decision made? Why is this business rule still here? Where is the evidence that this requirement is implemented? Which assessment concluded that this capability was fit for purpose? How do all these artifacts relate to one another?
Perhaps the Product Reference Model is therefore less concerned with documenting a product than with making the product understandable.
It becomes a navigational model rather than merely a descriptive one. That observation also changes my own perspective. Instead of inventing another framework, perhaps I should learn more from Enterprise Architecture. Architects have already spent decades thinking about repositories, viewpoints, traceability, relationships, stakeholders and governance.
The Product Reference Model may simply extend those principles into the daily life of a product team. Its contribution would not be another modeling language. Its contribution would be placing product understanding at the center.
Perhaps the Product Reference Model can therefore be described quite simply:
The Product Reference Model applies Enterprise Architecture principles to a single product, with particular emphasis on preserving product understanding throughout the product’s lifecycle.
If Enterprise Architecture asks how an enterprise remains coherent…
…perhaps the Product Reference Model asks how a product remains understandable.
Leave a Reply