Skip to Content
Technical Articles
Author's profile photo Matthew Shaw

SAP Analytics Cloud – Landscape Architecture & Life-cycle Management

What should the landscape architecture of SAP Analytics Cloud look like and how does it compare with traditional on-premise landscapes? How should I manage the life-cycle of content in SAP Analytics Cloud? I address these and many other common life-cycle management questions in my article.

I first look at typical on-premise landscapes and then compare this to the Cloud, what’s the same and what’s different. The final architecture is determined by many factors and I present the most important things you need to know, including summaries of:

  • Public and Private hosted editions
  • SAP Analytics Cloud Test Service and its Preview option
  • Quarterly Update Release and Fast Track Update Release cycles

I explain where each fit into the overall life-cycle, thus allowing you to determine the right architecture for your organisation. This includes explaining how and when you can transport objects between the different Services. Here between the Preview Service and the regular Quarterly Release Cycle (QRC):

and here between the Quarterly Release Cycle and the ‘Fast Track’:

(the ‘Fast Track’ is not provisioned by default)

I also present why multiple environments are need at all and what can be achieved, albeit in a limited fashion, within a single environment when managing the life-cycle of content.

I present the typical landscape options chosen by most other customers and the most common path of adoption. Thus, giving you some guidance on what your next step on your SAP Analytics Cloud journey might be:

Content Namespaces are also an important concept to understand and I present some recommendations on how to manage this to avoid known issues and reduce the risk for your projects.

I also present the options for transporting objects around the landscape and I finish with a Best Practice Summary.

You can access my article in the wiki, download the slides and watch a video of the content being presented

Your feedback is most welcome. Before posting a question, please do read the article carefully and take note of any replies I’ve made to others. Please hit the ‘like’ button on this article or comments to indicate its usefulness.

Many thanks

Matthew Shaw @MattShaw_on_BI

https://people.sap.com/matthew.shaw/#content:blogposts

