I used to overrate the importance of abstract datatypes, in large part due to Mike’s influence. I got over it. He should too. They’re useful, to the point of being a checklist item, but not a game-changer. A big part of the problem is [that] different parts of a versatile DBMS would prefer to do different things with memory.

and then left an IOU for a survey of abstract datatypes/RDBMS extensibility. Let’s get to it.

Perhaps the most popular term was actually object/relational DBMS, but I’ve never understood the etymolygy on that one.

Although I call RDBMS extensibility a “checklist item”, the list of products that can check it off is actually pretty short.

• PostgreSQL has the granddaddy implementation.
• Its ideas were commercialized as Illustra, which was bought by Informix, which later was bought by IBM.
• Oracle has one of the major implementations.
• IBM has one of the major implementations.
• Sybase has struggled with implementing the technology.
• So did Microsoft SQL Server, which of course started with the Sybase code line.

Surely there are more, but at the moment I can’t really think of which they are.

As you might think, the point of abstract datatype/extensible DBMS technology is a way for a DBMS to be extended to handle more datatypes, via something called a datablade (Illustra/Informix), cartridge (Oracle), or extender (DB2). Obviously, support has to be top-to-bottom, including in the DBMS’ parser, optimizer/query planner, etc. But the real issues usually lie in the access method — i.e., how data of the new datatype actually gets in and out of storage — and most particularly including indexes and the in-memory parts of query execution.

Notes on adoption start:

• In theory, DBMS customers can use abstract datatype technology to build DBMS extensions themselves. In practice, that almost never happens.
• In theory, partner companies can use abstract datatype technology to build DBMS extensions themselves. In practice, that rarely works out well. The only favorable example I can think of is ESRI, part of whose geospatial success came from supplying cartridges/extenders for Oracle and DB2.
• DBMS vendors have indeed used extension technology to implement, for example, full-text or (I think) XML support.
• I’m not aware of RDBMS+extensions providing good performance or feature sets for datatypes except those accessed in ways similar to those core relational datatypes are. E.g., while they’ve sold a lot of it, Oracle Text has never been all that competitive technologically. But geospatial indexing — which is lot like regular relational indexing — can work fine.
• Notwithstanding what I wrote above — and to my surprise when I learned it — IBM did not rely on its general extensibility framework for XML support.
• Sybase had an effort in database extensibility, and even attempted integration with Verity, a leading text search vendor of the 1990s. But the whole thing failed, and that’s where I first heard about mismatches in memory models.

The problem, in a nutshell, is that there’s a huge difference between making database technology sort of work and making it work really well, and datatype extensions typically get stuck in that muddled middle. One problem, as I mentioned above, is memory management. Another is getting any kind of decent cost estimate into the optimizer. A third is that the general RDBMS may just generally drag along a lot of overhead that a more specialized datatype-specific store might not need to deal with.

Beyond what I’ve already said, notes on the commercialization of RDBMS extension technology include:

• The whole thing started with Illustra, which was founded by Mike Stonebraker in his first visible commercial effort since Relational Technology Inc./Ingres. A lot of smart people were recruited, including star outside PR person Sabrina Horn.
• IBM was already doing similar things on its own.
• So was Oracle.
  • The eventual success of same may or may not have been strongly influenced by Oracle’s acquisition of the RDB product line from DEC (Digital Equipment Corporation).
  • If I recall correctly, the first version that sort of worked was Oracle 7.3.2 or 7.3.3. That said, “sort of” is the operative phrase, and I am speaking here from very direct experience.
  • Apparently, Oracle 8.15 was decidedly better, and things improved from there.
  • However, text search at Oracle wasn’t competitive — e.g. in performance or results-tunability — with standalone products. But Oracle Text got a lot of usage anyway.
