Call to Action

Webinar: Take a tour of Sparkling Logic's SMARTS Decision Manager Register Now


Decision Requirements and Modeling with DMN in SMARTS

DMN 1.3 support in SMARTS

In this post, we present how Sparkling Logic continues its involvement in the DMN standard, through its graphical tool SMARTS Pencil, which business analysts use to model business decisions by drawing a diagram to form a decision process.

DMN, a bit of history

The Decision Model and Notation (DMN) was formally introduced by the Object Management Group (OMG) as a v1.0 specification in September 2015. Its goal was to provide a common notation understandable by all the members of a team whose goal is to model their organization’s decisions.

The notation is based on a simple set of shapes which are organized in a graph. This allows the decomposition of a top-level decision into more, simpler ones, whose results must be available before the top-level decision can be made. These additional decisions themselves would be decomposed, and so on and so forth until the model reaches a more complete state. In addition, the implementation of the decisions can be provided, notably in the form of decision tables (which is also a very common means of representing rules).

The normalization of the graphical formalism (the DMN graph) and of the way the business logic is implemented (e.g., decision tables) allows teams to talk about their decisions, using diagrams with a limited set of shapes.

Sparkling Logic was one of the early vendors to provide a tool to edit (and execute) these decision models: Pencil Decision Modeler. It was released in January 2015, before the standard was officially approved.

Since then, the DMN standard evolved significantly, by adding new diagram elements, new constructs and new language features, while clarifying some of the existing notions. It is now at version 1.3. And we didn’t rest on our laurels either: in SMARTS Ushuaia, we made Pencil Decision Modeler part of SMARTS, as a first-class feature and added full compliance to DMN 1.3! This post describes how SMARTS supports DMN 1.3.


DMN 1.3 still defines the building blocks which were in the original standard and which I mentioned in Talking about decisions.

As a recap:

  • A Decision determines its output based on one or more inputs; these inputs may be provided by an input data element, or by another decision
  • An input data is information used as input by one or more decisions, or by one or more knowledge sources
  • A business knowledge model represents knowledge which is encapsulated, and which may be used by one or more decisions, or another business knowledge model. This knowledge may be anything which DMN does not understand (such as a machine learning algorithm, a neural network, etc.) or a DMN construct (called a “boxed expression”, see below)
  • A knowledge source represents the authority for a decision, a business knowledge model, or another knowledge source: this is where the knowledge can be obtained (be it from a written transcription or from someone)

These blocks are organized in a graph and the links between them are called requirements.

What’s new in SMARTS’ DMN Support

More building blocks

In DMN 1.3, the following elements may also be added to a graph:

  • A decision service exposes one or more decisions from a decision model as a reusable element (a service) which might be consumed internally or externally
  • A group is used to group several DMN elements visually (with whatever semantics may be associated with the grouping)
  • A text annotation is a shape which contains a label and can be attached to any DMN element

Custom types and variables

Input data, decision and business knowledge model elements all have an associated variable, which is of a given type (string, number etc., or custom). A variable is a handle to access the value directly passed by an input data element, or calculated by the implementation of a decision or a business knowledge model, from within the decision implementation.

Custom types may be defined to group multiple properties under a single type name (with structure) or to allow variables which will hold multiple values (arrays).

Boxed Expressions

A few constructs are available to provide an implementation for a decision or a business knowledge models; they are termed boxed expressions since such expressions are shown in boxes which have a normalized representation. The following types of boxed expressions are available in DMN 1.3:

  • Literal expression: this is a simple expression which can use the available variables to calculate a result
  • Context: this is a set of entries, each combining a variable and a boxed expression. Each entry in the context can use the variables of the entries defined before it, which is like using “local variables” in some languages
  • Decision table: this is a tabular representation where rows (called rules) provide the value of outputs (supplied in action columns), depending on the value of inputs (supplied in condition columns)
  • Function: a function can be called using an invocation, by passing arguments to its parameters. The result of a function is the result of the execution of its body (which is an expression that can use the values of the passed parameters). A Business knowledge model can only be implemented by a function
  • Invocation: this is used to call a function by name, by passing values to the function’s parameters
  • List: this is a collection of values calculated from each of the boxed expressions in the list
  • Relation: this is a vertical list of horizontal contexts, each with the same entries

