Category: Guest Post

Guest Post : Time Based Reasoning Worked Example

Guest Post : Time Based Reasoning Worked Example

It’s with great pleasure that I introduce you to Evert Fernandes, CTO at Magia Consulting UK Ltd. A self-confessed OPA geek, Evert has stepped up and written this article about Time Based Reasoning (and hopefully some more ) for the OPA Hub Website. Thank you Evert and…over to you!

Time Based Reasoning (TBR) – also known as Temporal Reasoning – is one of those subjects that new OPA developers tend to struggle with. It’s a more advanced subject that – once mastered – can provide huge benefits to your project.

In this article I will try to explain what TBR is, present a use case and provide a walk-through on turning the use case into rules.

So, what exactly is Time Based Reasoning?

Time Based Reasoning allows the rule developer to create rules that include attributes which contain values that are subject to change over time.

It is able to conclude rules like:

  • What’s the amount of daily benefit the citizen was entitled to on June 26th, 2017?

Time Based Reasoning Worked Example

Let’s have a look at the following use case:

“How much benefit is the citizen entitled to between 01-01-2017 and 31-12-2017 (inclusive)”

The following rules apply:

  • If the person is not married, the daily allowance is $10. If the person is married the allowance is $14
  • The person can only claim benefit if the daily income is less than $200.

For the sake of simplicity, we will only look at a binary relationship status, married and single. The real world is more nuanced and complicated, but feel free to expand on this example. 😉

As you can see, the mix of variables already creates quite a complex and fluid situation, especially considering that any of the variables are subject to change over the period in question (01/01/2017 – 31-12-2017).

So, let’s start by looking at the first element and create some rules:

OPA 12 - Time Based Reasoning Worked Example 1

There are a number of things happening in these rules, let’s take a closer look.

First of all, a rule table has been created (ALT + Z) to determine the daily allowance amount based on marriage status, $14 when married and $10 when single. The single status is implied by the ‘otherwise’ conclusion, i.e. the person is single because the person is not married.

The second rule calculates the total allowance over the time period, starting on January 1st 2017 and ending on January 1st 2018. The reason the end date is January 1st 2018 and not December 31st 2017 is because the end date is not included, so we simply add a day.

The function is called IntervalDailySum and takes in three parameters:

  • The start date (inclusive) of the period over which the calculation needs to take place;
  • the end date (exclusive) of the period over which the calculation needs to take place;
  • the rule text of the attribute over which the total daily allowance over the period needs to be calculated.

In this example, we provide hard coded values for the start and end dates. In the real world, the start and end dates will most likely come from date attributes.

We now need to test the rules. In order to do this, we start the OPM debugger and head to the data tab:

OPA 12 - Time Based Reasoning Worked Example

As you can see, not a lot is happening here. Let’s give the citizen a marital status by setting the value of ‘The citizen is married’ to ‘True’.

OPA 12 - Time Based Reasoning Worked Example

So far, so good. We have a marital status and OPA is able to work out the total allowance (365 days x $14 = $5110).

Let’s now assume that the person was single at the start of 2017, got married on March 1st 2017 and was single again on September 1st 2017 (don’t worry, they’re still friends! 😉).

How do we enter that data? OPA provides a handy feature called ‘Change Points’ to handle this.

Let’s reset the value for the citizen marital status:

OPA 12 - Time Based Reasoning Worked Example

Click on ‘Change Points’:

OPA 12 - Time Based Reasoning Worked Example

What this allows us to do is to take the attribute and set different values for different slices of time.

You can use ‘Add’ to add a new change point. Once a new point is created, you can set the date and value at that point in time.

Let’s add two change points. One on March 1st 2017 with a value of True and the other on September 1st 2017 with a value of False. Use the Date picker below the change point list to pick the dates.

OPA 12 - Time Based Reasoning Worked Example

The eagle eyed among you may have spotted that I’ve set the value at the top to ‘False’.