• Influencers — certainly including me — opined that database extensibility technology was a key market requirement.
• Informix acquired Illustra for a whole lot of money.
  • When I asked Informix CEO Phil White why he did the deal, he said “Because I thought that’s what you wanted us to do.” I facepalmed.
  • Informix somehow decided that the Illustra product could simply be merged with its flagship DBMS. This didn’t work well at all. Worse, Informix marketed with a “single code line” pitch that wasn’t true and, had it been true, nobody would have cared about.

And that’s where I’ll leave it for now. If I post some day on the history of search, or with more detail on 1990s RDBMS competition, I may return to the subject at that time.

• One post gives a general historical overview of the artificial intelligence business.
• One post (this one) specifically covers the history of expert systems.
• One post gives a general present-day overview of the artificial intelligence business.
• One post explores the close connection between machine learning and (the rest of) AI.

As I mentioned in my quick AI history overview, I was pretty involved with AI vendors in the 1980s. Here on some notes on what was going on then, specifically in what seemed to be the hottest area at the time — expert systems. Summing up:

• The expert systems business never grew to be very large, but it garnered undue attention (including from me). In particular, the companies offering the technology didn’t prosper much.
• What commercial investment there was in expert system projects, successful or otherwise, foreshadowed some of what would be tried using other analytic technologies. Application areas included, among others, credit granting, financial trading, airline flight pricing and equipment maintenance.
• Technological reasons the industry failed included:
  • The difficulties of debugging and maintaining a collection of rules.
  • Lack of ability to crunch data, or to benefit from data crunching. (This is surely why few expert systems use cases were in the marketing area.)
  • A paradigm that assumed the required rules pre-existed inside expert humans’ heads.
• There were some successful projects even so.

First, some basics. 

• The core expert system metaphor was:
  • Facts in.
  • A question (often implicit) in.
  • A recommended decision out.
• The essential technology of expert systems was what we’d now call a “rules engine”, but then was often called an “expert systems shell” or “inference engine”.
• The development process consisted of “knowledge engineers” talking to human experts and coming up with rules.
• Any product could handle 10s of rules. A good one could straightforwardly handle 100s of rules. 1000s of rules was a real test of performance, and only a few expert systems were that complex.

Anyhow:

• The canonical research expert system was MYCIN, which advised as to which antibiotic to use for an infectious disease.
• The canonical research expert system shell was MYCIN’s successor EMYCIN.
• The other major expert system shell research project was from DEC (Digital Equipment Corporation). It was called R1, leading to the oft-repeated line “I wanted to be a knowledge engineer, and now I are one.”
• The expert systems business featured the “four horsemen” startups Teknowledge, Intellicorp, Inference Corporation and Carnegie Group. A few more companies came along later, including Aion and Neuron Data.

All combined, the expert system vendors didn’t accomplish much. However, there were a few successes in financial services, famously including credit-decision support at American Express. Airlines adopted the technology fairly vigorously, in areas such as scheduling and aircraft maintenance. There were tries in manufacturing too, including in materials selection (I forget the use case — something to do with composites) and, again, equipment maintenance. In general, a number of application categories — and this fits with the EMYCIN antecedent — could be characterized as having something to do with diagnosis.

The most remarkable expert system story I recall, however, was of something entirely built in-house. At a small conference in 1984 organized by John Clippinger, a guy from United Airlines said that they had built a system for flight pricing, and were gaining over $100 million/year from it. I just assumed he was misspeaking, but other people thought he was serious. Either way, it was a long time before United allowed the subject to be aired in public again.

In contrast, Teknowledge’s standard demo was stunningly trivial — a Wine Advisor, based on about 40 rules (if I recall correctly), selecting a wine to go with your hypothetical meal. When I suggested they develop a more serious demo, they pled resource constraints. This rang alarm bells for me about the difficulty of using the technology; I should have paid more attention to them.

