Automated modernisation - Part 3

Application in organisations

Modernisations are very exciting from a technical perspective. From the perspective of the project or product managers, however, things look different. In this blog series, Open Rewrite is a tool for reproducible, testable and efficient modernisations. The first article on this topic explained the basic concepts of Open Rewrite. The second article dealt with the technical implementation of recipes and this article discusses the use of Open Rewrite in the context of an organisation's application portfolio. The use of internal libraries, application portfolios and efficient use as a service will be discussed.

Recipes for the migration of internal libraries

Standards and best practices are the cornerstones of efficient and homogeneous software development within an organisation. These standards often manifest themselves in centrally managed dependencies and best practices in small software artefacts. These basic artefacts are combined with the other dependencies and the business logic to form an application. This approach results in a high degree of similarity in the applications, which makes it easier for developers to switch between applications.

A major disadvantage of this approach is when the basic artefacts contain security vulnerabilities or require general updates. The use of artefacts in many or all applications results in a high degree of coupling. This coupling means that a change to the basic artefacts necessitates a change to all applications. Even if the adaptation only takes a few minutes, the additional work quickly adds up. This is where the use of Open Rewrite comes in handy to automate these manual adjustments. Ideally, the necessary recipes are provided by the developers who have also updated the basic artefacts. This is because this group in particular knows the special features and pitfalls of their own product and can therefore develop customisations efficiently.

The large Java enterprise frameworks such as Spring Boot and Quarkus also use this approach. For each new version of the frameworks, part of the core development team of the frameworks works together with the open rewrite community to develop recipes for the automated migration of software projects. If your own recipes cannot or must not be shared with the Open Rewrite Community, it is also possible to create a dedicated Maven artefact for migrations using the Recipe Starter Template. This artefact can now be used by the project teams to migrate their use of the base artefacts.

This combination of internal libraries and direct Open Rewrite Migration Recipes can be used to minimise the effort involved in reuse.

Modernisation of an application portfolio

In many organisations, not just one application is developed, but an entire portfolio of more or less up-to-date applications is maintained. Due to the reuse of proven patterns and procedures, many applications in these portfolios have a similar structure.

Due to the time lag in development, it is not uncommon for different old libraries to be used. If this portfolio is to be modernised, the same steps must be taken for many applications. Unfortunately, additional steps are added with each new version or library. These can often be implemented with Open Rewrite and can thus be reused in subsequent migrations.

This is where Open Rewrite can score points with its large pool of supported libraries. It is worth looking up the recipe catalogue when planning a migration step.

In order to migrate a complete application portfolio, some analysis and planning is required in advance. The first step is to prioritise each application. This priority is highly dependent on the organisation and its short-term plans.

In addition, the number of migration steps required for each application should be analysed and their rough order of magnitude determined. The number of migration steps and the total order of magnitude can now be used to create a sequence of individual application migrations that minimises the differences in effort between two successive migrations.

If the migrations are carried out with Open Rewrite and processed in the selected sequence, the previous migration can be reused in each migration. This avoids duplication of effort and reduces the total effort across all migrations. Together with the organisation's priorities, this allows very efficient migrations of complete application portfolios to be carried out that are tailored to the needs of the organisation. This procedure can then also be used iteratively in small steps to keep the homogeneous modernised portfolio up to date.

Keeping an overview more efficiently

Many migration efforts fail or are subsequently judged to be too expensive. The main reason for this is the underestimated complexity and manual implementation. Manual implementation can be automated with Open Rewrite and Open Rewrite also provides tools for the underestimated complexity. Data tables and search recipes can be used to automatically collect data and make the complexity more tangible. Search recipes use the same API as all other recipes. However, their results are not modified source code, but rather markers on elements, so-called search result markers. This allows the use of a specific method or interface to be analysed, among other things. These findings can be exported in so-called data tables. The findings are saved as lines in a CSV file and can be used for further analysis.

The ordering of applications according to migration effort described in the previous section can be created purely on the basis of data using this procedure and therefore becomes more meaningful.

A run of Open Rewrite can only collect data from one project. This restriction means that the data for each application in the portfolio must be collected individually and aggregated manually. The company behind Open Rewrite, Moderne Inc, has created the fee-based Tool Moderne CLI, which allows several repositories to be analysed simultaneously from one CLI. Using this tool eliminates the need to run Open Rewrite multiple times. The SAAS product Moderne Plattform goes one step further, not only enabling automated roll-out to an entire portfolio, but also enabling automated reporting through aggregation. By using Modern Platform, the effort and necessity of migrations are clearly presented to stakeholders.

Conclusion

This blog series has described the basics of Open Rewrite and the possibilities for extending it with your own recipes. In this last post, the possible application in organisations was described.

In recent years, adesso has gained a great deal of expertise in the area of modernising existing systems. This knowledge combined with the Open Rewrite tool makes efficient migrations of applications and entire application portfolios possible. We are happy to share our knowledge with you, support you in the realisation of your migration projects or give you a deeper insight at presentations and conferences.

Would you like to find out more about exciting topics from the world of adesso? Then take a look at our previous blog posts.

Also interesting

• Automated modernisation - Part 1: Open Rewrite basics
• Automated modernisation - Part 2: Develop your own migrations