Where Does Business Logic Go?

By , · 9 minute read

Let’s talk about business logic. Where should it live inside the enterprise?

This 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. Which is just 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:

  1. programming language artifacts
  2. data models
  3. AI or ML or statistical models
  4. 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? Which is really just an indirect way of saying, how should IT manage all of the business logic?

Why it Matters

This question 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.

What are the Choices?

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.

Second, there are many candidates for where we should store business logic. I don’t think any one of them is the right choice in the future, which is arriving right now, by the way, where enterprises build knowledge graphs to unify data and empower analytics and insight machines. But let’s discuss them anyway because there are lessons to be learned.

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 which 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.

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.

To manage business logic, business leaders must be able to see it as expressed and shared publicly. Except in extraordinary circumstances (i.e., software startups), code is not a primary business artifact. 4GLs, DSLs, and JavaScript notwithstanding, code is the business of coders. Business logic is the business of business leaders. These are to a statistical certainty disjoint everywhere and always.

TLDR: Code is for coders. Business logic is for the business. And these have always been at war, one with the other.

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. Or, more accurately, 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.

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.

The Right Answer Is…

Business logic should live in the data model. And, what’s more, it should live in the graph data model 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 semantic graph data model, embedding business logic there makes all kinds of sense with respect to contextual-awareness, reuse, and the like.

Finally we get to the essential conceit 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. 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.

Inconclusive Conclusion

But hey maybe I’m wrong? No, really. I’m less sure about the conclusions drawn in this article than I’m entirely comfortable with. So, what do you think, where should business logic live?

Read our Digital Transformation guide to learn how to ensure your enterprise data and business logic are integrated, consistent, and trustworthy.

Download Stardog today to start your free evaluation.


Top