Understanding DSM – System Setup practices

[former_member232496]

Why deployment is better than CTS

SAP Change and Transport management (CTS) is a powerful tool for collecting code and configuration changes built in the development system (DEV) and applying them to quality assurance systems (QAS) and subsequently to production systems (PRD). Powerful and structured but not speedy – even at the most organized of customers, transporting from DEV to PRD usually takes days. It is not uncommon for it to take weeks and sometimes months from first creation in the DEV system to arriving in PRD.  Even emergency changes are often only same day or overnight transports.

These delays common to CTS transports may be tolerable for complex code changes, but are not acceptable for changes to business rules.

In other words, in our fast paced world, when it comes to changing business rules, CTS reaches its limits quickly and a new approach to apply changes throughout the system landscape is needed - an approach that is:

• Fast – lets the business apply changes rapidly


• Simple – avoids reliance on IT people with special skills and training


• Safe – prevents premature changes; avoids incompatible changes; easy to rollback changes

SAP Decision Service Management (DSM) introduces the fast, safe and simple deployment concept to SAP applications that in the past usually had no alternative than relying on complex CTS processes.

Why CTS is not enough

Functional experts want to update any kind of decision making logic, in the productive systems as the need arises, without starting a complex change process involving other teams and incurring costs. And even more importantly, they want the updates to be applied in an instant.

Any waiting time can be a burden for the organization. Think of tweaking product discounting to counter a promotional push by a competitor. Think of corrupt master data that makes it’s way into the system while you are waiting for CTS transport requests even though you know what checks to apply. Or urgent changes in tax calculations that could be applied immediately.  Who wants to wait when you can have it instantly? DSM allows exactly that!

What’s more deployment is simple enough for business people to push changes without relying on IT assistance. Triggering a deployment is a simple 4 step process:

1. Select the decision service(s) to be deployed


2. Select the target system


3. Enter a comment describing the reason for the deployment


4. And finally confirm the deployment

Best of all DSM eliminates the complexity of CTS for business rule changes. No complex transport requests, no need to understand workbench vs. customizing, no need to merge requests to ensure dependent changes are applied together, no complex locking of objects when things go wrong.

Deployment is simple and fast.

Of course simple and fast is not enough.  Deployment also has to be safe – particularly when it comes to making changes in production systems. So without compromising the simplicity and with minimal impact on speed, DSM deployment also provides sufficient protections to ensure good governance and prevent accidents.

• Authorizations to control who can deploy what to which system


• Deployment simulation to ensure any dependencies are in place before deployment commences


• Time travel versioning so future changes can be applied and tested in advance


• Test case APIs to automate regression testing


• Deployment workflows to integrate automated testing, reviews and approvals for production systems without overburdening development and quality assurance systems


• Instant revocation of deployments to instantly returns rules to the previous deployed version in the event of a problem or a change of heart

CTS remains the default approach for complex interrelated code, user interface and database changes, where IT skills are essential to the build itself.  But for business rules and decision logic, DSM deployment is faster, simpler, safer… and that’s better!

 

Understanding DSM – Seeking Best Practice System Setup

SAP has seen an increase in the adoption of the DSM approach. Consequently, customers ask SAP for best practice guides.

During the first 2 years we have seen many different architecture models involving DSM. Some customers run one DSM instance mostly for smaller use cases involving multiple DEV, QAS and PRD systems. Others, mirror the landscape of the business applications resulting in a DSM system for DEV, one for QAS and one for PRD. And yet others have struck a balance between centralization vs decentralization.

What we have realized is that deployment best practice depends to some extent on the business need and the type of business.

For some businesses, particularly commercial businesses, speed is paramount, and being able to respond rapidly to market conditions is crucial.  A consumer products company needs to adjust discounting to head off an unexpected promotion by a competitor.  A utility company needs to rapidly adjust its dunning strategy to minimize negative public sentiment and government scrutiny after an embarrassing news cycle where a customer on life-support had their electricity shut off due to a missed payment.

For other businesses, particularly public sector organizations, flexibility, adaptably and business review of changes is critical, but the actual introduction of any changes needs to be very carefully controlled.  Think of changes in legislation that may or may not get through parliamentary processes, where the business rules are complex enough to take weeks or months to prepare, but where the actual date of implementing changes depends on a democratic vote which may or may not get passed, or may suffer a sudden delay when an amendment is proposed.

 

Where Speed is Paramount – the Centralized Deployment Landscape

Competitive commercial businesses often need to make changes within hours, sometimes within minutes, to respond to urgent changes in the market – whether to counter a surprise promotion by a competitor, respond to a natural disaster, or to take advantage of a twitter trend campaign.

