In the pre-relational days, it was common practice to buy products that hadn’t succeeded yet, and grow with them. Often these were programs written at enterprises, rather than third-party packages. Most of Cullinet’s product line, including its flagship DBMS IDMS, was came into the company that way. ADR, if memory serves, acquired the tiny vendor who created DATACOM/DB.

Then things slowed down. A Canadian insurance company oddly bought Computer Corporation of America, to utter non-success. (At least I got an investment banking finder’s fee on the deal.) Computer Associates, which did brilliantly in acquiring computer operations software, had a much rockier time with DBMS. It acquired Cullinet, Applied Data Research, and ASK/Ingres — among others — and didn’t have much growth or other joy with any of them.

Indeed, Ingres has been acquired three times, and hasn’t accomplished much for any of the acquirers (ASK, Computer Associates, Actian).

I used to think that Oracle’s acquisition of RDB provided key pieces of what became Oracle’s own extensibility technology. Andy Mendelsohn, however, disputed this vehemently — at least by his standards of vehemence — and his sources are better than mine. Rather, I now believe as I wrote in 2011:

… while Oracle’s track record with standalone DBMS acquisitions is admirable (DEC RDB, MySQL, etc.), Oracle’s track record of integrating DBMS acquisitions into the Oracle product itself is not so good. (Express? Essbase? The text product line? None of that has gone particularly well.)

Experiences were similar for some other relational DBMS pioneers. 

• Sybase did well with its acquisitions of what became the standalone products Sybase IQ and Adaptive Server Anywhere.
• Informix did well with its acquisition of what became Informix’s parallel offering XPS (the same technology Ingres passed up), but terribly with Illustra (which it unwisely tried to integrate into its other products).
• Microsoft has done very well with Sybase Adaptive Server Enterprise’s source code, which formed the basis for SQL Server.

IBM’s acquisition of Informix, however, didn’t accomplish much that I’ve been able to discern. Ditto various small deals such as Oracle/Sleepycat, Oracle/TimesTen, or IBM/solidDB. And no acquisition of an object-oriented DBMS vendor — of which there have been many — has succeeded in igniting that niche market.

Finally, let’s consider the recent merger wave in the analytic RDBMS sector.

• Microsoft went first, acquiring DATAllegro. Integration of DATAllegro and SQL Server technology didn’t go well; while PDW (Parallel Data Warehouse) has finally come to market, I believe it’s much less based on DATAllegro than Microsoft first hoped.
• IBM has sold a lot of Netezza into its installed base. Otherwise Netezza seems to be lagging. And it’s generally assumed that most noteworthy Netezza people have been or can be hired away. (Big exceptions: Phil Francisco, perhaps also John Metzger.) Wisely, IBM has made no moves to combine DB2 and Netezza into a single product.
• EMC/Greenplum has been the flashiest of these deals. Some early bumps notwithstanding, EMC poured resources into Greenplum, and EMC/Greenplum have been correspondingly active.  Partnerships (VMware, GE), name changes (Pivotal) and so on have also kept the pot stirred.
• For the first 2 years after being acquired by HP, Vertica proceeded fairly independently, with what seems like decent growth, but also without a Greenplum-like flood of resources enjoyed by EMC Greenplum. I expect somewhat more integration going forward, perhaps an appliance strategy that somebody actually notices.
• The Teradata/Aster case is much like IBM/Netezza — separate products, focused on the Teradata customer base. Details, of course, differ.

Let’s start with a breezy overview, setting the stage for more detailed posts to follow. As I see it, there have been four eras at Oracle, which between them reflect just about every tech company management theory I can think of.

Startup: This period comprised initial development, custom contract with the US military (CIA, I think, even though the demo database was always naval), and initial product release. This is the one phase of Oracle’s history I didn’t witness personally. But it seems to have been pretty much a story of “build a minimum viable product for a great vision, and hustle until somebody buys it.”

Hypergrowth: Roughly speaking, Oracle grew 100% per year on its way from $5 million in revenue to $1 billion. This period formed much of the basis for Geoffrey Moore’s famous “Crossing the Chasm” series of books. In line with Moore’s later observations, Oracle’s priorities in this period were:

• Sell.
• Ship good enough product to sell.
• Worry about the details later.

