I am part of the SAP team who has been introducing SAP NetWeaver Decision Service Management (SAP NetWeaver DSM) to the market since its launch in 2012. I have to admit that while we focused so much on describing the features and capabilities of SAP NetWeaver DSM we missed to provide more practical business examples where this solution can be applied.

Hence, I sat down with my colleagues Wolfgang Schaper and Carsten Ziegler who have a vast experience of real-life SAP NetWeaver DSM use cases from many customer projects they have been involved in. As a result, we documented 10 great SAP NetWeaver DSM use cases (in an anonymized and simplified way).

The goal of this slide deck is really just to give you a sense of the kind of use cases where SAP NetWeaver DSM can potentially be applied. These are of course only a fraction of the potential use cases, but hopefully they serve as an inspiration as you explore where this solution might be able to add value in your organization.

The SAP NetWeaver DSM use cases we documented are the following:

Check it out and please comment to this blog or email us in case you want to know more about a specific use case or in case you would like to share other good SAP NetWeaver DSM use cases.

Carsten Ziegler recently wrote a great blog post entitled How to Kill Custom Code and Z-Tables in which he shared how he was able to use a business rules engine (SAP DSM) to implement a simple business rule that would otherwise have needed many lines of ABAP code and many Z-tables. At first glance, it might seem that the title of my blog post contradicts Carsten’s claim but I encourage you to read on to see why this is not the case.

My blog post title suggests that you can’t simply replace Z-tables in your application with a business rule engine, but isn’t that what Carsten said he did?  Maybe. The key thing to note is that Carsten’s post didn’t just talk about reducing Z-tables but custom code too. This is a very important difference as it proposes that a business rule is not just a bunch of data records in a table but that a business rule also contains its own logic along with the data. I hope to explain this differentiation more clearly later but first let’s pull apart at a simple business rule to see what I mean about rules containing logic.

Dissection of a simple rule

Imagine you had a business rule that says that certain types of purchase requisitions can be auto-approved and let’s assume that every purchase req that doesn’t meet this rule needs to go through the manual approval process. In pseudo-code the business rule part might look something like:

IF purchase req type EQUALS‘Z1’ OR ‘Z2’ OR ...THEN
  Purchase req can be auto-approved
ELSE
  Purchase req cannot be auto-approved
ENDIF

Notice the conditional logic? I’ve highlighted the conditional keywords, just in case.

If you tried to implement this rule using ABAP and a Z-table you might do something like this:

SELECT SINGLE
  FROM Z_PREQ_AUTO _APPROVAL
  WHERE preq_type = current_preq_type.

 

IF sy-subrc = 0.
   Purchase req can be auto-approved
ELSE.
   Purchase req cannot be auto-approved
ENDIF.

Notice that the rule data is contained in the Z-table and the rule logic is wholly contained in ABAP? If you wanted to implement some clever “wild card” functionality within the table data then you would have to suck all the data out of the Z-table but the logic processing would still be in ABAP.

However, if you implemented this same rule in BRFplus you would pass the purchase req type to your BRFplus function and it would return a result saying whether the purchase req can be auto-approved. You could use a value range or decision table to implement the rule but, in effect, the whole of the previous ABAP code snippet (conditional logic plus the purchase req types data) can be replaced by a single call to a BRFPlus function.

So what?

If you’ve used a business rules engine before then you might think that this is all pretty obvious… so why am I labouring the point? It’s because I often encounter developers, particularly those who haven’t had too much experience with business rules, who try to use a business rules engine as a simple datastore rather than as a business rules engine. This behaviour often leads to the developer asking questions like “How do I extract all the data, including the condition columns, from a decision table into my code?”. This type of question suggests that the developer is trying to implement rule logic in their code rather than in the rules engine.

Why is this bad?

I have a couple of reasons:

Firstly, one of the benefits of a business rules repository/engine is that it can be used to abstract your business rules from your code so that they can be maintained independently. Once the definition of the rule is fixed and the interface between your code and the rules engine has been defined (in the BRFplus function) then changes in the implementation of the business rule should not necessarily affect the code and vice versa. You should be able to replace your decision table with a value range or a decision tree without needing to change a single line of code. But if your code assumes that a business rule will be implemented in a certain way inside the rules engine then you’ve broken the abstraction and have tightly coupled your code and rule implementations, cancelling out the benefits of abstraction.

The second, slightly less technical reason is that if you keep putting business rule logic into your code then you’re defeating the whole purpose of having a rules repository. A centralised rules repository allows you to have one place to go to find and analyse all of your business rules. This centralisation of rules can benefit developers, functional consultants and key users alike but if some rules logic is left in code then you will have split your rules into multiple “repositories” and some of those repositories will only be accessible to developers.

So what am I getting at?

To get right to the point, my suggestion to all rule designers and particularly to developers is to avoid treating your rules engine like it’s a technical collection of rules data to be extracted and processed in your code and instead consider that your business rule is there to make a business decision within your program. In other words, your rule contains both business rule data and business rule logic and therefore you shouldn’t just look to kill your Z-tables but kill the custom code that represents the decision too. This might mean a shift in thought for some folks as it means pushing the boundaries of comfort and moving some of the program control from a familiar environment (your code) to a potentially unfamiliar one (your rules engine) but I guarantee that doing this will help you design and build your rules more easily and more simply.

A tip...

One way that I’ve found to test your business rule definition to see whether it’s making a true and complete business decision as opposed to a being just a Z-table replacement is to write out its purpose as a sentence using business terms/phrases. If the purpose of your rule is something like “Get purchase requisition types that can be auto-approved” then you’re probably not using the rules engine to make a complete business decision and that the rest of the rule is implemented elsewhere in code. However, a rule like “Can this purchase requisition be auto-approved?” is asking a question of the rules engine and allowing it to make the decision in any way it sees fit, so is likely to be more complete. Notice that the second rule asks a question rather than making a demand of the rules engine? Generally speaking, I’ve found that questions with yes/no answers (“Is …?”, “Can …?”, “Should …?”) make more useful and more reusable rule definitions than others but, as with anything in life, there are always exceptions to this “rule”. 

1000 words is too long, time to wrap this up quickly

I hope this post has helped to highlight a change in thinking that is required when designing and implementing rules in a rules engine as opposed to custom code + custom table and that you need to consider killing custom code, not just Z-tables. I’d love to hear others’ opinions on this and especially if you have other tips or techniques for good rules design.

Postscript:
A more appropriate title for my blog might have been “A Business Rules Engine Should Not Just Replace Z-Tables…” but it might not have been as thought-provoking. Or attention-grabbing.

What is optimization of rule driven systems about? Just imagine you are a manager who uses the SAP Decision Service Management solution. You speficied and implemented business rules for a business process (think of fraud detection) that scans invoices for anomalies using BRFplus. Everything is OK and the Decision Service produces workitems for a team but now many people are ill or in vacation and now you have to adjust the result set by defining a random sample according some or all of the following criteria: size of the team resp. estimated working time, qualification expected benefit. And this is what this blog is about.

Recently Carsten Ziegler announced that rule evaluation and predictive models are on the roadmap of SAP Decision Service Management. This is a very important feature since after a implementation of business rules those need to be refined and optimized. I’m already looking forward to those features and I hope I’ll be able to them in a Customer Engagement Initiave. But before these tools are available I’ll write down some simple but somewhat effective approaches. If you are using BRFplus for automated checks like anomaly detection (think of fraud) it is possible that  the result of the rule evaluation is that a user has to do a manual control. Usually those controls are performed by a group of experts. If your Decision Service (think of a BRFplus function) detects anomalies that will be processed using workflows it is possible that the number of workitems needs to be reduced to a certain factor depending of the size of organizational unit who has to complete the workflows. In fact the size can change due to illness or vacation.

In the simplest case you know from experience (or using certain tools like Process Observer) that the number of workitems have to be reduced be a certain factor (think of 0.5) then you can choose a special BRFplus expression type that calculates a random value to reduce the number working set by that factor. As a result a random sample will be checked.

But usually the situation is more difficult since the result of a Decision Service is a classification that gives back a classification and sometimes priorization of the tasks, think of following: “high loss”, “medium loss” and “low loss”. In this case a feasible strategy is to restrict to “high loss” and perhaps “medium loss”. Restricting to fix categories is problematic because a possible result is that fraudsters optimize their strategy according to that strategy. So it is feasible to work with random samples of the result of a decision service where the random values are defined in a way that the expected business value is maximized.

This will lead to exactly the examples I discussed in my blog how to perform about linear optimization in ABAP. I got many comments on this blog and some SAP experts found the linear programming approach complex but maybe they will give the model a second look in the context of business rules and process optimization.

Task 1: Reduce the Working Set with constraint on Working Time of the Team

Supposed that you know (from experience and using SELECT statements) that in a certain period a Decision Service creates c₁ workitems of type 1, c₂ workitems if type 2 and so on. Each workitem of type i requires t_i time units . Then the task is to find (x₁, x₂, …, x_n) so that many of them – i.e. the sum of x_i –is maximized with regards to the following constraints:

• each  x_i  <= c_i since you will find a fraction of expected workitems of each type
• x_i>= 0 since this fraction needs to be positive
• the sum of x_i * t_i<= sum of your whole time  of your organization unit

As the result you find fractions, think of percentages, of the workitems of each type that should be checked. So those x_i can be used in a random function that generates a random sample of each workflow type i.

Task 2: Maximize an expected benefit of a estimated Working Set with constraint on Working Time of the Team

If in above model you know that the types of workitems have a different priority (the completion of a workitem of type i will lead to a benefit b_i) then you can use the model to maximize the sum of x_i * b_i.

