As an architect you should have the ability for abstraction and skills 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. This is needed as you go along from strategy to execution although the lines blur as you make this layered transition.Ability to talk business to the end users and technology to your internal teams is a vital asset.This needs constant zoom in and zoom out of the details involved.
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 ( arranging the logistics involved , assessing the impact of the solution, deciding which cloud hosting provider ) involved and also down below where you can get to see the actual pieces ( actual cloud provider , data migration / backup / restore , day to day running of the cloud setup , load balancers, network providers,security solutions co-hosted) of the solution. As you move from vision to execution the details start emerging which perhaps may have been a one point on your check list. This gets full blown as you move towards the bottom of the pyramid and all your skills arsenal will be put to good use.
Want to take something from idea to hit the ground It all starts with a context in which you want to solve the problem. All start ups may go through this this process but who cares about a framework when you need to hit the ground with your product. Nevertheless the thought process is pretty useful and serves you well when you move towards rolling out other products and solutions in the length / breadth of your career.
1. Contextual Vision of where you want to go ( mission/vision)
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 Facebook The high level mission statement is connecting people.
2. Conceptual level (flesh out the context into concepts ) : 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. List all the business processes , the actors involved in the process and all the other surrounding pieces that are needed to complete the interactions between the entities involved.
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. All the blocks that constitute the business , data , application and technology areas would be grouped together. Under each bucket we could have relevant sub buckets say under business all blocks dealing with people interaction, relationship manager,profile updater and so on will fall under this.
4. Physical ( Leave it to Implementation)
This is generally the last 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. The layer post this will be actually code or executables. 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. Ideally one should architect something which can sit on any stack and should be technology agnostic.One such 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) fulfils the needs for achieving the same. This helps the architect to help think of the solution independently without being constrained by one single solution.
Finally remember strategy formulation is just one step on your path to doing something. Anyone can steal your ideas , strategy and not your execution. Understanding this and walking the talk using architecture best practices help you gain value from all the combined understanding of frameworks.