Teknowledge was basically the company that commercialized EMYCIN. In general it was the most hyped-up of the expert system technology companies, with support from the relevant big-name Stanford professors and so on, especially Ed Feigenbaum. They raised a bunch of money (I got my biggest-ever investment banking bonus for helping) and got some visibility, but didn’t do much to overcome the technical problems I highlighted at the start of this post. Jerry Kaplan also got his first commercial experience there.

Intellicorp’s product KEE (Knowledge Engineering Environment, plus the obvious pun that Knowledge is Key) was more in the vein of STEAMER. The canonical KEE demo was what we’d now call a simple real-time BI dashboard — with dials and so on, so the dashboard metaphor could be taken pretty literally.* Intellicorp later pivoted from expert systems to object-oriented programming, and that was frankly a better architectural fit. Ed Feigenbaum’s name is also associated with them, but frankly I remember them more as being folks out of Texas Instruments (which had some AI efforts in the 1970s).

*Even so, KEE wasn’t used for much in the way of database query. I’ve now forgotten why.

Intellicorp also knew how to have fun. COO Tom Kehler led conference after-party sing-a-longs with his guitar. Workstations were named after famous disasters — Tacoma Narrows Bridge, Crash of ’29, Apollo 13 and so on. (The latter was said to have confused their Apollo salesman.) Managers put their desks in hallways, defying anybody who still had an office to complain about cramped quarters.

Inference Corporation marketed its rules engine ART on the strength of allegedly superior performance, because it was written in C and because it relied on the forward-chaining RETE algorithm rather than EMYCIN’s back-chaining. Sometime after they started telling the performance story, it actually became true. Even Inference didn’t get much out of the inference engine market, however, and eventually the product pivoted (unsuccessfully) to general object-oriented app development, while the company also pursued an effort in case-based reasoning.

The glossary to ART’s documentation is the first place I saw the entry

Recursion. See recursion.

I later stole that joke for my 1990s book on application development tools.

I had little contact with Carnegie Group — I don’t get very often to Pittsburgh — but I think it wound up focusing on the manufacturing sector.

Two other expert system companies are perhaps worth a mention:

• Aion came along slightly later than the four horsemen, and outlasted them, perhaps because its product was targeted at the IBM mainframe/enterprise market. Aion later merged with natural language query pioneer Artificial Intelligence Corporation to form Trinzic Corporation, which later was absorbed into Platinum Technology. Ironically, Bob Goldman ran Trinzic, while Platinum was of course founded and run by Andrew “Flip” Filipowski, Bob’s predecessor as the #2 guy at Cullinet.
• By the time Neuron Data came along, I’d stopped caring about the sector. But I do know that it eventually wound up owned by Fair Isaac, and rules engine zealot James Taylor — who wrote a book about same with Neil Raden — comes out of that effort.

 And I think with that I’ll finish this post. If there’s enough interest, I can write up more information later.

• One post (this one) gives a general historical overview of the artificial intelligence business.
• One post specifically covers the history of expert systems.
• One post gives a general present-day overview of the artificial intelligence business.
• One post explores the close connection between machine learning and (the rest of) AI.

0. The concept of artificial intelligence has been around almost as long as computers — or even before, if you recall that robots were imagined by the 1920s. But for a while it was mainly academic and perhaps military/natural security research. There’s been a robotics industry for over 50 years. But otherwise, when I first became an analyst in 1981, AI commercialization efforts were rather new, and were concentrated in three main areas:

• Expert systems.
• Natural language query.
• General AI underpinnings (especially LISP machines).

1. If I’ve ever gotten too close to a group of companies, it was probably the 1980s AI vendors. I unfortunately earned investment banking fees by encouraging people into money-losing investments in all three areas cited above, in Teknowledge, Artificial Intelligence Corporation and Symbolics respectively. I dated women who worked for Symbolics and Teknowledge. I wrote and performed a satirical song about Inference at an employee party for Intellicorp. Accordingly, when I write about individual companies in the sector, I fear that I may go on at self-indulgent length. So I’ll save all that for another time, and content myself now with a brief and dry survey that does little more than establish some context.