By the backhanded “good enough … to sell”, I mainly mean two things. First, Oracle quality was pretty questionable, across the board. Second, as I observed in a post on Oracle’s arch-rival Ingres,

Ingres was first to market with new features such as a 4GL or a truly distributed DBMS. Oracle, however, was the first to market with the features customers most cared about, at a level of completeness they found acceptable.

Plateau, Professionalization, and Conquest: Oracle then hit a wall. New “adult supervision” management came in to clean up everything from product quality to accounting. This is when Oracle got serious about competing with IBM and EDS. It’s when Mike Fields and I coined the label “Enterprise Data Babysitter”.

Regaining momentum, Oracle pulled irreversibly past the other independent DBMS vendors of the era, and in essence past IBM mainframes as well. Its application business also finally got some traction, albeit with a long way still to go. And most interesting to me, Oracle triumphed with a blend of product and professional services efforts in a way that hasn’t been seen before or since.

This was also the era during which I was most closely involved with Oracle myself. Oracle was my biggest consulting client for multiple years. I double-dated with Larry Ellison. Geoff Squire bought me an obscene statuette in Indonesia, and presented it to me at an Oracle analyst day.* I stayed for a week in Oracle PR chief Gail Snider’s house, and a night in Marc Benioff’s. Oracle VP Bob Jesse explained to me what raves were. (He later left Oracle to start a charitable foundation promoting drug use in the context of religion.) And Oracle analyst relations chief Daniel Sagalowicz didn’t even bother talking to me, on the theory I was getting along just fine without his help. Fun times.

*It was a lovely carving of two pigs fornicating. He said he saw it and instantly thought of me. I presume this was a reference to my Wall Street background.

Empire expansion: Now Oracle was atop the heap, selling complex, expensive products to complex, deep-pocketed customers. This left Oracle in what Clayton Christensen would call the Innovator’s Dilemma position, subject to disruption from below. And so Oracle adopted the Innovator’s Solution with a vengeance, by:

• Thickening its stack, to ensure that wherever the profit opportunity went, Oracle would be there.
• Going to great lengths to buy a leading disrupter, MySQL. (Oracle endured  expensive delays in the Sun acquisition it could have averted by divesting MySQL.)

In particular, Oracle bought huge numbers of software vendors — PeopleSoft, Siebel, BEA, and many more. And then Oracle went further, bundling hardware as well — but that brings us pretty much to the present day.

Related link

• Wikipedia’s timeline for Oracle’s history is pretty reasonable overall, but there certainly are errors and omissions. For example, Wikipedia seems to think Mike Fields and Ray Lane joined Oracle the same year, when in fact Mike’s (and Geoff’s) replacement by Ray Lane was a key event in Oracle history.

Hagia Sophia seen through the Sultan Ahmed fountain, by Linda Barlow.

Interior view of the Rüstem Pasha Mosque, from a nice page by an outfit trying to sell Turkish language classes.

Tile outside the Rüstem Pasha Mosque showing Mecca, for those who can’t physically make the pilgrimage, by Linda Barlow.

Linda lived in Turkey for a while with her first husband, and speaks excellent Turkish. (In general, the Barlow women have an amazing talent for languages.)

If you’ve never been to Istanbul, it must be seen to be believed. From a hills and water standpoint, imagine 10 San Franciscos, but with many of the buildings being 500+ years old. The whole thing is wrapped around the Bosphorus, in which at any moment you can see 2-3 tankers, a whole lot of commuter ferries, and generally more ship traffic than I imagine can be found in any other similar expanse of water in the world (the Panama Canal area perhaps excepted). And there are plenty of places from which to get awesome views, most notably on the water itself. If you’re ever in Istanbul, seize every pretext you can find to be out on the water.

When it comes to great religious buildings, Istanbul may be my favorite city in the world, ahead of Rome, Paris, and even Kyoto. Reasons include:

