I find reading articles about cloud adoption intriguing, particularly when presented as a more business oriented view. Not from a position of needing knowledge, but to see how people are conveying the values and propositions, Being an engineer at heart I make the effort to ensure Im balancing that tech thinking with business perspectives. Often I find these more business focused cloud articles focus on aligning business processes to vanilla industry standards, or the ability to go live with a major capability such as ERP or HCM in weeks or a few months. However, a lot less is said about the long term sustainability of using cloud solutions and how an organisation needs to think about such things. This is perhaps best conveyed through example.
Many organisations often only upgrade their core ERP, CRM, HCM systems when there is a functional need that can’t be typically addressed with a quick customisation or a new report. For example the infrastructure is struggling under-load, the vendor has stopped supporting the product from even the most expensive support offering, and occasionally upgrades get driven by having to deal with new legal obligations. As a result, it means every 3-5 years things get to a point that a significant project is started to absorb that backlog of change, and with it significant cost as all those tweaks and customisation need to be analysed and replaced. Then because everyone is nervous about the change the testing cycle becomes very extensive.
In the cloud context, the vendor is going to be pushing out bug fixes, security patches every month or couple of months. You will see functional updates every 6 to 12 months with a limited window in which you need to cut over to the new version. One of the value/cost proopositions from a vendor’s perspective is to cut the number of versions needing support. In the PaaS and IaaS layers the tempo of change is even faster and with shorter cutover windows.
All of this means that an organisational change of approach from risk averse to embracing change and risk mitigation is needed to live with SaaS and PaaS provided solutions. With this comes the need in most cases to working to the supplier’s timeframes not your own.
When you’re creating a solution that includes a lot of built features such as integrations, extensions (PaaS4SaaS, or even new bespoke solutions to provide those business differentiating capabilities) it is very tempting to adopt the old school model and perform one off manual tests to keep the delivery time scales short. Whilst it may keep time short on the 1st cycle, in the cloud you’re going to be going through upgrades far more frequently, so in the lifetime of a solution, automation or semi automation is going to pay a return. These areas where automation is not overly difficult are often going to cover the areas of greatest risk; an API change, the omission of maintaining an SSL certificate. These can all very easily cause a break things to break, and all are easily overlooked in the big picture when pushing out product updates. Generally these issues are not overly challenging to fix once the cause is found. So automating the tests first time means it becomes very quick to spot any issues before the updated instances are in production. But this again needs forward thinking, to realise automating tests may cost time and effort on the first cycle, but costing nothing in the 2nd, 3rd, 4th cycles …
A sales pitch may say, cloud eliminates all these issues, as the vendor is running the platform – the changes are incrementally small, nothing to be concerned about. But the reality is, enterprise SaaS solutions are still very configurable, meaning scenarios exist that the vendor may not have considered occur. A couple of years ago, this point was beautifully illustrated to me, by looking at the number of products Oracle offered and then calculating the number of permutations of product (not counting features or configuration points within a product), the figure came out at in excess of 19 million. If you tried to test even 1% of all these permutations by the time testing was complete, the product will be redundant. The vendor realistically has to do risk based decisions. So the reality is vendors will overlook scenarios or rule them out as very unlikely. This before you take into account those, Integrations or extensions are customer’s code, not a vendors.
As you can see, an organisation needs a mindset that understand change and how to, be on the front foot geared up to engage with the updates, plan for them against vendor timelines. Look to strategies of derisking and revalidating quickly going forward. Don’t get caught up in the delivery costs and timeline of 1 delivery/golive cycle, but focus on your TCO.
So when the conversation about cloud turns to organisational readiness, it isn’t just are the more up to date browser versions rolled out, or training on the new product or business processes, it is also that readiness to embrace constant change and how to mitigate the possible impacts. They do happen, ask Netflix and others about AWS, look at Microsoft’s status report site, and yes Oracle publishes its known issues for each cloud offering.