ERP Transformation Success: Speeding Delivery and Cutting Costs

Introduction

Project background – the customer needed an extensive architectural transformation. Migration to another platform on a stable web application was needed. It was necessary to develop a working application on a new platform within this project.

The application itself consists of two main components – the frontend and the backend. Historically, .NET technology on an IIS server is used at the frontend, and the backend runs on Java on a Tomcat server.

The main objective of this project was to migrate from the .NET part on an IIS server to a single technology stack (Java + JavaScript).

The customer wanted to finally receive the following benefits:

Thanks to the reduction of the technology stack the development and support of the application should become simpler.
It is possible to switch to a Linux server, which will allow implementing containerization on the project. At the same time, the customer wanted to get a number of benefits within the framework of the CI/CD culture.
The cost of infrastructure ownership should be significantly reduced.

Project main challenge

Migration to other platforms is in some respects a typical task, because problems are usually the same:

A huge number of relationships that do not allow to quickly find the migration algorithm.
A large number of uncertainties that do not allow to adequately assess the complexity of the task.
A large number of technical difficulties make the process long and non-transparent for the customer.
It is quite possible that a solution to the problem will not be found within a reasonable time frame. And the customer wants to know as early as possible whether it is expedient to implement this project.

However, it must be borne in mind that although the problems are the same, the solution in each case is absolutely individual.

In our case, the customer initially did not know whether it makes sense to invest in this project and needed a detailed assessment of the labor intensity. But how to make an assessment if the project is complex, has a lot of non-trivial solutions and requires a lot of time for initial research?

For these reasons, our project roadmap was as follows:

To conduct basic research and describe the current architecture of the application.
To offer several options for the architecture to which we propose to switch.
To apply the Assessment of Assessments method in order to agree with the customer on the time that we need for the initial study of the project complexity.
To create a working prototype of the new application.
To refine the prototype to a finished solution.
To implement the solution in production.

Let’s consider each stage in detail.

Describe the architecture of the application as it is at the moment:

The most important element for tasks related to architectural transformation is well-developed documentation. Since there are many small details in the process, it is critical to include them all in a diagram or document. This allows to process all the required elements within the project and greatly reduces the risk of critical difficulties.

As part of our project, to describe the system, we first made a deployment diagram, which showed all the components of the application.

Also, this diagram showed the interaction of the key components of the application – something without which the application, in principle, cannot function.

After analyzing all the files and components, both major and minor, a sequence diagram was drawn up. This diagram shows how data is exchanged between the frontend and the backend. This made it possible to determine the key functionality of all elements and evaluate possible ways

Identify possible solutions:

When we have a sufficiently detailed description of the current situation, we can proceed to work out the concept of solutions. It is very good to have several possible options at this stage for achieving the goal. This allows taking a broader look at the problem and choose the best solution based on all the influencing factors.

Based on the analysis of system current state, the team proposed the following options:

Migrate the frontend part to the existing Tomcat server where the backend is located. At the same time, rewrite the .NET part of the application using Java.
Replace IIS with another Tomcat by rewriting the .NET part on Java.
Replace IIS with an Apache server, leave only the static and dynamic JS parts of the frontend on it, and implement the .NET functionality as a separate module on the backend.

Option No. 3 was chosen as the best one, since in this case the estimated labor intensity and risks were minimal. The result of the work at this stage was the creation of deployment diagrams and the sequence of the future application.

How to estimate the complexity of a project with a very high degree of uncertainty:

We have a contradiction. We need to make a decision – whether to implement the project or not. The decision is made, among other things, taking into account the project complexity. But since the project has a very high degree of uncertainty, it is not clear how to deal with the risk that the labor intensity will greatly exceed the declared deadlines.

In a normal situation, we would allocate time to assessment, evaluate the task, and then make a decision. However, in the case of migration tasks, this cannot be done. To be more precise, the assessment process may be too superficial and then the risks of missing the deadlines will be very high. One can treat the assessment process as a separate small project. This will allow for a deeper qualitative assessment of labor intensity and risks minimization. But such an assessment is certainly more laborious.

As part of our project, we took another path. And the first question that we had – how long will it take to carry out a deep assessment of the project? To answer this question, we applied the Assessment of Assessments method.

The entire project is deeply decomposed. In our case, the work on the project was divided into 63 tasks and 14 sections. The developer had to give an assessment for each section – how much time it would take him to assess the time needed to complete the work on it. That is, to assess the assessment.

The result of this detailed decomposition gave us a fairly accurate estimate of the time we need to plan and evaluate the work related to migrating from an IIS server to Apache. That is, this is only the time that we need to assess the work on the transition and create a work plan. Ultimately, the assessment of the assessment took approximately 25% of the time needed for the entire work. About 25% was spent on the assessment. So, the customer received decision points for the research project, which made it possible to greatly increase the project predictability level.

The customer was satisfied with this result and approved the conduct of research work to assess the complexity of the project itself.

Assessment of the project complexity:

When assessing the project complexity, it was important to show that we not only assess the project, but are also ready to prove the concept we chose. Therefore, as part of these works, we made a prototype that showed the fundamental performance of the solution we chose.

So, as a result we provided the customer with a study containing an estimate of time and showed a prototype with basic functionality.

The customer was satisfied with the prototype and estimation. The next step was to bring the prototype to a fully functional state so that it could replace the current frontend server on IIS.

Create a working prototype of the new frontend application:

At this stage we began to refine the prototype. Support for key components was added to it, and a prototype that was intended to replace a working frontend server on IIS for all key functions was finally demonstrated.

Since the application was covered with many GUI autotests, the customer approved the acceptance of works after the prototype successfully passed all key GUI autotests.

Refine the prototype to a finished solution:

At this stage, all remaining functionality that was not transferred to the prototype was first defined.

Further work was based on standard development processes:

To add the remaining functionality.
To check its performance using GUI autotests and manually.
When all the functionality was implemented on the stage server, to carry out complete pre-release testing.

When a ready solution on a new platform was created, this project was accepted by the customer. The subsequent migration from an existing solution to a new platform in a production environment was already carried out as part of a separate project.

Conclusion

In order to migrate to another platform, it was necessary to conduct a detailed analysis of the current system. The task itself was complex and non-trivial due to very high risks both in terms of delays and in terms of possible problems that could arise during implementation. The customer worried whether it was possible to implement this project within a reasonable time frame with the required quality.

However, our experience in implementing such projects helped us approach the problem in the right way. And the necessary expertise of our engineers made it possible to successfully complete the project.