Summary

By separating business logic from business processes you make processes of SAP Business Suite more transparent and easier to change. But this is only the first step, in SAP Business Suite is an integrated system with amazing capabilities:

• you can perform operational reporting on workflows and built-in processes using process observer
• you have solutions for decision management
• you can perform mathematical optimization

Combing them you can make corporate decision management more flexible and optimize your business processes and their business value. SAP NetWeaver Decision Management has the potential to make that approach much easier. With HANA this will come to a new level since you can analyze your data in real time, analyze your processes using SAP Operational Intelligence and perform complex calculations on HANA. In my opinion the combination of SAP Operational Intelligence and SAP Decision Service Management will lead to a new evolution in SAP Business Suite. I think this will take some time but you can start right now using the optimization capabilities of SAP NetWeaver.

In the first half of 2013 BRFplus reached a milestone with more than 1000 customers. BRFplus and its successor, NetWeaver Decision Service Management, can be considered one of the most used business rule management systems.

Such a large number of customers sometimes creates a lot of pressure to quickly provide fixes or new features. The endless number of usage scenarios lets us continuously face new challenges which contribute to product quality and performance. Recently we have seen some use cases we never dreamt of, such as 20,000,000 objects, decision tables with more than 10,000 rows, etc.

You may question the need for this, and of course there are design issues resulting in those numbers. Nevertheless we took our chances to understand what is going on and optimize our code. Some results are available in form of the four notes which I want to mention in this blog:

1930741: Performance Improvements in the BRFplus Design Time

Looking at a decision table with more than 10,000 rows made my colleague Michael Aakolk wonder whether our persistence layer could be optimized. After some analysis and testing, he found the key to an incredible acceleration of the delta detection mechanism we use when saving objects to the database. In the respective scenario, the runtime for saving the decision table to the database was reduced from several minutes to 1.24 seconds! The improvement grows with the size of a use case and is independent of decision tables. The note is available for the NetWeaver releases 7.02, 7.30, 7.31, and 7.40.

1936926: Runtime improvements for decision tables

We continuously strive for improvement in rule and decision service execution. With this note, the performance of executing decision tables is dramatically reduced. Our internal test with some large decision tables showed an improvement by a factor of almost five (5 seconds versus 1 second). Smaller use cases also benefit from the improvement. Again, this was an achievement by Michael Aakolk. The note is available for the NetWeaver releases 7.31 and 7.40.

1940360: Changes to the Application Server Buffering for BRFplus Meta Data Tables

Some customers have small use cases, some have big ones. In some, the rules keep on changing all the time and in some they are quite stable. All of those influencing factors make it very difficult to define the best DB buffer settings. Therefore, we have decided to provide a report to help define buffer settings for BRFplus tables. Again, thanks go to Michael Aakolk. The note is available for the NetWeaver releases 7.31 and 7.40.

1938697: BRFplus: Remove unnecessary data conversion

We have found situations in which BRFplus was unnecessarily converting data back and forth. Customers cannot identify if and when they run into such a situation. With this note, a more intelligent data reference management is created that avoids unnecessary data conversions. Christian Auth is responsible for the improvement. Callers do not need to change their code. The note is available for the NetWeaver releases 7.31 and 7.40.

Other Notes

Another nice improvement is the support for BW InfoObject and business partner data elements in DDIC binding of element data obejcts. You may check out notes 1921114 (BW Integr.: Consider text and check tables for InfoObjects) and 1930400 (Consider texts for Business Partners). Several customers brought up those two requirements in the past. 

I already blogged in the past that in my opinion SAP’s BRM technology has great potential because it allows to separate business rules form business processes in IT systems and can make ERP systems more transparent and easier to change.

SCN has much to offer in the area of business rules management: we can ask questions in forum, blog about our experience with this technology and SAP does a great job by explaining tutorials as whitepapers and blogs.

If you look at the forum there are sometimes really challenging discussions by practicians, about do's and dont's and best practices – and sometimes I’m surprised because of the challenges people face and about smart solutions.

It is great to have a forum but I think now it’s time to come together to learn from each other. In a conference about decision management we could share success stories and best practices how to use BRFplus/Decision Service Management in the context of SAP Business Suite or how to use it in custom development projects.

My Suggestion is to arrange an SAP user group conference about business rules and decision service management where we can exchange and learn from each other.  In such a conference there should be both technical and non-technical tracks so that business and IT can meet because this is the most important success factor for any business rule management. So the attendees are

• enterprise architects/CTOs  who want to centralized governance and management of business rules
• developers who create rule sets
• business experts who work hand in hand with developers to achieve high quality rule sets
• software architects who want to use BRFplus their solutions.

There are many things we could discuss, let me mention only a few:

• Do's and Dont's for implementation of decision management in enterprises
• best practices for collaboration of business and IT in business rules management projects
• best practices for creating rule sets using BRFplus/DSM
• best practices for reduction of custom code using BRFplus/DSM
• modularization of rule sets
• best practices for documentation and changes of rule sets
• best practices for central government of business rules
• tracing and evaluation of traces of rule set execution
• best practices for testing rule sets
• optimization / fine tuning of rule sets
• best practices for migration of rules sets – think of migration from BRF to BRF+
• architecture of rule based systems
• using DSM on non-ABAP and non-SAP platforms and devices for centralized rule execution
• how to make rule sets “HANA ready”?
• using DSM in combination with HANA
• presentation of Partner-AddOns for SAP NW DSM and best practices for using them
• how to build own AddOns on top of SAP NW DSM

I think ASUG and DSAG offer perfect opportunities for this discussion. What is your opinion?

Many decision services are classifications: a certain case (think of an insurance claim) has to classified by looking at the facts related to this case. The processing of this case consist of a chain of classifications:

• at first we have to find out the claim type – think of an accident for example
• then we have to find out the subtype  – think of an staircase accident
• then we have to find out whether this could be a distinctive feature and its type – think of a potential fraud case for example
• if the result of a classification is a distinctive feature it is likely that automatic processing has to be stopped and we have to find a person in charge who does a manual control, so we have to assign it to a working sets which is a classification, too.

So classifications are, besides calculations, an important type of decision service which occurs quite in automatic processes and especially in data driven IT systems. Therefore business experts define classifications as business rules which can be implemented using BRFplus for example. As blueprint I use ontologies, a tool from knowledge management that describe conceptual models using description logic. I will use an open source tool for creating ontologies and test an inference using an open source reasoner. If you have experience with so called semantic technology you can use them to analyze, structure and document decision service that compute classifications. With some more effort you can check consistency of your models.

Ontologies as Blueprints for Decision Services

The idea is very simple. Ontologies are artifacts which are used to model knowledge domains: concepts as formal definitions and entities that are realizations or materialization of those concepts. Knowledge workers dealing with very complex domains use them to formalize theories – think of classification of diseases, genes etc. with open standards like OWL. Moreover you can compute inferences and check models using open source tools. If you are a familiar with ontologies and tools like Protégé you will able to formalize your domain model, get a deeper understand, visualize it and even can check it. This formal description could be a specification for a BRFplus implementation where a classification could be developed by one or more functions or a few rulesets. So you can use the ontology can be used a blueprint for a BRFplus implementation.

A Simple Example

In the following I will show you a simple example. The domain model consists of:

• incidents – that is the class if objects that have to be classified
• as the result of the specification there are subclasses
• a certain subclass StaircaseAccident is a special incident that has the information (given by the claim holder) that it is indeed an accident where a staircase is involved
• then we define a rule that says that an information about a slippery staircase is sufficient for a staircase accident
• after that we define an incident having information about a slippery staircase and the reasoned will confirm the inference that it is a staircase accident as expected

This is done in a few seconds using Protégé ontology editor. At first I’m creating a concept of an Incident and a special accident where stairs are involved:

The concept is called “class” which means that elements (called individuals) can belong to it. If we want to perform a classification we will test whether a certain element belongs to the class – in our case staircase accident. But to do this we need some logical conditions which are defined in the following.

Therefore I define an information – in our case it is a statement of a claims holder which is the fundament of a classification in our case. We define two special types of information: the first says that we have a general accident on a staircase and the second one say that the staircase was slippery:

We define this information as a so called datatype property that assigns a value (“yes”, “no”, “nor information”) to this incident:

This is used to define a class: a StaircaseAccident is an incident where we have the additional information that the staircase was involved using above define datatype property:

Now we add the following rule to the ontology: if there is the information, that if the staircase was slippery we assume that the information is about a staircase accident:

This could be done using OWL but here I use the feature that an OWL ontology can be enhanced using SWRL rules.

No we define a concrete claim as an incident (member of Incident class) having a information about slippery staircase:

Now I switch on the reasoner (HermiT supports SWRL inferences) in Protégé that computes above defined classification as an inference: the member Claim was by definition an Incident but because of above defined data type property and a SWRL rule a memeber of StaircaseAccident class.

This inference is a very simple example but I blogged about more complicated inference in blogs of my "Enter Semantic" series. Unfortunately they have been scrambled after SCN migration and it is very difficult to restore them because in many examples using XML and URIs. Even if SCN team corrects them it will take much time for proofreading the corrections. But if there people who are interested in my old blogs I could spend some time on checking them.

Reasoners can do a lot more by evaluating logical conditions: they can test whether a class is a proper subclass or superclass of another class, they can calculate whether classes are disjoint and test logical consistency of an ontology. But I will come back to that topic in a future blog. This is in fact a very interesting topics because sometimes domain experts experts disagree in their conclusion and with ontologies you can formalize the differences.

Strengths and Weaknesses of the Approach