In addition to these, SMARTS defines an additional boxed expression, called the rule set. This is a set of named rules, where each rule is composed of a condition (an expression evaluating inputs) and action (an expression providing some values to outputs).

Helping Industry Adoption

With SMARTS Ushuaia, decision models are first-class citizens. The full compliance with DMN 1.3 means that all the DMN elements and boxed expressions, as well as the ability to interchange diagrams with other tools, are part of the package.

As is usual, any model can be tested and executed in the same context as your SMARTS decision –a decision is never made in isolation, and a model is never used in isolation either. And of course, you will benefit from the great tooling we provide.

Finally, we at Sparkling Logic strongly believe that decision management technologies should be put in the hands of all business analysts. This is why we are part of the DMN On-Ramp Group, whose mission is to provide a checklist to help customers find the DMN tool to suit your needs, educate and raise awareness about DMN, and help with DMN compliance. For a great presentation of the group, check out here.


Sparkling Logic is a Silicon Valley company dedicated to helping businesses automate and improve the quality of their operational decisions with a powerful digital decisioning platform, accessible to business analysts and ‘citizen developers’. Sparkling Logic’s customers include global leaders in financial services, insurance, healthcare, retail, utility, and IoT.

Sparkling Logic SMARTSTM (SMARTS for short) is a cloud-based, low-code, AI-powered business decision management platform that unifies authoring, testing, deployment and maintenance of operational decisions. SMARTS combines the highly scalable Rete-NT inference engine, with predictive analytics and machine learning models, and low-code functionality to create intelligent decisioning systems.

Marc Lerman is VP of User Experience at Sparkling Logic. You can reach him at

If you envision modernizing or building a credit origination system, an insurance underwriting application, a rating engine, or a product configurator, Sparkling Logic can help. Our SMARTS digital decisioning platform automate decisions by reducing manual processing, accelerating processing time, increasing consistency, and liberating expert resources to focus on new initiatives. SMARTS also improve decisions by reducing risk and increasing profitability.

Software industry trends behind the digital transformation revolution

This article presents the three software industry trends driving the digital transformation revolution: DevOps, low-code / no-code automation, vertical integration with digital decisioning.


The pandemic changed tech priorities for many people both at work and home making a ‘hybrid’ work a top initiative. Where and how we do the work accelerated the need to improve customer digital experiences and efficiency across work, shopping, and everyday chores.

The data supports this new trend. The independent research firm Omdia compiled over 300 responses from executives at large companies indicated that working away from traditional offices will become the new norm. 58% percent of respondents said they will adopt a hybrid home/work. Even more interesting is that 68% of enterprises believe employee productivity has improved since the move to remote work.

Similarly, adoption of everyday on-line activities such as shopping, banking and entertainment further accelerated the pace of digital transformation. The need for improved applications increased the pressure on companies to relaunch efficient, friendly front-end customer apps with more intuitive UX. The back end now needs to support faster turnaround with the need to automate processes for the new on-line community of users demanding faster, cleaner, and more intelligent offerings.

To respond to this digital transformation, companies are rapidly adopting easy-to-use integrated enterprise software tools to optimize and accelerate development of these efficient digital products.

Several trends like DevOps, Low-code/automation and vertical integrations with integrated digital decisioning have emerged to help enterprises take the digital transformation journey faster and cheaper.


DevOps is a software development concept bringing together historically disconnected functions in the lifecycle of the software development. Traditionally, business analysts would define the problem, developers would interpret the concept and build applications, and operations teams would test, report bugs and provide feedback. The disconnect between the functions, silo’d approach created inefficiencies, increased costs and slowed down application releases.

The emergence of integrated tools and processes which integrate this multiple aspect of software development and promote collaboration between these different functions supported growth of the DevOps industry.

