Monday, October 26, 2015

Architecture compromise budget

I have been involved lately in more than enough architecture discussions. Microservices, REST, messages, asynchronicity and all the rest... Everything looks good in theory but when it comes to finalization we hit the wall in full speed.
Here the compromise starts creeping in. Developers cut corners, business demands features, the UX should be improved. Most of these come with an architectural cost. This cost should be more or less converted into a "architectural debt". In order to work with this I decided that I have an "compromise budget" that is consumed by the architectural debt.
What I did was to quantify the architectural debt based on a simple formula:

debt = 1.3 * data model^2 + 1.7 * ui cost + logic_cost + 2 * testing cost + 1.4 * communication cost ^2

From where the formula? Well it is kind of empirical curve fitting on the projects I have worked on:

1. Data model influences most of the coding due to the fact that changes in the model might influence all other tiers of the architecture. So the impact is quadratic to the change.

2. UI cost influences the presentation layer and the impact is quite linear - as far as I have seen.

3. The logic cost is in linear relation with the change size. Although it seems quite odd in fact the change is localised in the business logic tier so it might justify the relation.

4. Testing is important as the architecture changes so everything has to be double checked with the specs and regressions  have to be mitigated.

5. Communication cost is by far the most important one as the architect has to be a jack of all trades and sit at the table with many stakeholders each one with its set of driving forces.

The formula is non-dimensional so the variables have to be described consistently (money, man-hours, ...) in the end it will all converge to money as this is in fact just a technical debt.

So how I used it? For example I have set a Compromise Budget of  150 units on a project and started to do the math:

1. Devs using synchronous calls instead of async: after the evaluation I have obtained a cost of about 20
2. Data model changed due to multitenancy, feature added late: about 80
3. Late decision on third parties used: around 20

So far I used 120 units of my 150 budget.  In the moment that I get a new request that changes again the data model the formula puts another 45 on the table. So I will have a debt of 15... Is my initial project still inline with the initial idea? Do we build the same product anymore? What to do now?

1st thing is to inform the stakeholders about this. In an agile way we could adjust the backlog and find the best sequence that maximizes the team output in the next sprints.

One important aspect of this is why in fact I accept compromises? Well there is no pure black and white situation so I learned that I have to sacrifice the architecture in order to get things done and have something to deliver. The formula is just a trigger that stops me on accepting more unconformities.
For waterfall this is quite inline with the concept.
For agile, as the role of architect is not well defined, it is mostly an informative KPI that shows the divergence trend between the initial architecture and the current one.

In the end is this budget helpful? For me it is as I use this as an early warning system that enables me to create a strategy for steering the development further on.