You can use ontologies to analyze and document complex domain models and classifications. Those models can contain comments and annotations which is very useful as documentation. Moreover you can define axioms to ensure consistency of your domain models with regards to those axioms. But ontologies have also weaknesses:

• Although you can use data types with ontologies and perform calculations you don't have the strength of expression and tool support of BRFplus. Even generation of BRFplus artifacts from ontologies can be complicated.
• You can use Horn-like clauses(SWRL) in an ontology but I don’t think it can be used to exchange rules between BRM systems.But I will come back to ontologies in later entries of my blog and discuss more and even advanced applications in the area of business rules.
• Features from description logics can be quite confusing if you have no experience with mathematical logic.

But if you have experience with ontologies you have a powerful tool to analyzee, structure and document domain models.

If you want to try out the example above I recommend you to download Protégé and import the attached document as ontology in OWL 2.0 syntax.

In my last weblog I blogged about modeling rulesets using ontologies. In a comment Jann Müller asked me whether it is possible to generate BRFplus rulesets from ontologies. I mentioned some problems and in fact I don’t think that interoperability standards between rule systems are quite useful for practical purposes. But this doesn’t mean that the approach of using ontologies is not useful – you have only to adjust the scope and this is what I’m doing right now: I show equivalence of classification using an ontology to a decision table and then I discuss the strengths and drawbacks of this approach.

Decision tables are probably the most useful expression type of BRFplus and they are available in HANA, too, which is a promising way to push business logic down to HANA.

Decision table are well understood and commonly used in software engineering. Bythe way: I developed my first one long time ago using Vorelle in Cobol. Decision tables are easy to use but if they grow in terms of columns development and maintenance can be difficult especially if the number of rows increases, too. As Carsten Ziegler pointed out BRfplus is ready even for huge decision tables but this doesn’t solve the problem of creating them and this is where ontologies can help.

Recenty new semantic approaches in the area of decision tables have been published, but in this blog entry I’ll try out a basic and straight-forward approach:

• An OWL classification of a single can be translated to set of rows of a decision table. The datatype properties can be translated to rows of a decision table directly.
• If the classification of the ontology consists of disjoint classes then all rows of a decision table can be merged into a big one.
• You can check that OWL classes are disjoint using a reasoner, which is equivalent to ensure that the conditions do not overlap in the corresponding decision table.

This may sound complicated and so I provide a very simple example in the aear of insurance claims.

A Simple Example

Consider the case of a decision service that classifies a claim because of its value that is calculated using an expression or attribute of the content of a BRFplus function. This can be done in BRFplus using a small decision table having one input row (claim holder value) and the result is a classification with high or low value (in general a discrete set of values).

Now we do the same using an ontology. Using an ontology editor like Protégé we define a class (Claim) that represents BRFplus input and an attribute ClaimValue (part of the BRFplus context or calculated using a database view) that is represented in the ontology as datatype property that assigns a decimal value to a claim:

Then we define some subclasses of Claims: the class ClaimHighValue consist of claims having a value between 100 and 999:

Then I define another sublass: the class ClaimLowValue consists of claims with value less than 100:

It is obvious that these conditions can be translated as two rows of a decision table in BRFplus.

For testing purposes I define in the ontology an element test500 as element of Claim class with value 500 and using the a reasoner we can check that both conditions are disjoint (i.e. the class ClaimHighValue is disjoint with ClaimLowValue) and that the test500 element is classified correctly by reasoner als member of class ClaimHighValue:

We can see the same for the second class - again the inferred values are yellow highlighted:

So using data type reasoning we can check that both conditions do not overlap: the classes ClaimLowValue and ClaimHighValue are disjoint. There is only one drawback: the ontology can’t check whether the classification is complete: in fact a class ClaimVeryHighValue for Claims with value >= 1000 is missing. Of course we could define an element with that property and this would be a perfect test case for a missing classification but the reasoner can’t calculate this out of the box.

The reason is very simple: OWL (and, by the way SWRL, too) depends on the Open World Assumption and so there is no negation as failure: unless there is no element that proves that two classes don’t partition the whole set of elements then the reasoner won’t be able to make a statement about this partition. This is no defect and in fact a property of the decision logic used in OWL: OWL relies on the condition that a missing information does not prove the contrary. In other words: in an “open world” the existence of a black swan is possible although we have only seen white swans so far.

Towards Generation of Decision Tables

This was a very simple example but ontologies can consist of more complex conditions. In fact because of the Open World Assumption it is possible that you have to define even more properties (perhaps using features from SWRL) to get a more suitable (but in fact more complex) model. But you will never overcome the "restrictions" of the Open world assumption and in the end you will have to check the completeness of your model using a different algorithm. This could be done using a more sophisticated datatype reasoner or using BRFplus: just generate a decions table from the ontology and use completeness check in BRFplus.

Generating BRFplus artificats from ontologies is not difficult since we can add additional metadata to the ontology that are needed to generate a BRFplus function using the BRFplus API.

Summary

Ontologies provide a framework for classifications that can be used to model decision services especially decision tables. I think this is a nice to know for theoretical purposes but is this useful for practical purposes? Here I’m not sure: in my BRFplus projects I have been able to translate the complete set of rules into a huge decision table so far but in the end I favored a modularization using BRFplus functions or rule sets since often this is easier to understand. But there might be the case that rulesets can be quite large - and they will grow in the HANA context in my opinion – that a more structured approach can be useful for creation and maintenance. And here ontologies can help in my opinion. If have more experience with this approach and have some kind of best practices I will blog about them.

Again I attach the above used ontoloy as XML file to this blog entry - feel free to experiment with it. In fact I have many ideas for research topics (think of a diploma thesis for example): Can we define a description logic that represents decision tables in a better way? Could we generate decision tables (HANA and/or BRFplus) from ontologies, How do we bridge the type gap?

Most people in custom development who work with BRFplus use it for two purposes:

• SAP exposes a decision service and developers implement rule sets in own BRFplus applications and assign it to a function. This can be quite challenging since it would be desirable that decision management fulfills same business strategy in all lines of business of an enterprise and so within different applications within the value chain.
• BRFplus is used to create own decision services in custom applications.

  ISVs but also large custom development projects know both use cases but are facing additional ones:

• ISVs (like SAP) create BRFplus applications that are fundaments of rule sets that are implemented by their customers.
• ISVs implement rule sets of SAP standard applications instead of their customers.
• ISVs extend rule sets of SAP standard applications that are implemented by their customers.
• ISVs create business rule sets for their customers.

  I won’t discuss the last use case which is in fact a perfect use case for SAP NetWeaver Decision Management Service but the first ones are really interesting since they raise questions about best practices.

In the following I will discuss the most common case: an ISV (an SAP Partner) develops application containing a BRFplus function and customers assign their rule sets to that function. So a rule set consists of two parts: a basis shipped by the ISV containing a BRFplus function and a BRFplus application created by a customer. The challenge is that there is no single development landscape and the whole solution is developed on different landscapes but has to fit together. And this can get complicated because of transport of the rule sets, versioning issues of two different rule sets in different landscape and (multi-layered) extensibility.

What kind of artifacts should ISVs ship and which Storage Type is most useful?

Obviously an ISV has to transport ABAP code that calls the BRFplus function, the BRFplus function, data elements that build the signature of the function. Sometimes it is necessary to ship some expressions (think of formulas, own expression types as well as procedure calls). Those artifacts as part of a partner solution can make the development of custom BRFplus application on top of that partner solution easier.

In my opinion it makes sense to choose system storage type for the partner application. The storage type customizing is not that useful: a rule set basis is governed and can be changed only by the ISV. But there is another reason why I prefer system applications: they can be shipped as part of software components built using the AddOn Assembly Kit in contrast to customizing applications  which are neither ready for shipment as BC Sets, moreover transport management of customizing applications is more cumbersome.

Transport from Development into Maintenance Landscapes

In larger custom development project the system landscape is more complex and besides development system there are maintenance systems that are used for shipment of hotfixes and in-advance shipments. Sometime it is necessary to port software from development into those systems. If BRFplus artifacts are part of that application you have no other choice than to transport a BRFplus application or parts of it. The reason is simple since all BRFplus artifacts are identified using GUIDs and a new created data element has two different IDs on two different systems even if the data elements have the same technical name. So if a customer uses the data element (shipped by the ISV from a maintenance system) in own expressions the ISV has to ensure that data element is shipped in a later release from regular development landscape with the same GUID otherwise the rules and expressions defined by the customer using the element with the old GUID will break.

So here is my first question: How do you transport BRFplus applications from maintenance to regular development or vice versa? Do you use the transport system or XML upload and which import parameters do you use? Do you transfer always the whole application of parts of it?

Best Practices for Extensibility

Most SAP Partner applications have to be extensible like applications of SAP Business Suite. Here we can distinguish different case:

• An SAP partner (think of a solution provider) uses an extension technology and switches it on and ships the switched extensions to the customers. The extension can be switched functions/data appends, partner AddOns as well as switchable extensions created by the partner.
• an SAP partner uses an extension technology and switches it on but doesn’t ship the switch settings so the customer has to switch those functions/data model extensions on in his landscape.

  In fact the second case is much more challenges since the changes in the data model require actualizations of BRFplus elements which can’t be done due to storage type. Of course BRFplus is well prepared for this: there are many user exits that allow changes of the system behavior here. But more interesting is the question about best practices:

