Most often get to hear where does a Solution Architect fit into the overall hierarchy of an enterprise.People often confuse this with the role of an Enterprise Architect and some of them want to be better at Solution Architecture and move up being an Enterprise Architecture.

In an organization context when you are going from Strategy to Execution then it becomes imperative to understand what are the layers in this process,

Typically it shall be going from
Contextual —-> Conceptual —–> Logical ——> Physical.

As can be seen in the picture attached the Solution Architect is pegged at a layer between the conceptual and logical layers of the strategy to execution process. And the Enterprise Architect is mostly at the contextual layer where business problems are present at a particular context.

If you are wanting to better at Architecture and being Agile at the same time and such resources shall help you keep updated with resources for architects. Do send a mail to maileturnti@sairam.eturnti.com with subject Subscribe.

Togaf Trainings and Consulting : http://eturnti.us7.list-manage2.com/track/click?u=171856f3ca74842f465089b2b&id=67c266dd99&e=3d9b3ab567

Solution Architect Training :    http://eturnti.us7.list-manage1.com/track/click?u=171856f3ca74842f465089b2b&id=600fe9d5d3&e=3d9b3ab567

Agile Architecture Trainings : Mixing Agility with Architecture   http://eturnti.us7.list-manage1.com/track/click?u=171856f3ca74842f465089b2b&id=600fe9d5d3&e=3d9b3ab567

Innovation in Enterprises – How do you go about the same _ from Eturnti on Vimeo.

It is all around and unless you take action and find your innovation potential and align your best efforts in that direction, you as a company can effectively be a thing of the past. What best practices, challenges within and outside the organization will you have to face to get past this? How will you get people to accept a culture of innovation which is disruptive and acceptable in the market? How lean can you become to challenge your own status quo? We will look at a typical banking software company who can start looking at a lot of surround offerings by running parallel experiments instead of just being seen as a banking software player. The idea is to exploit the interface product boundaries and potentially also innovate in more than one industry.

All enterprise architecture frameworks talk about this. TOGAF also has prescriptions for moving from strategy to execution. Here is a short snippet explaining the process and involves addressing various concerns generally such as domain , data , application and technology without going into all the details. Togaf calls going through this famously as BDAT. ( Business , Data , Application and Technology). More details here.

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.