back to article It's been 20 years since Oracle bought two software rivals, changing the market forever

Twenty years ago next week, Oracle closed the $10.3 billion deal to buy HR and finance software specialist PeopleSoft after a fraught, drawn-out, hostile takeover. It marked the high point in a period of tech industry takeover mania, and the zenith of Oracle’s transition from a database company which also does applications to …

  1. Anonymous Coward
    Anonymous Coward

    and Hyperion...

    While the article focuses on the ERP side of apps, it should not be forgotten that Oracle made about 60 other similar investments between the 2005 Peoplesoft/JD Edwards and 2009 Siebel acquisitions.

    This included the key acquisition of Hyperion Software (a merger of Hyperion Solutions and Arbor [Essbase]) in April 2007 shortly after Hyperion had acquired the analytic vendor Brio.

    Hyperion continues to be a key pillar in Applications Unlimited, and customers can also host this in OCI, Azure, or AWS.

    Note: Essbase continues, more in tech as a database, to underpin the Fusion ERP and EPM cloud solutions, and the analytics elements have evolved to be a key element of the AI, reporting and dashboard capabilities as highlighted by the evident exposure by Red Bull Racing.

    1. Steve K

      Re: and Hyperion...

      Oracle have done no significant investment in Hyperion functionality for 10+ years apart from Tech stack updates (including Essbase 21C). The thought was to push people to FCCS/EPBCS which are only now starting to become competent products for some Hyperion clients (who haven’t already jumped to OneStream/Tagetik)

      They bought Hyperion/Arbor because their homegrown EPB (Enterprise Planning and Budgeting) solution was going nowhere fast and did not tempt anyone away from the Express-based OFA/OSA solutions.

      Hyperion is like a Lancaster bomber - a million pieces flying in close formation (possibly less so now that the Brio stuff has been deprecated from FR) and I say that as someone who has been well-remunerated for many years for keeping Hyperion infra fed and watered….

    2. big_D Silver badge

      Re: and Hyperion...

      Essbase was my first experience with OLAP databases, back in the mid to late 90s. It was great, but recalculating was horrendous!

      We had servers with dual and quad Pentium Pros, running at 60Mhz. I had a Pentium II 233 at home... It was actually quicker to export the bottom layer data, drive an hour home, import the data, calculate, copy the database and drive back to the office and copy the database back onto the server (thank goodness for Zip Drives!). I once forgot to set the compress flag on a new database, instead of around 90MB, it killed the server, when it got to 4GB and there was no more space!

      We used Essbase for monthly reporting and planning and Hyperion for budgeting, back then. Hyperion bought Essbase a few months after I moved to a different customer and I never got to use either again.

      I've been lucky, I've not worked anywhere that has used Oracle's database or software suites, or SAP for that matter. I did some consulting for a couple of months on a SAP data warehouse project, but on the business analysis side, not the SAP BW side, thank goodness. I looked at it, but it felt really old and creaky (2001), compared to Essbase and Hyperion that I had used 5 years earlier!

      Most places I've worked have either used industry specific ERP solutions or a couple have used Navision/Dynamics NAV. We currently use a specialist ERP for the chemical industry in our German parent company, whilst the American sub-division uses NAV at the moment. Before that, I was working for a software house that provided ERP solutions for the food industry, especially eggs and meat processing.

    3. mussadiq45

      Re: and Hyperion...

      The article highlights Oracle's strategic ERP investments, but the broader scope of acquisitions, like Hyperion in 2007, is crucial. 'Yesterday is dead,' but these moves shaped Oracle's current analytics dominance

  2. JacobZ

    Make it so

    My recollection (possibly faulty, it was a long time ago and a lot of beer has flowed under the bridge since then) was that a couple of years before all this kicked off, Ellison confidently predicted that the ERP and CRM space was inevitably going to consolidate, and that when the dust settled, Oracle would be one of the big winners.

    When the market steadfastly refused to go along with Ellison's opinion, he set about making it happen himself with a series of acquisitions of decidedly questionable business sense. Oracle's actions triggered SAP to follow suit, thus "proving" Ellison's foresight.

    BTW, in my experience one of the unalterable laws of software is that any project, product, or portfolio named Fusion is a hodgepodge of incompatible technologies that get along like a sack of cats and that Marketing is trying to throw a blanket over.

    1. Scene it all

      Re: Make it so

      I used to work on a small part of Fusion at Oracle and your description is exactly what it was like.

    2. Bitsminer Silver badge

      Re: Make it so

      "Fusion" signals hodgepodge.

      And "EZ" ain't.

    3. 'bluey

      "any project, product, or portfolio named Fusion is a hodgepodge of incompatible technologies"

      When I was a young, wet behind the ears graduate many decades ago, a wise old fart explained that the more gung ho a product's name, the shitter it actually is.

      That rule has really stood the test of time.

      For the other now-old farts out there, he was explaining this and using JSA (that fucking awful contractors account) and their Contractor+ package as an example.

  3. John Smith 19 Gold badge
    Coat

    JDE and Peoplesoft were both big AS400/iSeries hosts

    IOW they run on DB2/400 (or whatever it's called now) mostly for market share.

    People who've used it know that a lot of stuff just works. Not sure how much that is the case with Oracle. Be curious how many of those customers are still running on that hardware.

    "Oracle fired 5,000 PeopleSoft workers. "

    Literally no surprise there. That's how MBA types "Release shareholder value"

    Cut off a companies arms (IE it's support) and lobotomise its head (IE it's developers with their corporate memory).

    Better than SAP grafting on "Business One" from an Israeli firm? IDK.

    1. werdsmith Silver badge

      Re: JDE and Peoplesoft were both big AS400/iSeries hosts

      JDE ran on Windows Servers and SQL Server 7 / 2000 DB also.

    2. big_D Silver badge

      Re: JDE and Peoplesoft were both big AS400/iSeries hosts

      My first employer did a downsizing about 18 months after I started and looked for volunteers. One was a 40 year veteran of the company, he was incredibly expensive to let go - when we were taken over, the company took on our previous contracts, which included 1 month for every year of service severance. The company didn't do due diligence and let him go... Once month later, they realised he was the only person with any knowledge of around 2 dozen monthly data collection systems running under GEORGE 3 - the rest of the company ran on VAX or IBM, not ICL. He came back as a consultant for a further 8 months, to train up replacements! He got his golden parachute, along with a golden cushion to land on!

  4. disgruntled yank Silver badge

    I retrospectively became fonder of Peoplesoft when I encountered the table-naming conventions of Microsoft Dynamics: two or three letters to indicate the kind of data (GL, DTA), followed by five digits to specify it more closely. In my relatively few dealings with Dynamics, I kept a spreadsheet of descriptions handy. Peoplesoft had tables named along the lines of PS_PERSON, PS_COMPANY, and so on.

    Peoplesoft was over-engineered for the needs of my employer. I imagine that an organization with an order of magnitude more employees, say five thousand, would have been a better fit. I did like what I saw of it, though.

    1. Cliffwilliams44 Silver badge

      The table naming convention of Dynamics goes way back to the time of when it was called Great Plains.

      I remember those days well, and yes, I too kept a spreadsheet of that those cryptic table names related to.

      1. John Smith 19 Gold badge
        WTF?

        "The table naming convention...goes way back to the time of when it was called Great Plains."

        Wow.

        The MS buyout of Great Plains and Navison to mash them into "Dynamics" was > 20 years ago.

        That implies no overhaul since then.

        1. midcapwarrior

          Re: "The table naming convention...goes way back to the time of when it was called Great Plains."

          That's one way of looking at it.

          Another is that once you learn an archaic naming convention it's a PITA for the user base to switch even if a newer naming scheme makes more sense.

        2. big_D Silver badge

          Re: "The table naming convention...goes way back to the time of when it was called Great Plains."

          That is pretty normal. The software will be bandaided together and new bits stuck on top, but the underlying architechture is just added to, not replace wholesale. It is usually too expensive to do a complete re-write of the whole system.

          I worked on an ERP system for a while, it was written in C from the 1970s and the front end was a Windows GUI wrapper that read the VT100 screens coming out of the application and transformed them into Windows elements. It still used terminal control keys. "End" key = save, Home = escape/abort. The number of times I'd be editing a position in an invoice and hit home to go back to the beginning of the line and the system dropped the whole invoice and I had to start again!

          The current system we work with was a COBOL based UNIX system, which was converted to MicroFocus COBOL in the early 2000s. They finally did a complete re-write (bought in another ERP system on license as a basis) around 2018, which used a monolithic Java front end - each instance for each user on the terminal server requires 4GB RAM, and most users work in 2 tenants, so require 8GB RAM! Who on Earth made such a silly decision in 2018 to use a monolithic front end, instead of jumping straight to a web based system? They upgrade this summer to v. 2 and the client is still a monolithic Java system, but "only" requires 2GB per instance.

  5. jpennycook

    Saving money by buying companies

    At the time, I wondered if the goal was to save on rent - Oracle seemed to like buying fellow occupiers of Thames Valley Park in Reading

    1. John Smith 19 Gold badge
      Unhappy

      "Oracle seemed to like buying fellow occupiers of Thames Valley Park in Reading"

      Ahhh.

      Now that's the sort of thing MBA's can understand

      Consolidate offices --> lower headcount --> less office space needed --> lower annual rent --> Hello bonus

      1. Anonymous Coward
        Anonymous Coward

        Re: "Oracle seemed to like buying fellow occupiers of Thames Valley Park in Reading"

        I don't think you fully appreciate the business acumen here.

        Buy fellow occupier for $10B. Fire half the staff. Fewer offices needed. Less demand for office space. Oracle negotiates lower rents for it's office space saving hundreds of thousands EVERY YEAR.

        1. John Smith 19 Gold badge
          Coat

          "I don't think you fully appreciate the business acumen here."

          And you, Mr or Ms AC don't fully appreciate what the word ANNUAL means.

          English not your first language?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like