Tag Archives: enterprise architecture

Going from Blue Print to Brick and Mortar – Architect On the Job

Leave a reply

As an architect you should have the ability for abstraction and skills to get to the fine details 
StrategicToExectution

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.

 

Architecture Partitioning and why do you need it ?

Leave a reply

Architecture partitioning is a concept used most enterprise architecture frameworks often to separate concerns on how you partition your architecture based on various concerns. You can have the concerns such as length,breadth, time and domain as the parameters for slicing your architecture. Recently wrote a white paper for using enterprise architecture for being used in rural governance for rolling out micro finance solution to the rural population. Let’s say the architecture has lending, savings , schemes , offers and subsidy modules as different parts to the micro finance architecture as shown in the figure below. These parts form a part of your vertical slicing. You can go ahead and partition your architecture based on the vertical slicing which includes generally functional features of your architecture. Horizontal slicing your architecture means slicing your architecture based on technical features or features that are generally non functional . But it can also mean features that cut across horizontally across your architectures features.

architecture_partioning

For the sake of discussion  relating to rural governance in India let’s say Aadhaar ID being on similar lines to SSID in the US. Although there is still a lot of hue and cry on loopholes in the system on account of Aadhaar ID and the debate that it is not functional in the practical sense on many aspects. All said and done let’s put those issues behind us and say it is approved in full measure. As per the Aadhaar mandate there needs to be a case where savings account of people for whom government would roll out subsidies so rolling out such a feature would require the below steps.

These features are central to every functional features and cut across domains. So they would generally be horizontal features.

1. Linking all savings accounts of people in need of subsidies .

2. Releasing the actual subsidy to the accounts of the account holders.

3. Let’s we want bio metric authentication for accessing all functional modules that have integrated with Aadhaar ID and since this concerns across all modules it can also become a part of horizontal partitioning.

Togaf Architecture Partitioning

architecture_partioning_togaf

 Courtesy :  www.opengroup.org/togaf9.1

As seen in the picture above from the open group Togaf 9.1 website, it shows how architecture can be partitioned right from strategy architecture to segment architecture to capability or solution architecture. You can compartmentalize your architecture concerns into one of the following partitions. This would be the length wise partitioning . You can partition your architecture based on architecture domains(business,data,application and technical) of your architecture and that would be the breadth aspect to architecture. You can plan your architecture work based on time based iterations and that would the architecture time based iterations.

Issues with moving directly to Solution Architecture 

Some companies directly get into the solution architecture phase without much investment in the enterprise architecture phase based on their needs. A mature organization is able to move seamlessly from strategy to the solution architecture without issues. The issue is if you move directly to solution architecture then you have a tendency not to abstract common pieces of work that can be useful across other engagements and you can lose out on a reference model for your architecture. It would be more like you may have to specifically tailor a solution every time there is a need for one instead of driving the changes from strategy in which case your drivers , goal and objectives are well defined for your architecture. Ideally a mature organization is one where strategy and grounds up work are in tandem and gel well. In disconnected scenarios they would in silos where strategy is not well understood by the ground force and so such organizations do not invest in strategy due to pressures of quicker delivery. As an organization you will be judged by how well you can move from strategy to solution and vice versa in the long run. There are no doubts that a strategy well executed and understood by one and all in the organization is better than having no strategy at all. This would lead to chaotic processes and finally no accountability on overall architectural pieces and their execution.

These are recommendations from standard frameworks such as Togaf use what suits your context to enable you to better manage your architecture iterations.

Architectural Partitioning on the Server Side used in many deployment scenarios.

serverside_arch_partioning

In a typical web deployment architecture the server side components can be partitioned based on server side functionality offered. This can be factored in the design across all tiers starting from the browser end till the database. Having a modular design of course helps in big monolithic architecture , big ball of mud. So breaking up the modules on the server side helps avoid big ball of mud scenarios and also helps server side dependencies well. Instead of creating one executable or war file on the server side it can be deployed as many different war , ear files if you are coming from the J2EE side of things. Similar logic applies for .NET and other technology stacks. How do you design for modular architecture end to end is in itself needs a detailed treatment. But this is to drive home the point that architecture partitioning as a term can also be looked at for creating modular architectures among other things discussed above.