Architect is a specialization of Product Owner

So I've been thinking about the role of Architect. First, there is an argument that we don't need architects; I disagree. For a single small project, architecture is reasonably compact and can probably handled by one or more team members to good effect. For a handful of similar applications we might even get away with establishing a pattern and repeating it and calling that architecture. But when we get to a larger scheme of applications with a diversity of purposes, someone has to keep the train on the tracks. That person is an Architect. 

There are, at minimum, 7 aspects of architecture that need attention. But applying these across an entire enterprise uniformly is difficult to do organically. Much as I wish it were not true, someone has to make the choices about how a system will be maintained, how do we manage configuration, what systems interact with each other indirectly, and what constraints should be applied to all systems. 

For example, all systems will use OAuth2 backed by the Azure platform could be a valid Architectural Choice. Each process in the system will interact via an Event Bus could be another. I could go on with dozens more examples, but the point is, many of these choices would be different on a per application basis when observed in isolation. 

So I put forth the notion that an Architect is a specialization of Product Owner. A person with technical skills who understands both the economics of software development, the human aspects of organizational growth and stability, and the technical tradeoffs among the array of technologies available. Beyond that, their skills parallel those of a product owner. 

An architect needs to solicit the business for information about what needs to be true. Understand those constraints and find technological solutions to them. All the while, an architect must be conscious of the organizations ability to achieve and maintain those objectives, both financially and practically. For example, if an Architect specified a technology outside the reach of the developers technical acumen without a plan for training and sufficient time for experimentation by the team, he or she would be failing. Similarly, if the revenue stream is too small to sustain a multi-million dollar installation of technology, the architect would likewise be failing. Additionally, an Architect should be looking at the long term impact of technology choices including, operating cost, license and maintenance fees, availability of hirable workforce, availability of training and support, and general applicability to domain problem solving.

This is just a variation of the decision process that a product owner is making when choosing an interface or set of capabilities for an application. It is a balance of what the organization wants and needs against the business value delivered. The more technical nature of the work is irrelevant in terms of what the Architects role does for the organization.