• There are a lot of them here, since in the Ottoman Empire there weren’t many ways for the rich and powerful to use their wealth except by endowing buildings, most notably mosques (in particular, they could pass little wealth on to their heirs). The Ottomans built feverishly for about 400 years.
• Since Islam frowns on figurative art, the whole thing is very geometric, which I like.
• Mimar Sinan, the Ottoman analogue to Michelangelo or Leonardo da Vinci, got along fabulously with his patrons. (Suleiman the Magnificent called Sinan the only person who had “never disappointed” him.) Those patrons had much of the wealth of the Ottoman Empire to play with. Consequently, he had huge budgets and staff, and built many beautiful things.
• When the Turks conquered Constantinople, they found Hagia Sophia there, and developed much of their own style in mosques based on it. I think that style works beautifully on the outside of buildings just as on the inside, more than is the case for – for example – most Western cathedrals.
• Many of Istanbul’s great buildings can still be seen from the outside, at a distance, more than is the case in any other city I can think of. (The hills are a big help with that.)

The standard list of “must-see” sights in Istanbul would probably start with:

• Hagia Sophia.
• The Blue Mosque.
• Topkapi Palace.

They’re all great, but I’d put ahead of them:

• The Süleymaniye Mosque (by Sinan). To see why, just do a Google image search on its name.
• The Rüstem Pasha Mosque (also by Sinan). The big reason is the tiles, which – unlike in bigger mosques – are right in your face. Tiles are the greatest decoration in mosques, just as stained glass windows are in churches. I don’t find Rüstem Pasha quite as beautiful as Sainte-Chapelle in Paris – but the analogy isn’t far-fetched.

There also are several very nice tiled pavilions in Topkapi, but I’d put the Rüstem Pasha Mosque well ahead of any one of them.

Also on my mustn’t-miss list are:

• The final room in the Turkish and Islamic Arts Museum, aka the Ibrahim Pasa Palace. It’s a crafts museum, of course, since they didn’t have much figurative art in the Ottoman Empire. The final room has what must be the greatest collection of rugs in the world, many of them around 30 feet long. Don’t miss it, even if you only have 20 minutes to spend. It’s extremely close to the Blue Mosque, and hence to Hagia Sophia as well.
• The aforementioned boat ride(s).
• Topkapi Palace and the Blue Mosque.

Frankly, I like Hagia Sophia better from the outside than the inside, for beauty. It’s one of the world’s great feats of architectural engineering, unmatched in grandeur for about a millennium after it was built. But when the Muslims converted it from a church to a mosque (it’s now a secular museum, thanks to Ataturk), they covered up the art and made the whole interior rather plain. Also not on my can’t-miss list are the famous Covered and Egyptian/Spice Bazaars, although I really like the latter. More on those in a future post.

Istanbul traffic is a catastrophe, especially since streets are one lane wide and never point in the direction you wish to go at the moment. But fortunately, the absolutely-can’t-miss sights are all within walking distance of each other in the old city (i.e., the portion south of the Golden Horn inlet), and there’s a tram route looping around to help you out further. Also in that area is Eminönü, Istanbul’s busiest port area for boat departures. And if you do want to be driven around, distances are so short that, even though it’s slower than walking, it’s doable, and you do see extra stuff out the window as the vehicle creeps along.

A great Istanbul guide is very nice to have (but not required), and I have one to recommend: a freelancer named Tayfun Diker – pronounced like and with the same etymology as “typhoon” – whose Hotmail address is m+FirstName+LastName. Benefits of having a guide include:

• Lots of context – religious, historical, and architectural.
• Turkish language skills.
• Help finding stuff and getting around (and if you do want car/driver, it’s as cheap to get one with a guide as without).

Best of all, guides don’t have to be all that expensive; our hotel charged us 100 Euros for half a day with Tayfun, a van, and a driver – before tips — and perhaps if one contacted him directly one could do at least as well as that.

Not everybody can afford the time to spend a week or two in Istanbul. But if you can shoehorn even 2 days of Istanbul sightseeing into your schedule, I would highly recommend arranging to do so.

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:

• Bill of materials planning. This was before even my time, but it seems to have been a big part of what kicked off the whole DBMS industry, even though manufacturing applications then spent a decade not being DBMS-based.
• Order entry/accounts receivable. This was a tough problem from the mid 1970s though the mid 1980s or so. In particular, accounts receivable stumped John Landry at three consecutive companies — McCormack & Dodge, Distribution Management Systems, and Cullinet — before he claimed to finally have figured it out.
• Multi-currency support, about which I had an exchange that may be paraphrased as:
  • Pat Tinley of Ross Systems: “I’ve finally figured out how to do multi-currency right.”
  • Me: “Didn’t you tell me that at MSA?”
  • Pat: “I was wrong then.”
