Historical notes on software titan SAP AG. Related subjects include:
- Application software
- (in DBMS2) SAP’s database-related strategies
- (in DBMS2) SAP’s Business Objects business intelligence subsidiary
- (in Text Technologies) SAP’s TREX search engine and Inxight text analytics technology
- (in The Monash Report) Operational and strategic issues for SAP
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.
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:
- Major/core suite, large enterprises – e.g. ERP (Enterprise Resource Planning).
- Major/core suite, smaller enterprises — e.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.
|Categories: Application software, Cullinet, Database management systems, IBM, Informix, Microsoft, Oracle, Pre-relational era, SAP, Sybase||3 Comments|
- The first (this one) lays out very general issues in understanding and subdividing this multi-faceted sector.
- The second calls out characteristics of specific application areas.
- The third discusses application software products’ underlying technology.
1. There can actually be significant disagreement as to what is or isn’t an enterprise application. I tend to favor definitions that restrict the category to (usually) server software, which manages transactions, customer interactions, financial records and things like that. Some other definitions are even more expansive, including personal productivity software such as Microsoft Office, computer-aided engineering systems and the like.
2. Historically, application software has existed mainly to record and route information, commonly from people to machines and back. Indeed, one could say that applications are characterized by (up to) five (overlapping) aspects, which may be abbreviated as:
- Database design.
- Workflow/business process.
- User interface.
The first four of those five items fit into my “record and route information” framework.
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.
I recently wrote a long post on the premise that enterprise analytic applications are not like the other (operational) kind. That begs the question(s): What are operational enterprise applications like?
Historically, the essence of enterprise applications has been data management — they capture business information, then show it to you. User interfaces are typically straightforward in the UI technology of the era — forms, reports, menus, and the like. The hard part of building enterprise applications is getting the data structures right. That was all true in the 1970s; it’s all still true today.
Indeed, for many years, the essence of an application software acquisition was the database design. Maintenance streams were often unimportant; code would get thrown out and rewritten. But the application’s specific database structure would be adapted into an extension to the acquirer’s own.
Examples that come to mind from the pre-relational era include: Read more
|Categories: Application software, Cullinet, McCormack & Dodge, MSA, Pre-relational era, SAP||2 Comments|
Oracle pretty much doubled revenue every year until it got around the $1 billion level. Then things got tougher, industry-standard revenue recognition scandals not excepted. At one point there were only three buildings on the Oracle campus, with large portions of them eerily empty. But the ship righted itself, best exemplified by three transitions:
- Mature financial management arrived in the person of Jeff Henley.
- A serious commitment to product quality emerged, often credited to the late Bob Koii.
- Mike Fields* brought enterprise-class adult supervision to Oracle’s US field operations.
Political battles still raged at Oracle — Mike Fields vs. Craig Conway, Terry Garnett vs. Jerry Baker, and later on Mark Benioff vs. pretty much everybody. But the company was ready to move to next level. Read more
MSA (Management Science America). This section got so long I’m breaking it out as a separate post just about MSA.
M & D (McCormack & Dodge). M & D was MSA’s archrival in mainframe financial software. They had various claims to product superiority, based on having “more CPAs on staff” than MSA and also on being first to market with realtime applications. However, M & D sold out early to Dun & Bradstreet, and lost its edge as key managers left.
M & D seems to have been a lively company. Many stories about drugs or sex emerged (I don’t actually recall any drugs-and-sex-combined stories, for whatever reasons). Key players included: Frank Dodge, a former schoolteacher who founded another not terribly successful apps company (The Dodge Group) afterwards; Jim McCormack, who happily retired from software into real estate, but sadly died a few years later; development chief John Landry, who’s been a prominent industry figure ever since, and sales/marketing chief Bob Weiler, ditto. Landry and Weiler went together to Distribution Management Systems, Cullinet (after it bought DMS), and Lotus, before going their separate ways.
M & D’s venture into manufacturing applications seemed later and more half-hearted than Comserv’s or Cullinet’s. But they eventually did wind up with a version of (and may even have bought control of) the Rath & Strong technology.
Cullinet. Cullinet was better known as a DBMS vendor. But in a precursor of what became the Oracle strategy, it pursued financial and manufacturing applications as well. The financial applications were originally licensed from M & D. The manufacturing apps were originally licensed from Rath & Strong, as were M & D’s.
One negative consequence was that the industry teamed up against Cullinet. For example, ADR in DBMS and MSA in apps formed a close marketing relationship. To general industry agreement at the time, I dubbed this the ABC (Anybody But Cullinet) strategy.
Cincom. DBMS vendor Cincom pursued a Cullinet-like apps strategy. Not many people cared.
J. D. Edwards. If I recall correctly, JDE’s main platform was the IBM System 38, the predecessor to the AS/400. Anyhow, JDE was a Denver-based financial software company. Its main claim to fame, other than the platform that it ran on, was a superb order entry system. Rob Kelley, referring to his days at Arthur Andersen, once told me that Andersen’s order entry system had had 45,000 lines of code, JDE’s had had 5,000 lines, and JDE’s had been better.
SAP. I’ve already written up what I recall about SAP in the 1980s.
This initial list leaves a lot of companies out, of course. Other than the MRP companies — ASK, NCA, XCS, and so on — the biggest omission may be Walker Interactive. But also missing are Global Software, Data Design, a whole lot of human resources specialists and so on.
Also missing are other vertical market groups, most notably in banking software, which is where general ledger products (the first major financial application) first succeeded in a big way.
I hope to get around to writing about these subjects before too long.
Until the past couple of years, I didn’t have a lot of dealings with SAP. (That has now changed significantly.) But it seems that the things I do recall aren’t that widely known anymore.
I first heard of SAP in the 1980s. It was a smaller company than the then-leading mainframe application software vendors. Peter Zencke told me earlier this week that when he joined in 1983, the company had around 100 employees. From memory about MSA’s figures, I’d guess SAP’s revenue was somewhere in the $150-250,000 per employee range. Also from memory, I’d guess that MSA and M&D (McCormack & Dodge) were meaningfully bigger than SAP at that time. I also think that SAP combined financial and manufacturing applications earlier than the other mainframe vendors did, and hence probably got more revenue per client from a small number of clients. (MSA didn’t get into manufacturing apps until they bought Comserv, which if I recall correctly never broke the $20 million revenue mark on its own.)
SAP was almost unique among significant software vendors in being based outside the US, Software AG being the other obvious big example. There was no Business Objects then, of course. I don’t think that any of the UK companies that eventually made a modest impact — MicroFocus, LBMS, and much more recently Autonomy — were even active then. So it was pretty much off of people’s radar screens …
Indeed, at one point in the early 1990s I wrote to the effect of “Hey! There really are some important European software companies!” And spurred by that, my clients at Fidelity Investments invested in SAP. Too bad they were perennially stingy about compensation for good investment ideas …
Anyhow, the word on SAP from its competitors was that in the US at least, SAP focused tremendous sales effort on a small number of prospects, and in those accounts they were very hard to beat. These accounts seemed to be centered on the chemical and pharmaceutical industries, presumably because those industries were particularly strong in SAP’s home German market. Not coincidentally, SAP’s US operations were headquartered in Pennsylvania, near the New Jersey stronghold of those industries in the US. It’s natural to conjecture that SAP had superior functionality for process manufacturing industries, something that was pretty primitive in those days, but I don’t recall any direct mentions of this.
I learned more in the early 1990s when Jeremy Coote called up and introduced himself. He was the CFO of SAP’s US operations (he later went on to a big job at Siebel). It turned out that SAP had some contractual reason only to invest limited resources in the US. But that would change soon; one of the directors was coming over to run things in the US personally; and so on. Obviously, they lived up to that much more than I could possibly have envisioned at the time.
The story of how SAP’s rise dovetailed with the growth of the public accounting firms’ consulting practices is better known; I’ll leave the telling of that to another time.