Defining Solution Architecture

There are different types of architectures and architects in todays industry spanning from enterprise/solutions/system/technical/application/platform/data architectures/architects. (Architecture is now a very generic term) So the analysis of requirements to architecture differ for each of these cases.

Still let me try to explain the architecture at a solution architecture level as I understand enterprise architecture is still far from my reach :)

By understanding the business requirements and grouping them into modules/sub-systems at a high level we achieve the conceptual architecture. In normal scenarios we will be able to identify the different tiers in the system at this time.

These high level modules/subsystems are further analysed in more detail to get to a logical architecture and at this point we should be focusing on defining the various layers in each tier. This is achieved by identifying the business services, the reusable components that make up these services etc.

Now this logical architecture needs a technology mapping. Which technologies you choose for the each of the subsystems/tiers/layers are identified at this stage and this phase should form the pillar of our architecture. This is where the architecture reflects how the business requirements are transformed to technology solutions. This is where an architects breadth in technology knowledge comes handy and these chosen technologies are where a hands-on architect will increase his depth of knowledge. We also need to consider the non-functional requirements while choosing technologies and platforms. But please also note that non-functional requirements should be heavily prioritized as many of them can be compromised over the duration of a project. I like to call this phase as technical architecture (tarchitecture).

Once you have mapped your business requirements to technology, you need to define a physical view of how these technologies will be laid out and hence we define a Deployment architecture. The non-functional requirements like scalability, availability etc play a significant role while defining this. Whether our components should be co-located or distributed we decide at this stage assuming our tarchitecture supported both :)

So in short defining conceptual,logical,technical and deployment architectures are what i followed from the requirements to solution to delivery. There are more variations and additions and exceptions to these in specific cases which i skipped here and we can write a book to explain all those as we adapt many of our approaches based on each project :)