2. The 1980s also saw military-funded research into autonomous vehicles, as well as continued efforts in robotics and machine vision. Frankly, there wasn’t a lot of commercial overlap between these areas and the rest of AI at that time, and the rest of AI is what I tracked more closely.

But in one counterexample, a machine vision company named Machine Intelligence spun off a company that was building a PC DBMS with some natural language query capability. The spin-off company was Symantec. (Obviously, Symantec his pivoted multiple times since.) Machine Intelligence cofounder Earl Sacerdoti also wound up at expert system vendor Teknowledge for a while. So maybe there was more overlap in theory than there was in commercial practice. 

Note: The fact that I’ve mentioned companies named “Artificial Intelligence” and “Machine Intelligence” should illustrate just how early in the AI industry’s history I’m discussing.

3. Also in the 1980s mix was Japan’s government-funded Fifth Generation Computer project. Let’s ignore that fiasco and move on.

4. The next three developments of note were, in no particular order:

• Expert systems and LISP both fizzled. Some of their ideas were co-opted by object-oriented programming, which was a huge success.
• Text search became real.
• Speech recognition became real, at least for the purpose of dictation.

Neural networks also arose in academia, which helped pave the way for today’s machine learning.

5. Text mining, later called “text analytics”, also eventually became a thing. I wrote about that extensively on the Text Technologies blog, so I won’t recapitulate here.

And that’s it for now. More later.

Related link

• My chief technical contact at Symbolics was the late and much-missed Dan Weinreb. His posts on Symbolics history seem to still be available via the Internet Archive.

• 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.

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

• 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.

• The first lays out very general issues in understanding and subdividing this multi-faceted sector.
• The second (this one) calls out characteristics of specific application areas.
• The third discusses application software products’ underlying technology.

1. When I started as an analyst in 1981, manufacturers seemed to still be over 40% of the IT market. For them, the distinction between “cross-industry” and “vertical market” application software wasn’t necessarily clear. Indeed, ERP (Enterprise Resource Planning) can be said to have grown out of the combination of MRP and accounting software, although it never was a manufacturing-specific industry category. ERP also quickly co-opted what was briefly its own separate category, namely SCM (Supply Chain Management) software.

2. Manufacturing aside, other important early vertical markets were banking, insurance and health care. It is no coincidence that these are highly regulated industries; regulations often gave a lot of clarity as to how software should or shouldn’t work. Indeed, the original application software package category was probably general ledger, and the original general ledger packages were probably for banks rather than cross-industry.

3. Payroll processing is of course highly tied to regulation, especially in the area of state and sometimes even local taxation. It’s also one of the very oldest sectors of the computer services business, indeed predating most commercial computing. See for example the Wikipedia article on Automatic Data Processing (ADP) Inc.

In the early days (e.g. 1960s), banks tried to compete for payroll processing business. But the independent computer services industry won.

4. Human resources software often lives in its own world, which is often but not always separate from payroll processing. Reasons include:

• HR departments often live in their own worlds.
• HR is often the most regulated part of otherwise lightly-regulated businesses.
• HR deals with stuff like employee communications, employee benefits programs, applicant tracking, which are pretty disconnected from the rest of the business’ data.

On the other hand, while Dave Duffield has started some very innovative HR-first companies — consider the names of PeopleSoft and Workday — they eventually expand(ed) into much of ERP.

5. There are of course many other kinds of department-specific applications. The biggest area is marketing, discussed below. Another set of examples is more verticalized — certain industries use certain kinds of equipment, and there’s an associated need for software. Examples include but are hardly limited to:

• Shop-floor control in manufacturing.
• Test results in medicine.
• Check scanners in commercial banking.
• Meters in electricity and other utilities.

I think this group could become much more important in the age of machine-generated data.