• How do you create extensible rule sets?
• Are there besides generative techniques of BRFplus other approaches for extensibility? How far can you go with procedure and database calls for example to integrate extensions of the underlying data model?
• What are best practices for rule sets where data models contain multi layered extensions – think of SAP Business Suite – industry solution – partner AddOn – AddOns for special customers – additional extensions by the customer?

  In fact I already had to solve one of these problems and found a simple solution: if there are extensions that are done by customers outside my development landscape I’m using a mix of generative approach and generic techniques to pass the data to a generated function. This is useful when the generated function is completely different from the one I’m using in my development system. But here I have many questions:

• Wouldn’t it be great to have a mechanism for derivation of data types and function signatures in BRFplus?
• Of course derivation introduces additional complexity for the BRFplus framework, the ISV and the customer so are there ways to avoid it? Are there other extension types like database or procedure calls and when should we use them?

Summary

I mentioned only two challenges in larger ABAP development projects resp. development of partner solutions but there are more. BRFplus and its successor DSM are great tools because of their openess and provide many possibilities to deal with those challenges out of the box.

But it would be interesting to learn how other partners solved above mentioned challenges and what kind of best practices they have. And SAP could help two, since development of SAP Business Suite faces some of above mentioned challenges and SAP could tell how they’re working if they are developing rule based solutions that slightly(?) differ in various system landscapes.

There are some situations where we need to restrict the values of a decision table based on the login Business user, Roles and Authorizations to fulfill the business requirement.

Example: A manufacturing company allowed its dealers to maintain their own discounts for specific brands which are specified by the company. Each dealer login into the system and can maintain the discounts % for their allowed brands. Each dealer should only see/change their own allowed brands, they should not see another dealer’s discounts. This requirement can be implemented by using  below decision table has discount % for all different brands based on the Dealer but the challenge is to dynamically filter the values based login dealer.

Usually Application exist class can be considered for any kind of custom logic in the DSM/BRFPlus. The application exist class can be used several enhancements like control access of workbench objects, change/active notifications, F4 help for data objects …etc. However, it can’t be used to apply dynamic filters on a decision table.

We can achieve this functionality by enhancing the standard Decision Table WebDynpro Component.

Decision Table (Figure 1.1)

Step 1 - Identify the Decision Table WD ABAP technical component name & View:

Right click on the decision table and select the Technical Help context option to know the component name. FDT_WD_DECISON_TABLE is the component and ALTERNATE_VIEW is the view of Decision table.

Identify WD Component Name & View (Figure 1.2)

Step 2 – Add ABAP code to filter the Decision Table:

Enhance the Modifyview (with POST-Exit) method of alternate view. Dynamic table filter logic need to be added by using API. Thecurrent Decision Table instance can be obtained by using wd_comp_controller->mo_model_cl->mo_dcsn_table attribute.

Decision Table After Dynamic Filter (Figure 1.3)

Make sure this filter is applying only for the decision table that we wanted to filter. We should check condition by the decision table ID. Then it will not effect to the other Decision Tables.

Let me point out two new articles we recently published. While the first article shows how to use SAP NetWeaver Decision Service Management for enhancing a specific business scenario, the second article provides an example for integrating HANA with SAP NetWeaver Decision Service Management.

Next Generation Collections Management with SAP NetWeaver Decision Service Management

SAP Collections Management permits customer-specific dunning processes with segment-specific collection strategies. For adapting collection strategies to changing market situations, legal requirements, and policies it is essential to empower business domain experts to apply changes easily and with no IT expertise. SAP Collections Management uses SAP NetWeaver Decision Service Management to define rules for determining the next collection step for a business partner in a specific situation.

Integrating HANA with SAP NetWeaver Decision Service Management

In article Dynamic Database View Capability of SAP NetWeaver Decision Service Management we explain how to integrate SAP NetWeaver Decision Service Management with HANA databases. While the article is more of a technical introduction, this paper offers a realistic business scenario using Dynamic Database View in different ways. We will consider an airline promotion and loyalty program to evaluate special offers for customers who are close to an upgrade of their loyalty status.

Last December I blogged about “Decision Management in the Enterprise – It’s Time for a Conference”. Members of the working group “Software Development SAP NetWeaver ABAP and Java” of the German SAP user group (DSAG) decided to launch a “call for conference” that I’m reproducing below. If enough people show interest by answering the call there a “theme day” BRFplus/DSM organized by the DSAG working group.

If you are interested in BRFplus/Decision Service Management and DSAG member please contact the working group. But hurry up, the call for conference ends in ten days. We would appreciate if many BRFplus/DSM practicioners offer talks with focus on a variety topic like best practices, technical aspects, collaboration between business and IT in business rule management. A possible agenda could cover the following:

• overview about BRFplus and DSM
• implementation of BRFplus in SAP Business Suite: learned lessons and critical success factors
• use of BRFplus and DSM in custom development
• rules of thumb for successful use of BRFplus/DSM and follow-up costs
• proven methodologies for implementation of business rules in DSM/BRFplus

Of course I’m looking forward to it and I will offer a talk. My biggest motivation is to meet other practicioners to discuss best practices and to learn from their experiences. And for all of those who can’t participate I will blog about it.

Since it is a DSAG event please apologize that I include the original “call for conference” in german:

BRFplus und dessen Weiterentwicklung Decision Service Management (DSM) sind Frameworks zur Integration von Geschäftsregeln (z.B. Genehmigerfindung, Automatisierung von Entscheidungen, Prozesssteuerung u.v.m.) in SAP Anwendungen. BRFplus und DSM haben sich zum strategischen Geschäftsregelwerk in der SAP Business Suite entwickelt – sowohl für SAP Standardanwendungen als auch für kundenspezifische Entwicklungen. Der Einsatz dieser Lösungen bietet viele Vorteile und Chancen:

• Der Umfang von Customizing und Kundenentwicklung wird reduziert, da sich häufig ändernde Geschäftsregeln vom Anwendungscode getrennt werden.
• Diese Trennung und die Abbildung von Geschäftsregeln einem speziell dafür erstellten Werkzeug machen die Regeln transparenter, kostengünstiger, standardisierter und für den Fachbereich verständlich.
• Durch die gegebene Werkzeugunterstützung können Geschäftsregeln schnell und kostengünstig geändert werden, um mit dem Änderungen im Business Schritt halten zu können.
• Mit DSM lässt sich dies weiter verbessern in Hinblick auf eine zentralisierte Entwicklung, Test, Governance, Deployment und Analyse von Geschäftsregeln im Unternehmen und dies sowohl für SAP- und Non-SAP-Systeme
• Als strategisches Ziel besteht die Chance auf eine homogene Definition und Ausführung von Geschäftsregeln in Systemlandschaften für alle Prozesse der Wertschöpfungskette sowie auch eine Steigerung der Prozessautomatisierung durch die Eliminierung von manuellen Entscheidungen

Weitere Informationen zum Thema BRFplus und DSM finden Sie u.a. hier:

http://scn.sap.com/docs/DOC-29158
http://www.sap.com/pc/tech/business-process-management/software/decision-service-management/index.html
http://www.youtube.com/watch?v=YU3BR7veiZI

Vor dem Hintergrund der gesteigerten Bedeutung von BRFplus und DSM überlegen wir einen Thementag in 2014 durchzuführen – entsprechendes Interesse und Engagement im Arbeitskreis vorausgesetzt. Mit dieser Email bitten wir um ein Feedback, ob Ihrerseits Interesse besteht an einem solchen Thementag teilzunehmen. Gleichzeitig rufen wir die Praktiker unter Ihnen auf, sich mit einem Vortrag an der Agenda zu beteiligen. Dieser Vortrag kann einen eher technischen Fokus besitzen, aber auch ebenso Best Practices aus dem Umfeld mit Organisation und Fachbereich enthalten.

Sollten Sie Interesse an der Teilnahme oder aktiven Mitgestaltung dieses Tages haben, schicken Sie bitte eine kurze Rückmeldung bis spätestens 14.02.2014 an den Arbeitskreis DSAG AK Development.

Ihre Rückmeldung ist keine verbindliche Anmeldung, sondern dient dazu das Interesse an diesem Thema zu ermitteln. Bei ausreichendem Interesse folgenden weitere Informationen zu Agenda und Termin in den kommenden Wochen.

Nachfolgend finden Sie mögliche Agendapunkte zur Gestaltung des Thementages:

• Überblick und Abgrenzung von BRFplus und DSM
• Implementierung von BRFplus in der SAP Business Suite: Lessons Learned und kritische Erfolgsfaktoren.
• Einsatz von BRFplus und DSM im Custom Development.
• Entscheidungshilfen, wann und bei welchen Regeln und Prozessen ein Einsatz von BRFplus/DSM lohnenswert ist und welche Folgekosten damit verbunden sind
• Bewährte, ganzheitliche Methodologien vorstellen, mit denen Geschäftsregeln aus Prozessen in BRFplus/DSM abgebildet werden können

If you don't know how to contact the working group please drop me a line.

In this blog entry I will discuss some advanced aspects of business rule management using BRFplus. It is not likely that those aspects are relevant for most BRFplus projects, but they will occur in complex development scenarios where the software has to pass from one system landscape to another which is the case for larger custom development or the development of partner solutions. If you are using BRFplus in those scenarios this blog entry might be interesting for you. If you are not then this blog might be interesting because you can learn that BRFplus/DSM projects can have a different focus and challenges depending on the kind of use:

• BRFplus implementation can be part the implementation of an SAP solution
• BRFplus implementation can be part of a change of an SAP solution – think of migration from a legacy business rule framework like BRF to BRFplus
• BRFplus can be used in custom development
• ISVs who extend SAP solutions usually have to extend the BRFplus interface of the underlying SAP solution

For all above scenarios all of BRFplus best practices are still valid but new best practices can be needed and I want to discuss some aspects of this. So this blog is definitely not blog for BRFplus beginners but can show you some characteristics of using BRFplus in large scale projects.