In fact, the market data shows that these trends are supported by the investment community and exit activity. According to Venture Beat, in 2Q 2021, Venture funding for global DevOps startups reached $4 billion and the exit activity deal value was dominated by the IPOs of UiPath (robotic process automation) and Confluent, (data / application integration platform).

Low code / no code automation

Application development is also coming closer to non-developers with low/no-code approach and automation.

Software engineering, traditionally owned by IT and software engineers, has always been coveted by other, non-IT stakeholders in the enterprise. In 1991, Powerbuilder introduced a revolutionary concept of a development framework, aiming at democratizing development by allowing non-software professionals to get access to application development. Perhaps ahead of its time with clunky UX, WYSIWYG, Powerbuilder started the revolution of introducing emergence of ‘citizen-developers’, people who originally participated alongside IT in shaping the application and business models but could not code and create the applications themselves. It also introduced data integration with application logic and object-oriented concepts like inheritance and polymorphism and encapsulation, bringing software engineering to the masses.

Fast forward to 2020’s, virtually every enterprise tool platform and enterprise customer have adopted a low-code/no-code approach. The mission is the same as 30 years ago – to provide easy to use, graphical UI/UX, drag and drop concept to application development and allow business analysts, ‘citizen-developers’ and non-software engineers to create, test and even deploy enterprise applications.

Vertical integration with digital decisioning

The perennial challenge of allowing non-developers to create applications is the conundrum of how deep they can develop without coding and to what extent they can customize complex enterprise cloud applications without IT and coding.

To accelerate digital transformation, enterprise software vendors are emerging mostly from the workflow / BPA world, such as Pega and ServiceNow. They are applying a two prong approach – core tool collection and vertical integration. The workflow vendors have developed (or acquired) a collection of point tools in a core-component framework. Those components typically include AI/ML, reporting, workflow, RPA (Robotic Process Automation), case management, rules engine, decision management, knowledge bases, BPA (business process automation) and process orchestration. Those components typically feature common UI and work across a normalized data model and unified architecture.

But that is not enough. To satisfy modern rapid digital transformation needs, in case of fintech enterprise customers (i.e. banks, insurance companies and financial services) also now require pre-built workflow, data and application models. These vertical templates are higher level and more specific, providing out-of-the box, drag/drop solutions like credit card operations, loan management and payment operations. Using the low-code approach, a business analyst can graphically drag/drop pre-defined steps into a loan origination workflow with pre-defined commonly used tasks, created using best practices defined by the ‘centers of excellence’. Companies like UIPath have created a 3rd party marketplace for additional steps and templates created by analysts and consultants. (Those steps could be ‘get customer data’, ‘OCR input form’, ‘scrub customer data’, authorize user’, ‘assess risk profile’ etc.).

Beyond the top level tasks, the functionality ultimately becomes more complex and the sophisticated customer needs powerful decision capabilities to introduce their own business rules and implement proprietary features. The ‘secret-sauce’, which separtes most common steps from proprietary concepts distinguishes top corporations from the competition, requires more sophisticated digital decisioning tools. These digital decisioning tools enable non-developers to customize and manage decision logic, implement AI/ML features, run A/B testing and visualize performance results on training and production data in real time.

To satisfy most common customer base, digital workflow vendors typically provide rudimentary business rules integrated in their low-code platforms and further integrate them with the downstream workflow platforms and vertical ecosystem vendors (i.e. FiServ, Jack Henry, SAP, Salesforce and FIS in banking for example).

The most sophisticated and demanding customers, however, need a more sophisticated set of digital decisioning tools like standalone professional DM platforms. To simplify and visualize this complex decision management, a new generation of low-code digital decision management platforms like Sparkling Logic emerged. These platforms integrate historical business rules engine, data and AI, demystifying machine-learning and providing low-code approach to development and monitoring of application logic performance, continuously as the business logic and training data change and drift.

