Is it essential to redesign every monolithic application to Microservices? – Part2

In my last blog I mentioned about the scenarios which should be considered for any monolithic application before taking a decision to refactor its design to Microservices. Any application, if it’s able to serve the purpose of business without any limitation and without being a blocker for an edge on competition can be considered as a good design for a business problem it solves does not matter if its monolithic or micro services design. But there are scenarios where in customers are struggling to have an edge on competitors with their business as usual IT applications. This is where a well-defined strategy for aligning the IT with business is needed which should not only re-design the applications, but it should reduce the operational cost as well. Application re-design approach should be taken by analyzing the business scenarios and optimized development by considering the options like faster development patterns on cloud. Microservice design is one of the main aspects of application re-design which should be thought through as well. Any organization should think of adopting the microservices design over monolithic applications if they are encountering the business scenarios like as below:

• Applications needs to be quick in adopting interfacing with new devices
• Faster adoption of new business models without impacting existing modules
• Flexibility of changing a business process flow on fly
• Demanding performance KPIs needs
• Ability of autoscaling due to seasonal loads
• Flexibility of scaling the different modules & load levelling
• Resiliency to failure situations
• Lower cost of customization
• Faster releases for new changes by avoiding testing of whole functionality

Microservices design becomes a need for meeting the above scenarios for any business but again if the vision and strategy of monolithic application transformation is not right then there is a big risk for organization to fail significantly. Failures could be in terms of missing the business-critical functionality in the new design which might result into many iterations / sprint to get it right and may results in lengthy release cycles and revenue leaks during implementation phase.

?Second aspect of failure could be a choice of bad design by technical teams which might become a nightmare for maintaining and running the application in production despite of all functional module meets business requirements.

Its essential to think about the mitigation of all risks and challenges of design and implementation approach before we even start the transformation journey of the application. As shown in the diagram Reverse Engineering and Forward Engineering Analysis (RFA) approach should be very effective in mitigating all these risks up to a good extent.?

Approach of performing RFA should be tools based, workshops and interviews but it really depends upon the scenario of the situation in hand for example level of the technical documentation in place, availability of domain SMEs & technical skills around. Output of RFA would be your user stories backlog categorized as per their complexity and business criticality. RFA is a detailed topic with its aspects of doing it right, which is not in the scope of this topic.