6. It is widely reported that marketing departments now control more IT budget than central IT does. Obviously, marketers have used technology since the earliest days of commercial computing, but the big growth started in the 1990s. Signs and triggers I recall from that decade include:

• Huge amounts of new data became available to marketers, in two waves:
  • Detailed transaction tracking, via point-of-sale (POS) devices and loyalty programs, in industries such as retail and travel/lodging/gaming.
  • The internet.
• Data warehousing rose, generally for marketing purposes.
• One of the industries I knew best, retailing, went from being a cheapskate IT investment laggard to an aggressive user of technology.
• When I asked business intelligence companies whether, since they thought everybody should use BI, everybody in their own company was, the answer was usually “Well, the marketing department uses a lot of BI, but the rest of the company doesn’t yet.”

Accordingly, we’ve seen the rise of several marketing-related application software categories, the first few of which got combined under the rubric CRM (Customer Relationship Management). The first of them all was arguably salesforce automation (SFA). Siebel Systems was an SFA pioneer in the 1990s, with a big assist from Andersen Consulting, which was looking to repeat its great success in SAP-related business, and then grew into the rest of the emerging CRM category.

• 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.
• Social/collaboration.
• Analytics.

The first four of those five items fit into my “record and route information” framework.

That categorization ties into a number of my previous posts. In particular:

• Last August I reviewed some important examples of application databases. That post also links back to several things I wrote about enterprise application history.
• In February, 2013 I reviewed some difficulties around analytic applications.
• In September, 2011 I wrote (over-)optimistically about the integration of social technology into enterprise applications.
• Back in 2006 I laid out a kind of data/UI/business process trichotomy.

3. Application software can live either in suites or as point solutions. Reasons for the suite choice can include:

• Vendors like to sell more to any given customer.
• Customer like to deal with fewer vendors, and hence to buy more from any given vendor.
• There are many real reasons to integrate applications at the database and/or workflow levels.
• There are training and usability advantages when applications have a common user interface.

4. Acquiring application software is usually a big deal, especially in the case of suites. After all, the main point of getting application software is to change the way you do business. Indeed, the cost of application software commonly includes:

• Costs for software license/maintenance/whatever.
• Costs for underlying technology (hardware/data center/whatever).
• Costs for (re)training your employees to use the software.
• IT personnel costs.

Choosing SaaS (Software as a Service) delivery can obviate some of these issues — but only some.

Sometimes the previous paragraph is actually a great understatement; adopting software can involve major changes in how you run your business, well beyond what can be covered by a bit of employee education about new software features. To pick a couple of historical, generic examples:

• Before MRP* software, manufacturers commonly didn’t have business processes to track every part they used. They literally had to put parts behind locked doors and so on to use the application software.
• Business process reengineering (BPR) was a major trend of the 1990s.

The difficulty of adoption leads not just to high costs, but also to long projects and high project failure risk as well.

*MRP = Materials Requirement Planning. MRP II = Manufacturing Resource Planning.

5. With the software itself often being only a small part of the pie, there’s naturally a lot of interest among vendors in capturing other revenue as well. For starters I’d say:

• Semi-custom software for large enterprises, bundling packaged applications with a lot of professional services, is a great idea that succeeds surprisingly rarely.
• Oracle, SAP, and Microsoft all want to sell you DBMS and other “platform” software to run their applications. Oracle wants to sell hardware too. And they all also want to sell you BI.
• 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. Providing that stack is the traditional main business for Progress and Intersystems. It’s also a secondary business for most of the large-enterprise-focused vendors, and perhaps a primary business for Microsoft.
• SaaS vendors of course want to sell you a bundled remote service.

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
• Purchasing
• Inventory
• Fixed assets
• Payroll
• 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.

• Internet juggernauts — Google, Facebook and their younger siblings.
• The cheapskates at Amazon.
• Brogrammers.
• Etc.

Most of that is at the internet companies, although there are exceptions — any kind of companies can have ping-pong tables, beanbag chairs, and a bunch of dogs* running around the office.

