“Cloud first!” is the common cry from CIO offices across the land. All well and good, however, ‘Cloud’ computing comes in different flavours and the flavour you choose has a significant impact on what that means for your organization. At its most basic, the cloud simply means ‘someone else’s data centre’ but other approaches mean handing over more than just your hardware.

SAP Business Intelligence Cloud Approaches

S/4 HANA and BW4/HANA are categorized by SAP as ‘on-premises’ solutions, however they can be provisioned in the cloud via a hyperscaler. This is infrastructure as a service ‘IAAS’. This approach is very attractive to companies. It is cheap, flexible and ultimately, they still have control over their systems and what application-level code is running.
Software as a service (SAAS) is a different ball game altogether. In this scenario, the software vendor provides and manages not only the infrastructure but the software as well. So what? You might think, so A LOT! On the upside, you always have the latest code with the newest technology. However, this comes at the cost of a loss of control which some companies may be uncomfortable with.

Governance

I am a child of SAP best practice and have spent a lifetime working in controlled environments. In order to mitigate risk, an IT organization will control the following factors:
• What the landscape looks like.
• What changes are made.
• When they are made.
• How they are tested.
It is these elements which take the hit in an SAAS environment. Some of the loss of control comes due to inherent features of SAAS, some through the loss of key tools to the process.

Full System Copies

An application system is more than just code and configuration. It is a complex interaction between these components, the data within it and the users along with their authorizations. Looking at an empty system is like looking at a river without water or wildlife. This reality means that one of the most important tools that IT has in the support of good governance, is the ability to perform full system copies.
In the SAAS environment it is not possible to simply copy one environment over another. Worse still, fundamental differences can be baked into service offering, for example, in SAC users in the non-prod environment must have a certain license type which may not be what they have in production. If user control is governed purely within SAC this might be undesirable but manageable, however, if user provisioning comes from a third-party tool, there is a risk that user provisioning activities have to be adjusted and that would compromise testing.
Examples of the application of system copies and their impact on the what the landscape looks like and how it is used:

Replica Production Systems For Testing

A common risk-mitigation strategy is to have a very recent copy of production which is used to test any changes, both technically and functionally, before the change is made to production. If something goes wrong when moving updates into the copy system, there is an opportunity to correct the issue. In extremis, the change might be pulled altogether and never reach production.
Regular ‘copy backs’ from production to the test systems mean that any testing is performed against the latest data, the latest users and with their latest authorizations, not just the latest software updates.

Additional Transport Tracks

Should it be necessary, a project specific system can be ‘spun up’ and the transport track be managed by retrofit. This means that the project can proceed without the risk that code changed by the project can inadvertently be moved to production with a bug-fix.

Experimental systems outside of the transport track

It is very common for organizations to have a ‘sandpit’ environment where architects and developers can trial solution options without changing any of the systems in the core transport track. This allows the optimum solution to be found with no risk.

Landscape Complexity

Most organizations that I have attended have a five-tier environment (sandbox, development, quality assurance, pre-production and production).
The recommendation for most SAAS cloud options is to work with a two-tier landscape; production and ‘Non-prod’.
This approach may work in a stand-alone and low-change environment. However, where there are numerous teams working on shared models, the risks increase.
Where there is interaction between on-premises solutions and SAAS solutions, for example BW/4 HANA and SAC, having completely different landscape options is extremely hard to manage. (Do you point your single non-prod SAC system to development where new queries are being created or to the test environment where the data is better?).
It is possible to have more systems in the SAAS landscape, however, this dilutes the value proposition.

Software Release Cycles

Typically, SAAS and on-premises solutions release patches on a quarterly basis.
In the on-premises environment, you can choose which patches you want to apply. Updating the sandpit environment first means you can trial them without even touching your production track.
With SAAS environments, you get updates whether you want them or not. It is possible to opt for an “early-adopter” environment, however, this only gives you an extra month to identify issues before the changes hit all your core environments.

Maturity And Risk

The risk involved is inversely proportional to the maturity of the product. A very mature product will have fewer changes and therefore carry less risk. Unfortunately, in the BI space, it appears that there is still a lot of change to happen.
With SAC and Datasphere there is some overlapping of functionality that feels incongruous. Both can load, transform and store data. The communicated plan is for SAC plan data to be stored inside Datasphere so I anticipate some updates in this area particularly.
A huge amount has happened to SAC in the past 3 years, and it feels like the product is stabilizing as a fabulous tool (the question of data storage apart). Datasphere, only recently rebadged from Data Warehouse Cloud, feels like it is where SAC was 3 years ago.

Nobody is Perfect

SAP, of course, perform their own testing, however, last time I looked, the most recent OSS message number was 3221970. I am sure that not every number between 1 and this has been used, and not every OSS message is a bug fix, but it says something.
An additional consideration is that SAP test their code in their own environment. It does not (and cannot) take into consideration any customer applications or customizations. If an implementation has done something that SAP have not anticipated, then it is a matter of raising an incident and hoping that a fix will be provided within the necessary timeframe. There is always a risk that SAP will say that this usage is not supported, in which case an alternative solution must be found – but not having any control about when the problem hits production means that the timeline for this fix is challenging.

Conclusion

‘Fail fast’ is a great adage for an internet start-up, however, where enterprise data and core corporate IT systems are concerned, I find the loss of control concerning. If you are a government organization, a weapons manufacturer or are putting planes into the sky, how can you NOT have full control of your code?
SAP have said that S/4 and BW/4 are their strategic direction for on-premises systems and that they will be supported until 2040. Sadly, they have ceased development of new features for these platforms. Conversely in the SAAS cloud, there is some pretty amazing technology being developed.
This puts customers into a bit of a quandary. Should they abandon on-premises solutions with all their governance and rigour, and leap into the brave new world? Should they reject the cloud and dig in their heels? Or is there a third way? Please see my next blog “A Tactical Approach To Migration To The Cloud”.