The story so far…
- Part 1: Agile & ERP introduced
- Part 2: Good News: Agile can work with ERP!
- Part 3: Culture: How Agile & ERP cultures conflict
In this mini-series I’m discussing Agile development on ERP systems. If you are doing this and you’ve just Googled “Agile and ERP” there is a good chance you’ve found this blog because… bad news… there isn’t a lot of experience of doing Agile in an ERP environment.
Sure people have done it, sure some people have written about it in blog and journals but I said: “some”. Some means “not many”. One of the problems of doing Agile in an ERP setting is that there is a lack of knowledge and experience. People have done this, I’ve “done” it several times myself but… not as many people have done Agile in ERP as have done, say, Agile in Java Banking or some other domain. And very few of them have written their experience up. And even fewer have good stories to tell.
Partly it comes down to a question of “What do you mean by Agile?”. Sure you can do Agile in ERP if you define “Agile” as those “agile” practices which work in the ERP setting. On the other hand, when you do find the examples that are out there you will find many practices missing, specifically the technical practices.
Almost all the reports of Agile in ERP you will find are about process – much like my previous post . Doing ERP with test driven development, acceptance test driven development, simple design, emergent design and refactoring is almost unheard of.
Sure there are a few blogs out there which discuss it a bit but there is not much. I briefed a recruiter to find someone with (A)TDD and ERP experience. He came back a couple of weeks later and said “Its like looking for Unicorns, these people don’t exist.”
In part this is because ERP systems are sold on the promise of EVERYTHING. Their design dates back decades so they are monolithic and the culture that surrounds them is 20 or 30 years behind the current thinking.
My most recent run at this problem was the best yet but here is the bad news: with an ERP system once you move away from the Agile processes practices and start to look at the Agile technical practices things get very difficult.
The cultural problems (corporate IT and ERP specific) don’t help but the technology is the major obstacle. Lets start with testing…
Some test frameworks do exist (e.g. ABAP Unit and X++ Unit) but they are limited and, as with other languages, only a fraction of developers use them, and only a few of them do it properly.
One of the problems is an old one: Mocking and Stubbing. But in an ERP system the Mocking and Stubbing problems are far far worse because the system is provides so much already you need to do more mocking, the system is pervasive, there is just more system to mocks and stub.
Since ABAP is effectively Cobol you can forget reflection, annotation and polymorphic substitution. Heck, I don’t think it even supports macros!
Part of this problem is because of the architecture of ERP systems. The architecture is decades old, its decidedly not Object Oriented, as closer to working in embedded C than Java.
Another problem is because of lot of the system isn’t programmed in text. Remember I said some of the programming was table based? And some was pointy-clicky? That stuff is super difficult to test because it exists in a different paradigm. In some cases even when the “configuration” exists as a code like fragment it is considered data by the system and cannot be extracted.
In once case we exported “the code” only to find it wasn’t coded in ASCII. And if you’ve exported it you might not be able to import it again.
The designers of these systems actually expect their production code to be changed, tinkered with, messed with, hacked, by those configuring the system. Let me repeat: production code from the vendor may be changed as part of a configuration effort. Imagine that when you wanted to write a macro in Microsoft Word VBA you were allowed access to the underlying Microsoft Word code.
These systems are the exact opposite of what John Vlassides would advocate:
“the hallmark of good code is that it is changed by adding to it, not hacking it” John Vlassides, The C++ Report
Changing code by adding to it is a new idea in the ERP world, both for those “configuring” it and those building the product.
But the problems of Automated Unit Testing TDD pale into insignificance when compared to the problems of doing automated Acceptance Test Driven Development (ATDD).
Because ERP systems are monoliths it is hard, if not impossible, to find a way in to add ATDD style tests. These systems don’t just predate microservices they predate components, COM, CORBA, DLLs, shared libraries and even static libraries.
I’ve seen automated test tools work at the highest level, the UI level. I’ve heard Quick Test Pro can run against the UI on Windows interfaces and I’ve seen Selenium run against a Microsoft front end, I’ve even seen Selenium execute a Given-When-Then test but…
This is all at the UI level.
It seems impossible to set up tests anywhere between the very lowest level and the very highest.
If you are lucky the ERP system exposes some services or interfaces you can connect to, for example Rocket U-2 lets .NET code connect to it in places. But such interfaces are not always there, or if they are they are undocumented and subject to change. So most higher level testing needs to be at the UI level….
Since its at the UI level the tests are slow, fragile, slow, difficult to create in advance and slow; the whole system needs to brought up to run them so if something is found its a big pond to fish in.
Since the whole system is being powered up for a test you need test data and this is a problem. If you are very lucky you might be able to get to a relational database and insert your own data, if you are unlucky you won’t be able to access the database or you’ll find its an old propriety hierarchical database and you will need to load lots of data.
And did I mention its slow?
It is not just ATDD tests which are slow the build is slow too. Hours not minutes.
Building might not be much like you know it, I once had to explain source code control to an SAP team. Because all configuration is considered “data” the very idea of source code control can be strange – you are dependent on the vendor actually supporting source control which at one point SAP did not.
Sometimes actually saving “configuration” and loading it into another instance of the system isn’t supported to start with. You may need to build that plumbing.
And remember, these ideas may be completely foreign to the people “configuring” the system. These people are HR or supply chain experts who happened to pick up a bit of ERP and found it pays well. They don’t understand many software engineering concepts, they may not particularly want to learn them and their employers may not want them to either.
As I said before: these systems are large monoliths.
Many of the tools and techniques which software developers have created to manage large systems, to modularise them, to control them, to isolate parts of them, to allow change at different rates are simply absent. ERP systems are not just monoliths the are monopolies, they are intended to form the central nervous system of an organization and run the organization, they are a single thing.
That is their nature, their culture, their technology, even their raison d’être.
That might seem strong but think about it… Senior managers buy these systems to provide insight and control over large organizations. They want the large organization to function as a single entity, they don’t want duplication, they don’t want variation, they want a monolith and that is what the ERP sales people sell them.
So while you might be able to bring some Agile to ERP implementation there is a very deep seated conflict between the agile means and the decidedly non-agile end.
| Reference: | The Bad News: Agile & ERP, part 4 from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
