The topic of the C4C tenant strategy has been coming to the forefront in many customer discussions.
There is an excellent blog already covering this topic, but wanted to take the time to provide the consulting perspective, based on the numerous inquiries we have received from customers and partners.
It also look forward to some more recent feedback and experiences from the field.
While our roots with C4C are rooted in the "keep it simple" approach, the need to integrate into existing system landscapes has made it necessary to expand our approach to accommodate those landscapes. From a subscription perspective this is an important consideration since each tenant added to the integrated landscape requires a subscription to a test tenant.
From an implementation perspective the tenant strategy can be a key effort driver, especially in lean projects, where the setup of new tenants can have a significant impact on the overall effort. The tenant strategy should ideally be covered in the sales cycle to make sure the order form has the correct number of tenants and that the implementation partner includes the appropriate effort to setup, integrate and maintain those tenants.
1 tenant strategy
From a platform perspective a single tenant strategy was originally part of the vision. A customer could configure the system and go-live. While this seemed like a good idea from a competitive perspective, SAP isolates the productive tenants in exclusive production environments. It quickly became evident that customers willing to take this approach were very few and usually very small. Most customers required an established test environment. Once a customer decided they needed a test tenant it required added effort and human intervention to move the tenants to a test environment.
We have since eliminated this option. SAP currently provides an initial test tenant with every subscription. If this initial test tenant is used as the sandbox, it is not to be placed in the permanent integrated landscape. This test tenant or sandbox can be used to establish the baseline configuration and perform testing. Once testing is completed and signed off, the production tenant can be requested in the Service Control work center using the Test tenant solution profile as the source. The production tenant should only be requested once you have completed testing to minimize the amount of dual maintenance required in each tenant.
Once live, the test tenant/sandbox can be decommissioned if the desired end state is a single Production tenant. A new test tenant can be requested as part of a change project, to support ongoing configuration changes.
This approach works well with standalone implementations. However, if integration and/or customization with the SDK is part of the project scope, at least one permanent test tenant needs to be on the order form, to form part of the permanent integrated landscape.
2 tenant strategy
The 2 tenant strategy links a C4C Test tenant to the OnPrem QA environment. All testing and training is performed in this tenant.
Since there is only 1 test environment, you need to be aware that the initial data load will be performed in this tenant. While you want to give your key users access to the system as soon as you can, you also need to make sure you are not creating any issues that will affect the data load through the interfaces.
Example: if you are planning to integrate the organizational structure, you may consider creating a 'dummy' org structure for the initial setup, so that the full org structure load is properly tested and you are not creating any conflicts. For master data and transactional data we generally recommend using separate internal (automatically internally assigned) number ranges in C4C to minimize number range conflicts. C4C handles the mapping of the external ID, in the ID mapping tables automatically.
The 2 tenant strategy assumes that the integration is fairly standard and that you are not expecting to do any interface testing in the OnPrem DEV environment. Changes in DEV need to be transported to QA before they can be tested, so in implementations with extensive custom work in the OnPrem environment, the 2 tenant strategy hits its limitations since it may require a lot of iterative transports to perform testing in QA. In these cases it becomes necessary to integrate a C4C tenant to the OnPrem DEV system.
The Test tenant can be used for minor SDK development.
In some cases customer have connected their Test tenant to the DEV OnPrem system, customers usually prefer to performing user acceptance testing (UAT) in their OnPrem QA system.
While it's tempting to want to attach the C4C test tenant to the OnPrem DEV system and subsequently disconnect it and connect it to the QA system, we strongly recommend against this approach. There are various issues with this approach, most notably the issues that the mapping IDs are mismatched for all master and transactional data. In addition most of the integration work has to be reconfigured, which argues towards just integrating separate tenants anyway.
3 tenant strategy
This is becoming the more common C4C tenant strategy based on our customer's OnPrem landscape, mirroring the DEV, QA, PROD concepts we are so familiar with in the OnPrem world. The DEV tenant is used primarily by consultants and key users, whereas the QA tenant is used for user acceptance testing and training. It allows you to perform unit testing of the integration in a DEV tenant, and allows you to perform a 'clean' initial data load in the QA environment. Wherever possible, the QA tenant should be populated with the complete data set from the OnPrem system, similar to the planned production tenant cutover plan. It does require more effort, since each tenant requires setup tasks, which include the org structure, foundation data, field extensions and reports.
It also requires more ongoing maintenance post golive, since the changes need to be propagated manually through the tenant landscape, which calls for strong configuration change control processes.
The benefits of this approach mainly relate to the fact that the process of building out and populating the QA tenant acts as a dress rehearsal for the production cutover, giving everyone a higher level of confidence in the process steps and time needed to perform the productive cutover. It also provides a cleaner environment for integration testing and training, with less junk data. DEV tenants may also have stranded or in process solution design attempts such as extraneous field extensions, which should be cleaned up in the QA tenant, so that testing and training activities are isolated from ongoing solution design activities.
3 tenant strategy + SDK
Generally for major SDK work we recommend an isolated tenant for the development to avoid destabilizing the DEV tenant. It is also recommended that when requesting this SDK tenant it be provisioned in a separate system. This can be achieved by logging a ticket for the new tenant request and specifying the need for the tenant to be provisioned in a separate system.
1+N strategy
Many customer employ a 1 + N strategy in their OnPrem landscape. This approach provides multiple paths to production. Example: They have a sustaining path used for support and patches, and an 'project' path used for major upgrades or implementation projects. Based on our experience we try to keep it simple and not to mirror every OnPrem system. Generally we would recommend connecting to one of the paths to production, such as the 'project' path.
This blog does not cover every possible tenant landscape option, but should cover the most common ones. Depending on the customer you will encounter more complex environments, but I think many of the justifications described above will help guide you to an appropriate landscape strategy.
Refreshing landscapes
Customers often want to see more recent data from the production tenant in their test tenants and want to refresh their tenants. SAP does not provide the option to 'refresh' a C4C tenant, so you basically have to decommission and request a new tenant as a copy of PROD. This includes all the data and communication arrangements and ID mapping. While the communication arrangements can be reconfigured to connect to the OnPrem QA system, the ID mapping of the master and transaction data will most likely not match QA unless the OnPrem environment is 'refreshed' at the same time. We would recommend that any requests to refresh the data be a coordinated project across the landscape and that the frequency of these requests be limited. This is ultimately a question of cost and effort to coordinate and execute a complete landscape refresh. Many customers do not refresh their landscapes regularly.
- SAP Managed Tags:
3 Comments
