Why as an architect you should have abstraction and ability to get to the fine details ?

All the frameworks invariably touch upon the need for an architect to go from high level strategy to execution. How seamlessly you move from one to an other determines your maturity as an architect.

It is always better to keep a separate rack for storing your office or household items. Separation of concerns as it is referred to in architecture ensures that each layer in the architecture owns up what it is meant to and works towards making it happen.

As you grow up as an architect you need the ability to see the forest from the trees. You need to understand the details involved in lets say moving a data center in the cloud at a very high level where you see only the building blocks and also down below where you can get to see the nitty gritties of the solution. The high level solution may include a large number of building blocks and how the blocks themselves are composed of make up the details.

It all starts with a context in which you want to solve the problem.

1. Contextual Vision of where you want to go.

This the domain or the context in which your problem exists or manifests and you want to solve it. Mostly it is the 20,000 foot level.

Let’s say you are designing a social network. The high level mission statement is connecting people.

2. Conceptual level : This level of detail is more detailed than the earlier one where now you are moving one level below. The context is set and now the concepts get hashed out as to what aspects of the context you need to flesh out the details. Having defined the need for people to connect lets say over social media is out high level goal. What aspects of them same do you want to take it to the next level of details which will include how they will interact , what privileges do they share among each other and what kind of business process or data interchange happens between them and so on. Once these details are etched out , it becomes clear as to what building blocks are required to make this happen.

3. Logical ( Group them under a bucket/functionality etc)

Now the the problem having been defined at the conceptual level we need to see how to arrange them at a logical level. This generally would mean how to organize the pieces such that they are devoid of the underlying intricacies, technology stack that they run on. This also assumes that it excludes the implementation details as long as the blocks can be grouped into logical blocks for which a particular functionality be assigned or grouped.

4. Physical ( Leave it to Implementation)

This is generally the layer below the logical layer where you can decide to have a logically grouped solution being implemented using any of the technology choices on the table or leave it to implementation. Here if the logical solution has grouped the architecture into entities based on functionality , at the physical layer they could be implemented on a java stack or C# stack or ROR stack. The ability to abstract the high level details from the implementation is a key asset for an architect. One thought process is as long as the database interfaces are logically well defined. It would not matter which underlying database adapter (MySQL,Oracle,MS SQL etc) fulfills the needs for achieving the same. This helps the architect to help think of the solution independently without being constrained by one single solution.