Let’s talk about business logic. Where should it live inside the enterprise?
This questions matters because, increasingly, enterprises are struggling to transform themselves into institutions that can extract value from data, and, in that struggle, how business logic is managed is critically important, especially in a data fabric approach to data management. Which is to say, where should business logic live?
Maybe it’s clearer if we call it business policy instead of business logic? At least, I want to be clear what I’m not talking about when I say “business logic” in this article. When I talk about business logic, I do not mean any of these things:
- programming language artifacts
- data models
- AI or ML or statistical models
- enterprise architecture diagrams
Some or all of those things can be used to represent business logic, to be sure, but they are not the same things as business logic.
What I mean here are the assumptions, decisions, and goals that some software, automation, or data process relies upon or are intended to accomplish. Here’s an example of some business logic.
If a customer spends more than X dollars in Y weeks on goods or services in one of our stores in zip code AAAAA or BBBBB, then the customer will receive a 10% customer loyalty discount.
Where should those sorts of things live? How should IT manage all of the business logic?
Why Business Logic Placement Matters
The question of business logic placement matters because in the densely connected, interdependent world we’re building, old practices are being turned on their head.
In the old world, where information was costly and asymmetric, you could do things like customer segmentation to separate or isolate customers, customer experiences, and communications much more fully. Context was rich and deep and segmented. And so you could often consider business logic in a much smaller context, that is, in some particular offer, business line, or touchpoint with a consumer or trading partner.
But that world is rapidly being replaced by one of dense connectivity and, increasingly, little asymmetric information advantage vis-à-vis one’s customers. They know what you know; they may know more than you know. Now the context for business logic is, or is becoming, the whole enterprise or, indeed, the whole customer journey, rather than some relatively isolated moment of that journey.
That means that business logic management has to change, too.
Is AI/ML a Valid Option for Business Logic Placement?
First, it should be noted that waiting for AI to make this go away isn’t going to work. I know that it’s a tempting alternative: do nothing and things will just work out. Who doesn’t love that? But hopeful inactivity will not save you here.
Why not? Consider the question of who proposes and who reacts. Machine Learning will help you find statistical regularities and correlations in the data, such that you can base some business decisions on these patterns.
You should notice, however, these are descriptive and reactive, rather than prescriptive and proactive. The data can’t tell you what it doesn’t know. It can’t tell you what you should do when what you should do is anything other than a question of historical patterns and associations.
Sometimes we have to do a totally new thing and the past isn’t always a reliable guide. Sometimes we have to guess, be creative, experiment, take a risk. Sometimes we have to be right. Pattern matching always fails the first time.
Options for Business Logic Placement
There are many candidates for where we should store business logic. I don’t think any one of them is the right choice for the future, which is arriving right now, by the way, where enterprises build knowledge graphs to unify data and empower analytics and insight machines as part of their data fabric. But let’s discuss them anyway because there are lessons to be learned.
Does Business Logic Belong in Documents?
Maybe we can just put business logic in documents?
This isn’t actually as crazy as it sounds. It worked for hundreds of years, merely by virtue of the fact that we put everything, more or less, in documents because what else was there?
I will say that documents—you know, things that are composed of paragraphs that are composed of sentences, all of which are skillfully arranged into patterns of argument, evidence, and persuasion—are a perfectly good place for business logic to originate. They are in all ways better than adult business cartoons, i.e., PowerPoints.
TLDR: A good way to originate and build consensus around business logic; not an actual enterprise management tool.
Does Business Logic Belong in Code?
Then shouldn’t we just put business logic into code? After all, business logic eventually gets executed in or by computers that are in some way directed by programming languages. Absolutely true and also completely irrelevant.
Recall that what we’re talking about here is how we manage business logic at enterprise scale; our theme is not to list lots of places in which business logic, or its results, show up at some point. It does show up in documents and in code. But we can do better.
It’s worth noting, of course, that “put the business logic in code” is both a very old and a perpetually new idea. We could even say that it’s as old as Lisp, probably the oldest continuously used human programming language, and as freshly new as…Clojure. Sigh.
In a world in which everyone can program, this is still probably a bad idea. But we don’t live in that world. Much less do we live in a world in which everyone or even most people will think algorithmically. (Yes, I know what you are thinking, is there really a kind of thinking that isn’t algorithmic? Sudden flashes of insight aside, probably not. Draw your own conclusions.) And these lamentable facts mean that business logic can’t live in code because what lives in code is only truly real, that is, accessible, for and to programmers, i.e., people who are permitted to live in the code. Let’s not capitulate to that particular priesthood just yet.
TLDR: Code is for coders. Business logic is for the business. And these have always been at war, one with the other.
Does Business Logic belong in UML?
Having now made a pretty cogent, even if somewhat droll argument for UML and its ilk, I will tell you why I don’t think business logic should live there either.
UML is a fine tool and I have grown over the years to appreciate it more and more. And, certainly, in large enterprises UML is one of those artifacts where business logic will spend time.
However, there are two fundamental issues with UML that prevent me from recommending it enthusiastically.
First, as the smart person said, in the beginning was the word. My innate iconoclasm prevents me from being able to happily say that pictures can take the place of words in the public discourse of otherwise healthy, functioning adults. I am a fan and have been at times a reader and generator of various kinds of formal notation. I learned to read music at an early age and the notation of formal math and logic has a kind of majestic beauty that really does it for me. Alas, UML is in the end, that is, operationally, in my not-so-modest view, a kind of PowerPoint, i.e., a pretty substitute for actual thought and, more often than not, usually an ugly substitute.
Second, and quite more seriously, I’m not sure I’ve ever met a working software engineer who didn’t hate UML in her or his bones. While I do not believe we should capitulate the question of business logic to programmers by embedding it in code, I equally do not believe we should alienate them by embedding it in an artifact that they, by and large, despise.
TLDR: UML is more useful than I’ve described it here, and it isn’t the worst choice, but it’s not the best, either.
Does Business Logic Belong in Databases?
Now we’re getting warmer, but only relatively so. In truth, business logic, of course, lives in databases, just as it does in code and documents and in UML. Stored procedures may well exist as a kind of detente between the “biz logic in code” and “biz logic in the database” factions. Stored procedures are in the database, of course, but they are code-like and that’s frankly a pretty good compromise. At least, there’s nothing wholly broken about it that isn’t a function of the fundamental brokenness of RDBMS.
Yeah, that’s right. RDBMS or, more properly, the interplay of the relational data model’s pre-eminence and its leakiness as an abstraction, really is most of the problem with nearly everything in data management. Putting business logic into a system that is built on the wrong abstraction for the next twenty years is the main problem with putting business logic into “the” database.
TLDR: Abstractly, this is probably fine, except that the relational model is broken. Which means its distortions on business logic are only going to get worse as we go. It’s hard to be enthusiastic about systematic breakage.
Business Logic Belongs in the Data Model
Business logic should live in the data model. And, what’s more, it should live in the knowledge graph because that’s the right abstraction for the next twenty years. If you’ve been paying attention to this blog or to Stardog generally, then you must have known this is where we were going to end up.
Business logic is logic and, as such, its natural home is in declarative data management systems like a knowledge graph. My bedrock is that, except for game engines and other soft real-time systems, declarative always beats imperative.
Further, given the extensibility of a knowledge graph-powered semantic layer, embedding business logic there makes all kinds of sense with respect to contextual awareness, reuse, and the like.
Finally, we get to the essential concept of this piece, which is to say, it’s entirely false to think of business logic as only living in one place, as I’ve tried to imply above. Business logic ends up in lots of places, including the ones I’ve mentioned here, plus others as data fabric adoption increases.
So the real questions are more like: how should that happen, where should it come from, what is its lifecycle. I can only say here that 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.
We can think of this process as a kind of downcasting (or, if you prefer, upcasting) from business logic as logic to business logic as code, documentation, stored procedures, diagrams, etc.
But hey maybe I’m wrong? Every organization is different. So, what do you think? Where does your business logic live?
Curious to see what your business logic would look like in a knowledge graph? Get started with Stardog today to start your free evaluation.