• Process manufacturing, and the co-products/byproducts it entailed. This led to the one significant patent suit outcome in enterprise software history, in which Marcam really did chase Ross Systems’ product off the market.

A shining relational-era example is SAP’s inclusion of workflow as a central aspect of 1990s application design.

The resulting apps, however, are cumbersome — very cumbersome. They’re cumbersome to use. They’re cumbersome to install. They’re cumbersome to change. People who use enterprise applications feel trapped in a bureaucratic hell. That is why I agree with the sentiment that operational enterprise applications are the verge of significant change.

• Historical notes on analytics — the pre-computer era
• Historical notes on analytic terminology (in which many terms used in this post are defined)
• Historical notes on analytics — departmental adoption (this post)
  

What set off my “history of analytics” posting kick is, simply put:

• Most interesting analytic software has been adopted first and foremost at the departmental level.
• People seem to be forgetting that fact.

In particular, I would argue that the following analytic technologies started and prospered largely through departmental adoption:

• Fourth-generation languages (the analytically-focused ones, which in fact started out being consumed on a remote/time-sharing basis)
• Electronic spreadsheets
• 1990s-era business intelligence
• Dashboards
• Fancy-visualization business intelligence
• Planning/budgeting
• Predictive analytics
• Text analytics
• Rules engines

If we leave out data management/system technologies* — e.g. data warehouse appliances or Hadoop — that’s pretty much everything that succeeded (and a couple that perhaps didn’t). I don’t know what to put on an “Enterprise-wide from the get-go” list except for a couple of duds like executive information systems and balanced scorecards.

*”System software” technologies such as DBMS often do eventually fall under the purview of central IT. But even for them there’s typically a multi-year period during which departments take the initiative in bringing them in.

Of course, this should surprise nobody; information technology is almost always adopted departmentally first, with the exceptions arising mainly in cases where departmental adoption makes no sense. Reasons include:

• The problem being solved is department-specific.
• The expertise and specific techniques to solve the problem are (or seem) subject/department-specific.
• The budget to solve the problem is department-specific.
• The best reasons to centralize technology often involve integration among departments, and new technology is rarely expected to start out being all that integrated.

Departments most likely to be early adopters (relative to others) of analytic technology seem to be:

• Finance/planning, especially in the old days when analytic technology was newer (nowadays finance might be more involved in trying to push reporting/analysis discipline out to a whole company).
• Sales/marketing, because they often have more data than other departments (actual purchase transactions, other customer contacts, and also a lot of external data).
• Investment research, because financial analysis is almost literally their core product. (Ditto trading, for very similar reasons.)

Three examples, for me, serve to bring all this home.

Business PC use famously started with individuals and departments just acquiring PCs, outside of the IT department’s control or even knowledge, way back in the day of the Apple II. Most commonly, the reason to get the PC was to run an electronic spreadsheet, generally VisiCalc.

10-15 years ago, when business intelligence vendors banged the drum for enterprise-wide BI/dashboard adoption, I’d ask them “So, do you have an enterprise-wide dashboard yourselves?” Invariably, they didn’t — but they did have departmental dashboards for sales and/or marketing. It became clear that this was a general pattern in BI adoption.

Multiple generations of technologies that one might think of as having to do with artificial intelligence – e.g. expert systems, predictive analytics* and text analytics — have wound up with applications being concentrated in the same few areas:

• Marketing
• Quality/maintenance
• Scientific/engineering research
• National security/law enforcement/anti-fraud
• Underwriting/investing/risk assessment
• Publishing (for the text-oriented technologies)

Those categories comprise 90%+ of the applications I can think of for the golly-gee-whiz technologies of their day. (You could add simulation to the list as well.) And outside of the publishing and criminal-catching sectors, those apps are pretty departmental in nature.

*I think predictive analytics has evolved into a blend of statistics and (other) machine learning, and machine learning can be viewed as a kind of AI.

So why do I think you should care about all this? Two reasons:

• History is cool.
• It has relevance to current issues in analytic technology adoption, which I plan to write more about soon.

I hope you agree.

• Historical notes on analytics — the pre-computer era
• Historical notes on analytic terminology (this post)
  