*I mean literal pooches, not bad products. WibiData used to even post headshots of the dogs on their employee page.

But there was a time, before the internet era, when similar things could be said of enterprise IT companies. The biggest fuss about culture was perhaps made among the more buttoned-down crowd, including IBM (most famously), MSA (the example that made me think of this subject), and EDS (who commissioned a Ken Follett book about themselves). They are all I have space for in this post. But there were also the beginnings of recognizable Silicon Valley start-up culture, and I hope to discuss that in the future.

The dignity crowd

I still chuckle when I see an IBMer in a company-issued polo shirt, because there was a time when IBM had a strict dress code of conservative suits and ties. Along with that went never drinking alcohol in a customer setting, in an era when boozy business meals were the norm. The point of all these rules, I think, was twofold. First, IBM wanted to be seen as a trusted, dignified adviser to customer organizations. Second, IBM generally wanted some kind of rules so that the behemoth corporation would be a team.

And IBM was more than a collection of people; it was an organization. Employees with 20+ year service might average one city-to-city move per year. (Hence the joke that IBM stood for I’ve Been Moved.) But whoever was involved with your account — if your systems stopped working, IBM would do whatever it took to get you back running fast. And a large fraction of IBM’s sales effort was spreading FUD (Fear, Uncertainty and Doubt) as to whether rival vendors would care for customers equally well.

EDS (Electronic Data Systems, founded by Ross Perot) fancied itself as a cross between IBM and the US military. Even computer operators had to be clean-shaven and wear jacket and tie. A large fraction of hires were military veterans,* and an extreme “Do it now! No excuses for failure will be accepted!” ethos flowed through the company. 

*Indeed, generic college recruiting didn’t get serious until about a decade after EDS was founded; at least, that’s what Bob Sharpe once told me.

The extreme example, of course, is when two EDS employees were arrested and held by the failing Iranian government. Aspects of the story that I believe (some of which were documented in the Ken Follett book On Wings of Eagles) include:

• A dozen EDS employees, some of them then or later quite senior, volunteered to go into Iran and get their colleagues out.
• A requirement for being accepted onto that team was that you had killed somebody in combat.
• The leader was a well-known retired US officer, known for other prisoner extraction attempts.
• The team carefully rehearsed an armed extraction.
• The team infiltrated Iran, and discovered that their plan wouldn’t at all work. So they waited until the revolutionaries broke open the large Tehran jail in which the executives were being held. (Indeed, it is claimed a local Iranian EDS employee started the relevant riot.)
• (Part of) the team collected the execs and drove to Turkey.
• The team leader killed or persuasively threatened to kill (stories about that part differ) a recalcitrant Turkish border guard as they were entering the country.

That culture dissipated in the 1980s, after EDS was acquired by General Motors.

MSA (Management Science America, led by John Imlay) copied IBM’s demeanor, to the point that MSA’s logo was in the exact style of IBM’s — three letters compounded of many thin horizontal stripes. One exception: MSAers weren’t required to forgo alcohol. MSA print ads tended to feature senior and middle executives — many of whom I knew personally — “standing behind” the product. More on MSA is at the link above.

All three of my example companies had a strong interest in employee training.

• IBM is said to have trained lots of folks in IT, many of whom would leave the company and be IBM customers thereafter. (That’s sort of like McKinsey consulting today.)
• IBM also had a sales training program that included teaching you how to read upside down (in those days there were informative papers on people’s desks). My former colleague Jon Fram told me that part. Less clear is whether they taught lip-reading as well.
• EDS had a famed technical training program, somewhat modeled on military boot camp.
• MSA piggybacked on the EDS training program as best it could, as well as on sales training programs at other firms.

What does this all boil down to? Well, what these three examples share is:

• Strong focus on teamwork, and on whatever employee training, encouragement or uniformity seemed helpful in fostering it.
• Strong engagement with customers on the “Let us take care of your success” level.

