A while back I mentioned that a system’s architecture could be considered a product in its own right. In this post I want to explain that a bit more.
Products are typically regarded as packaged, user-facing things. But according to Rimonov’s tower of activity the defining feature of a product should be that it’s a coherent thing which meets people’s needs, which are in turn based on observable data.
A user-facing product should be addressing particular needs, and continually checked against those needs. The needs should be based on data, such as seeing people interact with an existing product, or market growth predictions based on historical data. In an idealised, rational world the data will come first, but of course there’s nothing wrong with guessing a need and then verifying it against research. Once the needs are understood a product needs to be created to meet those needs. And since not all possible needs will be met in the first version (and some new needs will be discovered by releasing that version and seeing how people use it) then we would benefit from a roadmap (or at least an initial pointer) leading us to new versions. The product may or may not have explicit packaging, a marketing campaign, or a leader would goes by the title “product manager”. Maybe. Maybe not. That’s secondary.
If a central system is supporting several other systems or projects then its architecture can be considered in exactly the same way. There are a variety of needs, from all the projects which depend on the central system. An assessment has to be made of which of these needs the central system should reasonably handle and, significantly, what future demands will look like. The architecture has to meet the current needs and be able evolve in time to meet the future needs. A technology roadmap can help, but it needs to be flexible, particularly in response to how the external systems end up actually using and needing it. The secondary details of a product’s packaging, marketing and having a product manager aren’t so important… although, as I said before, that product manager may exist and be called an “architect”.
So an architecture can, in these circumstances, be usefully regarded as a product. It doesn’t need to be labelled a product, but the core characteristics are the same. Most notably it is a thing its own right, with its own direction, addressing external needs, and it should not be at the mercy of random projects.