Assigned tags

      16 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Henry Banks
      Henry Banks

      Fantastic blog Matthew Shaw

      Thanks for taking the time to put this together.

      I know this is a really complex topic, with different, wide-ranging experiences for our various customers.

      This article really helps pull that all together, and will be perfect for a forthcoming discussion with one of my customers!

      Kind regards

      Henry

      Author's profile photo Iñigo Montoya
      Iñigo Montoya

      Thanks for the blog, Matthew!

      I have also reviewed your interesting powerpoint document.

      One comment I have: it would be usefull to include the impact of the QRC in the on-premise source systems.

      I mean, for instance, when a live connection is used, I am sure you are aware that there are a number of notes that must be applied.

      Then, I guess Test Preview should be pointed to a sandbox environment with the notes applied.

      What is your reommended approach?

       

      Thanks again for the insights,

      Inigo Montoya

      Author's profile photo Matthew Shaw
      Matthew Shaw
      Blog Post Author

      Hello Inigo

      Many thanks.

      For the impact on on-premise, then please take a look at another blog on mine: https://blogs.sap.com/2020/06/19/sap-analytics-cloud-technical-and-administration-overview/

      Any notes, typically needed only for new features, would need to be applied to the sandbox database (live data source using a live connection), yes. My other blog/video talks about this with a bunch of SAP notes to follow. But generally speaking your existing content should not stop working just because you're using a newer version of SAC. But having the sandbox gives you that re-assurance and if any action is needed then if you're using a Fast Track Sandbox or a Quarterly Release Preview gives you that opportunity to take action before the Quarterly Production/Development/QA environments are updated.

      Typically speaking though, any on-premise updates are for defect or performance reasons, though not exclusively. For example the BI Platform sometimes requires a Support Pack update or an update to the Tomcat/JDK etc. So there are exceptions but if you're on HANA or BW then you only really need to be more concerned if you're on a very old version of BW or HANA where SAP might increase the minimum support level, but there's SAP notes to follow to give you plenty of time to plan accordingly.

      Regards, Matthew

      Author's profile photo Bose g
      Bose g

      Hi Matthew

      Attended your webinar today, It was awesome. It's crystal clear

      by the way I was wondering whether SAC does holds a dedicated architecture other than

      SAC-Overview(attachment),similar to what BW holds( such as LSA,LSA++)

       

      Regards

      Bose

      Author's profile photo Matthew Shaw
      Matthew Shaw
      Blog Post Author

      Many thanks Bose for your feedback.

      There's no architecture diagrams as such, but I'll bear this feedback in mind as I can see there's a need for it. Could you describe more about what or why you'd like to see. I can then use this feedback to see what can be done. Many thanks indeed, Matthew

      Author's profile photo Bose g
      Bose g

      Matthew

       

      The reason being as part of our discussions with BW/HANA/B4/S4 regarding SAC Pros & Cons in conjunction with Business Objects SAC Architecture issue came up, hence this query

       

      Best Regards-Bose

       

      Author's profile photo Anirudh Srinivasa Varadhan
      Anirudh Srinivasa Varadhan

      Hi Matthew,

      your blogs are a one-stop solution for SAC questions! I find the lifecycle management of SAC content in a Live BW scenario quite unique and different from a BO-Server landscape.

      Is there information available on how objects like Comments and Bookmarks are stored? Are they stored in separate files or in the same file as the Story? When the same story with no comments from the Dev. Tenant in transported using the Content network to the Prod. Tenant, where the story does have comments/bookmarks - Are the comments/bookmarks retained in the Prod. Tenant?

      If yes, Does that imply the comments/Bookmarks for a story are stored in separate files?

      If No, do we need to transport the story to Dev. tenant before any change is made to story so that objects like Comments/Bookmarks are retained?

      Is there a plan to introduce automatic system switching for Live connection in the near future?

      Looking forward to your feedback!

      Best Regards,

      Anirudh

      Author's profile photo David PEIRO-REDON
      David PEIRO-REDON

      Matthew,

      Thanks for the content, very helpful and comprehensive tour covering many aspects around SAC.

      A question around your point 'a single SAP Analytics Cloud Service can not manage the life-cycle of content on its own', in our single-tenant landscape we are facing some of the limitations you describe in change and application life cycle management for our SAC stories, in your opinion which is the most cost-effective approach to implement a SAC Test environment and transport changes via Content Network?

      We currently operate our SAP S/4HANA infrastructure in private Cloud and SAC Production tenant in cloud foundry, is best option to request a test tenant in the cloud or there are options to go on-premise or private cloud?

      Regards,

      David

      Author's profile photo Yoav Yahav
      Yoav Yahav
      Matthew Shaw Thanks for this article, is there an update for 2021 quarterly releases?
      Thanks
      Yoav
      Author's profile photo Henry Banks
      Henry Banks

      Hi Yoav Yahav nice to hear from you. Thought i'd chime in ahead of Matthew Shaw incase he doesn't see this right away.

      The 2021 quarterly releases don't change the landscape recommendations, but if you're looking for an updated release calendar, then they are here: Note 2888562 - Harmonized release calendar for SAP Cloud products

      the scheduled release dates are:

      1. QRC1 weekend of February 20th,
      2. QRC2 weekend of 22nd May,
      3. QRC3 weekend of 21st August,
      4. QRC4 weekend of November 13th 2021.

      This reflects the current state of planning but may be updated without notice.

      1. QRC1 includes bi-weekly waves 2020.22, 2020.23, 2021.01, 2021.02
      2. QRC2 includes bi-weekly waves 2021.03, 2021.04, 2021.05, 2021.06, 2021.07
      3. QRC3 includes bi-weekly waves 2021.08, 2021.09, 2021.10, 2021.11, 2021.12, 2021.13
      4. QRC4 includes bi-weekly waves 2021.14, 2021.15, 2021.16, 2021.17, 2021.18
      again, this info above reflects the current state of planning but may be updated without notice. (i.e. some waves might be moved out to later QRC releases) 
      Regards
      Henry
      Author's profile photo Yoav Yahav
      Yoav Yahav

      Thanks Henry Banks, this is very helpful!

      Author's profile photo Derek Barrett
      Derek Barrett

      Hi Matthew,

       

      Is there an idea of a system copy in SAC?

      Example, we want to take all of our objects in Production and copy them down into our Test tenant. (Rather than having to select specific objects).

       

      Thanks!

      Author's profile photo Matthew Shaw
      Matthew Shaw
      Blog Post Author

      HI Derek

      Good question. There is no system (service) copy tool, you need to use the Content Network (or the legacy Export/Import) to transport content from one service to another as you indicated. There's no equivalent 'copy repository' like you could do with say the BI Platform.

      Regards, Matthew

      Author's profile photo Derek Barrett
      Derek Barrett

      Thank you Matthew !

      Author's profile photo Luis Lopez
      Luis Lopez

      Hi Matthew,

      Very useful and detailed content.

      I have a question regarding Cloud vs On-Premise Landscape and the scenario where there are fewer SAC environments than on-premise systems.

      For example, if we assume a two-tier landscape for SAC (Option 2 from the landscape options slide - with 1 Dev and 1 Prod tenant) and a 3-tier or 4-tier S/HANA landscape (Dev, QA, Pre-Prod, Prod).

      For acquired connections (as we are looking to use SAC Planning functionalities):

      • What is the the recommended connection setup between SAC & S/4 environments?
        1. SAC Dev to S/4 Dev and QA  /  SAC Prod to S/4 Pre-Prod and Prod
        2. SAC Dev to S/4 Dev, QA and Pre-Prod  /  SAC Prod only to S/4 Prod
      • How would the development lifecycle work within the SAC Dev tenant?
        • For example, when a development is ready to be tested against QA (or Pre-Prod), is it just a matter of repointing the same connection to S/4HANA QA (in the connection settings) and reload the QA/Pre-Prod data?
      • The Landscape options mentions that SAC "QA environments are not so common", in this scenario would you recommend including a SAC QA tenant? Cost aside, what should be the main driver to decide whether to include a SAC QA tenant or not?
      • For the above questions, are there any different considerations for Live Connections?

      Thanks in advance for your answers and any information you can share on this topic.

      Regards,

      Luis

      Author's profile photo Matthew Shaw
      Matthew Shaw
      Blog Post Author

      Hello Luis,

      Many thanks for your feedback and your question, its always a good idea to clarify things. Its a big topic this, but I shall give it a go...

      Firstly, there’s a big difference between acquired and live models. Models based off acquired data require you to load that model with data, unlike a live model.

      It means for a live model it’s as a simple as pointing it to a different connection and that’s it. (Though in practice you don’t do this, you need to follow a slightly different workflow that results in the same thing by re-using the same connection id, but that connection has different details inside it. You simply create a live connection, give it a generic name, and transport it from dev to prod. In prod you do nothing more than update that connection (not create a new one) to use the production data source, rather than the development one. Then all you need to do is transport ONLY the model, without the connection, each time. Then when the model is in the target, it will use the same connection ‘id’ (as in the source) but because you’d edited it to use a different server it will connect to production data).

      Even then, a live model tends not to have much extra in it that it doesn’t automatically get from the data source. In many cases a live model may not need to be transported, but simply updated in the target, by re-reading its new definition from the data source. You do nothing more than edit the model and press save! You only need to transport a live model if you added something extra to it (like grouping measures for example).

      For acquired models you have another aspect to manage, which is the data, not just the model definition.

      For acquired data models (and data sets) then the data in the model is typically imported via a connection (though there are workflows that import data via an uploaded csv/xls file that then doesn’t use a connection).

      That model can import data from anywhere! Though often you’ll limit the connections to only the ones associated to that environment (i.e., for SAC dev, you’ll probably have just ‘dev’ data connections). There’s nothing stopping you from importing data into your SAC dev model using a connection (still defined in SAC dev) but that is coming from a production data source. You might want to do this (in SAC dev, or SAC test) to really help ensure not only your model but any stories/applications are designed correctly for production data, even though you’re working in SAC dev or SAC test.

      This should help to answer your question about a single SAC service ‘connecting’ to dev and qa. (“Connecting” isn’t really a great word for acquired models, since you run a job to import/export data to/from one or many different data sources of your choice)

      For planning use-cases then its production that holds all those different versions of planning data and so the data itself doesn’t go through separate SAC landscapes dev-test-prod, it all happens in prod. You tend to then only need to worry about the model itself, not the data!

      It’s generally best not to transport the model with its data, but instead without data because the size is problematic. Besides you tend to keep the data separate anyway between environments and once a model is in a new environment you can run jobs to import data for that environment. Simply de-select the option ‘Data’ as shown here for Model 2, to transport a model without its data:

      image%20shows%20button%20to%20de-select%20data%20when%20exporting%20acquired%20data%20model

      If you’ve already exported a model with data, you can also choose not to import the data, but still import the model, at the time of import.

      (There are times, for things like formula/hierarchies, when you do need to transport a model with its data but that’s outside the scope of this article/blog. Nevertheless, it’s on my to-do list for a deep-dive session later. For now, do a simple test of transporting the model without the data and check everything has reached the target. If something is missing you might need to transport with data)

      This means, that in general models are transported without their data.

      Your choice of a ‘QA’ SAC service is most likely driven by the need to validate stories, rather than for models. Models tend to be fairly static in nature, but of course they do change a little overtime and they tend to change a lot at the start of a project. You’ll need that QA environment when validating new stories/applications before transporting them to production. And you might need that QA environment to validate a model too, and to validate what will happen to the production model when you do transport it!

      For live connections, additional environments become more critical simply because a single SAC model (and all its dependent stories/applications) can only use a single connection at any one time and there’s a need to test the data source itself because the stories are so dependent on it. This isn’t quite the same for an acquired model, as you just import the data and it’s the model that you need to validate. And stories built on an acquired model can be changed to use a different acquired model, unlike stories based on a live connection.

      (Though the practice of copying an acquired model and its stories, to then update each and every story to point to that copied acquired model, isn’t something I’d recommend for life-cycle best practices and I would strongly discourage this. There’re too many other things that are dependent on the unique ID of the model (and the stories) remaining static - but it might be a poor workaround for the short-term if you wanted to keep the number of SAC environments to a minimum).

      I would say QA environments are increasing in popularity as our customers maturity with the service improves over time.

      I hope this has helped. I see, separately, you’ve been in touch with your SAP CEE and I’ll propose we have a quick chat to iron out any other points you might have. But thank you for posting here, as I’m sure others will benefit from the discussion.

      All the best, Matthew