What this is saying is:

  • Until March 1st 2017, the value is False.
  • Between March 1st 2017 (inclusive and August 31st 2017 (inclusive), the value is ‘True’.
  • From September 1st 2017 and after, the value is ‘False’.

So, click ‘OK’ and let’s inspect the effect of our handiwork in the debugger:

OPA 12 - Time Based Reasoning Worked Example

There’s a lot more information here and one of the first things you’ll notice is that the total allowance has changed from $5110 to $4386.

If we break down the individual periods, you will see why:

  • January 1st – February 28th = 59 days x $10 (Single rate) = $590.
  • March 1st – August 31st = 184 days x $14 (Married rate) = $2576.
  • September 1st – December 31st = 122 days x $10 = $1220.

$590 + $2576 + $1220 = $4386!

Have a play with different dates and change points and you will find OPA is very good at working this stuff out for you.

OPA also offers a way to visualize this data. Right click the ‘the daily allowance for the citizen’ attribute and select ‘Show in Temporal Visualization’:

OPA 12 - Time Based Reasoning Worked Example

A new tab will appear top left named ‘Temporal Visualization’. If you click it, you will see:

OPA 12 - Time Based Reasoning Worked Example

This visualization confirms that we start off with $10/day, changing to $14/day from March 1st and changing back to $10/day on September 1st.

Time to complicate things a little by adding another variable to the mix in the shape of the daily income.

Let’s assume that the citizen started 2017 with a daily income of $150. Then later in the year the income rose to $250 and later yet, the income dropped to $180.

In order to deal with this new variable, we will change the rule that calculates the daily allowance to include the daily income for the citizen:

OPA 12 - Time Based Reasoning Worked Example

Remember that OPA will evaluate top down, so first it will check to see if the person is married and whether the daily income is less than $200. If this is false, it will check to see if the income is less than $200 and finally, if the citizen is not married and the daily income is greater or equal to $200, the ‘otherwise’ clause will apply.

Make sure the updated rule validates by pressing the ‘Validate’ button.

Now let’s start a debug session and have a look at the outcomes.

Start your debug session and navigate to the ‘data’ tab.

Supply the exact same values as the first example, making sure to set up the change points correctly.

Fun fact: Chances are that OPA still has your previous values in memory, saving you the need to re-enter them!

Check to see that you’re still getting the correct values.

You should see something like this:

OPA 12 - Time Based Reasoning Worked Example

Let’s set the value and change points for the daily income:

OPA 12 - Time Based Reasoning Worked Example

Click ‘OK’ and inspect the values in the data screen:

OPA 12 - Time Based Reasoning Worked Example

As you can see, the total allowance has now been set to $1926 (down from $4386).

We can have a look at what’s been happening in the Temporal Visualization tab.

Make sure the following attributes are shown by going to the debug data tab and right-clicking and selecting ‘Show in Temporal Visualization‘:

  • the daily income for the citizen
  • the citizen is married
  • the daily allowance for the citizen

Go to the ‘Temporal Visualization’ tab. You should see something like this:

OPA 12 - Time Based Reasoning Worked ExampleOPA 12 - Time Based Reasoning Worked Example

As you can see, there’s quite a bit going on here and the daily allowance for the citizen will vary based on marital status and income.

What you will hopefully be able to see is that, when it comes to dealing with changing circumstances, things can get quite complicated quite quickly. In the example we only dealt with two variables but throw in more variables and working out the right amounts would become very complex! Utilizing the out-of-the-box OPA temporal reasoning functionality allows you to manage the complexity of dealing with changing circumstances over time.

More information on Temporal Reasoning can be found in the OPA documentation:

https://documentation.custhelp.com/euf/assets/devdocs/cloud18c/PolicyAutomation/en/Default.htm#Guides/Policy_Modeling_User_Guide/Temporal_reasoning/Temporal_reasoning.htm

or in the Function Reference:

https://documentation.custhelp.com/euf/assets/devdocs/cloud18c/PolicyAutomation/en/Default.htm#Guides/Policy_Modeling_User_Guide/Work_with_rules/Function_references/FunctionReference.en-US.html

Finally for those who were wondering, the daily amount that the user is entitled to on June 26th is…

OPA 12 - Temporal Reasoning Worked Example

OPA 12 - Temporal Reasoning Worked Examplewhich is $14!

Thanks to Evert for his time and excellent article abut Time Based Reasoning. Readers who what to look at more Time Based Reasoning articles can search here.

Until the next time. If you want to write for the OPA Hub Website, reach out via our Contact Page.

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation #2

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation #2

In a previous post by our guest writer Dr Jason Sender, he investigated improvements in Oracle Policy Automation rules by applying some of the principles of refactoring, and then he began to discuss Object-Oriented Design Patterns and Oracle Policy Automation, and their application in real-world contexts.

As before, this third article draws on the work and publications of Martin Fowler, which we discussed in the previous post, those of Joshua Kerievsky from his highly regarded book “Refactoring to Patterns”, and the ground-breaking work on design patterns called “Design Patterns: Elements of Reusable Object-Oriented Software”, which had four authors known collectively as the Gang of Four (GoF).

Before studying some further examples of patterns and their application to Oracle Policy Automation, it is probably wise to step back and take a broad view of the context. Computer science is often defined as dealing in abstraction, and software engineering as managing complexity, and the connection is that only by considering different parts of programs and systems as abstract concepts are we better able to manage complexity.

Design Patterns and Oracle Policy Automation in Context

To put it in terms more related to our daily jobs, Oracle Policy Automation is often integrated with other systems that the Oracle Policy Automation developer does not need to understand, and can think of in abstract terms. A good example would be the Siebel CRM or Oracle Service Cloud database that Oracle Policy Automation may interact with, but about which the Oracle Policy Automation developer may not need to know anything – beyond understanding the available attributes for mapping and having a brief overview of the context. Abstraction is about ignoring irrelevant details, and this is often accomplished by what is a theme running through many design patterns, which is to: “encapsulate the concept that varies” (GoF, p. 54).

We often obtain abstraction in Oracle Policy Automation by using indirection (interposing an intermediate attribute) to encapsulate the attribute that varies. This allows us to “Program to an interface, not an implementation“, as the GoF (p. 18) term it, the rationale for which is that the implementation can be changed if other parts of the program only depend on the interface.

If you come, like some of us here on the OPA Hub Website, from a CRM background, you will be familiar with the concept whereby access to a CRM Object is provided through an interface, and the interface does not change even if the Object undergoes modifications (such as when using the GetMetadata Operation of the Oracle Policy Automation Connector Framework).

Although design patterns and refactoring techniques should serve the goals of reduced duplication, reduced complexity, and increased clarity, these goals can be in conflict, not just with each other, but with certain Oracle Policy Automation-specific goals. Take for example one of the stand-out benefits of Oracle Policy Automation: Policy Isomorphism. This means having the same form (i.e., you can copy and paste legislation or other source material directly into Microsoft Word, and base your rules on this and compare them side-by-side) and this is in tension with the concept of intermediate attributes (adding more attributes to increase clarity).

Design Patterns and Oracle Policy Automation : Strategy and Template Patterns

With that in mind we return to another example of how Object-Oriented Design patterns can be applied to Oracle Policy Automation. The following extended example will be given to demonstrate how useful the Strategy and Template Method design patterns (which we adapt from the GoF book) could be in reducing the number of tables and increasing the flexibility of calculations. We show this extended example to demonstrate the size of the reduction in rules from applying these design patterns to Oracle Policy Automation. We start with an information collection screen and associated Boolean rules to derive values from the drop down list items:

Example Model and Interview

We then look at the top level goals for determining the total profit of the company, which is our main goal:

Design Patterns and Oracle Policy Automation

These are then derived from three very similar tables of calculations, which are listed in succession below:

Table of Conclusions

Object-Oriented Design Patterns and Oracle Policy Automation 4

Object-Oriented Design Patterns and Oracle Policy Automation 5

Design Patterns with OPA : Implementing the Design Pattern

We can now alter this to implement our design pattern. We first create a main rule to determine the total profit:

Object-Oriented Design Patterns and Oracle Policy Automation 6

This is the Template Method pattern since it delegates a part of the algorithm – the tax factor, a newly created attribute. Then, we employ the Strategy pattern to effectively split up the tax factor into one of three algorithms (in effect, we are treating the tax factor as an algorithm and then applying Strategy to it). We do this by parameterising, based on type of company, using a feature called Apply Sheet that avoids multiply proven attributes by letting the parameter determine which Excel Worksheet applies:

Object-Oriented Design Patterns and Oracle Policy Automation 7

Then each of the subsequent tabs has a small table. As an example, here is the mining sheet. The others have identical structure and adjusted values for the tax factor.

Object-Oriented Design Patterns Example

For the Strategy and Template Method patterns, applying these design patterns has transformed our example rulebase into something much more easily extensible.

Improved Maintenance and Clarity

If we were to create another sector (e.g., oil), it would be very easy to add on another sheet in the Excel Workbook and add it to the Apply Sheet. In fact, we could easily add another 20 sectors, whereas there would be a lot of time-consuming ‘find and replace’ work to do in the original, and we would have ended up with dozens of pages of rules. Moreover, the original algorithm had a lot of code duplication, as the same Boolean attributes were repeated in row after row in table after table.

Furthermore, if we had needed to add or remove conditions from the tables it would have taken extensive work in order to verify that each and every table was updated correctly. In the reformed algorithm, the conditions were written only once and these are easily changeable. And, we were able to eliminate three (possibly confusing) and unnecessary sub-totals relating to each of the company types. The unvarying part of the algorithm (the total revenue – the total cost) is now written once, rather than 15 times, and so it is easily changeable.

Finally, our new algorithm mentions only the tax factor. This means that if all tax rates were harmonised, a single tax rate declared, or a new formula implemented that did not depend on the company type, since we have encapsulated the part of the algorithm that varies, we could just delete the Excel table and introduce a new table for the tax factor that did not mention the type of company. This would not have been so easy to do with the original algorithm.

Once again, even from a very simple set of examples, it should be clear that Oracle Policy Automation rules will benefit from the targeted application of principles from programming – in this case, the Strategy and Template Method design patterns. For more information about the ideas discussed in this article, Dr Sender can be reached using his LinkedIn profile, at the end of this article.

Design Patterns and Oracle Policy Automation : Going Further

The OPA Hub and Dr Sender are currently working towards the launch of advanced training based on his work. If you are interested, please take a moment to answer the 1 question survey below (if you have not already registered for the OPA Hub you can do that here before you answer). Thank you!

What kind of advanced OPA training would you be interested in attending?

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation

In a previous post by our guest writer Dr Jason Sender, he investigated improvements in Oracle Policy Automation rules by applying some of the principles of refactoring. Hopefully the short examples he gave revealed some of the increases in readability, maintenance and flexibility that you can build into your rules.Now, in the second article in this series, Dr Sender looks at Object-Oriented Design patterns and Oracle Policy Automation. This article draws on the work and publications of Martin Fowler, which we discussed in the previous post, and those of Joshua Kerievsky from his highly regarded book “Refactoring to Patterns”.

Design Patterns

Kerievsky makes two very important observations on design patterns. His first point is that, as he terms a section heading, “There are many ways to implement a pattern.” (Kerievsky, p. 26). This is key to what we shall see in this article, since with Oracle Policy Automation we should be aiming at implementing the core concept of a given design pattern, rather than strictly following the implementation example given in GoF (1995).

Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book describing software design patterns. It has been influential to the field of software engineering and is regarded as an important source for object-oriented design theory and practice…The authors are often referred to as the Gang of Four (GoF) (Wikipedia).

The second key point that Kerievsky (p. 32) makes is that: “In general, pattern implementations ought to help remove duplicate code, simplify logic, communicate intention, and increase flexibility. However…people’s familiarity with patterns plays a major role in how they perceive patterns-based refactoring.” So we see here both our aims in using design patterns, and a constraint (developer knowledge). Since OPA does not have objects and classes in the same sense as an object-oriented language, we should not expect a straightforward application to OPA.

In this article we will focus on one single pattern, known as the Adapter pattern.

Summary: “Convert the interface of a class into another interface clients expect.
Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces.” (GoF, p. 139)

Let’s look at applying the Adapter pattern to Oracle Policy Automation rules.  At one level, translation is possible; Oracle Policy Automation can translate all its attributes into another language so that the rules can be used once and deployed in multiple languages just by translating the variables, statements, and similar features, while not rewriting the rules. This example from Oracle (2016) demonstrates this:

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation

As a second example, we can make a variable equal to another variable, or a Boolean true if another Boolean is true. For example:

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation 2

Here we have adapted the ‘the sky is blue’ to ‘the sun is shining’ (but not vice versa) and adapted ‘the value of the car’ to ‘the value of the vehicle’ (but not vice versa). It might be thought that this is pretty simplistic and not all that useful. The following example highlights more complexity, and, instead of simply adapting the interface, as the above examples do, it goes beyond that to override some of the adaptee’s behaviour:

 

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation 3

 

Here we have adapted the interface from ‘the storey of the building’ to two different interfaces, ‘the lift floor’ and ‘the elevator floor’. British lifts start at 0 (or G) and US elevators start on the 1st floor and do not have a 13th floor. So not only have we changed the interface, we have adapted the behaviour. The new variables can be used elsewhere in the policy model in place of the original one.

Object-Oriented Design Patterns and Oracle Policy Automation : Adapter Pattern Summary

The Adapter pattern seems “made for OPA”. When discussing the Adapter pattern the GoF (p. 142) stress that:

“Adapters vary in the amount of work they do…There is a spectrum of possible work, from simple interface conversion – for example, changing the name of operations – to supporting an entirely different set of operations.”

The examples shown in this article illustrated three aspects:

  • The first adapted the language that users would see
  • The second was an example of changing the name of an operation
  • The third supported a different operation but was also an Oracle Policy Automation-specific variant of what the GoF (1995) term “two-way adapters”, since it adapted two variables from one underlying one.

Each of the three examples has different costs and benefits. The language translation tightly couples the adaptee and adapter, while the changing of the name allows for the other variable to change how it is derived without changing the adapter (i.e., a level of indirection).

It is important to note that the one-way variable name change or Boolean name change simply allow a new term to be used, but these might very well be used in more complicated ways in rule tables (for variables) or rules (for a Boolean) where the adaptee’s value equalled the adapter’s value only in certain circumstances. The two-way adapter allowed for a single variable to be used to provide multiple adapters, thus minimizing code duplication.

The Bigger Picture

It’s worth stepping back at this point to understand the broader context.  Computer science is often defined as dealing abstraction, and software engineering as managing complexity, and the connection is that only by considering different parts of programs and systems as abstract concepts are better able to manage complexity.  For example, Oracle Policy Automation is often integrated with other systems that the Oracle Policy Automation  developer does not need to understand, and can think of in the abstract, like the database that Oracle Policy Automation may interact, but which the Oracle Policy Automation developer may not need to know anything about beyond mapping attributes in Oracle Policy Automation.

So abstraction is about ignoring irrelevant details, and this is accomplished by what is often the theme running through many design patterns, which is to: “encapsulate the concept that varies” (GoF, p. 54).  We often obtain abstraction in Oracle Policy Automation by using indirection (interposing an intermediate attribute) to encapsulate the attribute that varies.  This allows us to “Program to an interface, not an implementation“, as the GoF (p. 18) term it, the rationale for which is that the implementation can be changed if other parts of the program only depend on the interface.

Once again, even from a very simple set of examples, it should be clear that Oracle Policy Automation rules will benefit from the targeted application of principles from programming – in this case Object-Oriented Patterns. The best approach is not a slavish application, rather a pragmatic use of those best-suited to the unique nature of the Oracle Policy Automation platform.

For more information about the ideas discussed in this article about Object-Oriented Design Patterns and Oracle Policy Automation, Dr Sender can be reached using his LinkedIn profile, below. Look out for more articles about Object-Oriented Design Patterns and Oracle Policy Automation coming soon!

Guest Post : Refactoring in Oracle Policy Automation #1

Refactoring in Oracle Policy Automation #1

The OPA Hub Website is extremely happy and very lucky to be able to welcome an esteemed guest author, Dr Jason Sender. Over the course of several months I have had the pleasure of reading Dr Sender’s work and conversing with him. His dissertation, entitled “The Application of Design Patterns to Oracle Policy Automation”, is a fascinating read and after due discussion with him, he has kindly agreed that parts of it might be republished here for the wider community; specifically in this article, an introduction to his excellent work on Refactoring in Oracle Policy Automation.

Dr Sender, of the University of Oxford, was Rules Architect for nearly four years on the most complex Rulebase used by the Legal Aid Agency in the United Kingdom, which is used to determine capital and income eligibility of applicants.

In this, the first of a series of posts, he looks at Refactoring Techniques based on Martin Fowler’s work and applies them to Oracle Policy Automation where appropriate. To simply state the goal of such an exercise, it can do no harm to state the goal of the book I just linked to:

“Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations, each of which “too small to be worth doing”. However the cumulative effect of each of these transformations is quite significant. “

How to Apply Object-Oriented Design Patterns to OPA?

At a broader level, it is possible to apply design patterns from Object-Oriented Design Patterns to OPA. Since OPA does not have objects and classes in the same sense as an object-oriented language, we should not expect a straightforward application to OPA. Not all of the patterns will be technically applicable, and even some of those will be unfeasible or without any great impact. Dr Sender’s work discusses the application of the eight most common patterns. If you would like to read further on this matter, please feel free to contact Jason using the information at the end of this article.

Improving your design Approach to OPA Rulebases

Object-Oriented languages come equipped with advanced development environments and a plethora of automation tools to help the refactoring effort. Oracle Policy Automation uses Microsoft Word and Excel, and is classified as a Production Rules System rather than a fully-fledged object-oriented language. As Fowler states (since it is particularly relevant to our daily lives as Oracle Policy Automation Consultants or Architects):

“There are also many languages where you don’t have tools, so knowing how to do it yourself is still important.”

The Application of Object-Oriented Refactoring in Oracle Policy Automation

This introductory article will focus on simple refactoring techniques that everyone can adopt, and which bring clarity and maintainability to Oracle Policy Automation rules. In a later article, Dr Sender will reveal OPA-specific refactoring techniques that were discovered during the course of his work.

Extract Variable Rule

Extract Variable Rule is a more meaningful OPA rebranding of Fowler’s Extract Method, since OPA does not have Methods. Have you ever seen something like this in an Oracle Policy Automation Word document?

Refactoring in Oracle Policy Automation - Extract

By applying the Extract Method: “You have a code fragment that can be grouped together. Turn the fragment into a method whose name explains the purpose of the method.” we find ourselves with a revised version that looks a little like the example below.

Refactoring in Oracle Policy Automation - Extract Example Complete

The gain in readability and ease of maintenance should be obvious. Now that Dr Sender has gotten us on the right track, let’s take a couple more examples from his work. These revolve around the removal of conditional expressions from Microsoft Word or Microsoft Excel tables.

Extract Rules from Rule Table

Extract Rules from Rule Table is a more meaningful OPA rebranding of Fowler’s Decompose Conditional Method. Consider the following table, where conditions and premises meet convoluted conclusions:

Refactoring in Oracle Policy Automation - Decompose Conditional

Now, here is the table, following an OPA-esque application of the Decompose Conditional refactoring technique, for situations where (according to Fowler):

You have a complicated conditional (if-then-else) statement. Extract methods from the condition, then part, and else parts.

Refactoring in Oracle Policy Automation - Decompose Conditional Complete

The aim of Extract Rules from Rule Table is to reduce code duplication and/or duplicated conclusion values.  It should be noted that it can add a level of indirection (i.e., flexibility) too, but its main use would be to extract duplicated rules from a complicated Word rule table, not, as in the example above, to extract only the conditions and conclusions of a single row, which arguably would add indirection at the cost of more code, unneeded flexibility, and complexity.

We would look to refactor to simplify code and increase clarity – if they do not do so in a given situation then they are probably not needed in that situation.

It’s worth restating the above in terms of goals.  One must understand one’s goals before applying a refactoring technique, and not every refactoring technique will be appropriate in every situation, and indeed many refactoring techniques are inverses of each other.  In certain situations flexibility is needed, even if it creates more code.  For example, instead of hard-coding a value in (e.g., an amount) in twenty different conclusions of a rule table you could set a variable equal to the amount and put the variable in the rule table, as this would add the ‘flexibility’ to change the amount if needed.  We would say it adds a level of indirection – but it does create more lines of code and complexity.

Almost everything is a balancing act and understanding one’s goals is hard, and it’s even harder to then figure out approaches that will help you achieve these goals, and that comes with Oracle Policy Automation experience, and a little help from OPA experts in articles like this one!

Refactoring in Oracle Policy Automation : There’s (Much) More!

Obviously these two simple examples can hope only to briefly demonstrate the value of the hard work that Dr Sender has put in to developing tools and techniques to improve the readability, maintenance and effectiveness of Oracle Policy Automation rules. He can be contacted using the link below should you wish to discuss his work, and he has kindly agreed to let me publish a couple more articles on this subject.

Watch this space for more valuable content on the topic of Refactoring in Oracle Policy Automation. The OPA Hub and Dr Sender are currently working towards the launch of advanced training based on his work. If you are interested, please take a moment to answer the 1 question survey below (if you have not already registered for the OPA Hub you can do that here before you answer) . Thank you!

What kind of advanced OPA training would you be interested in attending?

How Oracle Policy Automation (OPA) Helps In Enterprise AI

Enterprise AI – an Intelligent Data Warehouse/ERP system?

AI enables computers to do some things better than humans especially when it comes to finding insights from large amounts of Unstructured or semi-structured data. Technologies like Machine learning , Natural language processing (NLP) , Speech recognition, and computer vision drive the AI layer. More specifically, AI applies to an algorithm which is learning on its own.

To understand this, we have to ask ourselves: How do we train a Big Data algorithm?

There are two ways:

  • Start with the Rules and apply them to Data (Top down) OR
  • Start with the data and find the rules from the Data (Bottom up)     

The above Rules can be implemented / Executed using Oracle Policy Modeling and Oracle Policy Automation (OPA)

The Top-down approach involved writing enough rules for all possible circumstances. But this approach is obviously limited by the number of rules and by its finite rules base. The Bottom-up approach applies for two cases. Firstly, when rules can be derived from instances of positive and negative examples(SPAM /NO SPAN). This is traditional machine learning when the Algorithm can be trained. But, the more extreme case is : Where there are no examples to train the algorithm.

What do we mean by ‘no examples’?

a)   There is no schema