• Historical notes on analytics — departmental adoption

Discussions of the history of analytic technology are complicated by the broad variety of product category names that have been used over the decades. So let me collect here in one place some notes on how (and when) various terms have been used, specifically:

• Management information systems
• Decision support (systems)
• Report writer
• Fourth-generation language
• Executive information system
• Business intelligence
• OLAP (OnLine Analytic Processing)

Obviously, I can’t cover everything in this post. Omissions include but are not limited to:

• Anything in the data warehouse/data mart area. (For one thing, I don’t want to deal with the whole Inmon/Kimball dispute.)
• Anything in the predictive analytics area (but see the first point in a 2009 SPSS post).
• Terms I’ve recently sponsored, such as investigative analytics or machine-generated data.
• Big data (analytics) — I just discussed that mess a week ago.

The first prevalent term I recall for “information technology” was management information systems (MIS). I mention that mainly to note that it actually sounded a bit analytics-oriented, and hence to point out that in the old days — 1960s and so on — it didn’t seem necessary to name a separate category that amounted to “analytics”.

Meanwhile, the first prevalent term I recall that covered much of what we’d now call “analytics” was decision support, or decision support systems (DSS). I think DSS was always ill-defined, with multiple subcategories, just as analytics is today. The heyday of this term was in the 1970s/1980s.

Report writers were around in various forms for decades; consider for example the early 1970s history of Cullinane/Cullinet. By the time I became an analyst in the early 1980s, these were mainframe tools that let you specify paper reports, and the market leaders were probably Pansophic’s EASYTRIEVE and Informatics’ Mark IV. According to marketing, they could be used by non-programmers; in reality, they were a much easier way for programmers to do what end users asked. They were used both for one-shot queries and, as their main design point, repetitive reporting.

The report writer category then survived into the era of business intelligence (BI). (Indeed, Cognos’ big integrated BI tool early this century was called ReportNet.) More on that in the BI discussion below.

The term fourth-generation language (4GL) was widely used from the 1970s through the first part of the 1990s. Usually, a 4GL was:

• A vendor-specific programming language …
• … sold in connection with an interpreter …
• … that was particularly good at database manipulation.

In particular, the original 4GLs:

• Were primarily sold and used for analytics.
• Were often sold/used on a remote/timeshared basis.
• Often had some kind of (pre-relational) DBMS bundled in.

Classic examples of such 4GLs included FOCUS (the core product of Information Builders), RAMIS, and NOMAD; SAS arguably started out as a product of that kind too. Starting in the 1980s, however, 4GLs were used more generally, and indeed survived as an OLTP (OnLine Transaction Processing) technology long after they were supplanted by BI tools for most analytic purposes.

The last pre-BI term I want to mention is executive information system (EIS). EIS was in essence the 1980s term for “dashboard”, although the technology was much more primitive than it is today.

The term business intelligence was coined in the 1950s and then reinvented in the 1980s; however, it has described a major category only from the 1990s onward, specifically starting when GUIs (Graphical User Interfaces) became prevalent.. “Business intelligence” is sometimes used to comprise all of analytics; more commonly, however, it refers to tools focused on data selection and presentation.

These days, most of what we’d call BI comes in a single integrated package, focused on a dashboard; most of the exceptions are somewhat old-fashioned report writers. In the 1990s and early 2000s, however, business intelligence had several distinct subcategories …

… one of which was called OLAP (OnLine Analytic Processing). Actually,  the term “OLAP” has been confusingly been used to mean several different things, including:

• Pretty much all of analytics.
• A particular non-relational DBMS architecture that I prefer to refer to as MOLAP (Multidimensional OLAP).
• An integrated suite of DBMS, 4GL, and perhaps other tools around a MOLAP architecture. (Examples: The IRI Express and Arbor/Hyperion Essbase products Oracle bought.)
• A client-side BI tool with a little MOLAP DBMS built in. (Example: Cognos’ erstwhile flagship BI product PowerPlay.)

I hate the term “OLAP” with a passion, in part due to that confusion, and in part due to the specific way the confusion came about: Ted Codd introduced the term, allegedly objectively, but actually as a marketing shill for Arbor Software, which had an obvious business incentive to pretend that its specific technologies solved a broader class of problems than they actually did.

OK. With that too cleared away, I feel ready to write about the actual history of analytic technology.