The pandemic, hybrid work and pervasiveness of the cloud computing have irreversibly changed the software application development. Enterprise customers are seeking and deploying better, faster, more integrated software tools. DevOps integration, low-code, vertical templates, integrated AI and digital decisioning are becoming a new normal while defining the next generation of applications, created not only by software engineers, but by mere mortals across the enterprise.


Davorin Kuchan is the CEO of Sparkling Logic, Inc, an AI-driven digital decision management enterprise tools platform. Major enterprise customers like Equifax, Centene, First American, Nike, SwissRE and Enova deploy and integrate Sparkling Logic SMARTS digital decision engine. Sparkling Logic, Inc is based in Sunnyvale, California.

Business Decision Management (BDM) vs. Business Process Management (BPM)

Regardless of its market, in order to thrive, a business must manage its daily operations through well-defined, executed, and controlled processes and decisions. The top performers automate both with business process management (BPM) and business decision management (BDM).


Generally speaking, BPM is the set of technologies that automate processes of an organization, that is to say the stages through which the organization passes. Often, the stages include data entry, transformation, and enrichment. Then data activation, exploitation, and reporting. On the other hand, BDM is the set of technologies that automate the multitude of operational decisions of an organization. The number often varies from hundreds to thousands, and sometimes millions of times a day.

As is always the case in technology, there is no clear distinction between BPM and BDM. Suppliers of both technologies operate in both markets, and companies combine them to maximize the benefit of each technology. The purpose of this article is to draw a line between the two technologies through an example from subscription-based businesses such as Amazon Prime, Netflix, and WSJ, and a second example from life, property, and causality insurances.

Processes and decisions

Subscription-based businesses such as those listed above take the form of a billing relationship with a starting subscription event, a continuous servicing or insuring process, and an eventually un-subscription event.

Figue 1: Simplified lifecycle of subscription to a media showing both BPM and BDM Figue 1: Simplified lifecycle of subscription to a media

Figure 1 presents a high-level view of the processes and decisions that take place behind the websites of Amazon Prime, Netflix, and WSJ. Figure 2 does the same for the life, property, and causality insurances. When you take a close look to the diagrams, you may wonder what a process is and what is a decision. In fact, both are taking place within these two examples.

Figure 2: Simplified lifecycle of subscription to an insurance, showing both BPM and BDM Figure 2: Simplified lifecycle of subscription to an insurance

The key difference

The processes are stable enough in the sense that they do not change, because they are independent of each situation and indeed of each data. Whether it is a media or an insurance, the company always starts by prospect acquisition, then customer activation, and then customer management.

On the other hand, the decisions change too often, depending on the situation captured through data. Take the subscription to a streaming media (Figure 1). Ending the contract can be a tricky decision. Should the media end the contract the date of the subscriber’s call to cancel? Or should it try to propose a discount to keep the subscriber? Should the media recall subscribers who have not paid their last bill? A week or two weeks after the due date? These are the typical decisions that separate the media from each other. Each media has its own specific way to investigate customers when the relationship has ended.

Now, take the subscription to a car insurance (Figure 2). The insurance, like any other insurance competing for the same policies, searches to augment its business. But at the same time, it wants to reduce its risks. So decisions are more complex than in the case for a media. The subscriber may not be eligible for different reasons and to decide, third-party data may be needed. Also, the subscriber may present different risks depending on the age, car, and accident history. So the insurance has to take another series of decisions: Compute a risk level, then a price that hedges the risk.

In short, the processes are what make a company belonging to an industry, the decisions are what make the company unique in this industry.

BPM, BDM, and standardization

Under the pressure of competition on the one hand and regulation on the other, many service companies have realized the importance of separating decisions from processes. Until recently, they were nested. Leading this trend, the Object Management Group (OMG) has published two recommendations (BPMN for the former, DMN for the latter), thus accelerating the emergence of BPM and BDM as two different yet complementary technologies.


In practice, BPM technologies are appropriate when the problem is centered on a document that must be co-signed by different stakeholders. For example, a loan contract that passes from the Sales to Finance, then to the Legal department, then back to the Sales, and finally to the client.

