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.
niksilver.com 
Interesting perspective.
If I understand your assertion correctly – anything can be a product, so long as it has users and those users have needs. So far so good?
I think the clincher here is who the user is. A car is a product – but not its chassis. At least not the the user of the car. Perhaps to the manufacturer.
The central system is a product to the user of the central system, but its architecture is not a product to that user – it is a means to an end (delivering some bits of whatever the central system does). Who is the user of the architecture?
What is the benefit of considering architecture a product? What direction (other than the support of the user of the software?) does it need to have?
This is a contentious area for many, especially those who have suffered at the hands of software architects who dictate what and how software is built and swan about with blueprints and technology roadmaps with tech that was relevant decades ago when said architects last went near code.
Even the code that makes us the software, in my opinion , is not a product. The software is a product (of the code – and the architecture). Should code and architecture be maintained, kept relevant and clean – absolutely. Are they products in their own right? Absolutely not.
@Mike, those are all good questions. Let me try to take them on in no particular order…
I think there’s a subtle difference between “seeing an architecture as a product” and “architecture actually being a product”. I’m really advocating the former — a shift in perspective rather than seeking to dramatically reshape where architecture responsibility sits in the org chart or who owns it. So, I wouldn’t say “anything can be a product, so long as it has users and those users have needs” but more “anything can be usefully seen as a product if we start to think about its users and their needs”.
The user of the architecture is (directly) those people who work with the technology defined by the architecture. If the architecture is good then their jobs should be easier. The user is also (indirectly) the business people for whom the technology is being developed. Again, a good architecture will result in greater operational effectiveness for the business. The important thing is to have that user focus: do we know the pain points of the developers and the business strategists? Do we know how they expect their needs to evolve? Do we have insight from other sources about how we expect their needs to evolve, regardless of whether or they realise it themselves yet?
This user focus is a lot of what makes it a more product-centric view. It also shows up a clear difference from (as you say) “software architects who dictate what and how software is built and swan about with blueprints and technology roadmaps”. If the architects are more user-centric then they will not be perceived as “swanning around”, and those blueprints and roadmaps will be meaningful documents to be eagerly embraced by the developers and commercial strategists.