When you think about business logic, you probably imagine an application server or stored procedures, or custom code that accesses stored data and exposes it in a useful and manageable way – such as “show me all of a given customer’s purchases in this timeframe”.
These pieces of code reflect the understanding of the fundamentals of the business - like customers, orders, tickets, requests – and how they interact. In any business you build skill over time in understanding your domain and then build on top of that understanding to take the business further. Business logic is generally stable, consistent across requests, and subject to careful modification. After all, you wouldn’t want to put partly tested logic about bank balance transfers into production.
When you think about business policy, what comes to mind?
Maybe a stack of papers documenting HR or accounting guidelines, or maybe the elements of Sarbanes-Oxley requirements. Policy is not about how you compute a specific result – like the customer’s purchase history – but about other factors like who can access it, how frequently, from what locations, how it’s rendered, how long the result is considered valid, and other “meta-logic” issues. In any business you make changes to your policies frequently, as a way to meet the changing face of the market environment. The nature of business policy is therefore to be dynamic, varied according to the request context, and subject to frequent experimentation. For example, product managers need to continually test the value of different offers to given segments without having to redevelop the product.
When policies like security (“who can access this and what credentials do they have to show?”) and service level (“how many requests can be made in a given time interval?”) are collapsed into code responsible for business logic, the result is loss of agility, high cost to adopt new policy implementations (e.g. for identity and access schemes or to keep pace with increased hardware capacity), and confusion of concerns (rather than separation of concerns).
In the current era of cloud APIs, where these interfaces are being built as a direct link to what started as the backend for the website, many developers are realizing that what was really policy was built into their business logic layer. They’re also seeing that adding new clients – going from enabling partners to enabling rich clients to enabling mobile device (such as iPhone or Android) applications – require many adjustments to how the request and response of an API are rendered, but should require no changes to the stable core of business logic.
Supporting an API with a set of policies that activate based on the user (such as preventing or enabling access to different parts of the API – for example, only the development & testing methods but not production methods, or query methods only, or limiting requests to a certain transaction volume or financial value) and type of client (such as providing pagination and format translation for a mobile device) means that the risk of delivering the API is reduced, and the risk of negative impact to existing users of the API (typically the original website) are reduced. Also, the computational load for the policy processing can be moved to a low-cost, scale-out tier and away from the high-value application servers that host the business logic.
So what this seems to indicate is a movement towards a separation of concerns between logic and policy. Responsibility for business logic processing lies in a stable and slowly changing layer, and policy is processed in a tier that allows for agile modification and enables the total computational result to meet the shifting needs of the business.