RefStratERP – A Refactoring Strategy for ERP Systems

Sammanfattning: Enterprise Resource Planning (ERP) systems are used to integrate all functions of an enterprise. They often evolve from a smaller monolithic object-oriented application, covering one functional area and organically grow over time in features and size until all functional areas are covered. Once they reach certain size, unrestricted dependencies among numerous classes increase complexity of the system and make it harder for development team to create new features and maintain code stability. This creates problems to further evolution of the ERP system and poses a risk to economic consequences for company developing it. ERP refactoring strategy, together with process of its creation, is presented in this thesis. It can be used with ERP systems, having architectural issues, with a purpose to improve quality of system’s architecture and thus prolong its lifecycle. The goal of modularizing monolithic system it pursued with intention to reduce complexity and make it easier to reason about the system. This architecture-level refactoring strategy is created for one specific medium-sized ERP system through iterative trial-and-error explorative approach. This thesis is carried out at the main development site for this ERP system by project team consisting of employees working on its development. The result shows the RefStratERP, an innovative refactoring strategy consisting of target architecture, refactoring process to reach it, refactoring principles and refactoring limitations. Contrary to initial expectation, arranging domain modules (modules containing business logic) in directed acyclic graph (DAG) is, in general, not feasible without sacrificing internal module cohesion of business logic. Accidental unidirectional dependency between two domain modules is at risk of becoming bidirectional under changing business requirements. On the other hand, non-domain modules (modules without business logic) could be completely separated from domain modules in a way that domain modules depend on non-domain modules. This comes from underlying nature of business domain and the fact that functional areas of an enterprise are interdependent.