anchor.diff:  ==== [pattern]#Strangler Approach#
   
   ===== Intent
  -
  +Divide a legacy system into different functional domains and replace those step by step.
   
   ===== Description
   
  -Rewriting an old system "big bang" is a risky endeavour. It is harder than you think (see "Big Bang Approach" in aim42).
  +Rewriting an old system with the <<Big Bang Approach>> is a risky endeavor. It is harder than you might think at the beginning.
   
  -An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over
  +An alternative way is to gradually create a new system around the edges of the old, letting it grow slowly over
   several years until the old system is strangled. The most important reason to consider a strangler application over a
  -cut-over rewrite is reduced risk (it might cost more to do a strangler, but that's the price of risk reduction) [2].
  +cut-over rewrite is reduced risk (it might cost more to do a strangler, but that's the price of risk reduction) [1].
  +
  +Paul Hammont depicts the strangler approach as follows [2]:
   
   [[figure-strangulation]]
   image::strangulation.jpg["strangulation", title="Strangler Applications (Paul Hammant)"]
   
   He discusses two ways of achieving the goal of moving from the (red) old system to the (blue) new system:
  -1) with adding new features and 2) without adding new features. Deciding to go for the first strategy means that you can still keep your business happy, because you are still able to
  +
  +1. With adding new features
  +2. Without adding new features
  +
  +Deciding to go for the first strategy means that you can still keep your business happy because you are still able to
   deliver new features. However, this approach will take longer than the second one.
   
   
   
   ===== Experiences
   
  -* Paul Hammont reports the following positive http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/[case studies]
  +* Paul Hammont reports the following positive with his http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/[case studies]:
     ** Airline Booking System: the C++ application which was stable but hard to grow (and find developers) has been incrementally
        replaced by a Spring stack based application. A load balancer routed the requests to either the C++ or the Spring
        application. They introduced session store used by both systems (the C++ application needed to be adjusted for this).
  
positive.code: ===== Risks
  
  * You need to overcome the lack of will to actually finish the strangling (usually political will from
    non-technical stakeholders, manifested as lack of budget). If you don't completely kill off the old system, you'll
    end up in a worse mess because your system now has two ways of doing everything with an awkward interface between the
    two. Later, another wave of developers will probably decide to strangle what's there, writing yet another strangler
    application, and again a lack of will might leave the system in an even worse state, with three ways of doing things [1].
  * You need to have consensus across the development team(s) on the future state of the architecture and how to get there.
    If everyone runs into another direction, then you end up with a new system, which is also hard to maintain.
  * If you're introducing technologies that are new to the team or to support/maintenance staff (e.g. adding reliable async
    messaging to what is currently a synchronous three-tier client/server architecture) then you have to ensure that there
    are experienced technical leads on the project who know how to build systems with that technology, and support those
    systems. And those tech leads have to stick with the project for some time after the old app has been fully strangled.
    Otherwise, the architecture will degrade as inexperienced developers modify it in ways they know but not in ways that
    fit with the new architecture [1].
  
negative.code: 
  ===== References
  
  * [1] Martin Fowler http://www.martinfowler.com/bliki/StranglerApplication.html[about the Strangler Application]
  * [2] Paul Hammant's http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/[blog post] with practices and case studies
  * [3] http://stackoverflow.com/questions/1118804/application-strangler-pattern-experiences-thoughts[Discussion on StackOverflow] with Nat Pryce and Ira Baxter
  * Michael Feathers speaks on http://www.hanselman.com/blog/HanselminutesPodcast165WorkingEffectivelyWithLegacyCodeWithMichaelFeathers.aspx[Hanselminutes] about the Strangler Application