Webinar: Blueprint for omnichannel integration architecture

Are you interested in the insights to how organizations are implementing the foundational integration building blocks that lead to successful communication with their customers?

This story is about how an omnichannel customer experience makes customer engagement across all channels as efficient as engagement with a single channel. Let’s take a detailed look at an architecture blueprint based on research of actual customer solutions, and gain insight into how your integration architecture can map to support your customers’ omnichannel experiences.

Register for this webinar and you’ll gain insights on how your current architecture can map to support your customers experiences, for a detailed look at an architectural blueprint based on successful customer solutions, and receive instruction on how to discuss an omnichannel architecture in detail.

omnichannel integration architectureHere’s the official abstract, so join us on 12 Dec 2019 for a detailed look at a blueprint for omnichannel integration architecture:

Agile integration is a broadly scoped discussion around how to use all the services and power contained in your organization’s current architecture. While the topic is interesting in its own right, let’s take a deeper look at a specific solution within the integration context: providing an omnichannel customer experience. Omnichannel is the integration and orchestration of channels to make the experience of customer engagement across all channels as efficient as engagement with 1 channel. 

Be sure to register and look forward to seeing you there?

Business Rules Re-Imagined

The Impact of Cloud, AI/ML and RPA and on Decision Management

Decision making is a key component of today’s business applications. Complex business applications must be able to make decisions following the same rules a human would follow when making those same decisions.

Because business applications are so critical –  and because they need to incorporate business know – how into the applications to support accurate decision making – the building of these applications is no longer left solely to IT developers. Software development is seeing increasing involvement from the business side. 

For example, in the past an insurance company would write an application that records insurance claims. Today, IT is writing applications to sell insurance. That is a huge change. In computer science class, developers are not taught how to sell insurance. And it is not like the insurance company lacks that expertise anyway. They have many people who know how to sell insurance, but none of them work for IT. So more businesses are realizing that they need to involve the business stakeholders in the software development process, and incorporate more business knowledge directly into these applications. 

Clearly, the business stakeholder are not developers. They are not going to write code, but they can produce models of their business, based on the business rules, the processes, the policies, and the decisions they make while conducting company business. These models can be thought of as the source code that will be deployed within the business apps. 

How does IT empower the business user to encode as much of their knowledge as possible so they can add value to the applications the organization depends on? Development teams should utilize business rules rather than simply encoding business logic into applications. When business logic is built into the application – which is the traditional way of developing business applications – the business stakeholders have no visibility. It is hard for them to see what specific policies are being applied; what the rules are; and why a decision is made. 

The solution is to outsource the decision making to a business rules engine, which makes decisions on behalf of the application, based on a set of rules written in English so the business side can understand. Business can gain much more control over the policies that are applied automatically by these applications.

A business rules engine provides multiple advantages, including:

  • Separation of the business rules from the applications
  • Visibility for business stakeholders
  • Business rules expressed in terms that the business can really understand
  • Enabling business and IT experts to collaborate more effectively
  • The ability to change rules easily and quickly
  • Consistency of rules and decision-making

A range of Red Hat customers across various industries are having great success using a rules engine to provide decision services to the organization and keeping business rules separate from application code.

A lot has changed in IT over the past few years that has impacted automated business decision making. In this blog, I will cover three of the major changes that have caused the greatest impact: Cloud, Artificial Intelligence (AI)/Machine Learning (ML), and Robotic Process Automation (RPA).

The Cloud

The cloud has dramatically altered the way we create, deploy, monitor and manage business applications, and that has a tremendous impact on people using business rules engines.

Since the start of IT, organizations have built “Monolithic” applications, which are large, difficult to understand, and challenging and time-consuming to make a change. In the last few years, thanks to the cloud, monolithic apps have been replaced by containers, and microservices architecture, making it easier to create, deploy, manage and change parts of applications. A large app can be broken into smaller components that can be developed, scaled, managed and changed independently from the other components.

The flexibility of containers and microservices simplifies decision-making because rules can be added as components rather than being embedded in the application. In the cloud, rules can modified easily in response to changes in the market or in the way the company does business, and the entire application does not have to be rewritten. This provides businesses with a level of agility they never had before.

Artificial Intelligence (AI)/Machine Learning (ML)

Another set of emerging technologies that is having a major impact on business applications is Artificial Intelligence (AI) and Machine Learning (ML). 

One way of defining ML is “rules that write themselves.” This is obviously a huge leap from where we were 10 years ago. Instead of creating the rules based on your experience and building an app based on those rules, you can now look at historical data, figure out what rules produced those results, and then apply that knowledge to make decisions going forward.

