What happens when your business changes and your applications don’t change to support it? Existing applications must be updated or completely rewritten, and cobbled together to try to keep up with the new (and always changing) demands of the business. Decision logic is based on multiple inputs that are changing more and more frequently due to internal policies and external forces, such as legislation, regulations, and changing competition.
Simply rewriting applications is no longer good enough: it’s costly, time consuming, and often takes IT professionals away from more strategic work to focus on small and frequent changes to business logic. What’s needed is to change the way applications are written to begin with. This article explores strategies for creating Dynamic Business Applications – applications that change to reflect the changing demands of business.
Strategy 1: Understand Dynamic Business Applications & Dynamic Decisioning
Historically, application development has successfully focused on values such as improving data access, transactional throughput and scalability. Now the focus needs to turn to building applications that can change quickly to accommodate the changes needs of a business. These are called Dynamic Business Applications.
Dynamic Business Applications are built to support a rapidly changing business world. Rather than traditional applications that support requirements at a point in time (not built for change), Dynamic Business Applications anticipate and easily accommodate change. One characteristic of Dynamic Business Applications is that, in contrast to monolithic applications, they are comprised of application components that improve agility and encourage reuse.
Automating the operational decisions that drive the business is key to Dynamic Business Applications. The logic and input behind these decisions change frequently and is understood best by business users (analysts, risk managers, etc.) referred to in this article as subject matter experts, or SMEs. Dynamic decisioning gives SMEs control of the rules, logic, and calculations that are at the heart of every day operations. Dynamic decisioning frees IT staff from the burden of frequent updates to business logic, yet keeps them in control.
Combine dynamic decisioning with Web services, and you have dynamic decision services. Web services are self contained components that allow applications to share logic or data across a network, often used within a Service Oriented Architecture (SOA) approach. They can be anything from a call to FedEx tracking service or a complex process.
The term decision service refers to a Web service that provides decision logic; decision services are created to be shared and reused as needed by multiple applications. Web services and decision services are nothing new. But when you isolate and expose the logic used for a decision service and make it easily maintainable, even by non-technical SMEs, then you are using dynamic decision services and you are on your way to exploiting the power of an SOA approach.
Strategy 2: Determine project suitability for a Dynamic Business Application approach
Not all business applications need to be dynamic, and not all logic needs to be, or is appropriate for, implementing as a decision service or using a BRE. Before beginning a project, determine the suitability of the project for rules-based development and decision services. These criteria will help:
- Business logic changes frequently
- Changes are time sensitive
- Business logic is shared across systems
- Rules affect customer interaction or other core business operations
- Non-technical SMEs have the best understanding of the underlying logic that drives a decision
- Developers need to focus on strategic development efforts rather than the minutia of logic changes
Any of the following apply:
- Regulation Requirements
Strategy 3: Understand that IT cannot do this alone
The internal and external policies that drive decisions change too frequently and require too much input from SMEs for IT to handle alone. There has to be active involvement by business people, and some aspects of creating and changing decision logic will be outside of IT’s control. This is a disturbing thought for many long-time IT professionals: they are being directed to change not just the development process, but ownership and accountability. This is not something to be taken lightly, but it should be viewed by IT as an opportunity to support the business without getting mired in the minutia of changing business policies.
In reality, non-technical people have been involved in automating decision logic for years. But the tools they use – typically spreadsheets – are not built to be scalable or shareable. Worse, they are completely outside of the control of IT and as such may pose a security risk.
It’s important to recognize that the future of application development is not “business as usual,” nor is it “IT as usual.” Application development must become a partnership using technology that enables IT professionals and SMEs to create components supporting their domain of expertise, which will be assembled (and reused and reassembled) by IT into Dynamic Business Applications. The next strategy explores technology that enables collaboration and empowers SMEs, while allowing IT to maintain control.
Strategy 4: Isolate rapidly changing logic with a Business Rule Engine (BRE)
Automating decisions is key to Dynamic Business Applications, and business rules are where decisioning starts. A technical architecture is required to build decisioning, and this is where BRE comes in. A BRE isolates, externalizes and exposes decision logic in the form of rules and calculations, making it easier to find and share decision logic across the enterprise. The BRE provides a window into the logic of every day decisions. (See Figure A.) Much like what a DBMS does for data a BRE does for business rules, making logic a corporate asset that be shared across the organization.
The Essence of a Business Rule Engine
BREs play an important role in helping IT manage the shift in accountability and ownership for Dynamic Business Applications with features that enable IT and SMEs to collaborate. Using a BRE, business professionals can translate their knowledge into decision logic, in the form of business rules. IT still has control over the development environment, setting up the parameters within which business users will create and manage rules.
As stated earlier, not all logic needs to be implemented using a BRE. A good rule of thumb is to think of this in three terms: volatility, complexity, and visibility. Decision logic that is volatile (changes frequently) should be externalized to a rule engine where it is easier to find and update. Complex rules and calculations are better expressed in a rule engine, where it’s easier to if all possible conditions are covered. If rules need to be visible by others in the organization for risk or compliance reasons, externalizing rules with business rule engines is useful.
Once you have identified logic that is volatile or needs to be visible, delegate responsibility for that logic to SMEs (analysts, risk managers, etc.) who make decisions based on this logic and who have a thorough understanding of the underlying business requirements. This doesn’t mean turning SMEs into programmers, but giving them the ability to author and update rules and calculations that they understand, with technology that makes it efficient. Complex logic may be authored in the rule engine by developers or even by SMEs if the authoring interface is intuitive.
By putting business decision logic in the hands of subject matter experts, IT can reduce or remove the bottleneck created by constantly changing business policies.
Some of the enabling features to look for in a BRE include:
- An interface for authoring decision logic that allows an expression of logic in English-like language, intuitive enough for nontechnical users yet robust enough for technical developers to author complex logic. This allows SMEs from across the business to contribute to a business solution without the need to translate business terms to programming syntax.
- Easy integration with data sources, typically set up by IT so that SMEs can focus on entities in terms they are familiar with (loan amount, interest rate, etc.), without needing to understand the data source, its structure, and how to access it.
- An integrated testing environment, allowing rule authors to verify the behavior and results of rules as they author them.
- Administration and management capabilities that allow IT to easily manage the rules created by SMEs. This includes functionality such as setting access permissions, managing versions of rules, and controlling the promotion of rules or sets or rules from development to testing to production.
- An execution engine that optimizes the running of multiple rules under a variety of conditions.
- A rule engine that can be exposed as a web service
Strategy 5: Understand SOA and the role it plays
SOA stands for Service Oriented Architecture; it is an architectural approach. One of the goals of implementing an SOA approach is to have a high degree of flexibility and reuse. Other intended benefits include streamlining the development and deployment process, streamlining the maintenance process, reducing integration overhead and enabling IT to be more responsive to the business.
Clearly, the graphic in Figure A is simplistic in its representation of SOA. When considered in the larger context of an SOA implementation, this can be a bit overwhelming. Figure B shows a prototypical implementation of SOA.
Prototypical SOA Implementation
The parts in green are related to an Enterprise Service Bus (ESB) and its components which include all sorts of management consoles, queues, and data stores. The parts in gray are related to business applications of the enterprise. It is complex and there are many moving parts.
The good news is that you can begin to create or replace aspects of your business services today that are or will become part of your SOA framework using dynamic decision service approaches. Focus on this layer – the section highlighted – to have an immediate impact on the agility of your organization without necessarily waiting for a full-blown SOA implementation.
Strategy 6: Implement rules as dynamic decision services
SOA by itself is not enough to guarantee Dynamic Business Applications. But by externalizing logic with a BRE where it can be authored and maintained by SMEs, and making it available as a service within the context of an SOA stack, rules become dynamic decision services that are callable from other applications, services, and process flows.
Using a BRE, the rules comprising a decision service would be written and grouped together. For example, you might have a rule that denies a loan if the borrower has a credit card balance greater than $5000 or has any negative borrowing history. This rule is grouped with other rules that comprise an underwriting decision for a mortgage application, and can then be published as a service where it can be used by other applications.
Publishing the rules as a service using a BRE is accomplished in one of two ways. First, the BRE may have an out-of-the-box rule service where groups of rules can be called in a generic fashion. The service call usually includes directives on what rules to call and the XML data stream present to the rule engine. The problem with this approach is it is generic and there is not a specific type (or data contract) associated with the group of rules and therefore calling application cannot validate they are sending the correct data until after the service is called – not before.
For example, one group of rules may relate to a loan application and its associated data fields while another group of rules may relate to a housing appraisal and its associated data fields. Sending the loan data to the housing appraisal related rules would result in a run-time error.
To correct this problem, the BRE can publish a series of services – one for each group of rules that can be called. Each service would be published using WSDL (Web Services Description Language) specific to the data expected by the particular group of rules exposed as the service. WSDL is an XML-based language for describing Web services and how to access them. It includes information such as message format and protocol details for the web service. WSDL services are “discoverable” and can be called from any platform or application that is web service enabled. In the example above, instead of having one service with one way to call the service, there would be two methods for calling the service, one for processing the loan data and one for processing the housing appraisal data.
The Bottom Line
Application development is clearly headed for some big changes, as rapidly changing business requirements drive the need for Dynamic Business Applications. The future of application development includes collaboration between IT and non-technical subject matter experts, aided by technology that supports collaboration and puts business decision logic in the hands of business decision makers.
The vision of Dynamic Business Applications, like the vision of SOA, may seem like a long and intimidating journey. But you can add value in the short term by externalizing business rules and publishing them as decision services. The strategies outlined in this article can help you gain real value today while moving you closer to a strategic Dynamic Business Applications objective.