back to article Revealed: The gift that keeps on giving to Oracle ... is dying

Even as traditional enterprise IT vendors come under pressure from modern cloud and open-source applications, these old-school businesses have one strategy that is the gift that keeps on giving: Enterprise licence agreements. Not only do ELAs help to shield vendors from pricing pressure from open-source alternatives, they also …


This topic is closed for new posts.
  1. Anonymous Coward
    Anonymous Coward

    dunno, one of the best things about your old fashioned suppliers is that if you find yourself up shit creek without a paddle they'll come and air lift your log to safety.

    1. Anonymous Coward
      Anonymous Coward


      yes, but.... there are ways of getting good support without the top-drawer costs. Either by moving to a lower-cost support agreement (e.g. next business day rather than 24/7), separating support from upgrades (for mature products, obviously), or placing the support contract with a specialist VAR rather than the vendor.

      In my n=1 experience support from VARs has been quicker, friendlier, and more competent than vendor support - and they're more flexible too.

      1. Anonymous Coward
        Anonymous Coward

        Re: Indeed...

        well when I've needed support I've needed it then and there, and I've needed it well into the early hours of the morning, like 4am, on a Sunday. With the same tech at the other end that knows their systems back to front, no pillar to post bs, me, senior techie, until we get a solution.

        And at the time we were only running Oracle Standard, with ISV sale discount... (so about £20,000 for a 4 CPU 2 node rac. Plus errr £7,000 for the support...)

      2. Anonymous Coward
        Anonymous Coward

        Re: Indeed...

        Thing is, it's very very dependent on what your company situation is - if it's a database that's running your whole sales and billing system for the whole company, then you should spend money on support (no matter what you're running), if it's a system that can be down for a few days and nobody cares much, except Bob, over there, and nobody likes Bob. Then you get the support you need.

  2. Steve Todd

    Enterprise databases are more than just blocks of data

    They tend also to contain a lot of business logic. It's that which keeps companies locked in, not the effort to copy the data across to a different database engine.

    Oracle has never been aimed at small business. It really needs dedicated DBAs to manage and tune it, but when you do that it scales up to levels that the open source crowd simply wouldn't believe.

    Those two facts together produce a lot of inertia. Oracle aren't going to wake up tomorrow, or even in a couple of years time, and discover their user base has been decimated.

    1. Anonymous Coward
      Anonymous Coward

      Re: Enterprise databases are more than just blocks of data

      I wish I could vote you both up and down. Yes, it's true that Oracle scales up to levels the open source tools cannot reach. But not every Oracle customer needs that. In fact, for a lot of them, the open source tools will do fine.

      Oracle will always be in the "big relational database" space, but like IBM with mainframes, the growth you can extract from this segment is quite limited.

      1. Roland6 Silver badge

        Re: Enterprise databases are more than just blocks of data

        >Yes, it's true that Oracle scales up to levels the open source tools cannot reach. But not every Oracle customer needs that.

        It is also true that very few Oracle experts (DBAs and programmers) have experience of Oracle DB's larger than circa 300GB. Whereas the majority of DB2 experts not only had experience but naturally expected the DB to be big.

        Hence to deliver a circa 2TB transactional (!) DB project, we used the Oracle/Sql-Server guys to do the basic logic - which was also within the capability of the various application code-generation tools. Once signed off the DB2 guys would rework it by hand to support all those features you need when handling very large tables and indexes. Needless to say the production DB was DB2 ...

        I suspect similar can be said for many other DBMS's.

        1. LDS Silver badge

          Re: Enterprise databases are more than just blocks of data

          The size in GBs of ad atabase doesn't tell anything. It's how many records across how many tables and the required time to perform your queries that matters. Frankly, today you can have a single table with a few records and some multimedia data in it and reach 300GB almost instantly. While 300GB across billions of records is another matter. Anyway, I found very strange a project could develop the "basic logic" in Oracle/SQL Server (very different from each other! code-generation tools? I see a problem here already), and then port it to DB2. Unless the whole logic was outside the database, and if so I would have many doubts about the sound design of that application. A database is not a "data dump" - it's a data management engine, IMHO a good part of the logic has to be within the database to achieve maximum performance. But I see IBM here trying to sell some kind of expensive middleware....

          1. Roland6 Silver badge

            Re: Enterprise databases are more than just blocks of data

            This was a text only DB and we had several master index tables containing more than 130M records.

            The reason we did the development the way we did was that the enterprise application (now owned by Oracle) had mature tools for interfacing to Oracle and Sql-Server and hence the developers familiar with the application knew how to use these tools and could rapidly produce demonstrable functionality on Oracle/SQL-Server.

            However, once we started getting reliable sizing and performance figures for the production DB, we had to do some thinking, particularly as we discovered that both the developers and the application vendor's experts had no real experience of DB's larger than ~300GB, additionally, the enterprise application's tools didn't directly support very large DB features.

            Making use of the resources available to us, we made the decision to use DB2 for the production system - yes the client, enterprise application vendor and IBM played a part in this decision [aside: my preferred partners Sun and Oracle didn't respond to our approaches]. We were able to do this by making use of the then recently release toolset for a DB2 backend from the enterprise application vendor, which we confirmed permitted switching of DBMS with minimal modification, this enabled us to not disturb the development environment.

            We then made use of DB2 expertise (client's and IBM's) to do the necessary manual rework of the code and SQL generated by the enterprise application toolset to support the enhancements necessary to support large tables and to support interactive usage by 12,000 operators. As time went by the developers got better at producing suitable code and so the DB2 optimization piece got slicker.

            But I agree LDS, cross DBMS development does present problems and would advise avoiding it if possible.

            1. Anonymous Coward
              Anonymous Coward

              Re: Enterprise databases are more than just blocks of data


    2. Anonymous Coward
      Anonymous Coward

      Re: Enterprise databases are more than just blocks of data

      Much as I dislike (and often with a high intensity) a lot of the technical details and implementations of the Oracle database product, it is vastly superior to everything from the open source crowd and most of the commercial opposition. It is not even a contest. Oracle is an order of magnitude past SQLServer which itself is leaps and bounds beyond MySQL etc. Postgres is probably OK but again, I wouldn't bet my business on it any more than I would on MySQL. YMMV and so might your opinion.

      Anyone who has ever tried to convert/move serious applications between platforms and/or databases you will know that it is not an exercise to be taken lightly, and certainly not for nickel and dime support costs. The internal disruption costs dwarf the software support costs, and the risks can be absolutely, staggeringly enourmous. There needs to be a serious long term competitive advantage, otherwise things that aren't broken stay in place.

      Only moron analysts or salesmen with a product to sell make claims to the contrary. This was true 30 years ago and it is true today to an even greater extent as business reliance on data has increased so massively.

      Oracle is unlikely to disappear any time soon, because they have the market leading database product, and not altogether for no reason.

  3. Anonymous Coward

    I think that Oracle's ERP revenue might be at risk

    Mostly from 3rd party maintenance, but I don't see their database getting shifted out very easily for reasons that Steve Todd mentioned above.

    1. Matt Bryant Silver badge

      Re: I think that Oracle's ERP revenue might be at risk

      ".Mostly from 3rd party maintenance....." Oracle have been very aggressive at dissuading third-part support by locking their support knowledge away. SAP was a case of what happens when a third-party breaks Oracle's rules and tries to use their enterprise agreement to provide third-party support. If you are running a departmental database you might accept the risk of going third-party (but you're probably running MS SQL Server instead anyway at that level), but if you're running a business critical DB you would probably not risk it. Oracle is being eaten from the bottom up, but the big margins are at the top anyway.

  4. Anonymous Coward
    Anonymous Coward

    Oracle? That crowd spreading malware?

    The pre-ticked install a bloody toolbar "option" with Java updates. The delightful and highly undesirable "option" that relies on you talking specific action to avoid it, instead of it being truly an option for taking up at - er - your option.

    Malware is as malware does. And that IS malware.

    If they are that nasty about small scale stuff then God* only knows how much they're prepared to crap on bigtime customers.

    * or deity/supreme being of choice

    1. IMVHO

      Re: Oracle? That crowd spreading malware?

      * and the difference between God and Larry Ellison is... God doesn't believe that he's Larry Ellison.

      Oh, shush - it's always a good time to pull-out an old standard.

      Mine's the one with the unbreakable pocket protector.

    2. Anonymous Coward
      Anonymous Coward

      Re: Oracle? That crowd spreading malware?

      Oracle isn't Java. Their cash cow is RDBMS and tools like Peoplesoft.

    3. kb

      Re: Oracle? That crowd spreading malware?

      Who installs stuff like Java manually anymore, when even the little guy can have it automated and toolbar free? just go to Ninite, check the boxes for what you want, that's it. Totally free for personal use and if you're running a business they have really cheap support licenses and will even help you set up a copy of their server so updates to any software you have can be downloaded once and spread to all the PCs, really nice that.

  5. Anonymous Coward
    Thumb Up

    That's just where the danger is though

    You raise a good point about ELAs removing the incentive to make small changes to the software ecosystem away from the ELA licensor.

    However, if the licensee becomes sufficiently aggravated with the ELA itself to divest itself from it, then that's a hell of a lot of business to lose in one go.

  6. Tom Maddox Silver badge

    Not really . . .

    The ELA is a side-effect of the lock-in. The lock-in is the effect of having data and logic tied in with a proprietary system, migration away from which is expensive and difficult. The ELA is a way of ensuring ongoing support and upgrades for the buyer, and it also provides a tidy little revenue stream for the vendor.

    I agree that losing this revenue stream would be disastrous for the vendors who rely upon it, but CIOs and other decision-makers need to see that a) migration to a competing platform or product is less expensive over n years and b) that it yields sufficient tangible benefits to be worth the effort in the first place. It's likely that there's no one who doesn't want, on some level, to migrate away from Oracle, but justifying the time and expense may be challenging, regardless of the ELA.

  7. Yautja_Cetanu

    " SaaS and open source eliminate the second component of this lock-in, but nothing can fix the first part."

    Is that true? is a SaaS for very simple websites but doesn't have data lock-in as you can export your site, code, configuration, content and all and host it on your own set up if you need to. Even business logic stored in the way your site works can be exported.

    Now... Drupalgardens is obviously a very basic example and high end enterprise systems are unlikely to go the way of drupalgardens + Drupal. But I dunno if its true that "nothing can fix the first part". If Salesforce were to opensource their whole thing and allow you to run salesforce on your own servers you could essentially get to a point where you could migrate a salesforce site between vendors or host it yourself.

    1. Anonymous Coward
      Anonymous Coward

      The main reason you can't fix the first part is because in large complex enterprise systems you gain the most benefit by running the platform dependent components (pl/sql, t/sql, streams, materialized views, the data transformation stuff, partitioning, blah, blah, blah) if you don't run any of the complex platform dependent stuff then sure - you can move to anything, bonus, but then it's very likely your application will be significantly slower then solutions that do use these components and in many cases not able to do many of the things.

      The right tool for the right job though, it's always funny when you come across a database that's been shoe horned into an expensive database engine that could just as easily live in postgresql

      I mean even your example you can only move between vendors hosting Drupal, I couldn't go from Drupal to Joomla or to wordpress, coz they're different engines. I can if I use a hosted database solution already move my oracle from say Savvis to another provider of hosted Oracle. I wouldn't because I wouldn't suggest savvis to arch enemy as it would be too cruel but heyho.

    2. ysth

      Is that true?

      I also would question the truth of that - though I would say the dividing line is that free/libre software will fix the first part; just open source may not.

      SaaS too certainly doesn't have to - by day I'm a closed-source SaaS developer, and almost all customer data is exportable; where it's not, it's because I'm so busy :)

  8. Anonymous Coward

    The difficulty is...

    The CFO or "the business" sees these ELAs simply as the cost of running a business, almost like a tax, about which you can do nothing. The fact that there are structural or alternative product changes that can alter this is seen as business risk, easily managed by keeping up the ELA payments.

  9. amanfromMars 1 Silver badge

    New Anonymous and Autonomous Players ...... who may also be Seriously Smarter Programs

    Hi, Matt,

    It is somewhat odd that you appear to recognise that the great game has changed and yet you imagine that it hasn't yet changed and dinosaurs [sorry, Larry E, but the nature of the new way of doing things has rendered your style, so Yesterday Man] still roam and rule the Earth, as is evidenced by ......... Time to short Oracle and its ilk? No. There's still plenty of lock-in left in those ELAs. But time is running out on the proprietary vendors' lock-in of yesterday?

    1. Anonymous Coward
      Anonymous Coward

      Re: New Anonymous and Autonomous Players ...... who may also be Seriously Smarter Programs

      Time appears to be running out on Matt's CV too,spending less and less time in each position.

      I reckon he'll leave his next job two weeks before he starts it.

  10. IHateWearingATie

    No one ever got fired for choosing to stick with Oracle...

    ...but they have been fired for screwing up a move between vendors.

    If it were me, it'd have to be *a lot* cheaper to risk my career over!

    1. Anonymous Coward
      Anonymous Coward

      Re: No one ever got fired for choosing to stick with Oracle...

      It's also bloody difficult to do, unless you shouldn't of been using it in the first place.

      It also isn't just oracle, it's any database you've decided to put your money the main cost being development even if you haven't got a costly enterprise system. If you go open you can never be sure that five years down the line Fatty McBeardy Basterd Corporation isn't going to come along and buy the open project you decided on and throw it in the bin or err "provide their expertise" at throwing it in a bin.

      It's like when an ISV goes "oh we support Oracle or SQL Server" and I think "why? Shouldn't you have focused your efforts on a single database? If you can support those two then can you support postgres or mysql? I'm concerned.... is the only reason you support those because you live under the belief that those names buy additional qudos? That in fact your application is database is pure sql and all the logic is in some kind of middleware?"

      1. Anonymous Coward
        Anonymous Coward

        Re: No one ever got fired for choosing to stick with Oracle...

        "It's like when an ISV goes "oh we support Oracle or SQL Server" and I think "why? Shouldn't you have focused your efforts on a single database? If you can support those two then can you support postgres or mysql? I'm concerned..."

        No reason to be concerned. If you tell customers that you support Oracle, SQL, postgres and MySql that means that each release needs to be tested on ... Oracle, SQL, postgres and MySql. Your support staff need to know their way around ... Oracle, SQL, postgres and MySQL. Your implementation team need to be trained up on and aware of the differences between ... Oracle, SQL, postgres and MySQL. And so on.

        Add in that you need to support multiple versions of each database (SQL2005, 2008, 2008R2, 2012; 64-bit and 32-bit) and each new platform massively increases the size of your lab.

        A large Enterprise application can take weeks to test each build, even with automated tools. If you move from supporting two platforms to four then you move your release cycle out by months. I know this from when we used to support Three different platforms. Reducing that to only supporting Two cut our overheads by roughly 50% (not 33%).

        It is not just a case of "a database is a database", even if you have been careful not to use any platform-specific features (in which case your system will perform like a dog). With one product we went to the extent of coding *Foreign Key Relationships" into the middleware in order to avoid the overhead of supporting different methods on different platforms (one of the platforms in that case didn't do proper RDMS - this was many years ago). Even stripping back the database to be more like a set of name-value pairs, supporting the multiple versions and platforms was *still* a major headache.

        So next time your ISV says they only support one or two platforms, have a think about how much testing and support you can expect on a product from a vendor which doesn't care what platform you use ...

    2. Matt Bryant Silver badge

      Re: No one ever got fired for choosing to stick with Oracle...

      Unfortunately, many boards seem to get a perverse sense of value out of being bent over a barrel by Oracle. I have fought through many projects where we trimmed ten or fifteen percent of the overall solution cost out by switching from proprietary UNIX to Linux, pats on the back all round, but when you then come to look at the major cost element - the software stack - there is no desire to move away from "tried and tested". I suppose it's progress as twenty odd years ago no-one would have wanted to switch out the UNIX.

  11. LDS Silver badge
    Thumb Down

    Did you ever worked on a *real* enterprise database?

    Lot of sensitive data. Lot of precious informations. Lot of informations you don't want to share with your competitors. Big ETL jobs to add new data, and procedures to extract reports. Those are the last companies that will move to the "cloud" whatever that means. Sure, pointy haired bosses read about the "cloud" everywhere and tell when interviewed they think to move to the "cloud", and they think about a fluffy white vapor. Then they ask their BOFH, and he simply shakes his head - no way to make the actual data load work "in the cloud" - but maybe our private one. Built on Oracle or the like.

    1. Tom 13

      Re: Then they ask their BOFH

      If only there'd been a BOFH between us and the PHB. Heck, I'm not even qualified to be a junior assistant to the junior assistant of the BOFH, but I knew the PHB was wrong when I saw the announcement the first time. In the newspaper mind you, not even on an internal memo to the IT staff.

  12. James 100

    Effective lock-in

    We have a $$$$ annual campus-wide licence for Oracle. For a lot of things, Oracle doesn't make much sense - but since one particular instance runs a little task called "payroll", changing it is something to be approached with extreme caution...

    It's possible to migrate individual products off, though - it may not show an immediate saving, but as soon as you hit the point you could switch to a cheaper Oracle offering it'll pay off. Down to a single (virtual) CPU, for example? (Payroll's certainly an important job, but doesn't exactly need vast computing resources to run!)

    Short-term, the 'path of least resistance' is easy: just cough up another six figures for another year and leave everything as-is. Each time it comes up for renewal, though, I feel the urge to whittle away at the reliance on it.

    More importantly, though, in years gone by it was "either we use Oracle which we've already paid for, or pay for (other db)"; these days, it's "either we use Oracle, which doesn't cost extra *for now*, or MySQL/Postgresql/other which is free anyway". Much easier - and much less use for Oracle. (Back in the 90s, we had a cross-platform user account sync server which used Oracle as the database for exactly that reason - would it now? No chance.)

    1. Bobthe2nd

      Re: Effective lock-in

      This is also known in the trade as risk mitigation. So it costs $ per year but then it may cost a lot more if you break your system, or have to run 2x systems in parallel while you move it over, redesign solutions etc etc

      So its not the first place I would look to save money..

  13. Buzzword

    On the one hand we have Matt Asay telling us that Web 2.0 is the way forward, that it's all fluffy clouds and open-source open-architecture from here on. On the other hand we have Steve Bong of ¡Bong! Ventures telling us the exact same thing. Hmm....

  14. This post has been deleted by its author

  15. Anonymous Coward
    Anonymous Coward

    Not the rigth target

    Working for a big financial firm, I can tell you that an ELA has never been used in my experience to prevent the move to Open-Source alternatives. In fact the main purpose of an ELA with one big vendor is to squeeze the business of another big vendor. The main thing stopping wide-spread Open-Source adoption is the lack of a good enough SLA.

  16. Anonymous Coward
    Anonymous Coward

    I was kinda taken in, until I read...

    "Matt Asay is vice president of corporate strategy at 10gen, the MongoDB company"

    Hmm, a nice impartial viewpoint then.

    1. Gordon 10 Silver badge

      Re: I was kinda taken in, until I read...

      I was kinda taken in until I realised it was a Matt Asay babble piece.

      Firstly the scenario he paints is decades away. Its essentially a variant on the Mainframe dinosaur piece from the 80's and whilst they are declining they are still with us.

      Secondly there is still a huge lack of credible offerings that match the breadth and functionality of the incumbent vendors in everything but a few niches such as Big Data where the sector actually originated as Open Source.

      Thirdly SAAS just swaps ELA revenue for (generally) a per user per month model since the big guys are all jumping on the band wagon they have plenty of time given point 1 to tune their service fees to replace their ELA fees.

      Fourthly in the real world that Matt occasionally visits just because the licensing model is SAAS based doesnt actually make the effort of moving between vendors or even in house materially easier for Companies to do. As noted above by various posters the nuts and bolts software bit is the easy bit - the surrounding business processes and infrastructure is the hard bit.

  17. hmas

    My thoughts.

    For Oracle, the ELA creates a couple of challenges. For some companies, they've managed to negotiate a site or campus wide license that makes Oracle quite a cost effective in the long term. However, those ELAs possibly exclude certain lucrative options, like Real Application Clusters. So, it creates a barrier to entry for the Oracle salesperson as the customer has, for once, got the vendor over a barrel. So, you now have a customer that probably hasn't implemented the best, or most strategically appropriate solution, partly because they do not want to effect any change to their ELA. Not a great situation.

    It also makes life difficult for Oracle when it comes to selling their current flavour of the month - the engineered system (pretty much Exadata).

    However, the SaaS alternative isn't much better. Salesforce are no better than the traditional enterprise vendors in many respects - minimum contract commitment, annual billing, lots of hidden costs.

  18. TwoWolves

    Same Old, same old

    My snake oil is better than his snake oil.

    Blah, blah.

  19. AntiPoser

    SAP and Oracle ELA's

    I do agree with some of the article about the lock in long term costs, but am curious why the biggest provider of ELA's and also the largest auditor of their ELA's is not also included in this article (Microsoft), or is this just an accepted that you have no way out so why bother to include Micorosft and only the handful of clients in the world that call themselves, Linux shops are free of this or are they also in some way tied into one of the large Linux Shops with and ELA.

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2022