In this scenario, a single central DSM offers the fastest approach.  With one central DSM system being used to deploy business rules to all systems in the landscape.  The systems may be for multiple business applications, e.g. one DEV/QAS/PRD landscape for traditional ERP applications, one for HANA application, another DEV/QAS/PRD landscape for CRM applications, another for SRM, and another for TRM and so forth.  Code changes are unaffected and continue to be transported via CTS.

 



There are a few critical considerations for effective governance of rapid deployments;

Firstly, authorization to deploy to production must be carefully controlled, e.g. by security profiles or by deployment workflow approvals.  This is essential to avoid premature deployments to production, particularly where more than one rule may need to be updated at the same time.

Secondly, deployment simulation and testing of rules in each environment is still essential and must not be skipped.  The DSM rule testing option Remote System (Current Version) is very handy for testing rule changes against production data without impacting the current version of the rules in the production system.

Deploying even at a slightly future date/time can be a good idea to give a grace period for final testing with enough time to revoke the changes if need be. This can simply be set in DSM at the time of deployment.

Finally it is essential that someone has the ability to revoke a rule deployment to production as a fail-safe.

 

Where Controlled Rule Introduction is Paramount – the Balanced Deployment Landscape

Businesses that require carefully controlled introduction of rules into Production, often have extremely complex rules, and so they still value the freedom of rapid rule changes between DEV and QAS to support fast iterations of trial and error testing.

In this situation, an approach with one DSM system for development and testing (DSM-DEV) and one DSM system for productive use (DSM-PRD) is usually the best compromise between speed, flexibility and control.

• DSM-DEV is used for major changes in the structure of the business rules, such as new releases. DSM-DEV can be used for multiple business applications and systems. There should be no technical justification to set-up multiple DSM-DEV systems. DSM is built to serve many applications in various systems.


• DSM-PRD is used to work with productive systems. Again, there is no need for multiple DSM-PRD systems. One DSM-PRD is the central rules repository for all systems. The DSM-PRD can also be used to deploy to the QAS first, if testing is required.

You can establish a channel to exchange objects between the DSM-DEV and DSM-PRD systems. XML exchange, Transport of Copies or the service import capability in DSM can be used.

