Culture problems: Agile & ERP part 3

I suggested some cultural problems with software development in an ERP setting in my second post on Agile and ERP, this time I want to look more closely at the differences in the two cultures.

Many of the cultural issues revolved around the fact that ERP tends to happen in a corporate IT environment, and since corporate IT is a more challenging place to develop software anyway an ERP system is going to have “the usual” corporate IT problems.

However ERP systems seem to be prone to even more cultural problems.

I’ve already said that ERP systems are monoliths, and I’ve also hinted at the fact that they are hierarchical in nature. In part this is a historical hang over, they come from the Cobol mainframe world when systems were written like that.

If you know Conway’s Law what I am about to say is obvious: organizations developing, sorry, configuring, ERP systems are themselves hierarchal and monolithic. Separating the HR development from the Logistics development is hard.

This is actually a great example of Reverse Conway’s law (sometimes called Yawnoc): the organization is a copy of the system architecture.

When an organization buys an ERP system they buy a large, monolithic, hierarchal system, the investment (financial and personal) required from senior managers mean the homomorphic force is strong. Therefore the organization which engages with the system becomes a copy of the system - reverse Conway’s.

(On the bright side, since these systems are designed to serve yesterdays needs using technology based on yesterday’s paradigms there should be an opportunity to disrupt this model - but that is another topic for another day.)

Lets talk about some details…

The first problem hits you right out of the box, literally.

An ERP system is sold and marketed as an application which does not require programming, it only requires configuration. Take careful not of that word: configuration, not even customisation and certainly not programming. This is very sophisticated marketing.

ERP systems cost millions of dollars to buy and operate them. Very few technical people will ever have a say in the purchase of such a system. The sales people deliberately talk of such systems being configured (without programming) in order to say to the buyers “Look you don’t need any pesky (expensive) programmers.”

Instead they plant the idea that you install SAP, go to the tools menu, select options, choose the right tab, click on the box and … et voila! — the system is configured. OK, its a big system so it needs a “lot” of configuration but you get the idea.

This isn’t so.

The kind of configuration required by ERP system is far more akin to programming than any ERP seller would ever admit. It might not be the kind of programming recognisable to a Java developer but it is programming in a different paradigm.

Sometimes it is table based programming - a kind of predicate Prolog rules system.

Sometimes it is lots of parameters - think .ini or XML files but probably in some arcade syntax.

Sometimes it is quite literally lots of pointing and clicking.

And sometimes it is actual coding, usually in the systems only language, SAP uses a Cobol like language called ABAP while Microsoft Dynamics uses Frankenstein version of C++ called X++.

Note also, that because just about every ERP system I know of is actually an assembly of multiple different products built by different companies at different times and smashed together by the current vendor you are likely find all these approaches and multiple languages on the inside.

The first big problem to overcome when faced with an ERP system can be simply convincing people that programming is required. Or rather, that the kind of rules and thinking which apply to major programming efforts need to be taken here.

That programming is required is provable because there are always Testers. If configuration really was straight forward no testing would be required. Since ERP systems are always tested that which is called “configuration” is clearly more than tools, options, click. Clearly there is the possibility that two different pieces of “configuration” interact in unexpected ways.

Because ERP systems emphasis the business functionality and disclaim programming they claim to be configurable by practitioners, e.g. accountants, HR professionals, logistic experts. etc. Indeed you probably need to have domain skills to configure it but you also need technical skills.

Thus the people doing the “configuration” do not see themselves as programmers. They rarely have a programming background, concepts like cohesion, coupling, separation of concerns, interfaces, etc. are foreign to them and they wouldn’t know dependency inversion if it is turned them upside down - or any other pattern for that matter.

It is not that these people are stupid, actually they are experts in their own fields; rather because they do not believe they are programmers they take little interest in software engineering concepts. And since their education was in their expert field (logistics, accountancy, human resources, etc.) they they never learned these concepts at school.

Unfortunately when you program a big system, a big anything, having software engineering knowledge really helps - that is why the discipline came into being.

Worse than this, because the “no programming required” concept is encouraged by the vendors the programming systems inside the ERP systems also lack modern software engineering concepts. Remember: ABAP is Cobol, Cobol is not a modern language.

Like Cobol, ERP languages such as ABAP and X++ have a “commercial orientation” and lack the idioms required for engineering. On one ERP implementation I came to feel the whole thing was just Visual Basic on steroids - and VB6 at that! Such languages are Turning complete so you can do (in theory) do everything but somethings these things are damn hard.

The ERP culture creates other problems too.

There is no OpenSource for ERP. Nobody ever went home at night and wrote ABAP for release under the GNU license. As a consequence the kind of tools modern software engineers expect do not exist.

While ABAP-Unit and X++Unit exists they are not as widespread or as usable as JUnit.

Nor will you find Stackoverflow full of ABAP or X++ questions and answers. Sure there are a few but only fraction of what you will find for Python. To be fair, the number of ABAP or X++ programmers is only a fraction of Python, C# or Java programmers anyway so while some public resources exist there are tiny.

Many ERP “developers” work for system integrators (CapGemini, Accenture and countless small shops). They charge high rates for their people and take a very fluid approach to staffing. For example, an SAP HR “consultant” on a team I was working with had a two week holiday. The consultancy company sent another consultant to fill in for the two weeks she was away. I find it hard to believe the stand-in consultant could usefully do anything for the client in that time but by being there they could bill time for the system integrator.

A side effect of this is that the consultants are often in high demand, they may work on multiple client projects at once, and they are internationally mobile, they get lots of frequent flyer points.

This has some very practical limitations, these people may not devote 100% of their headspace to the client and getting a standup meeting to start early or at a regular time is hard it may depend on Heathrow congestion.

And because they work for someone else the client and the consultancy may not agree on who pays for any Agile training or workshops. I’ve found myself giving Agile workshops to client staff where the ERP consultants are excluded because they work for a supplier. Even when the client hires the staff directly, or the client and supplier agree, the ERP Consultants may resist learning about Agile, and especially technical considerations, because they do not consider themselves technical!

And when the ERP consultants do engage its is like stepping back 10 or 15 years, all the “old” arguments appear: “how can we do something in 2 week?”, “we must design the whole”, “the business must fix its requirements”, etc. etc.

In the next instalment we’ll turn to the bad news, the technology…