Obesity Matrix

Obesity matrix is used to find reasoning in architectural decisions.  This matrix is a set of one table and a two dimensional matrix.  Obesity matrix should be prepared for two scenarios:

1.       To choose one or more architectural option/s to implement a feature

2.       To visualize architectural decisions across product’s features

Case 1: To choose one or more architectural option/s to implement a feature

To create Obesity matrix, you will be listing technical options to achieve the feature and their consequences in a table similar to following:

#	Feature	Technical Options	Consequences
1	Self-serving customer management but if required support personnel should be able to intervene.
1.1		Implement as one enterprise service	1.    One big  complex service 2.    Performance may be better because of absence of multiple layers of indirection 3.    Difficult to maintain
1.2		Implement as two services – one for customer and another  for customer support personnel	1.    Clear cut separation of code on the basis of who is accessing the service 2.    Duplicate code between services
1.3		Implement as not only vertical slices (user and support personnel) but also in horizontal slices (common layers serving both user and support personnel slices)	1.    Highest level of separation and possible reusability 2.    Performance might be a hit due to two horizontal layers.
1.4		Use off the shelf identity management system	1.    Requires upfront money to purchase (do we have any open source option?). 2.    Need to evaluate multiple options 3.    May reduce maintenance cost in terms of man power but consider licensing fees.

This table lists technical options available for one of the feature of RentOMusic application. Though technical options list is not comprehensive but it gives an idea.

The next step is to layout these options in a 3x3 grid. The X-axis represents cost of maintenance and Y-axis is about cost of current development.  Since in agile, difference in development and maintenance blurs, so cost of maintenance also incorporate updation in existing feature during active development phase as well as impact on other features as they get developed. The cost should be estimated in terms of time required and skill set availability within team.

The matrix has three types of blocks:

F:  Fat – High to medium cost of current development and cost of maintenance.  These blocks must be avoided otherwise it team will bleed in medium to long term.  Product will be obese and will lose agility to change previous architectural decisions as time pass by.

M: Muscle – Low cost of current development and cost of maintenance. You must strive to bring architectural decisions in these blocks. Product will gain architectural resilience and cost of changing architectural decisions will not be high. Resultant product will be lean and muscular in architectural and design sense.

?:  Dilemma –  Here context plays important role. If team is making a decision which falls in one of these blocks, team must have very good reason to justify the choice.

Following matrix represent technical options and their location in Obesity Matrix for customer management feature for RentOMusic application:

In above example, might choose “1.3: Implement as not only vertical slices (user and support personnel) but also in horizontal slices (common layers serving both user and support personnel slices)” because of initial investment required.  Choice 1.3 is falling under dilemma blocks.

Case 2: To visualize architectural decisions across product’s features

This matrix is for documentation purpose.  This matrix is consolidation of decisions made for individual features.

This matrix is 3x3 grid. The X-axis represents cost of maintenance and Y-axis is about cost of current development.