Traditional approaches to designing IT systems are based around the well-established techniques of modeling the business processes that the system needs to deal with. For example, you set up the system to “place an order” and then model in detail the data that is needed to support these processes, e.g. “customer name,” “order number,” and “delivery point.” The process model and the data model then form the basis for the specification of the system.

Unfortunately, there is one big problem: the carefully crafted business and process models used as the basis for the systems design are afterwards stored away in a cupboard. In other words, the database schema becomes “hard wired” into tables and columns. This is fine if nothing ever changes, but it is the nature of things that something always does, and that’s where expensive maintenance comes in.

In the 1980s large companies started to build “data dictionaries” of data structures and some business rules, but since these were not directly connected to the systems development process, they tended to become out of date and regarded as an overhead. Moreover, the tools available to visually represent the data and processes were awkward and used terminology unfamiliar to most business people, so ended up being systems analysts’ best guess of how the business rules worked - a rarely accurate one.

An approach to this problem in the 1990s was the “upper case” tools such as IEF, which captured the data and process models in a data dictionary, and then generated code from these models. In principle, when something changed in the business, the systems code could be regenerated. This indeed had considerable merits, yet the approach ultimately faded into obscurity because of other limitations; e.g. the code generated tended to be inefficient and often required significant customization, which rather defeated the object. So people went back to doing things the old way, using 4GLs (remember those) to build systems faster than in the old 3rd generation languages like COBOL. In parallel, more and more functionality could be bought in packaged software, but the problem remained: a software package needs to be customized to a specific business, and if that customization involves actual programming, the maintenance bill starts to rise again. One only has to look at the often extensive tailoring of SAP systems using the ABAP programming language, and the consequent costs of even a simple SAP systems upgrade, to see this. Indeed various studies have shown that the maintenance costs of application packages are essentially similar to that of custom-built systems. There may be many advantages to software packages, but big cost savings on maintenance is not one of them.