Authors: Brandon Duong, Divya Divya, Matthew Panizza
IBM Business Automation Team
Enterprises face millions of critical decisions every day, from daily operations to strategic planning. Accurately evaluating these decisions is crucial to a business’ success, yet many still rely on hardcoded logic, spreadsheets, or undocumented processes. Decision Services offer a better path: modular components that encapsulate decision logic in business-friendly rules, models, and tables. Decision Intelligence (DI) enables the development, deployment, and execution of these services through visual modeling, low-code tools, and other integrations. This allows business and technical teams to seamlessly contribute without the need for a technical developer. This blog explores what makes Decision Services the better solution and how DI achieves this, using a banking loan example to showcase efficient decision automation.
Why Decision-Making at Scale is Harder than it Looks
To understand Decision Services, we must first understand decisions themselves. The two types relevant to Decision Services are strategic decisions and operational decisions. Strategic decisions are the more complex of the two, focusing on the overall outcome of the business and following business strategies and regulations. These determine the long-term direction, vision, and overarching goals of the organization. Operational decisions are decisions that are frequently made as part of day-to-day business activities in support of strategic goals.
these decisions can be very complex, demanding consistency, rapid adaptation, and control. For consistency, the outcome of a decision must be the same across various operational areas. Rapid adaptation refers to adapting to constantly changing business requirements. Control i closely related to rapid adaptation and is about not requiring IT dependency over the decision-making process. Finally, complexity is in terms of how these decisions involve multiple internal and external factors and data sources. Now that we know the difficulties with these decisions, let's investigate how businesses traditionally handle them.
previously mentioned, existing solutions heavily rely on hardcoded logic within software applications, embedded in processes, documented in spreadsheets, or completely undocumented. These primitive approaches lead to slow adaptation, poor visibility, and a lack of transparency (Figure 1). Essentially, business experts are unable to see, edit, or audit these rules without the help of IT as the application code is inaccessible. With this in mind, we can now explore how Decision Services bridge the gap between business and technical experts.
Figure 1 – How traditional approaches can hinder outcomes.
Decision Services: Integrating the Logic
When building a Decision Service, you typically combine several elements: inputs, decisions, calculations, and outputs (Figure 2). By centralizing this logic into reusable components, you avoid scattered rules across applications and spreadsheets.
Business users can read and manage decision logic through clear tables and visual models, while applications simply invoke the service. Every outcome is traceable back to the data and rules that produced it, making governance and auditing straightforward. This separation also allows teams to update decisions without modifying application code, improving collaboration between business and IT.
Figure 2 – A decision flow intuitive to business users.
You don’t have to use every component in every service, but together they give you a single environment where data, flow, rules, and AI work as one. Every decision you envision can be created. Under the hood, a Decision Service rests on four building blocks:
First, a scalable data model establishes a single schema for all inputs and outputs. Simple values and complex objects can coexist, and once defined, the same data structures are reused across the entire service.
Next, decision define how the decision is executed. Visual models connect inputs, calculations, and final decisions in a clear sequence, making it easy to understand how outcomes are produced.
Finally, decision logic determines what happens at each step. Rules, decision tables, natural‑language expressions, and calculations work together to produce consistent, explainable results. Where appropriate, AI models can be introduced to handle human-like responses, predictions, or unstructured data.
Together, these components (data, flow, logic, and AI) form a unified system in Decision Intelligence (Figure 3). They make it possible to build accurate, transparent, and auditable Decision Services for any business scenario.
Figure 3 – Core components of Decision Intelligence.
Now that we know a little bit about the components, we have a great starting point for creating a real-world example. Let’s explore a real-life business scenario and observe how Decision Intelligence will improve service operations for business users and citizen developers.
Example: Creating a Loan Approval Process
A concrete way to see how these components fit together is to walk through a single use case. Imagine you’re a citizen developer at a bank, and the goal is to automate loan approvals. You want them to be faster and more auditable. First, start with the data.
Consider the following data objects:
In this data schema, we have created custom objects and composed them. For example, the “Bankruptcy” object with its three sub-properties. Then, the “Bankruptcy” object can be integrated into a “Borrower” object using composite types. That schema becomes the single source of truth for the rest of the service. The decision model, the rules, and the tables all refer to the same structure, so business, compliance, and IT are aligned on what “Bankruptcy” and “Borrower” mean.
Next, you design the flow. In the decision model, you choose the initial input (the application data), add nodes for the calculations you need (e.g. salary score, corporate score, grade) and wire them together. Here, the path from input to final decision is obvious. The diagram is visual and intuitive: distinct node types for data and decisions, with sub-calculations where they make sense (Figure 4). Both business and technical users can understand it and modify it.
Figure 4 – Decision node in the Decision Intelligence user interface.
The actual approval logic lives in decision tables and business rules. Decision tables are simply truth tables that produce a result given a range of inputs. Likewise, business rules express conditions in plain language with full alignment to the data model. TheyIf you are choosing a business rule, you can use a human-readable language called Business Automation Language (BAL). Here, you use English-like code to set rules, with rule suggestions provided if you need a place to start (Figure 5).
Figure 5 – Using natural language to make decisions in Decision Intelligence.
Finally, you can include an AI layer context, prompts, variables, and examples to produce summaries. You can also feed scores from predictive models into the same decision flow, producing numeric predictions.
The result is one coherent service that:
Decision Services and Decision Intelligence give organizations a way to move decision logic out of code and spreadsheets and into modular, auditable components decision flows, and AI fit into one coherent service. As more enterprises adopt these practices, getting the foundations right is a clear step toward better outcomes and transparency.
In this blog, we left out a couple of topics. The following topics were mentioned, but never explained in detail:
While we did not have room to cover these specific components of Decision Services, they will be covered in future blogs and webinars.
Here is a list of upcoming blogs and webinars with their dates:
-
Unlock the value from unstructured data decisions with Gen AI (Blog)
Notes: This blog will cover the topic of Task Models.
-
How AI/ML and Decision Automation Work Together in DI (Webinar)