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.