Oracle’s Become Computer Associates (CA)

It’s all happened so quickly.

  • I’ve become my parents,
  • SQL has become Cobol,
  • and Oracle has become CA

Things were different back in 1985, when I, fresh from Berkeley, VAX/VMS documentation in hand, rode the 51 bus to Alameda where my first real employer, Ingres, was based.

You see, back then, Oracle wasn’t the establishment. Oracle was the rebel, a $50M-ish hyper-aggressive competitor trying to steal the relational database market out from underneath its lethargic inventor, IBM.

Back then, there was one software company that I didn’t understand. It didn’t really invent anything. It just bought up all the sick and dying software companies, often those who’d missed the mainframe to mini-computer transition. It acted as a software-industry garbage collector.

Being a bit of geek, I’d always thought of it as the planet-eating doomsday machine from Star Trek.

Who was this company? Well, CA, of course.

CA made money with the following strategy. They’d:

  • Pay a pittance for a broken software company (often less than 1x revenues)
  • Fire all the staff, leaving only a skeleton crew
  • Perform only basic maintenance on the acquired software
  • Crank up the maintenance fees on the largely helpless installed base

In fact, you could argue that CA was the first software company to truly value the maintenance annuity, at a time when most software companies were focused on the higher-margin license fees. And CA fully exploited the switching costs built into the enterprise software market.

Well, who’s doing that strategy today? Oracle, of course. Since my kids have been doing test prep, I’ll phrase this as an analogy: Oracle is to minicomputer as CA is to mainframe.

See this article, Oracle Fees for Maintenance and Support under Fire, which prompted me to write this post, an idea that I’d been mulling for some time.