Most customers use BRFplus in two development scenarios:

• SAP ships a BRFplus function in SAP Business Suite and rule sets are implemented to control an SAP process. This scenario is very common in implementation of MDG, SAP Banking Solution, GRC and other solutions.
• A customer uses BRFplus in his own custom development, creates an own BRFplus function and own rule sets.

In both cases the customer has complete control about his BRFplus artifacts. He can also use DSM to optimize development and deployment of business rules:

• development in a central system
• deployment of rules in the SAP landscape without transports
• deployment into SAP systems even into lower releases and even hot deployment into production.

In this blog entry I will discuss BRFplus use cases from the point of view of independent software vendors. In fact we do exactly the same as above described: we develop BRFplus applications on top of SAP standard software and our own solutions and implement them. But  we also use BRFplus in different scenarios:

• An ISV develops a function and the customers assign rule sets to this function. Here the ISV is in the same position as SAP as in the scenarios described above since his customers will heir business rules on top of the BRFplus function.
• The SAP Partner extends the data model and functions of SAP standard and the users of the partner solution create their own rule sets on top of SAP Standard and the partner AddOn.

In the following I will discuss some pesky little pitfalls in those scenarios.

Take Care of your Transports when doing modular BRFplus Development!

At first you have to understand that the ISV is in the same position like SAP. So far SAP doesn’t use DSM deployment to ship BRFplus artifacts to SAP customers and so won’t the ISV – unless there is an agreement about a defined governance process, but this is beyond the scope of this blog entry. But nevertheless DSM is part of many solutions like IS-U.

The challenge is that ISVs usually have a complex development landscaped with development as well as maintenance systems for shipping hotfixes. As a consequence an ISV has to ensure the consistency of the artifacts in both landscapes. Please note that the same challenge also occurs in larger custom development projects when there is modular development of BRFplus artifacts: business rules can’t be shipped as a single BRFplus application and consist of at least two parts: an adapter consisting of a BRFplus function, data elements and perhaps additional expressions, and rule sets in a separate application containing the logic of the decision service. Modular BRFplus development is often necessary since the BRFplus function called from the ABAP application is fix but the rule sets can be completely different on different SAP clients of even systems (think of global solutions with different productive systems). For an ISV this is the “normal” situation since the ISV is not the owner of the rule set. Maybe the following picture explains the situation:

Please be aware that this is ne only possible solution pattern. There are also applications in SAP standard where functions and data objects are generated, but shipping the signature of a BRFplus function is much easier to handle.

I recommend to transport the BRFplus adapter as system application because you can ship it in software components built using the AddOn Assembly Kit (AAK). The transport of customizing applications as BC Sets is  not possible (at least at the moment) for various reasons.

Let’s look now at the simplified systems landscape with the systems of an ISV on the left and the systems of the customer on the right:

This situation can be managed quite easily if you understand the data model of BRFplus. A BRFplus artifact is identified by an internal GUID and not its technical name. Parallel development in development and maintenance is system therefore can be futile. Think of the case that a new data element with technical name “foo” is created in the maintenance system, shipped to production and used in a rule set in a system on the right and later created in the development system on the left and shipped in a regular release. In this case both elements have the same technical name but different GUIDs and so every BRFplus artifact that uses the “foo” will not work properly after “foo” is shipped for the second time. So you have to synchronize the development of BRFplus artifacts using transports or XML exchange. Please note that is nothing unusual and holds for many SAP development objects like workflow patters or derivation hierarchies of persistent objects and any many more. The only problem is that SAP invents new development artifacts very rapidly but the communication about maintenance is usually not described in SAP Help Portal and you find the information only in OSS after many customers got into trouble. It would be great if SAP would publish following information for every new development object / resp. strategic framework (like BOPF): naming convention, transport behavior and support by correction workbench. Here BRFplus performs well since naming conventions have been published right from the start and the BRFplus team of SAP has put so many documents on SCN that the behavior of BRFplus can be easily understood. But for other parts of ABAP development I hope that senior documentation architects like Horst Keller read this blog and try to integrate this aspect to the documentation standard. This is very urgent since for custom development SAP landscapes get more complex to support rapid implementation and changes.

Extensibility of System of Rules

ISVs often extend solutions of SAP Business Suite: data models and business objects. Please also note that this is quite common and reflects the principle of the software pyramid that is the common architectural pattern of SAP solutions and their implementations:

As far as I know BRFplus functions are not extensible. If we need additional values in a rule set we use to create them as rule set variables and define their values as expressions. Of course BRFplus is open and you could use extension mechanisms of the workbench to bypass checks and to perform enhancements but I don’t recommend it since it will lead to many problems like every modification does.

When ISVs extend SAP solutions or want to create extensible but also robust solutions by themselves there are three patterns:

• Additional BRFplus expressions can be used to get extensions of the data model into the BRFplus application. The SAP Insurance solution uses quite sophisticated techniques you can use for inspiration, see here and here. Those extensions can be implemented using own expressions types or static method calls which is usually much easier.
• The second option uses BAdIs to take over the control of execution and calling an own BRFplus function instead of the one shipped by SAP. Often those functions are copied from SAP’s functions and extended afterwards. The drawback of this approach is that you have to take care when the SAP data model gets extended and then adjust the extensions and perhaps actualize DDIC binding and of course avoid name clashes.
• Another approach to support extensibility is to use the BRFplus API for generative techniques. This is perhaps the most advanced approach but I found it useful in some cases since it is very flexible.

Summary

With BRFplus SAP created a tool to separate business logic from business applications. This makes SAP Business Suite more transparent and easier to change. With DSM you have a tool for central development of rules which can be “injected” into systems but this doesn’t make transport of BRFplus artifacts obsolete, nor does it solve the challenge that comes with extensibility of SAP Business Suite automatically. The reason is that so far SAP positioned SAP NetWeaver Decision Service Management as product for scenarios in custom development with focus on deployment of rules into productive environment. As explained above this is very useful but doesn’t solve the challenges ISVs face when dealing with extensibility or when the landscape of the ISV is separated from the customer which is usually the case.

For most BRFplus projects above mentioned aspects are not significant but especially ISVs have to develop best practices to use BRFplus/DSM in an optimal way in more advanced scenarios. I mentioned some pitfalls and gave an example how extensibility can be implemented.

I expect that there are more solutions for above mentioned challenges and I would be pleased to discuss this aspect with other practitioners working in larger development projects. The reason is that BRFplus doesn’t have the limitations like other business rule frameworks in the SAP Business Suite and there are many possibilities to create flexible as well as extensible applications.

If you are reading my blog you will have recognized that the business rule framework BRFplus resp. DSM is my favorite topic at the moment. The reason is simple: I consider it as strategic technology, I’m using it successfully and many colleagues of mine ask me about my experience. Luckily I have very smart colleagues and they are asking me good questions. Today a senior developer heard my explanation about BRFplus and had the following remark:

Ok, you may be right that BRFplus is more powerful and flexible than customizing but customizing has one big advantage: I can use it for configuration by exception. Often my processes are standardized and I can ship the configuration (= business rules) as customizing content. Often this is exactly what the customers want but if they would to change it I create a second customizing table which is empty and filled by customers in a customizing process in a kind of “configuration by exception” approach”: the framework reads the customizing entries from both tables and if there’s an entry found in the second table it overrides the first one. So using customizing you can implement a transparent and lean approach to system configuration by implementing only exceptions. So have to the advantages of both approaches: My applications are running out of the box with reasonable "master customizing" that can be overruled in a "configuration ba exception" approach.

This approach is really clever since it gives a solution to a common challenge: developers want to make implementation and maintenance of a customizing-driven application easier by shipping a “master customizing” which is owned by them and also introduce a two-stage approach that allows to overrule the customizing by customers. This approach has some advantages but also some problems, which I will discuss, too. But at first this was my response:

With BRFplus decision tables you can do exactly the same:

• Just create a names decision table that has the same functionality as the customizing table. Use is in a rule set that can be assigned to a function.
• If a customer wants to have a configuration by exception mechanism he can copy the decision table and create another one for his entries as well as a simple rule that performs the two-stage approach described above.
• Of course speed it up be providing a BRFplus customizing project with exactly this functionality but can be used by the customers (or generate it in the fly using the BRFplus API).

 

I consider this approach as superior to the customizing solution:

• At first it will be faster since you need no database access – BRFplus compiles everything to code.
• Decision tables are more powerful than customizing tables since they support expressions and ranges. Moreover there are automatic checks for them as well as excel integration.
• They have a version mechanism that is superior to customizing.
• And last but not least there is a solution to a maintenance problem: If your “master customizing” changes this often requires an information process to people who overruled the “master entries”. With traditional transport mechanism (transport / BC Set) this is complicated, but you could use the BRFplus API to inform about changes or generate documentation about changes.

The following discussion shows a very simple fact: SAP solutions are extensible and configurable. The reduce the implementation effort and speed up the implementation process developers created quite sophisticated solutions in the ABAP world that are comparable to paradigms like configuration by exception which are quite common in the (more agile) Java world. But with BRFplus you can implement exactly the same solutions and even improve them.

In the last time I had many interesting talks with experts for the old BRF tool that learned about BRFplus. It is really interesting that those people have a completely different view how to structure rule systems. Today the challenge is that BRF and BRFplus have a different architecture: I recommend you to read this document if are interested in a comparison. This document is technical but it has serious consequences:

