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 (http://www.ruleml.org/, 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.

Tags: ,

  • I agree that there will always be a need for coding. I am a strong supporter of the “write it from scratch” club, in most cases. I’ve worked on other systems, trying to customize them to the needs of businesses, but mostly it ends up being a messy heap of code that is difficult to maintain or even understand. Indeed the tools today are so powerful and efficient, that it is actually, IMHO, better to write your own code rather than try to change someone else’s. And not only is the creation process easier, it also makes the product more maintainable for the future (if the coding is done properly, of course).

  • abraham

    Eish! I too, subscribe to the “write it from scratch” club. But then I must admit that my favourite memories as a jnr programmer were when I had to figure out somebody else’s spaghetti code and improve it. [I’m sure the next guy that looked at my code also thought “what on earth is going on here…!”]

    My point is though – as you progress through life as an IT professional, you end up not wanting to unravel other people’s mysteries – you are happier creating your own. And that’s where coaching and mentoring comes in…..I digress.

    I love the fact that I am now able to look at a problem/piece of code and spot the “error in the logic” and improve it, or just decide “stuff it! I’m re-writing this!” And, as has been reiterated, the tools nowadays give us more options and possibilities.

  • admin

    I would venture to say that all developers like to do things from scratch. It’s in our nature to want to express our creativity in that way. That’s why we do what we do, and why we enjoy doing it.

  • MattKing100

    Applications can be artifically segmented into four types:

    1) Hand coded
    2) Visual IDE (code generation, with optional access to code)
    3) Toolsets/Templates (code generation, without access to code)
    4) Configuration (no generation, just switching options on and off).

    Growth in type 3 is gaining momentum fast in offerings from the enterprise vendors, no doubt to address the well known “pig in a shoebox” limitations of type 4. This will reduce the needing to resort to type 1 where type 4 is lacking. Interestingly, type 3 presence is an acknowledgement of the weaknesses of type 4.

    In otherwords types 2 and 3 are a natural evolution to address the contrasting disadvantages of types 1 and 4.

    Having said that, all 4 will each make up about 25% of how application functionality is delivered to end users (calculated as an average across industries). In otherwords they all serve different yet equally important purposes. The tricky part, for a client, is choosing the most appropriate mix for their business. But having four options is a lot nicer than having only two!

    Side note: SOA will allow applications to be “mixed and matched” and changed more easily without disturbing other applications. Composite applications will allow “virtual” applications to be build which cobble together bits from “real” applications. Composite applications should be avoided as much as possible, but due to the constant churn in application landscapes, there will be an appropriate place for Composite application on a perpetual basis. Put another way, when the number of Composite applications exceeds the number of real applications, then it is time to streamline (overhaul) the real applications landscape. In otherwords Composite applications provide a “change buffer” allowing real applications to be phased in and out over time. An evolutionary rather than revolutionary process.

    Matt

  • admin

    Hi Matt,
    This is a very interesting take on the matter. It sounds like you have researched this topic quite a bit. I like the categorization of software solutions, and if you didn’t get this information from the internet, perhaps you are the right person to write a thesis on this subject :-)
    That aside, I strongly believe that there is still room for (or demand, or that demand will come about because of) a tool or framework that will allow easy modeling of business entities, processes and rules in a simple and generic manner. If this could be done in such a way as to allow exchanging of such information that can be adapted to anyone’s needs (imagine a repository of such business processes on the internet, (freely) available for anyone to use), it would sure be a winner. Maybe a collaborative, open source, open specification initiative is the answer.
    You also make an interesting comment on composite applications. In contrast to your statement, I think that composite applications, rather than being a means to “cobble together” existing systems or applications, should force companies to rethink their systems from a service-based perspective, and to design enterprise services from the ground up. Only then can the power of composite applications truly be realized.
    Martin

  • admin

    Hi Matt,
    After just reading through your list of categories again, I realized that there may/should be another option, and this is where I would place my utopian framework mentioned above. Under 3) Toolsets/Templates you talk about code generation. The system I have in mind would not be generating code, but would be an engine that processes definitions of entities, processes and rules. This to me would represent perhaps the “holy grail” of business software; something which, if it could be achieved, would give unprecedented power and flexibility to companies in the way they model their business systems.
    Martin