In the previous post in this series we examined how the nature of the relationship with a SaaS vendor has many parallels with being a certain Roman general and statesman.
Still not convinced?
Let’s consider how for the first fifty years of his life, Julius Caesar enjoyed a number of roles within the Roman Republic, culminating in his rise to Consul. It was during this time he conquered the Gallic tribes and ultimately returned to Rome by crossing the Rubicon river. This ignited a civil war which ultimately set in motion a course of events which would install him as an elected dictator (emperor in all but name) – but would lead to his assassination five years later.
In the world of on-premise software, organisations behave very much like democratic republics. Software applications might be developed by a vendor, but they are operated by your “elected” representatives (your IT team, who are ultimately accountable to their electorate – your organisation) and who can be relied upon to manage risk in alignment with your business goals.
The world of cloud applications is very different – mainly because your data is placed in the direct control of SaaS vendors and you depend on them to perform much of your day-to-day operations.
Rather than a democratic republic, this is more like being emperor over a series of (SaaS vendor) “tribes” who have local control of their own provinces.
Understanding the true loyalties of the SaaS vendor tribes across your empire is of much greater importance and dictates the level of trust you place in each one.
By adopting SaaS, the capability of our empire grows rapidly, but we entrust our reputations and livelihoods to these vendors, so we must consider a different approach to maintaining control.
And once we make this move, there probably is no easy route back. As Caesar said when he crossed the Rubicon – “the die is cast”.
Once we widely adopt SaaS, we effectively incite a civil war between our own IT teams and SaaS vendors, from which the SaaS vendors will generally emerge as victorious, due to benefits they offer to end-users.
The IT team that remains will often be transformed into a more consultative role meaning we are committed to a SaaS-based future.
So, it is important to move to ensure your level of governance is maintained, albeit you may need to take some examples from a dictator’s playbook to maintain it.
Some of the key considerations when assessing SaaS loyalty should therefore include the following:
Know your tribes (the vendor): it’s important to know as much as possible about the company that will be intimately involved in your day-to-day business and will have access to (potentially) sensitive data. That includes factors such as the jurisdiction of the vendor company and its financial status – is it a public company or a micro-business? Is it funded by venture capital and how long has it been in existence?
For SaaS businesses, which sell and fulfil entirely across the Internet, reputation and history are very important. A background search can bring up a plethora of information about the company, but this requires judicious sifting to assess its validity – as for any topic, simple “Googled” opinion can be unreliable.
Find and understand the local customs (the terms and conditions): Often the SaaS application will already be in use within the organisation before anyone takes a critical view on the legal arrangements they may try to impose. In all probability, for all but the most mainstream, big-vendor SaaS, the contract was probably executed by an individual employee clicking ‘accept’ on an online End User License Agreement (EULA). Worse still, the contract and any updates will most likely be sent directly to their mailbox, not to purchasing or corporate legal. It can be a significant effort to track down who actually signed up to an application and know what versions of a EULA they agreed to.
How strong are your borders (is your data safe?): Perhaps the most significant aspect of SaaS is that data is handed to the vendor to manage and process. It’s vital to know where that data will be held, who will have access to it, and how it will be protected. Considerations such as data privacy have become much more critical with legal protections put in place in various jurisdictions – GDPR in the EU and CCPA in California, to name two of many.
There are multiple strands related to security and privacy, but a good place to start is information published by the vendor. A thorough privacy policy outlining what they intend to do with data in their possession, stated compliance with privacy and security standards and legislation, and transparency about key aspects of their infrastructure are good things to look for. Do you have access to all of these? Have you reviewed them? Outside this, a sound background knowledge of news stories about data breaches can also indicate whether the vendor has a history of poor security practices.
Keep your friends close, and your enemies closer (ensure your data is always available): Having entrusted your data to the SaaS vendor, it is important to think about whether you will still be able to access when situations or relationships change. This is a consideration often ignored for SaaS applications, because they typically use highly-available public Cloud infrastructure provided by one of the major Cloud providers – who work very hard to ensure their infrastructure is reliable. However, there are many ways in which Cloud-hosted SaaS can still fail catastrophically – which means you won’t be able to access your data or keep business processes operating.
Some of the availability features of public Cloud require the SaaS vendor to explicitly take actions – and pay enhanced subscriptions – so it’s important to understand if that has been done. The application software can fail and take a long time to recover, or the SaaS vendor might cease trading without much warning. If the service fails and doesn’t come back up, there is very little the customer can do – not even the option of reinstalling on a new server as with non-SaaS software.
It may not be easy to create a ‘Plan B’ for a SaaS application. In many cases it’s not possible to continuously extract your data from the application in any useful way. Implicit in the SaaS business model is the need to lock in customers using whatever mechanisms are available, so it’s not in the SaaS vendor’s best interests to make it easy to transfer your data out. Being able to extract all your CRM data to XML files in a proprietary format is not a viable business continuity strategy, unless you have a means to import it into an alternative system and keep running.
For business continuity it is important to assess what the vendor offers and think about whether data can be extracted and meaningfully backed up outside the SaaS service to provide a disaster recovery option.
Divide and conquer (avoid concentrating your risk): As more SaaS is deployed, concerns have been growing about concentration risk: more and more SaaS services are being concentrated into a decreasing number of hyperscale Cloud providers means that in the event of a platform failure on the part of (say) Google Cloud, a significant number of services could be lost simultaneously.
In a world of composable applications, there is a strong likelihood that the single SaaS application that you are using is dependent upon other SaaS applications for particular functions. Virtually every basic application function – from deployment to monitoring to reporting or payment processing – are available as SaaS services, allowing SaaS vendors to build them into their own applications. There is an iceberg of SaaS applications under the water that you cannot see, and in many cases the same basic service is used by hundreds of applications.
Concentration Risk has become a concern to regulators in several industries, including the Financial regulators in the EU and UK, who have issued advice to their regulated suppliers – and are planning legislation to enforce it. Considerations about which Cloud platforms and subsidiary software services underpin the complete SaaS environment within the organisation are important – but it can be a major challenge to map out all the dependencies.
The shift to SaaS has changed relationships with software vendors in unexpected ways. Vendors are more likely to be more deeply involved in supporting your business day-to-day and can have a much more immediate impact if their service has an outage. Yet at the same time, relationships are much less rigid with often just a click-through EULA and an email address as formal contract initiation.
So, how did you build your new empire? Was it through systematic consolidation of well-known allies with whom you have an extensive treaty? Or did it grow through the victories of your most capable lieutenants, fighting on your frontiers, taking what they consider reasonable risks in the field?
Being aware that the balance of responsibilities has shifted around, and that your organisation’s policies need to keep pace is key, otherwise there is a real risk that the trust upon which business is built will not be maintained.
Despite his reputation as a great military general, Caesar was almost defeated in some of his biggest battles and was well known for taking great risks, many of which could have relegated him to a smaller footnote in the history books, had fortune swung slightly the other way.
And, of course, this did finally catch up with him, as he was assassinated by his own lieutenants, and Rome eventually fell due to an inability to control the tribes it governed. It was finally sacked in 410 by the Visigoth King Alaric leading to ultimate downfall by 476.
If we don’t maintain control over our SaaS Empire, the benefits of SaaS in driving innovation at an ever-increasing rate through thousands of agile SaaS vendors will not be realised.
In fact, the risks you are taking with your data will mean your own governance and compliance could be under considerable threat due to the actions of some remote software vendor “tribe” leaders.
And history will probably not look on you as favourably as Caesar.
