Why is “Business Logic” an Oxymoron?

Dear executive: quick! Where is your business logic? In the business or application tier of your n-tier architecture? Ingrained in your business and enterprise applications? How about stored procedures in your databases? You wouldn’t have any business logic in your client apps, portals, or Web pages, would you? How about your identity and access management software? What’s that you say? All of the above?

The fact of the matter is, for most large organizations (and many midsize ones, as well), business logic resides in all of these places, and more. Where it doesn’t reside is in the hands of the business people. And there’s the contradiction: how can business logic be business logic if it’s locked away in the technology, rather than in the hands of the business?

The business logic shell game

There’s nothing new here — hard-coding business logic into applications dates back to the very early days of computing. After all, COBOL was the Common Business-Oriented Language, specifically created to be a tool for coding business logic. And today’s leading programming languages, including Java, C++, and C#, all descend from the likes of COBOL.

Sure, there have been advances, including object-oriented programming and distributed computing, that seek to encapsulate business logic in to increasingly abstract constructs to improve the maintainability and flexibility of the code. And while there have been modest flexibility improvements since the monolithic program days, the unfortunate truth is that these advances have been little more than a business logic shell game, moving the hard-coded logic from this piece of compiled code to this JavaBean or that distributed app. Instead of concentrating legacy systems in the host data center, we now create instant legacy code all over our infrastructure. You may think the pea under the shell has disappeared, but in reality, it’s just been moved around.

Service Orientation to the rescue

The business logic oxymoron is not going away any time soon, but there is hope on the horizon, in the form of Service-oriented (SO) computing, which leverages Service-oriented architectures (SOAs). Fundamental to the SO approach is a separation between the business requirements and logic, defined in the form of business processes and rules — and the technology, consisting of the infrastructure that underlies the Services layer of abstraction. In a properly architected SOA, business Services represent the data available to the business and the core functionality of the underlying systems. Business people then compose those Services into SO processes, configure the processes based upon the applicable business rules, and then expose those processes as Services that can be composed into other processes.

The important point to understand is that in a fully developed SOA, the SO processes contain all of the business logic in the enterprise. While certain programming logic will remain in the software infrastructure that supports the business Services available to the enterprise, none of the business logic remains in that infrastructure. Business users will create, configure, and compose SO processes without traditional programming languages, but instead will use tools appropriate for those users.

Metadata: the secret sauce

Programmers, among others, will no doubt be incredulous at such a bold position. What will they code all day, after all, if not business logic? Or will the need for programmers succumb to the double whammy of the SO and offshoring trends? The answer lies in how software can support the capabilities necessary to offer business users the power they need. The secret is metadata.

Metadata are information about data, or more broadly, information about the business processes and rules that the business users work with. The underlying software must be able to process those metadata. So, instead of hard-coding business logic into the programming code, the business logic appears in the form of metadata, which the programs must be able to deal with. Fundamentally, then, the business Services form the crux of the SOA and act as the intermediary between the SO processes on the one hand, while the underlying technology on the other deals entirely with data — since, after all, metadata are data. Programmers, therefore, must understand that the role of the software infrastructure is to deal with data — moving them, processing them, storing them, making them available, and not coding to specific business requirements. The specifics of what those data and metadata include, however, is in the realm of the business user.

What it all means for you

So, should this provocative vision for business logic come to pass, what will the shift to SO computing mean for you?

  • For enterprise IT programmers — today you’re coding business logic and integration. Both are going away, and your job might be going offshore anyway. Time to become an architect or move to the business side, or learn to focus on building Services.
  • For business application vendors — today your software includes infrastructure, user interface, and business logic. Eventually, your value-add will be entirely on the business logic side, building tools for business users that consume and produce Services and SO processes, and providing the underlying Services and a separate process layer that orchestrates those Services. Leave the infrastructure and user interface to someone else.
  • For middleware/software infrastructure vendors — Forget business logic. You’re building the plumbing that makes the SOA work. Your products are all about data and metadata. Important note: if you’re already offering a strong metadata tool (and you know who you are), you’re sitting pretty.
  • For SO software (and hardware) vendors — To stay the SO course, always keep in mind that business logic is a metadata-driven abstraction, never to be hard-coded.
  • For business users of IT — Gone are the days where you can write down business requirements in simple text and pretty pictures, throw them over the wall to IT, and expect them to code it all for you. Instead, stay tuned for a growing number of increasingly powerful tools that enable business process and rules that you — yes, you — can use to define, manage, and maintain your business. You won’t ever need to be a programmer, but sufficient technical skills to understand how to best use the extensive technology at your fingertips will be critical to your job and your career.

The ZapThink take

So, do we really believe that SOAs will lead to business logic belonging entirely in the hands of business? Probably, but it will take some time for this IT vision to become a reality, and there are many roadblocks along the way to realizing this vision. The most obvious barrier is the existence of legacy business logic. Whether in mainframes, EJBs, Web Servers, or business applications, all that business logic isn’t going to disappear any time soon. For the vision in this article to become a reality, we’ll have to wait until companies gradually retire the legacy stuff in favor of SO solutions. However, as ZapThink reiterates frequently, SOAs make it easier to get value out of legacy systems — so instead of offering a quick, but difficult fix, we’re suggesting a gradual evolution of IT. Eventually, however, business logic will finally be entirely in the hands of the business.

Download the Full Why is “Business Logic” an Oxymoron? Report Here