• Historical notes on analytics — the pre-computer era (this post)
  
• Historical notes on analytic terminology
• Historical notes on analytics — departmental adoption

Sometimes, what people describe as being “New, new, new!!!” in analytics has actually been happening since before they were born, or even before their parents were. Occasionally, I point this out. I think it’s time to collect some of those observations into a short series of posts.

Before getting to the history of actual analytic software, I can’t resist racing through some really old stuff. In a 2004 white paper, I wrote:

Transactional business processes have been around literally since the beginning of recorded history. Some of the oldest known writings are clay tablets that record merchants’ tallies in Sumerian cuneiform, complete with seals to enforce transaction integrity. Analytic business processes date back nearly as long, especially in military applications; the first chapter of Sun Tzu’s The Art of War is called “Calculations,” or in some translations “Laying Plans.”*

As enterprise complexity increased, so did the sophistication of analytic business processes. Almost two centuries ago, Nathan Rothschild made an investment fortune from early news about the Battle of Waterloo, and several decades later Florence Nightingale** introduced statistics to the study of public health. With the invention of machines to tabulate information in the late 19th Century, analysis began to blossom.

*Back when I wrote that, I also considered including some of the accounting Caesar cited in his Commentaries on the Gallic Wars, but eventually decided that was a “production application” rather than anything we’d recognize as “analytics”.

**Florence Nightingale is, simply put, one of the more impressive women in history. Unfortunately, a couple of other statistical greats were associated with the deplorable subject of eugenics. I am thinking specifically of Francis Galton, who invented several really basic statistical concepts, and seems to generally have been a brilliant guy, and Karl Pearson. (Hat-tip to John Verostek for, um, tipping me off to Galton.)

Statistics also seems to have led the way in business applications of analytics. Specifically, statistical quality control dates back to the 1920s or so, pioneered by Walter Shewart and given greater visibility by his protégé W. Edwards Deming. On the monitoring side, various organizations collected industry-wide numbers by the 1930s or so. For example, movie box office receipts were reported at least as far back as 1939, perhaps by Variety; the New York Times bestseller list seems to have started slightly later, in 1942; and a rather superficial site on media history first gives hard numbers for the decade of the 1930s.

Still, to continue quoting the same white paper:

What utterly transformed both transactional and analytic business processes was the advent of electronic computing in the 20th Century. In particular, the volume of available data exploded. Even more important to analytic processes was the superhuman increase in the speed of computation. Various types of software emerged — business intelligence (BI) tools, spreadsheets, statistical packages, and the like – permitting kinds of analysis that had been infeasible without computers.

And with that out of the way, let’s return to discussing computer-era analytics.

• Oracle started out doing what amounted to custom development for government (military/intelligence) clients.
• Even when Oracle said it had productized its software, the stuff didn’t work very well without services to get it running.
• Oracle and Ingres both got a huge fraction of their early revenue* from deals to port their software to various brands of hardware.** That’s a lot like professional services.
• Oracle’s huge Tools Group grew out of professional services, if I have the story straight. Indeed, its first product was written by later long-time group chief Sohaib Abbasi when he was a consultant.

*Revenue recognition rules were rather different back then. Multi-million payments or guarantees for ports could be recognized as lump-sum revenue up front.

**Ingres once ran on more hardware platforms than it had employees, when both numbers were somewhere in the 40s. Most of the boxes on which the porting was tested were in one small office.

The benefits for a young software company of being in the professional services business include:

• It can be high-margin, especially if it shares the cost of sales with your software offering.
• It allows you to say “yes” to whatever the customer asks for. (More precisely, it takes you closer to that goal that you’d be without a service offering.)
• It allows you to fund capable staff. Or to put it even more bluntly …
• … professional services brings in revenue that pays your bills.
• It gets you involved with customers, learning stuff about their needs, and specifically addressing them.

The disadvantages of professional services generally boil down to various forms of defocus; you can screw up your development schedule, your development priorities, your sales priorities, your partnering efforts, your market positioning, your burn rate or just about anything else.

Many software companies pursue substantial professional services when they’re young. Many don’t. Both strategic choices can make sense.

This was all slightly before my time — I only entered the industry and met Software AG in 1981. So does anybody else out there recall more of the story than I do?