Software Architecture
In almost all enterprise software projects that involve one or more software components interacting with one another, across systems, the role of Architecture is often confused with various things like design or translating the business needs into software modules or meeting non-functional needs like performance, HA, scalability, Security or Cost optimization etc.
While all the above drive the software architecture, they are just needs imposed on it. The Architecture itself is about structure. It is not about designing data models of the domain or it is not about working out the process flows that is very domain specific.
Architecture is a meta layer that understands all of the above but ensures the structuring of self-contained components or services and their interactions. So to that extent, it is like building a city and not a house in the city. The houses are the components or services. Designing them require a deep understanding of the domain for which the software is built for. A person who can build a house cannot envision how a city can be built.
At a higher level, it is possible to see reusability across components. If every component needs a cache, then that can be abstracted out and it can be made into a component of the Architecture. If the process flows are more aligned to messaging, then a message bus of some sort is needed in the architecture. As you abstract out all these common components, the real business flows now become plug and play or a configurable aspect of this structure called Architecture.
This meta layer constitutes the real Architecture stack. Such an abstract stack can be concretized with specific software. For example, for a cache, you can choose redis.
The real job of Architecture is to be able to construct this abstraction out of the common needs arising in the underlying components and find a suitable OTS software or custom build one based on what is appropriate for that project.
Therefore the Architect need not be a domain expert and preferably should not be as it is difficult to don multiple hats and do justice. The Architect should be a good listener. He has to develop an understanding of the domain, the needs imposed on the software under construction, hear out the views of the component designers, work with data modelers, domain experts, product managers and customer in a passive way until this meta layer emerges.
This is mainly to allow things to happen in its natural way without imposing preconceived ideas from past. Every project is different and has to be given its due attention to find simple ways to solve it. Using templates without going through this process of understanding a project in its entirety can ruin the chances of finding a easy solution or questioning a need.
At the end, the abstracted meta layer is what makes the Architecture that helps to make the process flow, the data flow needs of a project happen smoothly with the desired level of performance.
A well laid abstraction makes it easy for future changes to the software caused by new process flows, new components coming in or changes to existing components.
A lot of the above is mostly applicable in the initial stages of product development. The need for an Architect should reduce and disappear totally as a project moves towards completion.
