November 11, 2015

Notes on the technology supporting packaged application software

This is part of a three-post series on enterprise application software over the decades, meant to serve as background to a DBMS2 post on issues in enterprise apps.

0. I’d like to discuss the technology underneath packaged application software. To create some hope of the discussion being coherent, let’s split apps into a few categories:

1. The idea of bundling ERP (or its predecessor MRP) with an underlying DBMS has been around for a long time.

And for smaller enterprises, it has been the norm, not the exception.

2. Expanding on that point for some leading vendors:

3. There’s a huge difference between designing applications to run on one particular technology stack, vs. needing them to be portable across several. As a general rule, offering an application across several different brands of almost-compatible technology — e.g. market-leading RDBMS or (before the Linux era) proprietary UNIX boxes — commonly works out well. The application vendor just has to confine itself to relying on the intersection of the various brands’ feature sets.*

*The usual term for that is the spectacularly incorrect phrase “lowest common denominator”.

Offering the “same” apps over fundamentally different platform technologies is much harder, and I struggle to think of any cases of great success.

4. Returning to the small(er) enterprise market, I mentioned in a companion post that

Smaller enterprises are commonly served by VARs (Value-Added Resellers) that sell complete systems, including application software (proprietary or relicensed), hardware and so on. If the software is proprietary, it’s commonly built on a rich stack.

Reasons include:

As for what the underlying stacks are, I think that historically there have been three eras:

One important design point — the technology could not require much in the way of onsite operation. E.g., the Progress DBMS famously had “zero DBA” operation.

5. Siebel Systems started out with software that ran on laptop computers. This was in the mid-1990s. I still think that’s cool. Sybase SQL Anywhere, perhaps not yet with that name, was originally the underlying DBMS, but Siebel eventually felt it should add bigger brand names as well.

As evidenced by its corporate name, salesforce.com started its SaaS (Software as a Service) crusade serving the same remarkably distributed market of field salespeople that Siebel started out in.

Other examples in my “remarkably distributed” category were hardware-led, such as:

Stock quote machines are also in this area.

Comments

4 Responses to “Notes on the technology supporting packaged application software”

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

    […] The third discusses application software products’ underlying technology. […]

  2. Transitioning to the cloud(s) | DBMS 2 : DataBase Management System Services on December 7th, 2015 12:49 pm

    […] 9. The previous point, and the last bullet of the one before that, are why I wrote in a post about enterprise app history: […]

  3. Notes on vendor lock-in | DBMS 2 : DataBase Management System Services on July 19th, 2016 8:35 pm

    […] The technology underlying packaged applications (November, 2015, but it has a historical focus) […]

  4. Brittleness and incremental improvement | DBMS 2 : DataBase Management System Services on June 20th, 2018 4:14 am

    […] to enterprise applications, which facilitate business processes, have UIs, and commonly involve platform-like technology as […]

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.