In speaking with hundreds of different enterprises, we find that they generally ask the many of the same questions -- one of which is; which app should we rewrite?
The challenge here is that if a development team chooses to rewrite a service or application that’s too important, management won’t want to risk failure. They’ll hear, “That’s too critical of an application” or “You haven’t proved your approach works”, but if you choose something not important enough, then it’s “That system isn’t important, even if you rewrite it, that will prove nothing…”
First, it’s important to understand “why change at all?”. Is it a business driver? Is it a competitive need that can’t be effectively met using existing technology and approaches? Understand the why.
I asked some of the expert engineers at Lightbend about this challenge, and this is what they had to say:
The app you choose should be where many of the infrastructure concerns are addressed and new deployment technologies are introduced. By taking this first, low-key approach, you allow yourself some leeway to be able to learn from missteps made during this phase. This phase may not directly deliver any business value, but is a preparation phase. Practice makes perfect ;)
Select a service that has a high business value to extract or migrate - not necessarily something that is central, but something where there is a real problem (can’t deliver features fast enough, doesn’t scale, fails too often, etc). Since you’ve already proven (somewhat) the technology in the first phase, the argument that the service is “too important” is not as strong. You can focus on the domain problem of this important service without worrying about the infrastructure problems because they’ve already been dealt with (i.e Phase 1), and a successful migration will deliver real business value since it solves a real business problem.
Throughout your project - these two phases are deemed vitally important. Prove that your solution works with a less-critical application, learn from it, then repeat with a higher business value service. By doing it this way, you’re able to mitigate risk while gaining the experience needed to rewrite the app that was “too critical for you to touch”.
If you’re interested in learning more about Reactive, Lightbend and IBM Cognitive Class have released a new, free 5-hour course titled Reactive Architecture: Introduction to Reactive Principles. This course can be completed independently, without cost, on demand, and over time. Many people in our community say self-paced learning is convenient.
