A few days ago, SAP’s Ariba Network shut down for about four hours. The outage was reported to customers on the network, but you can see a daily status report of the trailing week here from Ariba’s website. Here’s the snapshot for posterity.
Although the above network status screen is public, the outage has not been reported by any media, so I decided to report on it because there are some important lessons to take away:
- Application suites in the cloud have data dependencies regardless of their database, as seen in the fine print above. Modules that are not highly componentized in a service-oriented architecture with APIs adhering to REST will be more prone to this level of tight coupling and shared dependency on the database/network/hardware. If you put all your eggs in one basket, you’d better make sure that the basket doesn’t fall.
- If you have many systems running in the cloud, you better make sure that if one system goes down, you have the contingency plans in place to deal with the scenario of each of those systems going down that run on their own servers. With SAP, although it’s “one vendor,” you will pretty much be guaranteed to have multiple systems underneath: Ariba Cloud Applications, Ariba Network, Fieldglass, and any hosted versions of SAP SRM, SAP ECC, SAP SNC, etc. I wrote about this problem in Don’t Fall for the Myth of Integrated ERP Procurement.
- Although it’s easy to say that a cloud system should be “always on,” it is obviously harder to do. When working with any cloud provider, you should make sure that redundancy is well in place and near bulletproof. The use of a strong IaaS (Infrastructure-as-a-service) capability is key, whether it’s a commercial IaaS provider or a SaaS provider that uses its own IaaS stack or someone else’s. For mega vendors like SAP, Oracle, IBM, Microsoft, and other who are building out their own infrastructure, they are not going to just plug into Amazon AWS or Rackspace. And since they are inheriting much of that infrastructure with every acquisition, switching out the infrastructure underneath is, ahem, non-trivial.
- Make sure that your cloud contracts are rock solid. Make sure that you have SLAs well defined that also have some teeth. We won’t get into the intricacies of indemnification clauses for cloud providers, but when the systems do become mission-critical, you need to truly look at the business cost of downtime. This leads to the most important point…
- If you are going to run your mission-critical Six Sigma supply chain on the cloud, you better be damn sure that your information supply chain is running at those same levels. OK, so a four-hour down time, even in the middle of the day like this event (times are GMT), might not be that big of a deal for indirect spend (although there is a lot of fairly-mission critical indirect spend out there too). But when you get into the supply chain, it’s a different ball game in today’s hyper-lean environments. It’s not that you went down to 99.95 percent uptime based on the above event, but rather that you disrupt operations to the tune of revenue disruption, and that’s not a happy place to be for anyone. But for SAP, with the Ariba Network, it’s not like one customer’s server went down. It’s like Houston command control going down, and until the global data centers are all built out with proper infrastructure (work that is feverishly being conducted right now), heads of supply chain will obviously be viewing SAP’s tenuously-made assertions for the Ariba Network being supply-chain-ready as a bit premature.
For other cloud-based providers, they’re obviously not immune from this issue, so it’s really key to work closely with your partners to ensure not just their contractual guarantees, but their infrastructure and level of investments in continuity planning. The levels of uptime that EDI providers have guaranteed to certain (but not all) customers in the past for connectivity, e-invoicing, and other areas is actually less than Ariba’s 99.5% standard guarantee. And let's not forget even AWS is not immune from unplanned outages.
But don’t just create (or accept) contracts based on a specific SLA for up-time – that’s the legalistic and easy way out. Take the time to understand what it takes a connectivity partner to get from 99-percent to 99.5-percent to 99.9-percent to 99.999-percent uptime. These are order of magnitude leaps in many cases. And remember, these are key partners in the case of supply chains – not just supplier network hubs for routing POs and invoices for paper clips (AKA "office fasteners") or run-of-the-mill software vendors.
Obviously, SAP has its work cut out for it, and raising system availability for the Ariba Network as it begins to tackle direct spend areas is just one consideration. It also has to ensure that its procurement customers are in fact being granted the rights that they deserve, as I’ve written about in my Procurement Bill of Rights series (see Related Articles).
The cloud is no longer a strategy, as we’ll be writing about shortly, given some recent organizational changes at SAP. The cloud should be assumed as implicit for future computing, but if you just assume it will be deployed to you seamlessly without a strong Procurement Information Architecture and some sort of a Procurement PaaS strategy, you'll be exposing your business and supply chain to significant and unnecessary risk. We touch on some of these PaaS elements here, here, and here but also with specific examples such as Elemica, Tradeshift, Nipendo, and E2open.
The battle for the best procurement [true] platform is only just really beginning. The applications are the weapons on the battlefield, and they are obviously critical, but not the whole story to winning the war.