In-flight migration from legacy ERP
Since 2014 the Italian Basketball Federation (FIP) is managing most of its business processes with a quite large monolithic software system (over 6.600 Function Points) developed during the previous two years by a medium-sized system integrator with an estimated effort of about 50 person/years.
The system implements 16 main functional areas supporting a wide spectrum of activities related to administration and bookkeeping, memberships, affiliations, referees, coaches and instructors, agents, transfers & refunds, sports justice procedures, and many more. The system also interfaces the backend of other public administrations, financial institutions and strategic suppliers.
In 2019 FIP decided to start an ambitious project to allow all the registered basketball players, coaches and referees (over 500,000 people) access the system directly and manage their own information and bureaucratic practices via a dedicated web portal.
In order to achieve this result, it was decided to gradually decompose the monolithic backend of existing legacy system into smaller, loosely coupled service components exposing a GraphQL API, with the main goals to reduce maintenance costs and improve scalability.
However, such migration toward a more flexible and distributed architecture had to be performed gradually, without any impact on the availability of the legacy system, while concurrently improving and extending each migrated functionality.
After a preliminary analysis, it was decided that the first service component to be implemented would have been the common registry of all the people the ERP was managing (about 1.5M people), and Livebase was selected as the best technology to create such module, given the limited time available and the complexity of the registry data model.
A team of two analysts have used Livebase to model and generate the a new service component along with its database and its GraphQL API. Then, a team of three software developers completed the integration in three steps: they (1) refactored the legacy ERP backend to make it invoke the API of the new service component for all write operations, rather than accessing the ERP database; (2) plugged into the service component the little code required to align the ERP database; (3) developed a dedicated client for the new service component.
The following pictures shows the overall system architecture before and after introducing the new service component generated with Livebase (shown with orange background).
Once the new service component was integrated with the legacy system as described above, developers could easily and gradually comment-out business rules implemented in the legacy systems and replicate their logic as either extensions of the component’s model (i.e. using the Livebase Designer, without coding) or as plugins of the component.