On the other hand, BDM technologies are more appropriate when the problem is centered on operationalizing decisions. For instance, evaluating the eligibility for a loan, accepting or rejecting the application, and so on.


  • Regardless of its market, in order to thrive, a business must manage its daily operations through well-defined, executed, and controlled processes and decisions
  • Processes are what make a company belonging to an industry, decisions are what make it unique in this industry
  • BPM is the set of technologies that automate processes, that is to say the stages through which the organization passes. BDM is the set of technologies that automate the daily decisions
  • In practice, BPM technologies are appropriate when the problem is centered on a document that must be co-signed by different stakeholders. BDM technologies are more appropriate when the problem is centered on operationalizing decisions


The statements in this article belong solely to the author. The article was not reviewed nor endorsed by any company or organization mentioned. You can send your comments to the author at

Technical Series: Decision Management Platform Integrations

DMNDecision Management and Business Rules Management platforms cater to the needs of business oriented roles (business analysts, business owners, etc.) involved in operational decisions. But they also need to take into account the constraints of the enterprise and its technology environment.

Among those constraints are the ones that involve integrations. This is the first series of posts exploring the requirements, approaches and trade-offs for decision management platform integrations with the enterprise eco-system.

Why integrate?

Operational decisions do not exist in a vacuum. They

  • are embedded in other systems, applications or business processes
  • provide operational decisions that other systems carry out
  • are core contributors to the business performance of automated systems
  • are critical contributors to the business operations and must be under tight control
  • must remain compliant, traced and observed
  • yet must remain flexible for business-oriented roles to make frequent changes to them

Each and every one of these aspects involves more than just the decision management platform. Furthermore, more than one enterprise system provides across-application support for these. Enterprises want to use such systems because they reduce the cost and risk involved in managing applications.
For example, authentication across multiple applications is generally centralized to allow for a single point of control on who has access to them. Otherwise, each application implements its own and managing costs and risk skyrocket.

In particular, decision management platforms end up being a core part of the enterprise applications, frequently as core as databases. It may be easy and acceptable to use disconnected tools to generate reports, or write documents; but it rarely is acceptable to not manage part of core systems. In effect, there is little point in offering capabilities which cannot cleanly fit into the management processes for the enterprise; the gain made by giving business roles control of the logic is negated by the cost and risk in operating the platform.

In our customer base, most do pay attention to integrations. Which integrations are involved, and with which intensity, depends on the customer. However, it is important to realize that the success of a decision management platform for an enterprise also hinges on the quality of its integrations to its systems.

Which integrations matter?

We can group the usual integrations for decision management platforms in the following groups:

  • Authentication and Access Control
  • Implementation Support
  • Management Audit
  • Life-cycle management
  • Execution
  • Execution Audit
  • Business Performance Tracking

Authentication and access control integrations are about managing which user has access to the platform, and, beyond that, to which functionality within the platform.
Implementation support integrations are those that facilitate the identification, implementation, testing and optimization of decisions within the platform: import/export, access to data, etc.
Management audit integrations enable enterprise systems to track who has carried out which operations and when within the platform.
Life-cycle management integrations are those that support the automated or manual transitioning of decisions through their cycles: from inception to implementation and up to production and retirement.

Similarly, execution integrations enable the deployment of executable decisions within the context of the enterprise operational systems: business process platforms, micro-services platforms, event systems, etc. Frequently, these integrations also involve logging or audit systems.
Finally, performance tracking integrations are about using the enterprise reporting environment to get a business-level view of how well the decisions perform.

Typically, different types of integrations interest different roles within the enterprise. The security and risk management groups will worry about authentication, access control and audit. The IT organization will pay attention to life-cycle management and execution. Business groups will mostly focus on implementation support and performance tracking.

The upcoming series of blog posts will focus on these various integrations: their requirements, their scope, their challenges and how to approach them.

In the meantime, you can read the relevant posts in the “Best Practices” series:

How to $ucceed In Business Rules Without Really Trying


Three ways you can make sure your business rules projects succeed!