TIP: The Service Import capability is preferred as it allows the rules to be imported with an assigned managed system to correctly baseline any metadata references (Understanding DSM - That's so meta! and the Assigned to Managed System feature). The service import feature allows you to connect to any system, provided an RFC connection is available, inspect the deployed services and rules and finally import them.

Customers should not connect their DSM-DEV to a target PRD business application system, e.g. to avoid accidental deployments into the wrong target system.

In this scenario, the better and safer approach is to write any object you want to exchange between DSM-DEV and DSM-PRD to a transport of copies (TOC). Note: You can put single objects on the request. There is no need to take the complete application or service. With a TOC you could very conveniently take a changed decision table from DSM-PRD into DSM-DEV. Alternatively you could prepare a new release by a TOC from DSM-DEV to DSM-PRD. In DSM-PRD you can even make some final adjustments and then trigger a new productive deployment into the appropriate PRD system.

 

Practical considerations - utilizing separate clients as a DSM “system”

As DSM has very low hardware requirements, it does not necessarily require a standalone system. An existing System can provide clients for DSM.

However, in a multi-client setup (where DSM is part of a rule target system), the decision services must be of storage type customizing rather than system. The reason for this is, that if any decision services are of type system, the active version could be accidentally used during execution instead of the deployed version. This would happen if the wrong function call is implemented. To avoid these accidents, if system objects are used, a standalone DSM system would be preferable.

If a multi-client setup is an option, the following scenarios can be considered:

• Single DSM client on a target system


• DSM-DEV and DSM-PRD clients on one self-sufficient system


• DSM-DEV and DSM-PRD clients on a target system

 

Single DSM client on a target system

This architecture can be an alternative to the Centralized Deployment Landscape where a separate System is used as the DSM system. Here in a quality System one client needs to be provisioned as the DSM client; provided the DSM software requirements are met and the applications on the system are of storage type customizing. The reason why the QAS system is often selected as the DSM system is due to practicality; not many Developers get access to a productive system but do to the QAS, at the same time business users are often testing on the QAS and have users there already.

Advantages

• Cost efficient (due to reuse of systems)


• Single point of rule development


• No Rule exchange via Transport of Copies required (as in multiple DSM solution)

Disadvantages

• Technical rule development and productive rule maintenance cannot happen concurrently


• DSM is not self-sufficient, but bound to the maintenance cycle of another system


• No applications of storage type system, only customizing without side effects possible

DSM-DEV and DSM-PRD clients on a target system

Two emulate the multi-DSM landscape without the need of a separate system the following setup can be considered:

In productive/quality System, provision clients as DSM clients, provided the DSM software requirements are met and the applications on the system are of storage type customizing.



Advantages

• Cost efficient (due to reuse of systems)


• Technical rule development and productive maintenance can happen concurrently

Disadvantages

• No applications of storage type system, only customizing without side effects possible


• DSM is not self-sufficient, but bound to the maintenance cycle of another system


• To get technical modifications into the DSM-PRD, they need to be moved either via a ToC, the XML export/import or the service import


• Unless there is a connection from DSM-PRD to a QAS system, the changes in productive maintenance cannot be tested without first importing these changes into the DSM-DEV

Note - Solution Manager

• It is possible to use the Solution Manager to get rule changes from DSM-DEV to DSM-PRD, instead of ToC, XML export/import or service import


• To satisfy the usual process which consists of a 2 layer transport (meaning there is an intermediate transport before being transported to PRD) there could be a transport from DSM-DEV(client X) to DSM-DEV(client Y)


• The alternative to the above customizing transport would be another DSM QAS system which would serve the same purpose.

 

DSM-DEV and DSM-PRD clients on one self-sufficient system

A standalone DSM system is used for both, DSM-DEV and DSM-PRD. Two clients in the system are used to separate the DEV and PRD DSM. Here the same constriction regarding storage type apply as on the above examples.

 



Pro

• Technical rule development and productive maintenance can happen concurrently


• self-sufficient system


• more cost effective than two separate systems, good for smaller use cases

Con

• No applications of storage type system, only customizing without side effects possible


• To get technical modifications into the DSM-PRD, they need to be either transported via a ToC, the XML import or the service import


• Unless there is a connection from DSM-PRD to a QAS system, the changes in productive maintenance cannot be tested without first importing these changes into the DSM-DEV


• Extra cost of another separate system

 

Recommended for customers with many rules for various applications and systems, however none of storage type system.

 

Practical considerations – useful DSM and BRFplus Tools

Authorization management and deployment workflow as alternatives to a multi-DSM setup

Authorization Management:

If the most relevant reason for considering a multi-DSM setup is to avoid accidentally deploying rules into production rather than a DEV/ QA System, then having a well-defined user role-model could be an alternative. The main goal should be to control which users can deploy what to which systems. A detailed description can be found on https://help.sap.com/nwdsm .

The DSM authorization objects can regulate just that by defining:

1. which managed systems can be viewed in DSM


2. who can create new managed systems and edit existing managed systems


3. who can test deploy or deploy to a managed system


4. who can delete a previous deployment to a managed system

Deployment Workflow:

Often, when deploying decision services to managed systems, the deployment should not be released immediately, but only after some tests, approvals, or checks have been processed.

This deployment process starts when “Start Deployment Process” is chosen rather than “Deploy”. Instead of an immediate deployment to the managed system, the workflow contains steps to approve or deny the deployment. More detailed explanations as well as an example can be found on https://archive.sap.com/documents/docs/DOC-53371.

 

BRFplus Tools – how to transport only specific Objects/Applications between systems

A very useful tool for transporting BRFplus objects can be found in the Transaction FDT_HELPERS. In particular the Report FDT_TRANS where a single BRFplus object or an entire BRFplus application can be written into a specific transport request.


This tool is indispensable in a multi-DSM architecture where transports between the DSM-DEV and DSM-PRD are needed.

 

Conclusion

The advantages of DSM vs. CTS are easy to see. The simple, fast and safe way of DSM to change business rules cannot be beaten.

However, one solution/recommendation that fits all is not available due to the many factors that impact the DSM setup:

• Your need for concurrent maintenance and development on the rule repository
  
  
  
  • DSM-DEV and DSM-PRD are recommended
  
  
  
  


• The types of your rules - customizing vs. system
  
  
  
  • You might need a separate DSM system
  
  
  
  


• The complexity and size of your system landscape
  
  
  
  • for complex landscapes, a more detached DSM system/s might be better
  
  
  
  


• The need for independence of maintenance cycles of other systems
  
  
  
  • a standalone DSM system would solve this
  
  
  
  


• The governance processes that need to be observed in your organization
  
  
  
  • DSM-DEV and DSM-PRD might be needed
  
  
  
  

 

Please feel free to share your experience with different setups and scenarios and how it solved your specific business need.