In API Modernization, APIs need to be treated as products rather than projects. API Product perspective needs to be embarked upon in order to take complete advantage of the booming API Economy.
With the fast use of cloud computing and changing business requirements, businesses need to stay competitive and provide an environment that allows for scalability and creativity.
With monolithic existing systems, tightly coupled components, and increasing volumes of data, the systems are not built to handle today’s business requirements, which need real-time data, support event-driven interactions, and scale on demand.
It is now essential to modernize these applications to respond to new market demands, advancements in technologies, and consumer expectations.
Approach for application movement
A complete API Management Platform can help any organization to start with their API Modernization journey right from scratch. The basic API platform helps build robust API Programs which can lead to greater business revenues and achieve the business goals, and KPIs set by the enterprises.
There is a need for the right approach to move these applications. If the application is smaller to medium-sized and slightly stand-alone, we can take an approach of refactoring, rearchitecting the solution, or even replacing it with more modern off-the-shelf alternatives.
However, the process of determining the approach becomes increasingly complex for larger applications with multiple component integrations. An understanding of the business processes and an evaluation of the current application landscape can help formulate the right API modernization strategy.
API modernization strategy typically could be a mix of refactoring, re-architect, and retire decisions based on an organization's resources, time, budget, or other constraints.
Why APIs or Application Programming Interfaces?
Application Programming Interfaces (APIs) are one of the most efficient and flexible ways of modernizing legacy systems. APIs provide a standardized way for applications to expose their functionalities and data, thus providing integration capabilities for a connected environment and enabling the experiences required by customers.
Over the years, we have worked on numerous API modernization projects across several verticals like construction, travel, hospitality, manufacturing, etc. One such system was an HR system specialized for end-to-end cabin crew management for a reputed aviation client.
The existing system was a mix of several thick and thin client applications, built using varied technologies, all connecting to one common Oracle database. This has resulted in significant issues such as:
-
Manageability and Reliability issues
Manageability and reliability issues due to duplicated functionalities, lack of data ownership, etc.
-
Maintainability
Issues with maintainability are caused by the spread of business logic across applications and database stored procedures.
-
Performance
Performance bottlenecks are created by several applications communicating with the database directly and sometimes non-essential and long-running requests take priority over more critical ones.
Understanding API Modernization and workflows
This was not just an IT problem because, eventually, this ended up in some disconnected processes, confusing workflows, and a poor user experience overall, which was impacting the business users significantly.
After a thorough understanding of the system and business processes through several discoveries and design workshops, system study, and brain-storming sessions.
We concluded that a re-architect and re-engineer approach would best be in this situation as it allowed us to consolidate the workflows, technologies, etc. and build a more scalable, resilient, and future-proof system.
Ways of Adoption
The first step was to carve out the functional domains for the system. This allowed us to adopt a domain-driven design and microservice architecture to better manage the data and functionality ownership. We also finalized the data strategy.
Even though we wanted to maintain a database per domain to allow scalability at the database level, we had to decide on a single database given the licensing and maintenance overhead. Eventually, we settled on a schema-per-domain approach.
This gave us the flexibility to break out into individual databases in the future if necessary. Additionally, we also finalized the retention and archival policies.
Building APIs
Once we had the functional domains and key entities for each domain defined, we went ahead with the API build. We decided to build the APIs using ASP.net WebAPI on DotNet Core 3.1. To expedite the development, we made use of our in-house code-generator framework that we have developed over the years from our collective experience in building web applications.
This significantly reduced our work as the framework bootstrapped the code for us and provided for all the cross-cutting concerns like security, logging, exception handling, base ORM implementation, request/response handlers, API-to-API communication, service health monitors, etc. out of the box.
This allowed the dev team to focus their efforts on building just the business functionality and code quality. The API documentation and discovery were managed using Swagger, which again came from our code-gen framework.
Performance of APIs
We put great emphasis on the API performance and used JMeter to build a performance test suite that measured the performance of each key module not just for its current usage but with a projection of capacity for 5 years into the future.
We used Hangfire to build a background job framework that served two purposes: first to schedule and trigger routine jobs and second to allow asynchronous operations. This came in very handy in designing our data integration framework around this as well. This was required as the HR system needed to interact with several other systems like rostering, attendance, CRM (Customer Relationship Management), etc.
Finally, the front end was built using React. We used Azure DevOps for branch management, CI/CD, and Work management.
Conclusion
Everything was not smooth sailing and there were several challenges like functionalities that spanned cross-domain, some modules that had high-performance requirements, etc., and other technical challenges that we faced along the way.
However, we were able to put six critical modules into production in less than a year and were able to improve the user experience of critical processes for more than 100 back-office users and 10000+ crew.
We have built a system that is future-ready, can be scaled at need, and is open for integration through a robust API framework. For any questions you may have please contact our experts at Azurehelpdesk@sonata-software.com. Our team will be delighted to help you out.