English | EN 
In my last blog, I mentioned the scenarios which should be considered for any monolithic application before deciding to refactor its design to Microservices. Any application, which can serve the purpose of business without any limitation or being a blocker for an edge on the competition, can be considered as a good design for a business problem it solves, irrespective if its monolithic or microservices design. However, there are scenarios wherein 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. The application re-design approach should be taken by analysing the business scenarios and optimized development by considering 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 mentioned below:
- Applications need to be quick in adopting interfacing with new devices
- Faster adoption of new business models without impacting existing modules
- The flexibility of changing a business process flow on the fly
- Demanding performance KPIs needs
- The ability of autoscaling due to seasonal loads
- The flexibility of scaling the different modules & load leveling
- Resiliency to failure situations
- Lower cost of customization
- Faster releases for new changes by avoiding testing of the 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 are not right then there is a big risk for the organization to fail significantly. Failures could be in terms of missing the business-critical functionality in the new design which might result in many iterations/sprint to get it right and may results in lengthy release cycles and revenue leaks during the implementation phase.
The 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 all functional modules falling in line with the business requirements.
It is essential to think about the mitigation of all risks and challenges of the 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 depend upon the scenario of the situation in hand. For example, level of the technical documentation in place, availability of domain SMEs & technical skills around. The 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. Once we have RFA report in hand then we get into detailed design and selection of design patterns for Microservices design and its development methodology which I will be discussing in my next blog.
