SPReaD: service-oriented process for reengineering and DevOps

Carlos Eduardo Da Silva,Yan De Lima Justino,Eiji Adachi

doi:10.1007/s11761-021-00329-x

Abstract

The reengineering of systems into a microservice-based architecture can be seen as an implementation of a service-oriented architecture (SOA). However, the deployment of SOA into an enterprise is a challenging task, as it may involve the modernization of mission-critical systems with high technical debt and high maintenance costs. To this end, a process is required to provide an appropriate set of steps and techniques that minimize risks and at the same time ensure the quality of the systems during the migration process. Thus, this work presents the Service-oriented Process for Reengineering and DevOps—SPReaD, an instantiation of the mainstream SOA methodology focusing on the reengineering of legacy systems integrating DevOps aspects for developing microservices systems. This process has been defined during a real software reengineering project of legacy systems from a Brazilian State Department of Taxation. The results obtained include a substantial improvement in the quality of the main taxation system used by the state, including not only code-related metrics but also performance improvements of the services offered, and a change in the methodology adopted by the software development team.

Highlights

Microservices can be understood as a software approach and system architecture built upon well-established concepts of modularization and technical boundaries [14]
We presented the Service-oriented Process for Reengineering and DevOps (SPReaD), a process for the reengineering of legacy systems into microservice architectures
We presented a report of an industry project applying SPReaD to reengineer the UVT system, an information system maintained by the Rio Grande do Norte State Department of Taxation (SET)

Summary

Introduction

Microservices can be understood as a software approach and system architecture built upon well-established concepts of modularization and technical boundaries [14]. It has been the choice of development teams eager to adopt emerging practices whose design, standards, and technologies favor more streamlined software delivery. A Service is a software published via an API, which is part of a contract and provides a collection of resources [6]. These resources are grouped into logical units that represent a functional context. Microservices do not constitute a new architectural style different from SOA, but qualify an implementation of SOA with state-of-the-art software engineering practices [31]

Methods

Results

Conclusion