That is the question that I have been asked a few times: are there different classes of Architecture that we Software professionals deal with? So wanted to address this question in this post.
The most common kind of software architecture we do in OPD (Outsourced Product Development) done in Persistent is what we can name is Software Product Architecture. The corresponding professional would be Product Architect. This is all about building a software product. The usual kinds of problems solved here are how do we structure the software, what kind of data structures we use, how do we remove performance bottle necks, and so on. The focus of Product Architect is to build software that meets the requirements as given by product management. In turn product management would get their requirements from understanding the problem to be solved in a particular market. Typically such a product addresses problems faced by a vast majority of customers in that market.
The second kind of software architecture that is common is solutions architecture and the corresponding professional is the Solutions Architect. More often than not a Solution Architect solves a problem faced by a particular customer. Further a solution thus built might include a many software products working together. Each software product in the mix solves one part of the mystery. Thus a Solution Architect solves a problem using a right mix of the appropriate software products integrated in an optimal way. If and when this problem faced by the customer becomes more common place, there is a chance that the solution can be turned into a software product.
The third important kind of architect associated with Software is the Enterprise Architect. Many times an Enterprise Architect is confused for a person who is working on software products that are used in the Enterprise. Nothing can be more incorrect - Enterprise Architect is concerned with "implementing" the right kind of structure that can address needs of the business that this Enterprise is built to solve. So the Enterprise Architecture in addition to software systems, can also include other technical capabilities of an organization - people, organization structure, information structure, technologies used, etc. Enterprise Architecture by definition is far reaching as it also addresses an organization's changing needs as it evolves. Many people might contribute in building it but all contributors are not Enterprise Architects.
A quick look at the skills needed by each of these Architect classes throws more light on this discussion. The Product Architect needs a very sound basis in Computer Science - needs to understand the implication of using one algorithm over the other, one data structure over the other, etc. S/He needs a very good idea of what it takes to build a robust software and be able to translate user requirements into implementable software components. The Solution Architect on the other hand needs a very good handle on which off the shelf products solve a given problem. Further s/he needs a very good understanding of issues related to integrating them. So it goes without saying that this person has integration technologies on the finger tips. Also having a good handle on the domain in which the solution is being deployed is critical. The Enterprise Architect however, is akin to the godfather of the Enterprise s/he is out to structure. S/he is a formidable personality who can influence the way people work, the way processes structured, the investment made and so on. As one could see the skillsets here would need to be beyond technical capabilities (which by the way are a necessity in all the three classes).
Thus each of the above architects play a major role in their own way. Note that, in addition to these terms there are other architectures (like Application, Data, Hardware, Deployment Network, System, etc). However I feel that most of these terms do not intersect much with each other and mostly are self explanatory.
