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.
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.