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 the part of software and data systems that expresses the policies or rules that produce a desired business outcome. Perhaps it’s a colloquial way of putting it: business logic is the part of a software program that the company cares about most; everything else is the part that engineering cares about the most.

If you’ve been around 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 talking about programming language resources; AI, ML or statistical models; or enterprise architecture diagrams, process flow diagrams or data models.

While many of these things may represent business logic, the truth is that they are not business logic. On the contrary, business logic is about the expectations, results and objectives that the software, automation or data process needs or wants to achieve.

Here’s an example: Suppose we have an offer for high profile customers and it needs to be programmed into a pricing system. If a customer spends more than a certain amount on direct purchases from stores in any of the 3 zip codes for 30 days, they are entitled to a 15% discount because they are a premium customer.

Now that we know what business logic is and what it can bring to the business, let’s ask why it matters, what the best options are and where it should be in the company.

Why does it matter?

Simply put, our highly connected, interconnected world has turned traditional approaches on their head. In the past, where information was precious 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 plentiful and segmented. So business logic was achieved in a much smaller context.

Today, the world looks very different and is rapidly being replaced by dense connectivity and often little asymmetric information benefit related to an organization’s customer. Context for business logic has become the entire enterprise and/or entire customer journey rather than an isolated moment of that journey. The customer knows as much, if not more, than you know, which means business logic management needs to be transformed as well.

What are the options?

For many, the first thought is to rely on AI to replace business logic and make the problem go away. While attractive, doing nothing and relying on AI to solve the problem is not a viable option.

Consider, for example, the question of who proposes and who responds. Machine Learning (ML) can help find statistical symmetries and associations in the data, enabling organizations to make certain business decisions based on these patterns. The problem is that they are descriptive and reactive rather than prescriptive and proactive.

After all, the data can’t tell you what it doesn’t know. Nor can it provide a solution if something other than a matter of historical patterns and associations is to be done. Sometimes the best approach is to be creative, do something new and take a risk. Other times we have to be spot-o – and the past isn’t always a reliable textbook. Complicating things further is that pattern matching always fails the first time.

Where to store business logic?

When it comes to where to store business logic, there are countless contenders. None are ideal for the long term. However, the “future” is just around the corner: Enterprises are building knowledge graphs to unify data, power analytics and insight engines, and gain better insight faster. So while not ideal, the following approaches to business logic offer some valuable insights into lessons learned:

• Documents: Putting 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 convinced readers. It boils down? They are a good way to build and establish support for business logic, but they are not a business management tool.

• Code: If it’s not in documents, why not just put business logic in code? Seems plausible because at some point business logic is eventually implemented in or by computers instructed in some way by programming languages. But business logic can’t live in code because that’s only really accessible to/for programmers. To effectively manage business logic, business leaders need to see it as expressed and shared publicly. It boils down? The debate must end: code is for coders; business logic is for the business.

• Unified Modeling Language (UML): This is a fine tool and in large enterprises it is one of those areas where business logic will spend time. However, there are two fundamental problems with UML. The first is the lack of words. Where UML visualizes the architectural blueprints of a system in a diagram and is more like a PowerPoint, it is really just a nice substitute rather than an actual/concrete (written) thought. Second, most software engineers hate UML. So while transferring business logic to programmers by embedding it in code isn’t an ideal solution, alienating them by embedding it in an artifact they despise isn’t an option either. It boils down? 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 the other places mentioned above. In fact, stored procedures can exist as a sort of compromise between the “biz logic in code” and “biz logic in the database” divisions. Although stored procedures are in the database, they are actually code. At least nothing is broken that isn’t already a function of RDBMS’ fundamental brokenness. Rather the interplay of the superiority 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 built on the wrong abstraction is why putting business logic into “the” database is not the best approach. It boils down? While the approach may be acceptable, the relational model is out of order, meaning business logic disruptions will only get worse over time.

So where does this leave us?

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

Given the extensibility of semantic knowledge graphs, it makes sense to embed business logic there because of contextual awareness, reuse, and other factors.

The reality is that business logic ends up in lots of places. The real concern is how to do it, where to come from and what its life cycle is. Documents, code, UML diagrams, and database components are all perfectly reasonable as compilation targets for business logic that, as logic, is expressed, managed, and stored in a knowledge graph.

Navin Sharma is vice president of product at Star dog.