The right debt(s) and timely payoff
In the early 2000s, Amazon moved to SOA architecture when they realised that their monolithic application is slowing them down. It took Amazon four years to move to SOA completely.
That move was very crucial and prompt for Amazon. It had set the foundation for their architecture, helping them integrate their products together. And also to move to “You build it, you run it” culture — key for enabling Continuous Delivery.
Read the following which talks in detail about Amazon’s move to SOA
This pattern, known as Strangler Application, strangles the existing ones by replacing them with the new ones. Amazon is not alone in this. There are other companies who moved to better architecture over a period using the Strangler Application technique. Branch by Abstraction is another technique to follow if you want to make major changes within the application.
On the other hand, there are cases where Technical debt has become one of the key reasons for the company’s demise.
Paying off Technical debt
Foundation for making such big changes is following the fundamentals of designs such as good OO practice and paying off the Technical debt on a consistent basis. As I’ve written in my earlier post, Technical debt can occur intentionally or unintentionally.
Items on the left side of the above quadrant under the reckless section, occur because of low-quality work i.e. either the team does not care much or because of the team’s lack of knowledge.
No teams exist without Technical debt. But usually, the teams who have their debts in the right quadrant [which are prudent], will be alert and takes appropriate action(s).
References
In the video below, Jez Humble refers to Strangler Application and Amazon’s move to SOA:
Below is an interesting read, Steve Yegge’s platform rant — Jez refers in the above talk, summarising the memo that Jeff Bezos sent to the entire team for implementing SOA :).
