Categories: Comment, Ideas/Insights, SAP

If the shoe doesn’t fit…

The decade of the 90s was the heyday of ERP systems. Of course, the history goes back much further. Look at SAP, for example, who started in the early 70s by producing “one size fits all” solutions. This was of course a radical departure from the norm up to then, in that most companies wrote their own systems from scratch. SAP recognized a need in the market for such solutions, as the same solutions were being written over and over again. While I imagine that this worked quite well for accounting software like SAP’s first product, R/1, covering other aspects of business is and has been a different story.

Anyone that has been on more than one SAP implementation knows that there is no such thing as “Vanilla SAP”. It is a utopian ideal, but in actual fact, there is no such thing. It’s a term that is used with good intentions at project kick-off events, and bandied around in meetings by zealous consultants, who know full well that it is like talking about Santa Claus or the tooth fairy.

Granted that SAP has been very successful with their offerings, especially in the amount of flexibility built into their systems through no shortage of customizability, there are always aspects of each business (because every business is unique) that cannot be modeled in their ready-made solutions, resulting in endless debates on projects about how best to squeeze a pig into a shoebox (which is a picturesque way of describing the frustration of trying to represent a particular business requirement using only standard SAP means). This sometimes leads to the remark (intended as a joke mostly): “Why don’t we just write the whole thing from scratch?”. Good question.

So if we did go and write a whole system from scratch, would that mean we have come full circle and that we’re back to where we started in the 70s? Not really. Today, we have frameworks, standards, languages and platforms that weren’t around 30 years ago. 30 years ago we had UNIX and pretty much everything was written in either COBOL or C. Today, you can build applications (from scratch) using a number of (for a lack of a better word) tools that lay the groundwork and save you the trouble of reinventing the car.

I think that today you should be able, using available or emerging technologies, to model your organization’s entities and processes as a software system in the same time that it takes you to customize a ready-made solution to do the same thing. For one thing, it will save you the frustration of getting that poor pig into the shoebox. There should be no more “best fit”. One should aim for “perfect fit”.

Having said that, any solution will only be as good as the people that implement it, and their ability to conceptualize real-world problems. Part of the solution lies in having tools that allow one to express business logic in a very natural manner. In this area, consider for example the work done on rules egines by, for example, JBoss, and work to standardize the expression of rules in XML (, etc. – there are a number of initiatives). Not that you’re going to expect your business analyst to write XML, but based on this, it is possible to develop tools that can capture something that is perhaps too dynamic to put into code. (Mind you, scripting languages have been very much overlooked as far as this goes. One problem with putting business rules in code is that it is mostly compiled into binary form, and the compile-link-deploy cycle makes it difficult to maintain).

Anyway, there will always be room for coding. After all, while you can provide a visual interface to ease the development of something, you can never capture all the complexities in a visual interface. Think, for example, of visual administration interfaces on Windows versus command-line administration on Unix platforms, or WYSIWYG versus markup. But that is a discussion for another day…

UPDATE (22 April 2007): I wanted to be clear on something: The standardization of rules mentioned above is just an example of the kind of the kind of standards that make it possible to express something in a universal manner. There are of course many aspects to modeling business requirements, but standardization means a simplification of how we approach modeling and interchange of knowledge about these aspects.

Article info

Leave a Reply

Your email address will not be published. Required fields are marked *