August 7, 2015

Application databases

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:

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:

*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:

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.

Comments

4 Responses to “Application databases”

  1. Data messes | DBMS 2 : DataBase Management System Services on August 7th, 2015 10:02 am

    […] Finally, suppose we return to the case of operational data, assumed to be accurately stored in fielded databases, with sufficient data integration technologies in place. There’s still a whole other kind of possible mess than those I cited above — applications may not be doing a good job of understanding and using it. I could write a whole series of posts on that subject alone … but it’s going slowly. So I’ll leave that subject area for another time. […]

  2. Notes on packaged applications (including SaaS) | DBMS 2 : DataBase Management System Services on October 7th, 2015 7:28 pm

    […] 4. This is actually an example of a more general point — packaged or SaaS apps generally assume rather fixed schemas. (The weasel word “rather” is included to allow for customization-through-configuration, but I think the overall point holds.) Indeed, database design is commonly the essence of packaged app technology. […]

  3. Enterprise application software — generalities | Software Memories on November 11th, 2015 5:29 am

    […] August I reviewed some important examples of application databases. That post also links back to several things I wrote about enterprise application […]

  4. Issues in enterprise application software | DBMS 2 : DataBase Management System Services on November 11th, 2015 8:40 am

    […] August I reviewed how central database design has been to application software over the […]

Leave a Reply




Feed including blog about software history Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.