English | EN 
Many enterprises rely on data in existing back-end systems but need modern technologies to enable rapid digital transformation while meeting ever-changing customer needs to stay relevant in the market. Until a few years back, SOA based point-to-point implementations were common to integrate distributed and separately deployed systems. Today, that approach has shifted – Microservices based architecture enable businesses to respond to market conditions rapidly while leveraging robustness of enterprise data.
Microservices have disrupted the technology integration by enabling decentralization, fault tolerance, selective scaling and layer abstraction while remaining agnostic of underlying technologies.
Here are some thoughts for IT managers & leaders who are new to microservices and want to deploy microservices in their organization:
Microservices is an extension of traditional SOA but more suited for Agile
Traditional SOA approach used SOAP-based web services and was built to meet less demanding data delivery needs. In the past, Engineering teams would take multiple sprints to deliver a single SOAP-based service. Compare that to microservices which are more granular and designed to be composed within a single sprint. In some cases, engineering teams can crank out multiple microservices in one sprint.
Multiple incremental releases enabled by its scaled-down payload and light weight implementation approach makes microservices ideal for agile delivery.
IT leaders should take advantage of this low complexity and enable back-end and, front-end and integration teams to stay focused on a common theme in each sprint while ensuring the delivery of fully integrated components. Product owners and business analysts should be coached to build sprint deliverables that are independent and testable.
Think in terms of vertical slices
Leaders should coach teams to think in terms of vertical slices – whether you are using an API platform or performing custom development, technology implementations generally require substantial upfront investments. Subsequently, stakeholders are keen on seeing returns as early as possible.
Demonstrating value early helps promote credibility.
Work with business to come up with a handful of use cases that provides the most value. Collaborate with development team to evaluate technical complexity and decide on your quick win use cases. A quick win is that which takes the least amount of time and delivers the most value to the business. This approach also increases the probability of project success by incrementally delivering a handful of microservices in each sprint.
Measure success in terms of Business enablement
The modular nature of microservices provides an opportunity to measure business outcomes early in the implementation life cycle. This is a departure from the classic perspective of measuring project success purely in terms of delivery of services on time and budget.
Measuring business impact requires upfront planning with customer organization and performing sufficient due diligence so that there is alignment on business outcomes and KPIs. These metrics should ideally drive requirements prioritization & sprint planning discussions. The KPIs can then be tracked & adjusted throughout the course of the project.
Contract first approach
Following an outcome-based approach, development of each microservice should be focused on fulfilling a specific business requirement or a user story. Engineering teams should collaborate and ensure they are on the same page in terms of what the end data structure looks like for each service prior to development. Teams should work closely during sprint planning and pre-planning stages to arrive at a contract – this will enable them to walk away with mutually agreed integration & data standards that both teams can then independently work towards.
Abstraction and reusability
In addition to the reduced risk from delivering in smaller increments, microservices can be composed into a hierarchy of multiple abstraction layers as well. The layer closest to the data source might be designed to connect using different protocols and authentication mechanisms, while the layers closest to the front end is oriented towards a specific user experience – say for example – displaying up-to-date bank balance in banking mobile app.
Supporting architectural decisions that promotes reusability not only saves money and time but also minimizes complexity
While abstraction is not a new concept, it is imperative that IT managers appreciate the cost and time savings resulting from reusability enabled by such an architecture. Supporting such architectural decisions will be beneficial in the long run.
Thank you for taking the time to read through this article and hope you were able to take-away some pointers. Are there any suggestions you may have for technology managers & leaders who want to deploy microservices in their organization?
