Avoid BDUF ( Big Upfront Design) and keeping adding value in increments and iterations. Fail fast and learn in the iterations.

Agility and Architecture uses a common tip to speed by agility amongst teams and is known as “Centralize Interoperability and Decentralize Implementation. There is a detailed blog on the same on the site here  for more details. This tip is inherently used by many architectural frameworks such as Togaf and even project management frameworks.

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

 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.

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.

Key Take Aways from the Presentation

How to relate to Enterprise Architecture Frameworks such as Togaf and Zachmann and make it work for your in your Organization ?

• Why do need an architecture in place in a product or solution ?
• Why are different views to architecture important and why is important to create the one that you are interested in ?
• How do you apply framework level separation of views to create a reference architecture ?
• What is the role of architecture vis-a-vis agility? How much architecture is needed for the hour ?
• How will people in the organization benefit from having a visual representation of architecture. It is there for all to see.