Join top executives in San Francisco on July 11-12, to hear how leaders are integrating and optimizing AI investments for success. Learn More
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 policy or rules that achieve some desirable business outcome. Maybe an informal way to put it is: Business logic is the part of a software program that the business cares most about; all the rest is the part that engineering cares most about.
If you’ve been around tech, you know that business logic is crucial. What I want to ask today is: Where should it live? To be clear, when discussing business logic, I am 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, the truth is that they are not the same as business logic. Rather, business logic is all about the expectations, results and objectives that the software, automation or data process needs or wishes to achieve.
Join us in San Francisco on July 11-12, where top executives will share how they have integrated and optimized AI investments for success and avoided common pitfalls.
Here’s an example: Imagine we’re running a promo for premier customers and it has to be programmed into some system for calculating prices. If a customer spends more than a certain amount over 30 days on direct purchases in stores located in one of 3 zip codes, then they are entitled to a 15% discount for being a premier customer.
Now that we know what business logic is and what it can deliver to the business, let’s ask why it matters, what the best options are and where it should live inside the enterprise.
Why does it matter?
Put simply, our heavily connected, interrelated world has up-ended traditional approaches. In the past, where information was costly and asymmetric, it was easy for businesses to perform customer segmentation to identify specific customers, create relevant customer experiences and develop communications much more copiously. Context was abundant and segmented. So business logic was achieved in a much smaller context.
Today, the world is much different and is swiftly being replaced by dense connectivity and, often, little asymmetric information advantage in regard to an organization’s customer. Context for business logic has become the whole enterprise and/or the whole customer journey rather than some insulated moment of that journey. The customer knows as much, if not more, than what you know, which means managing business logic has to transform 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 appealing, doing nothing and relying on AI to solve the issue is not a viable option.
For instance, contemplate the question of who proposes and who reacts. Machine Learning (ML) can assist with finding statistical symmetries and associations in the data, enabling organizations to make some business decisions based on these patterns. The trouble is, they are descriptive and reactive as opposed to being prescriptive and proactive.
After all, the data can’t tell you what it doesn’t know. It’s also incapable of providing a solution when what should be done is anything other than a question of historical patterns and associations. 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 dependable handbook. Complicating matters 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 numerous contenders. None are ideal for the long-term. However, the “future” is on our doorstep: Enterprises are building knowledge graphs to unify data, empower analytics and insight machines and get better insight faster. So while not ideal, the following approaches to business logic offer some valuable insights on lessons learned:
- Documents: Putting business logic in 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 readers. Bottom line? They are a good way to create and establish buy-in around business logic, but they are not an enterprise management tool.
- Code: If not in documents, then why not just put business logic into code? Seems plausible because at some point business logic eventually gets implemented in or by computers that were in some way instructed by programming languages. But business logic can’t live in code because that is only truly accessible for/to programmers. To effectively manage business logic, business leaders must be able to see it as expressed and shared publicly. Bottom line? The debate needs to 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 issues with UML. The first is the lack of words. Where UML visualizes a system’s architectural blueprints in a diagram and is more akin to a PowerPoint, it really is just a pretty substitute rather than actual/concrete (written) thought. Second, most software engineers hate UML. So while surrendering business logic to programmers by embedding it in code is not an ideal solution, alienating them by embedding it in an artifact that they despise is not an option either. Bottom line? UML is useful and isn’t the worst choice, but it’s not the best, either.
- Databases: We all know that business logic lives in databases, just as it does in the other above-mentioned places. In fact, stored procedures can exist as a kind of compromise between the “biz logic in code” and “biz logic in the database” divisions. While stored procedures are in the database, they are in fact code. At a minimum, there’s nothing broken about it that isn’t already a function of the fundamental brokenness of RDBMS. Rather the interplay of the relational data model’s pre-eminence and its leakiness as an abstraction, which is the problem with nearly everything in data management. Putting business logic into a system that is built on the wrong abstraction is why putting business logic into “the” database is not the best approach. Bottom line? While the approach may be acceptable, the relational model is broken, meaning distortions on business logic are only going to get worse as time goes by.
So where does this leave us?
Because of the limitations of the above-mentioned approaches, many will believe that business logic should live in the data model and those individuals are leveraging knowledge graphs to serve as the necessary abstraction. Because business logic really is logic, it’s no surprise that many feel its natural place is to reside 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 contextual awareness, reuse and other factors.
The reality is that business logic ends up in numerous places. The real concern is how it should happen, where it should come from and what its lifecycle 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 VP of product at Stardog.
Welcome to the VentureBeat community!
DataDecisionMakers is where experts, including the technical people doing data work, can share data-related insights and innovation.
If you want to read about cutting-edge ideas and up-to-date information, best practices, and the future of data and data tech, join us at DataDecisionMakers.
You might even consider contributing an article of your own!