Translating Business Logic Into Code

Imagine a science-fiction novel involving a computer that becomes independent of humans. It runs their affairs and takes care of their lives, but few, if any, know its inner workings.  But that isn't science fiction. There are lots of business systems that no one fully understands, designed by people who no longer maintain it, encompassing business logic that was dictated by people who are long gone. In both scenarios, we are at the mercy of a computer. In the first one, Arnold Schwarzenegger saves us. In the second scenario, a humanoid robot won't do. Enterprise software development comprises understanding, documenting and implementing business logic, which is the human process the software is supposed to automate. And yet, one of the often neglected links in the chain of skills that software developers possess is the business side. Understanding of the business is necessary to keep the underlying software connected and to stop it from becoming an isolated, unreachable island over time. This skill does not come naturally or derive inevitably from a technical background. Despite the name, "There are few things that are less logical than business logic," software guru Martin Fowler writes. Business logic lacks the determinism of functions and conditional paths and the clear-cut rules of Boolean logic. Business logic is the creation of sales and marketing, not mathematicians and software engineers. A "hybrid-professional" is needed: someone who knows the business and the technology. The benefit of this approach may not be obvious. After all, division of labor exists for a reason, and specialization is due to the limited capacity of individuals and time available to them. Without specialization, major human endeavors wouldn't have been possible. There are, however, certain scenarios in which strict specialization is more of a barrier to progress than a facilitator. Enterprise software is an example. On the surface, the delineation seems natural. The business people know what the business logic is, and they deliver it to the developers in the form of requirements. The developers then translate the requirements to software. The weakness of this approach is the direction of the translation. Distilling the business process to a set of requirements by a non-developer necessarily deprives the developers of the big picture, so they will write software based on the pinhole view given to them. It's like translating text from a foreign language. The message, more or less, can be conveyed if you translate word by word, but to fully appreciate the original content you have to understand the original language in its cultural context. So developers need to understand business language and directly engage the business side. This approach seems to be merely a reversal of direction. Instead of having the business side deliver the requirements to the technical side, we would be doing the opposite. How is that better? It is better because the end product lies at the technical end, not the business end. We're trying to build software to accommodate the business, not the opposite. That dictates the direction, and it makes all the difference. Business people excel at business, and they do it without worrying about how their decisions will translate to software. It is best to free them from that worry -- unless the business itself is software! Software developers have to worry about the software they create. Because one of the two groups has to be burdened with both sides of the equation, the latter is the natural candidate. So the ideal hybrid-professional is one with solid roots on the technology side and the skill to venture into the business side and obtain insight into the specific business domain she is developing for. That skill is made up of people skills that complement the "machine skills"; the ability to compartmentalize technology so it doesn't pollute or dictate the business model; and having true insight, not just knowledge, into the business domain, so that there is never anything lost in translation.