That all worked well up through, say, the mid-1980s, when IT was still mysterious to most people, and post-WW2 business norms were widely accepted. Then it didn’t hold up as well in the face of more aggressive upstarts such as Microsoft and Oracle. But those are stories for another time.

• John was a jolly huckster. Of the entrepreneurs I’ve known with manic amounts of sales energy, he’s the one I can least imagine saying or doing an unkind thing. Indeed, the breathless bit about John’s “kindheartedness” toward the end of this 2010 article doesn’t ring too false.*
• John wasn’t technically the founder of MSA, but he might as well have been. (Analogy: Steve Case at AOL.) When he got there, it was Management Science Atlanta, a failing hodgepodge of tiny businesses. He turned into Management Science America, a leading software company of its day, and the one that “should” have become what SAP is today.
• My 2006 post on MSA Memories has 90 comments, the vast majority of which are from former MSA employees who loved working there.

*Not as persuasive is the story about the missed chance to buy Microsoft in 1981. I knew a LOT of folks at MSA in the 1980s, and nobody ever mentioned that. Also, the story has an obviously wrong Microsoft fat (what city it was in).

John Imlay was a showman, best known for giving speeches with live animals or other dramatic visual aids, as per this short 1994 New York Times interview. But he was also a tireless, lead-from-the-front seller. An MSA salesman who booked John into an exhausting schedule of sales calls could expect a return visit from his CEO soon, because he was using Imlay’s time optimally. Indeed, I didn’t really know John all that well, probably for a couple of reasons:

• He was rarely around when I visited; he was much more likely to be out on the road selling.
• This was back in my stock analyst days, and I generally spent more time with detail-oriented folks, numbers- and product-oriented ones alike.

But my personal experiences with him and the stories I heard from his colleagues paint a consistent picture of a genial-but-driven guy. And by the way, when he did give a talk for me at a conference, it was the second-funniest, behind only that of designated comic lunch speaker Larry Welke.

Memorable was the time when John got the chance to give a speech in London that somehow involved Prince Charles. We never heard the end of it, and it’s one of my strongest personal memories of him. Apparently, he was dazzled by royalty.

Like John Cullinane, John Imlay was a largely non-technical leader. That is of course common now just as it as it was then. But another aspect of his leadership approach was more distinctive — the famous “People are the key” mantra, supported by little Tiffany key lapel pins every MSAer was expected to wear. See for example the NYT interview above, which talks of the pins, and also reminds us that some of John’s top showmanship was delivered at in-house company meetings.

The culture-building worked. I knew a lot of MSA folks back in the day, and on the whole, they were smart, affable southerners. (Exceptions could be found in regional sales managers, who could for example be smart and affable Midwesterners, smart and affable New Englanders, or smart and affable Brits.) Whether this was, from a shareholder value perspective, the ideal culture to build is another question, that I’ll address in a separate post. But in any case, John Imlay was a likeable, successful character, and the planet is a poorer place now that he is no longer on it.

I’m surprisingly saddened by John’s passing. In simplest terms, I think the reason is that he was amazingly full of life.

For starters, let me say:

• I met Larry Ellison the same year I learned of him, which was 1983. We were in fairly active touch until the late 1990s. Then we drifted apart. That period corresponds roughly to the eras I characterized in my Oracle history overview as Hypergrowth, Plateau, and Professionalism.
• With Larry as with other “larger than life” industry figures I’ve met, what you get in private and what you see in public are pretty similar. I’ve had high-intensity dinner conversations with Larry (numerous times), Bill Gates (a few times) and Ross Perot (once) that are quite in line with their public demeanors.
• With Larry, facts can be mutable things. The first time I met him, I came away with the impression he had a PhD. The second time, it was only a masters degree. Ten years later, he’d almost graduated from the University of Chicago, but had failed or not take a French exam. And I gather his educational resume has retreated a little further since.
• Larry is hilarious, in a scathing way, and an excellent story-teller. Unfortunately, his humor rarely translates well to out-of-context print.