• BRF has no mechanism neither for “hiding” rules as privacy concern nor controlled reuse between applications where BRFplus has both.
• BRF is limited but BRFplus is open and extensible: it has an API, multiple extensions points and even parts of its UI is reusable.
• Understanding BRF rules requires expert knowledge – BRFplus rule systems can be created that they are readable by business experts.
• BRF forces you to create rule systems in a bottom up approach since you have to do many preparations until you can start to build up your rules – f.e. using nested expressions to access the context. As consequence in BRF projects you have to create many artifacts until you can start your work. BRFplus is easier to handle and allows more agile approach to creation of rules.

To fight all weaknesses mentioned above good old BRF has only one answer: use proper naming conventions. The challenge is that naming conventions have to be quite sophisticated to cover all those different aspects and often you have to use develop additional tools to ensure that changes and maintenance can performed in a robust way. Those tools are not necessary when you are using BRFplus or they can be built using the BRFplus API with less effort and costs. But let's get back to BRF: with naming conventions you organize separation of concerns, reuse, documentation and keeping control of a plethora of different artifacts. So it is not really surprising that the first question of a BRF expert is what naming conventions you are using in BRFplus. So when you as BRFplus expert try to explain to differences between BRFplus and BRF to a BRF expert it will lead most likely to the following discussion:

Q: I did some experiments with BRFplus workbench and decision tables. This is really cool and we can use it to create complex rules with a few mouse clicks. But can you tell me about BRFplus naming conventions?

A: BRFplus doesn’t require naming conventions. The reason is that technical identification for an object is completely different in BRFplus compared to BRF, only in the context of functions and rule sets the technical names have to be unique. Please consider that there are completely different scenarios for BRFplus. If you implement rule sets on top of a BRFplus application shipped by SAP it is likely that SAP recommends a certain system as implementation guideline and I recommend to be consistent to this system. But don’t expect that this system is the same in the whole business suite since the underlying SAP applications are different and so is are the corresponding BRFplus applications. But there is nothing to worry about it since BRFplus is more transparent and easy to understand compared to BRF.

Q: But I need naming conventions to structure my application.

A: Yes, but at first I recommend that you try out other features like catalogs to structure your application since they offer advanced features. And don’t forget, unlike BRF objects in BRFplus (like rules and expressions) don’t need to have a name.

Q: No name? Weird, what is that good for?

A: If an object has a name you can reuse it and this can be fatal if it is misused in many parts of the application or even in other applications.

Q: Reuse between applications? This wasn’t possible in BRF. But let’s discuss the misuse first. In fact this is really a problem in BRF since it is hard to test the side effects of a change.

A: Exactly. If an object has “local scope” then don’t give a name to it since sometimes it is better to avoid reuse it and to create a new rule. This is so easy with Drag&Drop and sometimes redundancy is good for you since you can perform changes independently.

Q: But will agree that some expressions and of course rule sets should be reusable – and how do I name them?

A: As I told you, have a look at the SAP implementation guideline, and in custom development you have to make a choice – but renaming objects is very simple. In my opinion the longtext is more important than the technical name.

Q: Why?

A: Since they allow you to create rules that are easily readable like running text.

Q: This is cool. So you recommend me to learn how to create readable rule sets, learn about the new features of BRFplus, about features of reuse between applications, how to prevent reuse in some cases and how to create structured BRFplus applications.

A: Exactly. In BRF you can only use naming conventions for all those requirements and you have new possibilities and to learn about them is mission-criticial.

Q: Hey, the fact that you can use object without names has an interesting consequence: I can create rules and expressions on the fly, isn’t it?

A: Yes, you can create your rule system top-down instead of bottom-up. In BRF this wasn’t possible since you had to do many preparations like using nested expressions to access the context. In BRFplus this is much easier and you can focus on business requirements and even create the rule system with business experts together using the BRFplus workbench.

Q: So using BRFplus is more than just performace gain? It is about creation of more readable, more transparent and easy changeable rule systems?

A: Yes. And DSM has even more advantages.

Q: So tell me, what is DSM about? And let’s discuss the transportation mechanism and workbench tooling.

A: Well, that’s not a topic for the coffee-corner. Let’s meet together in the office tomorrow. We can discuss the system landscape and transport mechanism on the whiteboard.

Q: Great. See you tomorrow!

A: Bye, bye!

It is hard to keep track of all the contributions. Especially in the last few weeks a lot of new blogs and documents have been provided. Time for a new reader’s digest blog about new content! Some of the documents can also be found on the SAP NW DSM community page.

SAP NetWeaver Decision Service Management in SAP CRM for Utilities

SAP NetWeaver Decision Service Management is tightly integrated into SAP CRM for Utilities. Over the next few months, hundreds of Utility customers will benefit from this integration. Learn more about it here.

Budget Transfer Rules with SAP NetWeaver Decision Service Management

Jose Araujo's team created a solution to control budget transfers with flexible business rules. Learn about the details in this presentation.

Next Generation Collections Management with SAP NetWeaver Decision Service Management

SAP Collections Management uses BRFplus during the dunning process to define and apply segment-specific collection strategies. With the integration of SAP NetWeaver Decision Service Management, you can raise the bar even further. This document helps you understand how.

Sample use Cases for Applying SAP NetWeaver Decision Service Management

We are often asked for examples from other customers. Here you go. Thanks to Wolfgang Schaper for taking the time.

Debugging Business Rules with SAP NetWeaver Decision Service Management

A debugger for business analysts is a new capability of SAP NetWeaver Decision Service management. Learn how it works in this document.

DSM/BRFplus Troubleshooting Tools

Srinu Marapureddi of MOURI Tech contributed this nice document explaining the backend tools accessible through transaction code FDT_HELPERS.

Integrating HANA with SAP NetWeaver Decision Service Management

HANA is a topic of growing importance. Wolfgang Schaper provided this document to illustrate how SAP NetWeaver Decision Service Management can benefit from HANA. To illustrate the capabilities, an airline promotion and loyalty program has been built.

Accessing Managed Systems Metadata (ABAP Data Dictionary Objects) in DSM BRFplus Application

In his blogRaghava Vakada of MOURI Tech shows how SAP NetWeaver Decision Service Management helps access data on remote systems, enabling central rules management.

BOBF Expression Type

NW DSM/BRFplus provides integration points that let application developers (SAP but also partners and customers) extend the functionality and enrich the expressiveness for writing business rules. An expression type for reading data using the Business Object Framework BOBF has existed for several years. Recently, it has been improved, especially with respect to code generation. The development team has provided a document describing how to use the expression type. BOBF is used in many SAP applications such as Transportation Management.

Tobias Trapp

Tobias Trapp is a phenomenon! Some month ago he and his organization joined the club of NW DSM/BRFplus users. However, this is not enough for him. Since then Tobias keeps digging deeper and deeper. The result is a list of excellent blogs and comments:

• SAP TechEd Amsterdam:  A Wrap-Up and some Food for Thought for SAP
• The Evolution of BRF to BRFplus: From Naming Conventions to Robust and Transparent Governance
• Some Aspects about Transport and Extension of BRFplus Applications from an ISV's Point of View
• Configuration By Exception: Why BRFplus is Superior to Customizing
• What are your BRFplus Best Practices as an ISV or Architect of a large Custom Development Project?
• Optimization of Rule Driven Systems
• A Small Piece of Research: Modelling Decision Tables Using Ontologies
• Modelling Rulesets Using Ontologies

Basic BRFPlus example to confirm whether an Employee is a Team Lead (Manager)

Juan-Carlos Garcia-Garavito contributed 2 blogs in which he describes how “…BRFplus gives some kind of freedom to us, the non-developers…”! Curious? Then check out his two blog postings to see what he did:

• Basic BRFPlus example to confirm if an Employee is a Team Lead (Manager) or not
• Basic BRFPlus example to confirm if an Employee is a Team Lead (Manager) or not (Part 2)

SITSP 2013: Marcelo Ramos - BRFplus Overview

Marcelo Ramospresented BRFplus as part of SAP INSIDE TRACK SÃO PAULO 2013. This is the first time I've heard of BRFplus in the Portuguese language. Since there are more and more Brazilian customers, this was just a matter of time. Unfortunately, the growing base of experts in Latin America is doing away with opportunities to visit my second home Sapiranga, RS, Brazil. Desculpa mãe.

HR Triggers in Access Control 10.0

An excellent document in the context of GRC has been provided as the appendix to an SAP note. GRC is an application I'm not very familiar with. Therefore, I am very happy for the level of detail provided.

• Understanding HR Triggers in Access Control 10.0
• GRC 10.0 - HR Trigger configuration

How To - Master Data Governance for Material: Send a Mail Notification During the Governance Process

Once again Master Data Governance. Thanky you, Elke Menninger for sharing this how-to document on SDN.

I am glad that many people read my blogs about BRFplus/DSM on SCN and I got many questions about them. And it is even more interesting there are three questions I’m hearing all the time so I decided to answer in this small blog post.

„DSM is of no use because no one is so crazy to do hot deployment into production!“

This sentence always makes me smile and my answer is as follows: if you don’t have the grit to deploy your software into a productive system you should stop working in business and do research & design instead. The truth is very simple: It comes the time that you deploy your application resp. change into production and you can use DSM with or without any downtime.

The major question is whether the installation process of software into a productive system is robust or if there’s the danger of crashing the productive system. SAP experts are highly skilled and know complex procedures to deal with transports. Please be aware that DSM has its advantages:

• rules systems can be deployed as a whole and the process is transparent in the sense of audits and reviews compared to dealing with transports. If a problem occurs just undeploy the latest version which is nearly impossible if you work with transports.
• rule systems are easier to test: just deploy them in a test client or test landscape, so tests can be performed much easier and this is good for the quality of your implementation.