Essentially ML is used for constructing predictive models. For example, with regard to the rules covering when insurance claims are denied or paid, you have data about how you arrived at decisions in particular cases. You could use ML to build predictive models to repeat those decisions in similar cases. 

How do predictive models compare with user written rules in terms of their usefulness and viability for these types of decision applications

  • Rules are created by people, while predictive models are automatically created based on analysis of historical data
  • Rules produce results that are explainable, while predictive models produce results that are not explainable.
  • Rules are subject to human error. One of the challenges with rule-based systems is you get gaps – such as situations you forgot about, or edge cases you did not address. Conversely, predictive models are subject to historical bias. You are limited to reproducing behavior apparent from the training data. So if the data is biased, you get a biased model. 
  • Rules take a significant amount of time to produce, while it is relatively quick to generate a predictive model once you have the data.

The goal when using ML to augment decision making is to combine the advantages of applied rules and predictive models. New rule languages, like Decision Model and Notation (DMN), make this possible by simplifying the process of creating rules.

In the past, rules were created in a complex notation. Thousands of rules leave open many possibilities for error. DMN is a graphical language for encoding rules that make a decision. It makes it much easier for business stakeholders to create the source code for their decision applications. They create a graph to encode complex business logic. Then they can incorporate a predictive model into the DMN diagram, and they can incorporate business rules as well, effectively combing the best of both options

Robotic Process Automation

Robotic Process Automation (RPA) is an exciting, fast moving space right now. With RPA, software robots are developed to perform routine, repetitive work that would otherwise be done by a human worker. The advantages of RPA are all about reducing cost and headcount by automating tasks.

Time spent copying information from a back office database into a spreadsheet, and moving data around from system to system – this is not the type of work where a human worker adds value to the process, but it still has to be done. RPA allows an organization to automate those repetitive tasks. 

One of the best advantages of RPA is that it enables you to automate work without having to change your underlying systems. You can keep your legacy mainframe and other applications exactly as they are. The robot pretends to be a human and carries out the same tasks exactly the same way a human worker would. 

But it is very important to consider RPA as just another software development approach. In future, as RPA evolves, I would expect to see containerized robots roaming around your hybrid cloud. But for now, RPA is just another app and it needs to be managed just like any other app. Version control and QA are very important. 

When you create a bot, beware of the attack surface. You create an opportunity for someone to add a few lines of script to that bot. Think about the damage that could be inflicted by an automated bot with high level access to all your enterprise data. That is a key reason why RPA should be subject to the same governance as any other software.

Also it is very important to understand that the value of RPA is in the ability to automate human work, not to patch holes in IT systems. If you find yourself building bots to fix holes in IT, you really need to take a good look at the infrastructure instead. It is not productive to use bots as band aids, because the bots themselves will continuously break as things change within the infrastructure. It is more productive to focus on fixing the source of the issue in the underlying infrastructure.

For RPA to remain relevant and continue to support software development, bots should be compatible with the cloud, and be able to run in containerized environments. This is technology we expect to see in the next few years or so.

The Red Hat Solution

Red Hat is very active in the software development space and offers a range of tools designed to solve the challenges associated with incorporating rules and decision making into business applications:

  • Red Hat Decision Manager is a platform for developing containerized microservices and applications that automate business decisions. Decision Manager includes business rules management, complex event processing, and support for building DMN models.
  • Red Hat Process Automation Manager is a platform for developing containerized microservices and applications that automate both business decisions and processes. Process Automation Manager includes business process management (BPM), business rules management (BRM), and business resource optimization and complex event processing (CEP) technologies. It also includes a user experience platform to create engaging user interfaces for process and decision services with minimal coding. 
  • For development in the Cloud, Red Hat OpenShift is an enterprise-ready Kubernetes container platform with full-stack automated operations to manage hybrid cloud and multicloud deployments 
  • Red Hat Runtimes is a set of products, tools, and components for developing and maintaining cloud-native applications. It offers lightweight runtimes and frameworks for highly-distributed cloud architectures, such as microservices. 

Robotic Process Automation and Cloud Technology – Challenges and Opportunities

The original article was published on IT Toolbox on July 23, 2019. 

RPA holds incredible promise for organizations looking to drive greater efficiency and cost savings; however, the industry must overcome several crucial challenges before it can truly live up to its potential. This article unpacks those challenges and explores the opportunities ahead.

Robotic Process Automation holds incredible promise for organizations looking to drive greater efficiency and cost savings; however, the industry must overcome several crucial challenges before it can truly live up to its potential. This article unpacks those challenges and explores the opportunities ahead.

