What business logic is and where it should live

Let’s talk about business logic.

But first, let’s make sure we know what it is. Business logic is that part of software and data systems that expresses the policies or rules that achieve a desirable business outcome. Perhaps an informal way of putting it: business logic is the part of a software program that is most important to the business; The rest is the part that the tech takes care of the most.

If you deal with technology, you know that business logic is crucial. What I want to ask today is: Where should it live? To be clear, when I talk about business logic, I’m not referring to programming language resources; AI, ML or statistical models; or enterprise architecture diagrams, process flow diagrams or data models.

While many of these things can represent business logic, they are actually not the same as business logic. Rather, business logic is all about the expectations, outcomes, and goals that the software, automation, or data process needs or wants to achieve.

Here’s an example: Imagine we’re running a promotion for premium customers and it needs to be programmed into a pricing system. If a customer spends more than a certain amount on direct purchases in stores in one of 3 zip codes over a 30-day period, they are eligible for a 15% discount as a Premier customer.

Now that we know what business logic is and what it can offer the business, let’s ask ourselves why it’s important, what are the best options, and where in the business it should be used.

Why does it matter?

Put simply, our highly connected, interconnected world has turned traditional approaches on their head. In the past, when information was expensive and asymmetric, it was easy for companies to perform customer segmentation to identify specific customers, create relevant customer experiences, and develop communications much more comprehensively. Context was abundant and segmented. So the business logic was achieved in a much smaller context.

Today the world is very different and is quickly being replaced by dense connectivity and often little asymmetric information advantage in relation to a company’s customer. The context for business logic has become the entire enterprise and/or customer journey, rather than an isolated moment in that journey. The customer knows just as much, if not more, than you do, which means managing the business logic has to change too.

What are the options?

For many, the first thought is to rely on AI to replace the business logic and eliminate the problem. While it’s appealing, doing nothing and relying on AI to solve the problem isn’t a viable option.

For example, think of the question of who proposes and who responds. Machine learning (ML) can help find statistical symmetries and associations in the data, allowing companies to make some business decisions based on these patterns. The problem is that they are descriptive and reactive as opposed to prescriptive and proactive.

After all, the data can’t tell you what they don’t know. Nor is it able to offer a solution when what should be done is nothing more than a question of historical patterns and associations. Sometimes it’s best to be creative, do something new and take a risk. Sometimes we have to look closely – and the past is not always a reliable guide. To make matters worse, pattern matching always fails the first time.

Where should business logic be stored?

When it comes to where to store business logic, there are numerous competitors. Neither of these are ideal in the long term. However, the “future” is on our doorstep: companies are building knowledge graphs to unify data, strengthen analysis and insight engines, and get better insights, faster. While not ideal, the following business logic approaches offer some valuable insight into the lessons learned:

• Documents: Injecting business logic into documents has worked for decades, largely because there were no other options. These carefully arranged sentences and paragraphs created an argument, provided evidence, and persuaded the readers. bottom line? They are a good way to create and establish acceptance for the business logic, but they are not a business management tool.

• Code: If not in documents, then why not just put business logic in code? Seems plausible because business logic will eventually be implemented in or by computers that have been instructed in some way by programming languages. But business logic can’t live in code because that’s really only accessible to programmers. To effectively manage business logic, business leaders must be able to express and share it publicly. bottom line? The debate needs to end: code is for programmers; Business logic is for business.

• Unified Modeling Language (UML): This is a good tool, and in large companies, it’s one of those areas where business logic spends time. However, there are two fundamental problems with UML. The first is the lack of words. Where UML visualizes a system’s architectural blueprints in a diagram and is more like a PowerPoint, it’s really just a pretty surrogate and not an actual/concrete (written) thought. Second, most software developers hate UML. So while letting programmers handle the business logic by embedding it in code isn’t ideal, it’s also not an option to alienate them by embedding it in an artifact they despise. bottom line? UML is useful and not the worst choice, but not the best either.

• Databases: We all know that business logic lives in databases, just like in the other places mentioned above. In fact, stored procedures can exist as a kind of compromise between the “business logic in code” and “business logic in database” departments. Although stored procedures reside in the database, they are actually code. At least there’s nothing broken about it that isn’t already a function of the fundamental brokenness of RDBMS. Rather, the interplay between the supremacy of the relational data model and its leakiness as an abstraction, which is the problem with almost everything in data management. Putting business logic into a system based on the wrong abstraction is why putting business logic into “the” database isn’t the best approach. bottom line? While the approach may be acceptable, the relational model is broken, meaning the business logic distortions will only get worse over time.

So where does that leave us?

Due to the limitations of the above approaches, many will believe that the business logic should live in the data model, and these individuals leverage knowledge graphs to serve as the necessary abstraction. Since business logic really is logic, it’s no surprise that many find its natural place in declarative data management systems like a knowledge graph.

Given the extensibility of semantic knowledge graphs, embedding business logic there makes sense due to its context sensitivity, reuse, and other factors.

The reality is that business logic ends in numerous places. The real concern is how it’s supposed to happen, where it’s supposed to come from, and what its life cycle is. Documents, code, UML diagrams, and database components all make perfect compilation targets for business logic that is expressed, managed, and stored as logic in a knowledge graph.

Navin Sharma is VP of Product at Stardog.