b)   Linearity(sequence) and hierarchy is not known

c)   The output is not known(non-deterministic)

d)  Problem domain is not finite

Hence, this is not an easy problem to solve. However, there is a payoff in the enterprise if AI algorithms can be created to learn and self-train manual, repetitive tasks – especially when the tasks involve both structured and unstructured data.

Oracle Policy Automation - AIHow can we visualize the AI layer?

One simple way is to think of it as an ‘Intelligent Data warehouse’ i.e. an extension to either the Data warehouse or the ERP system

For instance, an organization would transcribe call centre agents’ interactions with customers create a more intelligent workflow, bot etc using Deep learning algorithms.

Enterprise AI layer – What it mean to the Enterprise

So, if we imagine such a conceptual AI layer for the enterprise, what does it mean in terms of new services that can be offered? Here are some examples

Bots : Bots are a great example of the use of AI to automate repetitive tasks like scheduling meetings. Bots are often the starting point of engagement for AI especially in Retail and Financial services

Inferring from textual/voice narrative: Security applications to detect suspicious behaviour, Algorithms that can draw connections between how patients describe their symptoms etc

Detecting patterns from vast amounts of data: Using log files to predict future failures, predicting cyberseurity attacks etc

Creating a knowledge base from large datasets: for example an AI program that can read all of Wikipedia or Github.

