In my recent post on data messes, I left an IOU for a discussion of application databases. I’ve addressed parts of that subject before, including in a 2013 post on data model churn and a 2012 post on enterprise application history, both of which cite examples mentioned below. Still, there’s a lot more that could be said, because the essence of an operational application is commonly its database design. So let’s revisit some history.
In many cases, installing an application allows enterprises to collect the underlying data, electronically, for the first time ever. In other cases the app organizes data that was already there in some previous form. Either way, applications tend to greatly change the way data is managed and stored.
My first group of examples don’t assume nice relational DBMS underpinnings, for several reasons:
- Before the mid/late-1980s rise in relational DBMS, application vendors commonly assumed their apps would run over flat files, e.g. IBM VSAM. In a file-based world, there were a lot of data silos.
- Some software vendors didn’t even assume IBM mainframe underpinnings. That could make their DBMS situation even worse.
- One of the early application categories to get started, bill of materials planning, was well-suited for pre-relational systems.
I don’t know how many applications there now are in SAP’s core suite, but it’s many 100s at least. Back when I became an analyst in 1981, however, few application software companies had as many as 10. Indeed, industry leader MSA ran an advertising campaign around its “Big Eight” apps, as wordplay on what was then the phrase describing the major accounting firms,* namely:
- General ledger
- Accounts payable
- Accounts receivable
- Fixed assets
- Human resources
*Since reduced greatly in count, because of mergers and Enron.
But even those few applications, running in batch rather than interactive mode, weren’t integrated. Indeed, Payables, Inventory and Purchasing each had their own vendor files. A major feature in those days was the “Three-Way Match” between those applications, and I learned to challenge “our apps are integrated” claims with the question “How many vendor files do you have?” Not until the mid-1980s did I confidently expect the answer “One”.
Similarly, a major differentiator for retail banking application suites was when they had a halfway decent “customer information file”, pulling data from customer silos for some kind of very elementary customer-interaction functionality.
In yet another example — if you stipulate that data dispersed among multiple organizations is the biggest mess of all, then it’s easy to understand why Ordernet made such a large business out of connecting them.
And then there was Marcam, which I’ve cited before as having one of the most significantly patented technologies in the history of the software industry, and more generally the category of process manufacturing support. Manufacturing applications — starting with bill of material planning — generally assumed that discrete objects were manufactured out of discrete parts. But what if you made batches and flows of (generally liquid) stuff — orange juice, steel (which is molten in its early stages), or gasoline? Complications could ensue including:
- There would be multiple “byproducts” and “coproducts” — think of all the different outputs of an oil refinery.
- Inputs would be of varying quality and nature. One tanker of oil is not exactly like the next, and same goes for different truckloads of oranges.
Despite manufacturing applications generally being quite a big business already, their data models were lousy for process manufacturing, and hence different vendors were able to shine.
I’ve always supposed that SAP was early in process manufacturing, because I know a lot of its early traction came in the chemical and pharmaceutical industries — certainly in the US, and I presume in its German origins as well. But I don’t recall whether that supposition is actually correct.
Eventually — and I’d time this to early in the relational era — applications became pretty good at elementary database design. Still, room for significant differentiation remained. One example was central to the rise of PeopleSoft — it’s software was very good at rearranging hierarchies, especially of employee/management, and that database flexibility (instantiated via PeopleTools) had strong application benefits.* Another and more important example was SAP weaving business process/workflow into the heart of its applications.
*PeopleSoft was also early with a client/server architecture, but I count that as more of a UI advantage than anything else, even if a lot of database programming was technically involved. For one thing, early client/server programming, with its heavy dependence on server-side triggers and also on fat-client code — well, I think of it as a possible origin for the Flying Spaghetti Monster idea.
Finally, there’s my favorite example of all. By the early 1990s, MCI had risen to challenge AT&Ts dominance of the long-distance phone call market. It developed and spent massive national advertising dollars on its “Friends and Family” program, wherein you got significant discounts for calls to a named group of people. Amazingly, MCI rolled out the program, including doing application development, within 10 weeks of conceiving the plan. AT&T, which got hammered by the initiative, wanted to respond quickly — but couldn’t. This was a huge triumph based in large part on software agility, and database management was surely a non-trivial part of the whole.