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.
- The first lays out very general issues in understanding and subdividing this multi-faceted sector.
- The second calls out characteristics of specific application areas.
- The third (this one) discusses application software products’ underlying technology.
o. 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:
- Major/core suite, large enterprises – e.g. ERP (Enterprise Resource Planning).
- Major/core suite, smaller enterprises.g., the province of Progress and Intersystems VARs (Value-Added Resellers).
- Remarkably distributed applications. This is where a lot of the more unusual technology choices cluster.
- Other point solutions. Sometimes, a guy just needs a catch-all category.
![:)]()
1. The idea of bundling ERP (or its predecessor MRP) with an underlying DBMS has been around for a long time.
- Cullinet and Cincom tried it, but with pre-relational DBMS. Oops.
- Oracle has always had that strategy.
- A sizable minority of SAP’s customers ran
And for smaller enterprises, it has been the norm, not the exception.
2. Expanding on that point for some leading vendors:
- Oracle has always brought its full software stack.
- Microsoft has long brought an even fuller stack, from the operating system on up.
- That said, Oracle’s enterprise apps business is very much a first-class citizen in its product portfolio. I wouldn’t quite say the same about Microsoft Dynamics.
- SAP has made several tries at bringing at least part of a stack.
- MaxDB has been a low-cost DBMS option underneath SAP for a very long time.
- Now HANA and Sybase are targeted to go underneath SAP apps. Indeed, I think HANA is required for a few of them.
- SAP tried to make NetWeaver into a big deal. Opinions vary as to whether it succeeded.
- SAP also has its funky data warehousing layer BW.
- Strictly speaking, Crystal Reports has been in the mix as well.
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,
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:
- Small enterprises with little or no IT staff want the proverbial “one throat to choke”. I.e., if they need to rely on an outsider for IT troubleshooting, they’d like to keep that down to ONE outsider, thank you very much, or at least as few outsiders as possible.
- Selling application software to anybody, especially the core run-your-business stuff, is time-consuming and expensive. So if you go through all that trouble, you want all the revenue from it that you can get.
- The vendors are small, or at least started out that way. In particular, they usually start out by bootstrapping, rather than with a big venture-capital-fueled development bang. So rather than reinventing the wheel, they need to build on the best possible pre-existing technology they can find.
As for what the underlying stacks are, I think that historically there have been three eras:
- Minicomputer (through about the late 1980s). Data General and HP (specifically the HP 3000 series) are two of the big names here.
- DBMS + 4th-generation language + operating system/hardware (through at least the late 1990s).
- Progress and Informix were neck-and-neck in the early days of this market, before Informix refocused on large enterprise sales (vs. Oracle et al.) instead.
- Microsoft has a large presence here.
- IBM, Oracle, Sybase et al. have had large presences almost in spite of themselves.
- While Progress defocused and chased a lot of other markets, Intersystems became a serious competitor.
- Same, but without the 4GL. Eventually, 4GLs started seeming outmoded.
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:
- Retail point-of-sales terminals.
- Automated teller machines.
Stock quote machines are also in this area.