17 responses to “Oracle’s Become Computer Associates (CA)

  1. What’s about ASG and Mobius ?

  2. Dave,Generally like the blog but I don’t really see how SQL is dead / like COBOL, now matter how many times you state that it’s so.A bit is a bit is a bit and the total number of bits continues to grow faster than our methods of dealing with it. This makes me question the value of putting those bits in a wrapper that makes them even bigger (i.e. XML) except in the specific use cases for which MarkLogic is marketed.That said, Oracle is totally like CA. Even their core products are being neglected now and all product “enhancements” seem to add more complexity to increase the switching costs further.However, CA was not competing against open source and the biggest push towards open source that I see in enterprise is from Oracle customers looking for some relief.

  3. Joe,Thanks for generally liking the blog and I know the SQL is COBOL thing is controversial, and at least from the point of view of this post, a bit gratuitous as well. (That is, it’s non-essential to the post but seemed to fit well into the opening litany.)Why do I keep saying it? Because I think it’s true. I’m probably just 5 years early. But do you honestly believe our kids are going to think SQL is some great programming language? They will, imho, see it the way we say COBOL, which in 1985 I saw a necessary-evil language that was in widespread use, but not interesting technologically and not something I wanted to study.In fact, for my first post-Cal job, I had the choice between doing INGRES/SQL/QUEL/C work or COBOL/MF assembler work, and guess which I picked?To say SQL is COBOL, btw, is not at all to say that SQL is dead. 25 years after I chose to avoid it, COBOL lives on (ask MicroFocus). It’s just not new, hot, interesting, et cetera and ergo, imho, none of the most talented new engineers learn how to code in it.Thanks for asking, hope this clarifies my position.(And remember, in 1985, I was one of the guys saying get off IDMS and go relational …)Cheers/Dave

  4. Anon,Yes there are several success COBOL vendors out there, but my point was that I believe that the best and brightest computer scientists are not working on or in COBOL. Yes it lives on — almost nothing actually dies, it seems, in IT.Lest we all miss the point, the actual purpose of the post was not to incite the COBOL programmers of the world to unite (against me), it was to point out that Oracle’s business model has become quite similar to CA’s.Best,Dave

  5. One last thought on the SQL is becoming COBOL thing.Go ask 10 freshly minted CS graduates from MIT, Stanford, Berkeley, CMU,et cetera, what they think about SQL?Another point: what’s arguably the hottest technology related to RDBMSs these days? Ruby on Rails. And what, exactly, does Rails do? It *hides* the underlying DBMS from the programmer.The root cause of all this, imho, is the age-old “impedance mismatch” between RDBMSs and the programming languages that access them.

  6. GR8 conversation.The fact that something does not change daily, does not mean it is dead.SQL should not compete with XQuery or Xpath. and the relational model does not compete with XML. It is true that relational is overused, and many use cases are better served by Object-oriented representations like XML. but that is not SQL fault.If Object Oriented is about data encapsulation, Relational is about exposing data. adhering to relational limitations ensure that the data you define may be joined in the future in ways you can not foresee today. With XML – it is much harder to “slice and dice” data. most XML is encapsulated representations that are hard to combine with other XML.XML gives wonderful flexibility, I am sure that if 10% of the use cases where XML is a better fit than relational were implemented correctly, MarkLogic would have been 10 times bigger than today.Do not hate relational just because it is sometimes misused – you will miss it when the world moves to those new amazon\google cloud DBs that tell us the APIs of pearl DBs of 15 years ago are the future.

  7. Is XQuery becoming more popular?

  8. Thanks, great interchange here. For the record, I definitely don’t hate relational. Heck, I was footsolider in the relational revolution and then spent nearly a decade at Business Objects enabling a big part of the original relational vision — enabling flexible end-user access to data. So I quite like relational databases. I just don’t think they can do everything. Think: “it’s a dessert topping and a floor wax.”I have two general arguments: (1) for those managing large amounts of XML semi-structured content, you should look at MarkLogic, and (2) — this one’s bigger and more controversial — I believe that XQuery and XML servers can effectively replace the Java/RDBMS/app-server stack and serve as a more efficient way of building web 2.0 apps.Just so you know, at Mark Logic, we primarily sell on (1) and let customers discover (2).

  9. Is XQuery getting more popular? Yes. I wouldn’t characterize it as “hot” or “on fire” or any of that, but let’s remember a few things about XQuery: (1) it was largely written by the architects from the big DBMS vendors who got their “second chance” at building a query language, (2) ergo it benefits from lessons learned building SQL are ego is theoretically superior (same folks, 2nd try), (3) it was designed for both data and content (SQL really only for data), and (4) it was designed to be a programming language from the start, not just a DDL/DML as was SQL, (5) it’s also a superset of XPath which I’d dare say is popular, and (6) many different vendors implement XQuery for different reasons.Example: DataDirect implements it as a federal language. MarkLogic implements as a data query/programming language. The RDBMS vendors implement it in a franglais-like way because it’s a standard and they feel they have to and because deep down I believe their architects — who’d never be allowed to admit it — feel that one day XQuery will be the primary API into their DBMSs.XQuery 1.0 only became a standard in 2007 or so, so in some ways we’re lagging SQL by about 20 years (SQL-87 is the first SQL standard I recall.)And by the way, in 1984-1985 Oracle was about the same size as Mark Logic (-ish and from memory).

  10. Dave here with another (excerpted) comment I got via email and will respond to in a separate comment:I never met a customer who was delighted with paying his current bill for support. It’s not even clear that Oracle raised the charges on its acquired products other than to bring them in line with existing Oracle support structures.As far as I can tell, Oracle has pretty much retained most of the development staff of companies it has acquired. Most of the cost savings has come from nuking IT, administration, finance, and some sales and marketing. I’m not aware of any n+1 revisions of acquired software that got shut down, although most n+2 efforts have been scaled back and folded into Oracle’s Fusion portfolio. I’m sure that support for acquired applications running on databases other than Oracle has been frozen or curtailed; I would not expect Oracle to do otherwise.Just like you, I loathed CA. Many great technologies got tarnished or just disappeared under the CA yoke. And yeah, Inges was one of them. I still seethe over that one, as I’m sure you do as well.But on CA’s strategy comparison with Oracle, I disagree with all your points.1) Oracle didn’t acquire any broken companies, much less at fire sale prices.2) They didn’t fire the development staff of the acquired companies.3) They performing some development, much more than “basic maintenance”.4) Their price increases on maintenance don’t seem to be out of line to me.And finally, the SQL is COBOL mantra. Yes, I agree that SQL is being wedged into round holes that the relational square peg has no business entering. Yes, I agree that relational databases may ultimately be enshrined for their formalization of transaction support rather than their calculus of tabular data.But…SQL is pretty damned good at querying data, a whole lot of which sits very nicely in schematically-organized tables. I don’t see much on the horizon to replace it for that purpose, and that purpose isn’t going away any time soon.Any programming language would kill to have the longevity of COBOL. There’s still a lot of code being written (or generated) for COBOL, like it or not. Today’s contenders such as XQuery or Java would kill for the penetration and longevity of SQL, just as SQL would kill for the penetration and durability of COBOL. (PS: the scientific community still seems to be writing tons of code in FORTRAN, another beloved dinosaur of mine.)

  11. I’ll respond to the points in the previous anonymous comment, first those that pick at my Oracle/CA analogy. My basic take is while I generally agree with the four points, it doesn’t change my view that the analogy works. I might change my wording: Oracle is doing CA’s strategy but adding the words ” and executing it better.”And, by the way, I see nothing wrong with CA’s strategy as a business strategy. I give kudo’s to Ellison to emphasizing product leadership in the 80s (when it mattered), market share and applications in tihe 90s (when it mattered) and now financials / consolidation in the 00s when it matters. Putting bankers in charge of the company was, imho, prescient.On the SQL/COBOL analogy, I’m happy and amazed that it generates so much controversy. But it also generates confusion. I’m not saying COBOL is dead. I’m not saying COBOL wasn’t great. I’m not saying SQL or XQUERY wouldn’t kill for COBOL’s penetration and longevity.I am saying, however, that when I graduated Berkeley I had zero, zero interest in COBOL despite all its penetration (I view it as a technically un-interesting business language that was there because it was there) and that most of my brighter peers had a similar non-interest. My contention isn’t, btw, that SQL actually *is* COBOL but that our kids and their kids will see it as such. Despite raising hackles everywhere, I still think that’s true.At 23, I think my kids will think of SQL the way I thought of COBOL at 23. And they won’t see the data/content divide, either.

  12. Interesting conversation!The only thing i would like to add is that i do not think the relational model is anywhere near dead, in fact i think it will prove to be the best database model for a long long time ahead. Regarding SQL though, that’s another story. SQL is bloated, constrained by it’s history and all in all not a very good language to query relations with. Stuff like allowing for null values and not to mention the strange language construct it uses to describe nested selections.A much better way to describe relations would be to use a language that reflects predicate logic. In my view of the future that is what i think we will see our children use when they design their information retrieval systems.

  13. Dave,The "dessert topping AND a floor wax" bit is older than SQL (thanks, SNL) — you are definitely dating yourself dude. Go Quel!

  14. gr8 conversation.What are your views on DB2 9.7 that allows great integration of XML with the relational model . best of both the worlds ?@Dave: I liked your fav books collection. I read inside the tornado and it was love at first sight. That prompts me to read other of your fav…

  15. “COBOL is Dead” in terms of a career. Do your own research!!!

    I found two job in London that cite the word COBOL:

    This is an example. Check out job sites you use.

    Anyway I have left COBOL a few years back. I did COBOL for three years and was a Software Systems Developer. In QA hoping to get the skills in demand to get a developer position.

    Graduates you have been warned. But don’t take my word for it as I said search for jobs.

    And the language does matter – try a search for C# or Java for example.


    • Pluh-ease. Finding one spotted owl doesn’t mean the species is thriving. With this logic you might argue that becoming an auto-worker in Detroit is a good idea because they exist — and are well paid — too. Yes, hello, in IT things “die” slowly if at all. But waxing and waning are two different things.

  16. Pingback: Cowan’s Peter Goldmacher on Oracle’s Potential Math Problem | Kellblog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s