Finch, in the broadway musical “How to Succeed in Business Without Really Trying”, rises to the top of the World Wide Wicket Company by following the advice in the book.  Perhaps you won’t rise to the top of your company by following the advice in this blog post, but a little guidance can go a long way in keeping your business rules projects on track!
Read More »

Intelligence in the Cloud

The Cloud is one of the top priorities for most CIOs.  They want to better understand the risk and the opportunities.  This disruptive technology is forcing both technologists and business owners to think outside the box, to take real advantage of the “new way” of doing things.


Being Sparkling Logic, we have been thinking pretty hard about it for a couple of years.  BPM has been an interesting case study for Decision Management on the Cloud, as it is a sister technology with a wider adoption in the Enterprise world, and, predictably, a wider mind-share in Cloud solutions.  My objective here is to share some of the key benefits that the cloud certainly brings to Decision Management practitioners. This is a topic that I have seen popping up in some forums, and also the main theme this year for IntelliFest, the new name for the Rules Fest conference, to reflect its wider scope on Artificial Intelligence.

Why the Cloud?

Have not heard it a thousand times already?  I am pretty sure I am not saying anything new here:

  • It’s easy to get started: Software-as-a-Service is all about having the infrastructure ready for your usage.  You get a login and password and you’re all set.  No more IT to work with for procuring the equipment and software.  No more internal delays.
  • Opex versus Capex: this is indeed a financial argument but it plays a role in your budgeting decision.  Cloud subscription means that you can pay as you go, based on your needs.  You can start small and then, over time, add usage as you need it.  This is a business model change that is not tied to the technology evidently, but it is expected that you can do that with Software-as-a-Service.  Given the current economic situation, it is only fair that organizations want to be more cautious about the rate of adoption.  What used to be “one project then expand” is becoming “one seat then expand”.
  • Elasticity: it is the equivalent argument on the IT side.  Many projects starts with a painful discussion on sizing…  Sizing is hard because of the so-many unknowns.  In the end, it often boils down to someone putting a stake in the ground and hoping for the best.  Truth is usage is something that evolves through time, so having the flexibility to adjust to the added capacity by the click of a button, rather than IT having to upgrade equipment.  That works for scaling up and down by the way.
  • It is secure…  yes, really!  There has been tons of arguments about security in the Cloud.  The reality is that the Cloud has to be secure.  The media would make a mess for every instance of a security breach on those servers.  In fact, it has been said that the Cloud was actually more secure than private facilities.  For some reason, I believe I might get some push back on that one!
  • It feeds off Big Data: Being on the Cloud, it is no surprise that Big Data is just a click away.  SaaS products are so much more ready for harnessing Big Data.

What is driving the Cloud adoption for BPM?

As I see it, BPM mostly gained acceptance on the Cloud for its collaborative capabilities, albeit mostly for capture and modeling purposes.  Being able to quickly get started with no IT intervention is highly valuable even with such a restriction.

In fact, many of the BPM vendors on the Cloud do not really focus on execution.  The perceived value is on business process capture or authoring.  Some refer to the “walk before you run” analogy.

Think about it, there are so many processes that are hardly documented.  Visio only helps organizations so much in getting things well documented.  Having the opportunity to collaborate with no or little set-up brings a bunch of value to the organization.

Running business processes on the Cloud is certainly doable technically but still limited to fewer projects.  Why?  My guess is that most businesses are either worried about outsourcing their operations on the Cloud, or simply are not ready to do so. It could also be because the data required to run on the cloud is not available there, for reasons ranging from practical to corporate policy-driven.

Why is Decision Management behind?

BPM has been much ahead of BRMS and Decision Management technologies.  Though the arguments for BPM technically would equally apply to Decision Management, there is a key difference in the application of the technologies.  I may not go as far as Boris in his BI-CRM comparison…  I am actually very optimistic on the Cloud uptake for those technologies, but I think that he has a very good point, or maybe a couple.