Some anecdotes:

• Larry at one time told me he’d selected my firm PaineWebber for the Oracle IPO. When he told me he was reneging, part of the explanation of why he wanted top-brand firms like Goldman Sachs was the analogy of having the girl on your arm be the most beautiful one at the party. Even then, it was clear that being envied was important to him.
• By the late 1980s, Larry was famous for agreeing to appear at conferences and not showing up. I kidded him about this, saying that he’d acquired an international reputation for rude unreliability. In a mock-sad voice he replied “Yeah — I used to just piss off my close personal friends.”
• Larry is one of only two people ever to blow me off for a meeting at his house. But he was very gracious when he came to the door and apologized.*
• In the late 1980s Larry promised to seed-fund a venture of mine. When Oracle hit a financial rough patch, he faded on me. A few years later, despite the lack of any kind of written commitment, he gave me $25,000 in apology.*

I didn’t realize until I made that list how many stories I have about Larry breaking promises.

*Larry is generally very good at apologies, perhaps because he’s had so much opportunity to practice them.

Of course, Larry’s habit of missing meeting schedules can be brutal on his employees. But that major annoyance aside, my general sense of his employee dealings has been they were tough-but-fair.* The only one of the many Oracle firings I didn’t understand at the time was that of hugely successful COO Ray Lane — and truth be told, Ray hasn’t come close to his Oracle level of success since. There have been some hirings I thought were doomed when they happened, but that’s a different matter — business judgment, not ethics. Of course, it helps in treating people fairly when your stock skyrockets and makes a whole lot of them rich.

*And when a complaint is made to the contrary, I tend to disbelieve the complaint, even the sexual-harassment ones.

Another group of stories that stick in my mind boil down to Larry delegating or not as the case may be.

• That $25,000 check I referred to above wasn’t actually signed by Larry; his assistant Jenny Overstreet evidently had that level of signing authority over his account.
• On the other hand, well into the 1990s, Larry had to personally approve every Oracle hire and every expenditure over $5,000. (When Jenny finally retired, that limit quickly rose to $15,000.)
• It was even longer that Larry personally approved every Oracle press release.
• In the 1980s Larry kept trying to offload “business” types of considerations on other executives. After various failures, he told me he was looking at them more himself and actually was finding P&Ls and so on rather interesting. Ironically, this was around the time he hired Jeff Henley as CFO, and finally had somebody outstanding to delegate that stuff to.
• In the same time frame he said he kept expecting somebody to rise to the level of replacing him as CEO. But in his estimation that person never actually emerged.
• Larry once told me he was bestowing millions of dollars more on his third ex-wife than their prenuptial agreement had called for, without objection. As he framed it, she was looking after his children, and he regarded keeping her happy as being of the utmost importance.
• And then there was the time Larry had a headache before a major speech, and sent his PR staff scurrying to get him aspirin of his particular favorite brand (Bayer).

Yet another group of stories focuses around aggression and relentless energy. Most remarkable to me were a couple of times when Larry described a sales manager’s particularly energetic aggression to me with admiration and glee. Some of that was around the famous “Cut off their oxygen” phrase, originally applied to competitor Ingres and later repurposed for other rivals. But then there was also the time I heard about a 2-on-2 basketball game, featuring Larry, sales (and marketing?) chief Mike Seashols, and Mike’s direct report Gary Kennedy. Apparently, Gary shoved Mike around quite a bit during the game, and Larry cited that as a strong foreshadowing that Gary would soon also shove Mike aside for his job. And it’s from Larry that I first heard the Genghis Khan quote to the effect that the greatest pleasure in life is to see your enemy utterly defeated.

Finally, I’ve heard a lot of stories about Larry Ellison and attractive women — and except for the employee-harassment tales, I believe them all.