4 comments on “Application Pattern: Vertical Divide and Conquer”

  1. > 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…)

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


  3. Eric Minick

    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


Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>