Emptoris IBM Supply Management Crash: User or Vendor Error?

One of the questions surrounding the Emptoris IBM event failure (see Part 1) in a massive UK public sector bid involves whether we should even be concerned, in a cloud world, about the limits of hardware and computing scale. To this, my colleague Peter Smith opines: "Hardware capacity? Aren't we in the days of unlimited cloud-based capacity, all available at the flick of a switch ... Independent of who your provider is and whether they talk about 'cloud', it's worth establishing just how they manage capacity peaks within your portfolio of work or indeed across their whole client base."

Bookmark this thought for a minute – we'll come back to it. But perhaps the more interesting question is why this particular agency created such a massive bid with such a range of lots and diverse suppliers participating collectively. Equally, why would a procurement organization construct events that included huge volumes of attachments? Might the event have been broken into smaller bids with limited attachments? Here Peter observes and questions:


Buyers might also want to ask themselves whether sourcing exercises need to be quite so enormous? One positive outcome from this incident is that GPS are looking hard at how to simplify their own major tenders, as it was in part the sheer volume of bidders and the documentation GPS required from them that triggered the ADDSS problem. Is it essential to ask for so many different documents (certificates, compliance statements, separate references) or ask quite so many questions?

The bid failure, government response and supplier actions aside, the technology wonks in the Spend Matters audience are going to want to know exactly how one of the most proven e-sourcing systems, Emptoris, could run out of capacity. After all, if this was back in the early days of Trading Dynamics (Ariba), Bay Builder (Purchase Pro) and CommerceBid (Commerce One) and other reverse auction platforms, this might have been the expected outcome of such a large event. I personally watched a Commerce One bid crash before my eyes when I was at FreeMarkets doing a bit a competitive snooping.

We'll attempt to get to the bottom of this question in the next installment in this series. In the meantime, we believe it's important to leave Spend Matters readers with a few key takeaways regarding the scalability of the Emptoris platform today based on our own experience, evaluations and client selections:

  • Customers should not be any more concerned with the scalability of Emptoris (from an architectural perspective) than other competing solutions
  • All sourcing solutions have limits – some of the limits have root causes in architecture; others in the presentation layer; and yet others in deployment approaches and specific client configurations (which is the likely culprit here)
  • If users feel they may push the limits not only of a sourcing application itself but also a particular deployment approach in a specific situation, they owe it to themselves to reach out to – and work closely with – technical and product resources from their selected vendors
  • Keeping in mind that the greater the level of particular customization and highly detailed configuration requirements – for example, country or regional specific compliance, process and policy enforcement such as OJEU (Official Journal of the European Union) – for solutions not originally designed for a highly specific environment or process type, the potential for a greater processing load on the application itself (beyond the limits of testing in a more standardized configuration)

Stay tuned as our analysis continues.

- Jason Busch

Voices (4)

  1. Jason Busch:

    Mike,

    Thanks for the comment. I responded privately. Happy to discuss further live.

  2. Mike Oswalt:

    Really?!!!?? We are going to lay blame on the customer for planning an overly complex sourcing event while the solution provider is given a near pass? I can tell you that when solution providers are pitching solutions the phrase "All sourcing solutions have limits" is rarely, if ever, uttered. I am looking forward to additional investigation and analysis. I find it hard to swallow that a sourcing solution is so fragile that a customer needs to dumb down a complex package for the sake of the sourcing tool. There is an obligation of forthrightness by solution providers when there is failure. I’m not suggesting that IBM Emptoris need to make public errors caused by the software or hardware configuration but, neither should a campaign be undertaken to minimize their role or responsibility. This reeks of whitewash.

  3. Jason Busch:

    Perhaps the more salient question is what load/usage levels did the UK government plan for in the original deployment architecture and how was this articulated to Emptoris/IBM? Was the bid outside the box of what Emptoris committed to supporting based on the contract/deployment in question?

  4. an interested party...:

    re "cloud capacity".. are you in danger of assuming that the public sector customer of Emptoris was using a cloud-distributed system on Emptoris hardware, rather than an on-premise or ASP (via an approved government IT supplier) configuration??

Discuss this:

Your email address will not be published. Required fields are marked *