First of all, and this is shared with BPM and other Enterprise tools technologies, there has been few efforts to create dedicated cloud-based Decision Management tools. Software-as-a-Service is much more complicated than putting “cloud” lipstick on a pig.  Software that is not architectured to be horizontally scalable, elastic, multi-tenant, etc. can be thrown “out there”, but it won’t really work with the needs and expectations of those adopting the cloud. It’s not just administration and management that need to be made as simple as consumer applications. The awkward usability and necessary complex “set up” that many quickly put together cloud solutions require are, in my opinion, much bigger issues.

Second, decision management requirements are still hard to formulate for prospective users, and availability of the technology on the cloud does not change that fact.  Partially, this is because Decision Management is new to many industries; and partially because the needed interactions are still new to the industry, that has been feeding of the idea that IT would be there for a big deal of customization.

Those are some of the “excuses” for Decision Management being new to the Cloud.  I don’t think that they represent barriers that will limit its adoption going forward though, as the stakes are significant enough to make those initiatives appealing to the traditional consumers of those technologies, but also eventually to a much wider audience.

I think that Decision Management is following a similar trajectory as BPM in terms of cloud adoption. Though some users are already jumping on the Cloud for the execution of their Decisions, a great deal of opportunities lies in simply capturing and refining collaboratively the business rules in a “business-ready” environment which is greatly simplified by the Cloud.

To learn more, join us at IntelliFest.
Carole-Ann will address this very topic in more details.


Want to know how strongly I feel about it?  Check my video:


Decision Management Rumors Confirmed

Did you guess right on the acquisition rumors that were spreading at BBC 2011 this year?

CorticonCorticon announced today its acquisition by Progress software.  One more independent vendors ends up in the heart of a BPM and more platform.  This is a great validation for BRMS technology.  You can’t really fit all decisioning logic into process maps without crowding them.  Another interesting conclusion is that CEP did not suffice either in the BPM platform.  The quotes from the announcement were pretty telling:

Dr. John Bates, chief technology officer, Progress Software said: “Within modern responsive businesses, the need to make informed and accurate decisions ‘in the moment’ is critical. High quality real-time decisions are key to avoid fraudulent transactions, to comply with complex and evolving regulations and to generally make the right decision for the business at the right time. The acquisition of Corticon reinforces Progress’ commitment to deliver operational responsiveness by helping customers build highly agile, responsive business systems with models and tools that maximize simplicity and accelerate time-to-value.”

Dr. Mark Allen, founder and former chief executive officer of Corticon, now a member of the office of Progress’ CTO, added: “[…] rules alone are sometimes not enough; to meet the holistic needs of customers, a number of technology areas need to converge […]”

Effective Decision Management is all about Agility and Simplicity.  I wholeheartedly agree with that!

Congratulations, Mark!

More Business Rules Consolidation?

Do you remember the buzz at Business Rules Forum 2008 when RulesBurst / Haley did not show up?  We all suspected an acquisition and soon got confirmation of the suspicious absence of this “regular” at the show.  They had been acquired by Oracle.

This year again, one of the usual suspects did not come and, since then, the industry has been buzzing quite a bit.  Well, technically the company was there, but the leadership team was not.  We have reasons to believe that our colleagues have been acquired by another platform vendor.  Do not look for the big names though.  It is quite interesting to see the growing presence of BPM / CEP vendors in the Decision Management space, fast acquiring business rules capabilities…

let’s wait and see how long it will take for the rumor to turn into a formal announcement!

On the BRMS side though, we are left with fewer and fewer independent vendors.  This puts more pressure on the vendor locking issue.  The standards are not nearly mature enough to allow for interplay between the rules vendors — which has not been a burning issue up to now.  But as BRMS are becoming an integral part of the entire platform, the initiative of swapping them becomes less of a per-project decision…  and as a result, the current investment in business rules assets might require a port from platform A to platform B, meaning from BRMS A to BRMS B, as companies standardize on those ecosystems…

What are the outlets?  Investing on interoperability standards is the long road.  My personal inclination would be to take a better look at decision modeling environments — but I am biased of course 😉

© 2022 SparklingLogic. All Rights Reserved.