By now, you’ve probably heard about Robotic Process Automation (RPA). It is not especially a new idea that’s suddenly gaining attention as businesses strive to become more digital. The promise of RPA is providing quick and significant cost savings through automation of human tasks with software robots. In fact, PwC estimates that “45% of work activities could be automated, and that this automation would save $2 trillion in global workforce costs.”

Challenges Faced by Organizations

Today, there are thousands of software robots automating everything from simple tasks like order entry and invoice preparation, to complex interactions, like issue resolution and customer service. But there are challenges awaiting many organizations, who have rushed to deploy robots.

1. Cloud Infrastructure Challenge:

First, there’s the matter of the cloud. Before RPA came along, those same organizations were busy planning multi-year efforts to reap the benefits of cloud computing. Moving IT to the cloud offers a similarly enticing cost benefit, but it is a long term project, requiring the deployment of new and emerging technologies.

Much has been invested in containers, orchestration, microservice and service mesh architectures, etc., as we lay the foundations for a serverless, data center-less future. However, RPA has some catching up to do. It is still confined to the desktop—the Windows desktop, to be precise.

The majority of software robots currently deployed are of the ‘attended’ type. This means that they exist on your Windows desktop, much like the little ‘Clippy’ assistant in bygone versions of Microsoft Office, where they do things like, move rows of data from a back office database to a spreadsheet, so that you can focus on more important things.

In the recent years, RPA has evolved to enable ‘unattended’ bots to manipulate your enterprise data behind the scenes, on Windows servers. That’s a step in the cloud direction, but still far from the notion of cloud-native bots that can cruise around your hybrid cloud and fix whatever needs fixing.

When will we see containerized bots, orchestrated by standard platforms like Kubernetes and Istio? Well, presumably not until RPA vendors realize the central role that Linux plays in modern cloud architectures. But more importantly, not until RPA goes open source. Why? Because open source software is the central pillar of modern cloud stacks, and if RPA is to have a role in hybrid cloud infrastructure, it must be open source too.

However, today, there is very little in the way of open source RPA. There are a few open source RPA-like projects such as, TagUI, Robot Framework and Sikulix, but these are very bare-bones compared to the market leading proprietary products in the market currently. The opportunity for these proprietary vendors to play in the hybrid cloud market is immense if they can embrace open source business models.

2. Cost Challenge:

The second challenge for users of RPA looking to save on labor costs is that today’s bots just aren’t all that smart. They don’t measure up to their human counterparts in their ability to figure out how to get the job done when some part of it turns out a little differently. Some bots are simple macros, repeating the same series of steps over and over. Others may have a little more intelligence, perhaps a rules engine to handle complex scenarios, but very few have anything close to actual intelligence.

The world of AI and ML is currently separate from RPA, and although some bots may be able to utilise AI services, like IBM Watson, none of them have the in-built ability to learn from past experience so they can do a better job the next time. Consequently, the anticipated cost savings don’t always materialize, and bots can be limited to highly structured and repetitive tasks. Just like with the cloud, though, there is opportunity here. I expect a marriage of RPA and AI/ML will likely happen soon, and will open up a new landscape of possibility for automated business.

3. Implementation Challenge:

Finally, there’s the implementation challenge—how to deploy RPA technology so that it supports your IT strategy rather than hobbles it. It’s easy to be tempted by RPA’s promise of a quick fix into attacking the symptoms of your problems rather than the root cause. Some organizations deploy bots as ‘band-aids’ to relieve bottlenecks in semi-automated processes, when the real problem is an ageing infrastructure that can’t accommodate new business requirements. This may solve the immediate problem, but will continuously break again with every minute change in operating processes, applications or infrastructure. Partly, it’s the ease with which an RPA bot can be deployed that’s to blame. Why go to the trouble of creating APIs for critical applications when it is easier to just have a bot screen-scrape, say, an accounts receivable app to get the one extra data field needed for the new invoices?

The answer, of course, is because this problem is just a symptom of a larger issue within the IT infrastructure, RPA does not fix a spaghetti tangle of applications, data and integration strategies. Organizations with this problem need to focus on building a cloud-native foundation first. Otherwise, if the team continues to throw bots at every new business request, the entire data center will eventually collapse from unmanageable complexity.

Automating Human Work

RPA is a valuable technology when it is used to automate human work, and not to patch holes in IT systems and applications. It is made more powerful when it can integrate effectively into a modern application environment—monitoring events, using cloud services to gather information and interacting with applications via APIs.

The opportunities for automation are huge, but the supporting IT infrastructure is critical. I believe those enterprises that are able to combine a modern cloud-native application environment with open source, intelligent, cloud-native bots will have an unparalleled competitive advantage.