Divide and conquer vertically to reduce cost of change
Application architecture is an oft-overlooked aspect of Continuous Delivery, and an application that encapsulates orthogonal business capabilities is a direct impediment to our stated aim of rapidly releasing small changesets to improve our cycle time. How can we better align technical capabilities with business capabilities, and consequently improve our release cadence?
For example, consider a Fruit Basket application that contains unrelated Apples and Bananas business capabilities, both of which rely upon a messaging service to integrate with a third-party endpoint.
This is clearly an ineffective architecture as it encapsulates unrelated business capabilities with different rates of change, violating Bob Martin’s Single Responsibility Principle and Kevlin Henney’s assertion that “an effective architecture is one that generally reduces the significance of design decisions“. A Fruit Basket release that contains new Apples functionality must also include the unchanged Bananas functionality, creating an inflated changeset that increases transaction costs and the probability of failure.
We can reduce the cost of change and enable Continuous Delivery by using Divide and Conquer to split Fruit Basket into independent applications, but it is important to assess the merits of different strategies. Horizontal Divide and Conquer favours a division of technical capabilities, and would result in separate Fruit Basket and Messaging applications.
While Horizontal Divide and Conquer allows for independent releases of Fruit Basket and Messaging, it ignores the fact that the variation between individual business capabilities will be greater than the variation between business and technical capabilities. Over time there will be far more orthogonal Apples/Bananas requirements than orthogonal Fruit Basket/Messaging requirements, with each Fruit Basket release still a bloated changeset – and when an Apples or Bananas requirement needs a Messaging change, the changeset will grow even larger.
In order to have a significant impact upon cycle time, we must value the decoupling of business capabilities over the deduplication of technical capabilities and adopt a Vertical Divide and Conquer strategy. Vertical Divide and Conquer favours a division of business capabilities, and would result in separate Apples and Bananas applications.
By creating independent Apples and Bananas applications we align our technical capabilities with our business capabilities, and respect the different rates of change in the Apples and Bananas business domains. This will ensure each Apples and Bananas release consists of a minimal changeset, unlocking batch size reduction benefits such as improved transaction costs, improved risk, and improved cycle time.
If we identify Messaging duplication as an issue after Apple and Bananas have been decoupled, we can further improve our architecture by extracting Messaging as an independently versioned library. This will further shrink Apples and Bananas changesets, and the introduction of a Messaging Published Interface will make it easier to reason about responsibilities and collaborators.
The corollary to Vertical Divide and Conquer is Conway’s Law, which tells us for our vertically aligned business and technical capabilities to be truly successful we must also re-structure our organisation so that our development teams are vertically aligned with singular responsibility for specific business capabilities.
> In order to have a significant impact upon cycle time, we must value the decoupling of business capabilities over the deduplication of technical capabilities
so true … but so difficult to anticipate !
Also, it may be costly to do (i.e you need single sign on and other goodies so that the user is not impacted by that, for ex reuse of GUI components…)
Hi Chris
Thanks for that. Yes, it is difficult to anticipate when business capabilities have different rates of change. It may emerge only after a period of time, but just because it’s hard doesn’t mean we shouldn’t try!
It can be costly to refactor a single application into multiple applications, but it is not difficult to estimate the Cost Of Delay for such a change – calculate per release how much time is lost due to the extra unchanged functionality you have to carry around, and estimate the greater probability of risk.
Single sign-on may indeed become necessary, although I would argue it should be considered upfront. Stefan Tilkov gave a great talk on this at QCon London 2012 – check out http://www.infoq.com/presentations/Breaking-the-Monolith
Thanks again
Steve
The argument seems to drive towards smaller and smaller components which are assembled later. If like messaging, logging, authentication and other components are modular and shared as either libraries or micro-services switching to single sign on is relatively easy (swap out auth libraries).
Dependency management and backwards compatible micro-services are both somewhat hard, but extremely freeing once in place.
Also on the good ideas from Martin list is Release/Reuse Equivilancy
Hi Eric
Thanks for that. My argument is for the Ian Robinson definition of a service – “a group of capabilities on an endpoint”, with the proviso that each capability is within the same business domain and has the same rate of change…. as Don Reinertsen shows in Principles of Product Development Flows, there is an optimum batch size and perhaps that is larger than single piece flow. Perhaps we end up with an architecture of micro-services that do one thing only, perhaps we end up with an architecture of 4 services that each provide 4 capabilities. But anything is better than a single monolithic application, or a monolithic application previously sliced by technical capability into n applications that for some mysterious reason has not improved cycle time.
Thanks as ever
Steve