So please don’t tell me that you are afraid of deploying into production. As SAP experts should know about all of state-of-the-art techniques of deployment and transportation. And please note that DSM is not about (recklessly) deployment – it is a mechanism to make those things more robust. Moreover it has many features like debugger, unit test environment, HANA expression types, future activation of rules and so on. I recommend to look at the product and its features.

Technically hot deployment is not a big risk since SAP has many experience with object generation and in many frameworks liek web services and output management for example many objects will be generated on thy in production. With DSM it is easier since you have a good toolset for deployment.

„The WDA frontend of BRFplus is so slow – why can’t you code this in ABAP Dynpro“

When I’m hearing or reading those words I’m feeling despair. At first WDA is not slow and you can develop very fast UIs using it. It is interesting that I hear this argument only by people who know only ABAP Dynpro.

But hearing this in connection with BRFplus and DSM I get sad because its UI is sophisticated as well as highly optimized. I know many other BRM frameworks like condition techniques, HDT, BRF and so on, but BRFplus allows very fast development: I love its drag&drop features, the fast navigation forward into detail views and backwards and the extremely flexible UI. So if you have this impression of BRFplus please ask a BRFplus expert to demonstrate you how efficiently you can work with it. And if you have knowledge about ABAP Dynpro please have a second look at the BRFplus UI and ask yourself how to create it. I think even using commands like IMPORT DYNPRO and GENERATE DYNPRO it will be difficult and perhaps even impossible.

So I recommend to learn how to use the UI and you will start to like it.

“At a hands-on session I did some simple exercises but this is child’s play. Formost we need naming conventions for real world rule systems.“

Yes, we need naming conventions for many reasons, f.e. we have to ensure that in the context of a rule set or functions or data elements have unique names. But please consider the following: in legacy frameworks like BRFplus  we use naming convention for multiple purposes like internal structuring of rule sets, separation of artifacts having different ownership and prevention of reuse for example. Please be aware that those aspects can be realized and controlled(!) using different techniques like modularization of BRFplus application, catalogs and unnamed artifacts. So I recommend that you start to learn the advanced features of BRFplus.

Summary

To be honest I’m not surprised about those misconceptions. When SAP started to explain the table lines shouldn’t be used anymore many people spoke up and declared the end of the world and that it wouldn’t be possible to code efficient ABAP applications in the future. The same happened when ABAP Objects was introduced: many people argued that it is not possible to develop scalable ABAP applications using OO techniques. Today we are laughing about this mind-feebleness but this is not fair: every technology based on new paradigms creates misconceptions and I’m not immune to misunderstanding, too. In fact this is a weakness of my character type since I definitely belong to the judging character types according Myers & Briggs classification. So “getting things done in the most efficient and effective way” is my motto – and this is why I like BRFplus. But one weakness of my character type is that I’m judging too fast so I try to slow down and to examine the facts more carefully instead coming to hasty conclusions.

The concept of named vs. unnamed objects objects seems to be the most confusing one in ABAP programming. Unlike in other programming languages so far ABAP knows only named objects: development objects are defined by the object catalog (TADIR entry). And development objects without representation in the object catalog like local classes have a name, too. But in BRFplus there is the concept of unnamed objects that can only used locally but can’t be reused.

What is the reasons nor naming objects? When you create rule systems bottom up, most objects will have names. At first you create expressions, then you use them in rules and there are used in rule sets. If you create rule systems top-down then it is likely that you create BRFplus artifacts on thy fly and often without names. Since this can lead to a refactoring process sometimes it can be easier when you work with named objects. So the design methodology can propose certain best practices. But are there other aspects to consider?

When BRFplus applications contain many objects they become complex and vulnerable to side effects of changes and this is what my blog is about.

What about naming Rules?

Functions and rule sets are named BRFplus artifacts - but what about rules? Rules can exist either locally (and so unnamed) within a rule set or can be reusable and so have a name. My experience is the following:

• In general rules have little potential for reuse. So there’s no real need to name them. Moreover reuse can be harmful because of unwanted side effects. So if you want to prevent side effects you should avoid naming rules.
• Nevertheless, rules and expressions can be qualified for reuse due to subject-related reasons. In this case they should of course have names. If you want encourage people to build their rule sets bottom up from existing rules and to use rules as templates for modification after copying you should name them to make this process easier.

Should a Rule use only named Content (= Expressions and Rules) internally?

In general I don’t think so although I mentioned an exception in the last sentence: if there are rules and expressions as part of a reuse library they shouldbe used in the rule. But in general I don’t consider this as useful and isolation of rules is the better choice since rules should be save from unwanted changes in other parts of the BRFplus application.

A rule is a very complex object: a rule consists of a condition, a true-action and a false-action. A condition is TODO. A true- resp. false-action is a set of

• BRFplus actions
• assignment of context objects
• assignment of values
• executions of expression
• nested rules
• expression assignments and assignment of results

The complexity of a rule is hidden behind a very sophisticated UI – and the UI hides the ID of the condition, the true- and false-actions.

So my advice is: try to work with unnamed objects. Only if there are already artifacts where reuse makes sense, use them in rules. But using many names object to build up a rule can make a BRFplus application very complex and you have to consider side effects when doing changes. I made the experience that “spaghetti” BRFplus applications are hard to understand and to change.

I made the experience that a little bit redundancy can simplify changes because you can change rules independently.

Simplify your Life!

Reuse and isolation are two contradictory paradigms and both can be used to simplify a BRFplus application. If central objects like expressions and perhaps in rare occasions even rules are named you can reuse. If they provide reasonable calculations having a precise meaning then reuse can lead to simplification. In other cases naming objects could lead to unmotivated reuse and nasty side-effects when changing the BRFplus application. Give unnamed rules a chance!

It is with great pleasure and pride that I am writing a blog again. In this opportunity, I want to share that a new and updated SAP NetWeaver Decision Service Management Roadmap is available for public consumption from our SAP Service Market Place. This roadmap can also be directly accessed via this link: Click Here.

A lot has happened in the last 6 months and very interesting and new capabilities added to this solution. Take a look at the summary snapshot below.

Take a little time and get familiar with the new capabilities in Decision Service Management as you may find exactly what you are looking for.

Look forward to your feedback and further improvement ideas well!

The truth is that many people set rules to keep from making decisions.Mike Krzyzewski, American basketball coach and former player

An expert is someone who has succeeded in making decisions and judgements simpler through knowing what to pay attention to and what to ignore. Edward de Bono

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

5 days ago (and counting) the A/V Receiver in my home entertainment  surround sound system died after almost 10 years of faithful service.  My TV, my Blu-Ray recorder, my gaming console, 5 speakers, 1 subwoofer, and a bass speaker are all connected to my A/V receiver, so all of a sudden I was looking at pictures with no sound.  Calamity!  Or as my sister put it: "oh no, you’ve introduced a single point of failure!"

So for the last 5 days (and counting) I’ve had a decision to make. 

As it happens, I had to travel to my project this week anyway, so a few days living in the hotel has given me some time to do the necessary research, work out what needs to go into this decision, i.e. what rules I want to apply/ignore; and coincidentally put together some reflections on the difference between decisions and rules that I have been discussing with my current customer.  Oh and yes this customer has an ongoing project using SAP NetWeaver DSM and BRFplus, although many of the reflections would apply equally to the use of decisions and rules in BRM.  We currently have totals of well over 1000 rules to implement within a dozen decision services.

What’s the difference between a decision and a decision service?

Most people recognize a decision when they see one.  There’s an issue at hand, factors to be considered, and a choice to be made.  As the Oxford Dictionary puts it:

A conclusion or resolution reached after considerationhttp://www.oxforddictionaries.com/definition/english/decision

We make hundreds of decisions every day: what clothes to wear; what to eat; what to drink; what route to travel to work; what school to send our children to, and so forth.  Businesses make thousands of decisions every day: what price to charge a particular customer for a specific product; where to locate an employee; what work is assigned to each employee; how much we pay our contractors; what suppliers we use; what distribution/carrier companies we use; what servers we build; what software we support; what software we blacklist; what tax we pay and when, and so forth. 

Knowing that there are lots of decisions and choices is fine.  But there are so many decisions without some guidelines and understanding it can be overwhelming to try and work out which decisions we automate and which we don’t.     

Automated decisions are implemented as decision services. A decision service is a self-contained, callable service for the purposes of making decisions.  A decision services encapsulates one or more business rules that must be executed together, in the correct sequence or order, to make that decision.

Each decision service asks a question, for example “How much discount should this customer receive when purchasing an A/V Receiver?”  Each decision has a specified result (i.e. answer), for example “The discount percentage, and maximum discount amount permitted”.   Making the decision may require one or more business rules to be executed, for example:

• What's the credit rating of this customer?
• What other purchases have they made with us in the past?
• Are they buying the A/V Receiver as part of a Home Entertainment Theatre package?
• Is the price of the A/V Receiver high enough to warrant a discount?
• What's the maximum discount our policy people have decided the business can support?

Contrast this with a manual decision. Manual decisions are those made directly by a person.  When someone makes a decision on behalf of the business it is their responsibility to ensure they know, understand and are current (up-to-date) with the business rules that need to be applied, the result that needs to be determined, and that they apply those business rules correctly in making a decision.    Think of a Home Entertainment salesperson who is on staff at your local electrical appliances store, and who can assess and decide what discount to give a particular customer.   Of course, if they get it wrong it’s often too late to fix it once the purchase has been made or the contract has been signed.

At its simplest: Decision services automate decisions that would otherwise need to be made manually. 

Decision services are particular critical where it would be difficult for personnel to keep current (up-to-date) with the information and knowledge of all the rules that need to be applied, such as:

• There are many underlying business rules that need to be executed
• The business rules change over time, or with different circumstances
  • Where different business rules need to be applied as at different dates based on changes in legislation or policy
  • Where the correct rules need to be re-applied retrospectively, e.g. if a complaint or appeal or objection means the decision needs to be re-evaluated, under the rules that were in place at the time the original decision was made
  • Where rates and factors in the rules change frequently, e.g. changes in thresholds, changes in discounts, changes in inflation factors, etc.
  • Where there are specific situations that change which rules need to be applied, e.g. strategic customers, remote geographical locations, even whether the carrier has to deliver a product to a multi-storey apartment without a lift.

Why can’t I just use a web service, method or function module?

But hang on a minute, doesn’t that automated decision service sound awfully like a web service or a method or a function module?  Where’s the boundary line between decision services and other automated (encapsulated, callable, coded) services? It all comes down to understanding the degree of change that needs to be supported.

To put it another way, does what needs to be considered (the underlying business rules) in making the decision change more frequently than the need to make the decision (the calling application or program itself)?

Decision services replace traditional automated services where decisions would otherwise be coded in programming languages that the business cannot read, which require significant IT support to maintain, and are constrained by IT change and transport lifecycles to implement those changes.

Or to put it even more bluntly, does the business need to:

• Be able to change how the decision is made more frequently than IT can support
• Be able to change how the decision is made more rapidly than IT can support
• Be able to confirm that nothing has been lost in translation between business and IT.
  • Regardless of how many test cases you run, sometimes testing is just not enough for business experts or policy makers whose careers and peace-of-mind depends on knowing that the rules are correct, complete and true to their intention.

When we are talking about the speed at which IT can support changes, we are not just talking direct coding costs. Don't forget the perennial IT backlog, conflicting IT projects, budget negotiations between business departments and IT, political power negotiations between senior management , and the many other common barriers to getting changes agreed, designed, built, tested and into production.

Essentially what this boils down to is that decision services are critical where the speed of change must be determined by the business and not IT.

That is, it must be possible for the business to update the rules, or the rates or factors on which they depend without being constrained by IT projects or IT change and transport cycles. For example, if a new rate is determined, it may need to be implemented within minutes, hours or days of the new rate being decided, regardless of whether this fits with the current IT transport schedule.

How to decide whether to turn a decision into a decision service

Not all decisions are necessarily suitable as decision services.  When choosing potential decision services, the first step is to check that the decision is suitable as a decision service. Decision services are used where:

• The decision is repeatable
  • There is a pattern to making the decision that can be followed and automated
• The decision is non-trivial
  • It is sufficiently important that the benefit of making accurate, reliable decisions outweighs the cost of automation
• The business process, or business event, that triggers the decision is clearly identified
  • We know and where the decision needs to be made
• The information needed to make the decision is known
  • We can identify all the data needed to make the decision
• The knowledge of underlying business rules is clear
  • We know the legislation, policy and operational considerations that go into making the decision
• There is a clear sequence or order to applying the business rules
  • We know what rules have to be checked first, and can clearly articulate when we have applied all the rules and can return the result
• The business needs visibility of the decision and the underlying business rules
  • We must be confident that the correct rules are being applied
• The business is accountable for ensuring the underlying business rules, and any rates or factors on which they depend, are correct and current (up-to-date)

Typically the need to make the decision, and the calling applications or other triggers that require the result of the decision, change very rarely; while the underlying business rules, rates, factors, and even the data sources evaluated in making the decision may change frequently.  There may be any number of causes of frequent changes to making the decision; common causes of change include:

• Changes in legislation
• Changes in policy  or operational practice
• Changes in market conditions, e.g. competitive pressures might mean we lower thresholds or raise discounts to give customers a more attractive outcome
• Changes in our business partners or our arrangements with our business partners, e.g.  a change in a carrier’s rates might make it more attractive to ship with them
• Changes in rates and factors that need to be periodically updates, such as inflation factors, discounts,  minimum/maximum thresholds
• Changes due to corrections, e.g. updated formulas

As a second step, many SAP solutions provide for calling of decision services at certain points within a solution. For example, in many SAP solutions these days, such as TRM, CRM Utilities, CRM Social Services, Debt Collection Strategies, etc. , there are often several points where decision services may be called either via configuration – i.e. the rules application that holds or the BRF+ function that represents the decision service can be directly entered in configuration – or via standard business logics slots such as BaDIs – i.e. Business Add-Ins where additional business logic code can be added, including calls to a decision service. Examples include, but are not limited to:

• Decision services for complex validations on data entry forms
• Decision services for determining whether someone is eligible for a benefit, or discount
• Decision services for determining which collection strategies will be used to pay off a debt
• Decision services for determining amounts, such as debt amounts, tax amounts, entitlement amounts

Where SAP provides for the calling of specific decision services, often the signature (i.e. the inputs and result) of the decision service are predefined.   But of course you can create your own decision services too, which is especially useful when you want to call decision services from custom programs or BaDIs for your organization-specific or industry-specific decisions. Once the potential decision service has been identified as available and suitable for use, the decision service needs to be logically decomposed into the underlying business rules, and the information needed to support the decision, i.e. the rates and factors, and data sources which underpin the business rules.

What’s the difference between a decision service and a business rule?

I find the simplest way to think of business rules is as subcomponents of a decision.

Let’s take my A/V Receiver decision as an example.  If I was to turn the choice of A/V Receiver into a decision service, there are a number of business rules I might want to include, such as:

• Is the price of the receiver within my budget?
• Is the receiver in stock from a supplier I trust?
• Will the receiver support my current and desired future surround sound requirements? Because I’m thinking of moving from a 5.1 channel to a 7.2 channel system later this year.
• Did the receiver rate in the top 5 recommended receivers at review sites I trust?
• Will the receiver fit in my current entertainment unit cabinet?

Isn’t a business rule just a decision service in itself?Certainly sometimes it is. But here’s the thing - most of the time I don’t care whether any of the shelves in my entertainment unit are sufficiently high, wide and deep enough to hold a different A/V receiver, and although I could have measured the shelves at any time, there was no value and no reason in doing so.

So this is where I take issue with those who suggest that a business rules engine should be some sort of massive re-usable bottom-up designed repository of all the possible business rules in an organization, which are then assigned to the relevant decision.  Where’s the cost benefit in documenting a whole heap of rules that you may never map to an automated decision service? It’s usually better or at least far more pragmatic to work top-down, i.e.

• What decisions do I need to make?
• How do those decisions map to decision services?
• What rules underpin those specific decision services?

What about reusability?  Sure, some rules are re-usable - checking if the price of a product falls within my budget for starters.  But here’s the thing – when you are adding that next decision service, it’s a lot easier for the business to identify rules they want to re-use, and copy them to a re-usable version, if they can see all the rules in the first place.  Actually what we find in practice is that underlying rules are often less re-usable than you might think, it’s more often the data sources or the rates and factors that you want to re-use.

What isn’t a business rule?

I don’t have to specify that a date is a valid date, any more than I have to specify that my entertainment unit has height and depth and width.  It’s an entertainment unit – height, depth, and width come with the furniture – literally.  It turns out that with SAP solutions you tend to get quite a lot of built-in rules that come with the furniture: data typing rules, data validation rules, standard configuration, process flows, business objects, etc.  The beauty of DSM/BRFplus for is that those furniture rules can be treated as instant data sources whenever I want to call on them.

Decision services, business rules and effort estimation

There's another useful aspect for project effort estimation when you consider decision services vs. business rules.  Speaking as someone on a very large project involving well over 1000 rules to build, it's a lot easier, and far more effective to break effort estimation by our into our dozen decision services rather than our many many many business rules.  Plus it makes a lot more sense from a testing perspective, because while I *can* individually test most of those rules, in practice it's shows more progress to my business people if I can show a whole decision is working, and show it being called by the relevant calling application.  Granted some of our decisions hold 20 rules, and one has more than 400, but then from a testing perspective we can break our testing into checking the decision service makes the correct decision for each scenario, without the business person who's testing it having to worry about how many rules this particular execution of the decision requires.

Oh and don't forget to include your Rules Catalogs, i.e. the business view of the rules where they will adapt, simulate, and deploy future changes, a part of your effort estimation.

Final thoughts

Would I put my A/V receiver decision in DSM/BRFplus? Well not for myself, I’m seriously hoping this is not a repeatable decision, but if I was a company selling home entertainment theatre equipment … then it might well be worth automating decisions about best or recommended A/V receivers based on typical rules my customers apply.

In the meantime I’ve made my decision, ordered my A/V receiver, and I’m off to pick up my new A/V receiver in the morning.   Wish me luck with connecting all those cables…!

Success with business rules products like BRFplus or NetWeaver Decision Service Management relies on a focus on decisions - on Decision Management. To introduce this topic I will be giving a webinar on Getting started with Decision Management with Dr. Juergen Pitschke, Founder and Managing Director at BCS on April 1, 2014 at 16:00 CET (10:00 AM EST).

Organizations like yours are improving results, streamlining operations and personalizing customer transactions by automating the repeatable decisions central to their operations. These organizations are using the time-tested and proven decision management approach to effectively apply business rule, predictive analytic and optimization technology to these operational decisions as an agile service in their enterprise architecture framework. Decision Management intersects with and complements business process, case management and technology -based approaches.

In this webinar you will learn:

• Why defining decisions improves enterprise architecture transparency and agility.
• Why explicitly modeling decisions complements and enhances business process management/adaptive case management.
• How to get started with decision management and the new beta Decision Model and Notation (DMN) standard.

Register here.