Creating content on scale: Using Robots to replace Writers or even to compose Pop songs

Predicting future workflows: Using existing patterns to predict future workflows

Mass personalization: in advertising

Video and image analytics: Collision Avoidance for Drones, Autonomous vehicles, Agricultural Crop Health Analysis etc

These applications provide competitive advantage, Differentiation, Customer loyalty and mass personalization. They have simple business models (such as deployed as premium features /new products /cost reduction )

The Enterprise AI layer and IoT

So, the final question is: What does the Enterprise layer mean for IoT?

IoT has tremendous potential but faces an inherent problem. Currently, IoT is implemented in verticals/ silos and these silos do not talk to each other. To realize the full potential of IoT, an over-arching layer above individual verticals could ‘connect the dots’. Coming from the Telco industry, these ideas are not new i.e. the winners of the mobile/Telco ecosystem were iPhone and Android – which succeeded in doing exactly that.

Firstly, the AI layer could help in deriving actionable insights from billions of data points which come from IoT devices across verticals. This is the obvious benefit as IoT data from various verticals can act as an input to the AI layer. Deep learning algorithms play an important role in IoT analytics because Machine data is sparse and / or has a temporal element to it. Devices may behave differently at different conditions. Hence, capturing all scenarios for data pre-processing/training stage of an algorithm is difficult. Deep learning algorithms can help to mitigate these risks by enabling algorithms to learn on their own. This concept of machines learning on their own can be extended to ‘machines teaching other machines’. This idea is not so far-fetched and is already happening, A Fanuc robot teaches itself to perform a task overnight by observation and through reinforcement learning. Fanuc’s robot uses reinforcement learning to train itself. After eight hours or so it gets to 90 percent accuracy or above, which is almost the same as if an expert were to program it. The process can be accelerated if several robots work in parallel and then share what they have learned. This form of distributed learning is called cloud robotics

We can extend the idea of ‘machines teaching other machines’ more generically within the Enterprise. Any entity in an enterprise can train other ‘peer’ entities in the Enterprise. That could be buildings learning from other buildings – or planes or oil rigs. We see early examples of this approach in Salesforce.com and Einstein. Longer term, Reinforcement learning is the key technology that drives IoT and AI layer for the Enterprise – but initially any technologies that implement self learning algorithms would help for this task

Conclusion

In this brief article, we proposed a logical concept called the AI layer for the Enterprise. We could see such a layer as an extension to the Data Warehouse or the ERP system. This has tangible and practical benefits for the Enterprise with a clear business model. The AI layer could also incorporate the IoT datasets and unite the disparate ecosystem. This will not be easy. But it is worth it because the payoffs for creating such an AI layer around the Enterprise are huge! The Enterprise AI layer theme is a key part of the Data Science for Internet of Things.

Note : this article was reprinted in The OPA Hub Website with the kind permission of the author. You can find him on LinkedIn and the original article can be found here.

Worldwide
Logo by Southpaw Projects LLC