Assessing Legacy ERP Systems With Wardley Maps

DZone 's Guide to

Assessing Legacy ERP Systems With Wardley Maps

Can legacy ERP systems do more harm than good?

· Agile Zone ·
Free Resource

Let's talk about today's Swiss army knife software systems called "Enterprise Resource Planning Systems" (ERP systems). These are really powerful tools, no question, but in some situations, they can cause more harm than good — especially when they are really old and called "legacy systems." So, I want to tell a fictive story that shows how an organization can get deep into trouble. For this, I’ll try to use Nick Tune’s brand new Core Domain Patterns and Wardley Mapping (if you aren't familar with Wardley Maps, I recommend watching the YouTube video "Investing in innovation").

For understanding the context around ERP systems better, we first take a brief look at the role of IT systems in the past decades:

  • 1970s: Automation of processes/rationalization
  • 1980s: Achieving economic goals
  • 1990s: Enabling new business processes
  • 2000s: Differentiator in business models
  • 2010s: Integration hub for reaching new markets

Especially in the last two decades are very interesting: Differentiation from other competitors via unique features with the help of IT systems in the 2000s and competitive advantage with flexible API integrations in the 2010s. Let's think back to the early 2000s. Our company sold goods at online marketplaces like eBay. No other company could integrate APIs from various marketplaces as we did. We were the stars among the API integrators. Integrating was our core business! For faster time-to-market, we used a brand-new ERP system.

You might also like: How to Convert Legacy Applications into Future Proof Applications

We didn't have the ERP system just for API integration alone, but also for all this generic stuff like invoicing where we wouldn't create our own separate application for this, of course (we were not stupid!).

But our salespersons had always special requirements for us ERP system developers. We just couldn't deny a wish from them. This came with a cost over time: All this customizing was expensive and heavily dependent on the internals of the ERP system. Yes, there were things like interfaces and a vendor-specific database schema, but who cared? Nobody could pimp the ERP system as we did. As technical savvy developers, we even customized the base module of our ERP system (ERP v1', green colored).

Some years passed by and suddenly (who had thought of this!) a change in the law regarding invoicing happens. A new version of the ERP system was released (ERP v2, red colored), bringing all compliance updates for the invoicing module for free (red colored, too)! We just would need to update to this version and everything would be fine.

But wait a moment. A few years ago, we changed the ERP base module so heavily with the cost of not being able to update to new ERP versions. It was a deliberate decision to enable the super cool API integration tool based on ERP functionality. It was totally OK past then. But here we are now, stuck in the past because of our massive adaptations of the ERP system's internals. This creates huge inertia (red thick lines).

We've invested a huge amount of financial capital for this. So we don't want to throw away all the investments. But even if we would want to pay the price, we wouldn't be able to update because all modules in our system are now depending on an undefined mass of customized code in the base module. The risk of losing all the valuable micro-optimizations all over the place is simply too high. This leaves us with only one option: Ensuring that the old version of our invoicing module is compliant to the new law regulations. So here we are, programming our own module in the generic subdomain (red colored component on the lower left). This simply means wasting money!

But it gets even worse: With the new ERP system, there is also a new super cool API integration just out of the box (violet colored). All our competitors can now update to the newer system. Our differentiation vanishes completely in comparison to our competitors, leaving us behind because we cannot use this opportunity: We are still stuck in the past (violet thick line)!

We ran into "Table Stakes Former Core": Our former core asset was degraded to a mere supporting function or liability, leaving us with maintaining ordinary supporting and generic subdomain modules. No new core, no new chance for differentiation but buried with the challenge to keep the old system running, because we have no more money to get rid of all the mess. 

The Unhappy End.

What's the Moral of the Story?

Nobody can foresee the future, but there are some things that you can avoid. When using an ERP system, don't mess with the ERP's base module for creating a differentiator of the cost of not being updatable. Have in mind that you also have modules of other strategic (non-)significance that depend on the base module. In the worst case, the tide may turn and you are left with just supporting and generic modules that you have to maintain at high costs, leaving you with no differentiation on the market.

And on the meta-level, I hope that you saw how you can explain this situation with Nick Tune's Core Domain Patterns and Simon Wardley's Wardley Maps. These are great tools for strategic thinking!

 Oh, and please leave a comment to discuss!

Further Reading

The Challenges of Legacy Software

Solution to Legacy System Gridlock

enterprise architecture ,legacy systems ,strategic design ,domain driven design

Published at DZone with permission of Markus Harrer . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}