Ideas for #BPMshift – Delenda est “vendor-centric #BPM” – How to modernise a legacy ERP

I was recently asked for advice on how to modernise a legacy ERP. It was developed long time ago to handle the core business. Right now it shows the following symptoms of difficult maintenance:
  • integration
  • incorporation of new technologies
  • old programming techniques
  • heavy releases
  • availability of industrial products for previously unique functionality (e.g. event management)
  • some generic functionality is commodity
  • just slow to evolve
Sure that the root cause is that the ERP had emergent/historical grow not being architected for such evolution.

The goal of modernisation can be formulated as the following:
  1. Agile (with the pace of business) provisioning of business solutions
  2. From disparate IT applications to a business execution platform which will “liberate” people for business innovations
  3. Combine various provisioning methods: assemble, rent, buy, build, outsource, centralised vs. kept locally, standardised, re-engineered or automated
The principles of the modernisation are defined in the following way:
  • Step-by-step technical transformation in two interrelated and intermixed streams:
    1. Disassemble ERP functionality into services
    2. Re-assemble business functionality via processes
  • Business evolution has to drive technical transformation (each transformational step brings something to business and does some modernisation)
Let us start from the simplest part - assemble via processes
  • A processes defines Who (roles) is doing What (business objects), When (coordination of activities), Why (business rules), How (business activities) and with Which Results (performance indicators)
  • Business processes make bigger services from smaller services

Disassemble an application into services schematically looks as the following:

Of course, disassemble of an ERP is more complex:

Advantages of this approach are the following:

  • Use of specific functionality from COTS (e.g. event management)
  • Use of generic functionality from “suites”
  • In-house developing ONLY specific-business-core-functionality
  • Integration of commodity or best-to-fit functionality
  • Faster evolution is possible because of BPM/SOA architecture

In case of transformation of a group of related legacy applications – please see http://improving-bpm-systems.blogspot.com/2013/06/enterprise-patterns-eclipse.html


No comments: