Blog

Beyond Programming: Translating Business Logic to Code

Kal Nasser
Insurance Experts' Forum, May 29, 2014

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. A business system 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—isn’t science fiction. 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 the business logic, which is the human process the software is supposed to automate. And yet, one of the oft-neglected links in the chain of skills that software developers possess is the business side. It is the ability to keep the underlying software connected and to stop it from becoming an isolated, unreachable island over time.

This skill does not come naturally nor is it inevitably derived 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.

It takes a "hybrid-professional" approach to achieve the aforementioned objectives; 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 it, 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 of that.

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 appreciating the big picture, and so they will write software that is a reflection of this pinhole view given to them.

It's like translating text from a foreign language: The message, more or less, can be conveyed, but to fully appreciate the original content, one has to understand the original language in its cultural context.

So developers need to understand the 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. Since 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 attain insight into the specific business domain for which they are developing. 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.

Kal Nasser is a software developer with X by 2, a technology company in Farmington Hills, Mich. 

Readers are encouraged to respond to Kal using the “Add Your Comments” box below. He also can be reached at knasser@xby2.com.

This blog was exclusively written for Insurance Networking News. It may not be reposted or reused without permission from Insurance Networking News.

The opinions of bloggers on www.insurancenetworking.com do not necessarily reflect those of Insurance Networking News.

Comments (0)

Be the first to comment on this post using the section below.

Add Your Comments...

Already Registered?

If you have already registered to Insurance Networking News, please use the form below to login. When completed you will immeditely be directed to post a comment.

Forgot your password?

Not Registered?

You must be registered to post a comment. Click here to register.

Blog Archive

What It Takes to Have a Tech-Savvy Workplace

The tools and technologies to build the next workplace are available, but not common yet in corporate settings.

Avoiding the Bermuda Triangle of Data

Handled poorly, questions around data ownership, data quality and data security can sidetrack big data conversations and alienate business stakeholders.

A Prototype of the Successful Innovation Leader

Celent research reveals the prototype for the successful senior innovation leader.

Global Supply Chain, Local Problem

As a technology provider, your client’s ability to deliver products and services to their customers, when and where they need them, is at the heart of their business success.

Legacy Systems Are Increasingly a Competitive Handicap

Legacy systems, while reliable, increasingly hold insurers back, a new study finds

From Her to Watson, and What’s Next?

Imagine a learning system that can replace the performance of your best employee to provide the same level of support across the organization.