Implementing a Decision Service takes decisions and typically deploys them as part of the business service layer in a Service-Oriented Architecture, or SOA. When a Decision Service uses a business rule management system (BRMS) to support the implementation, the focus of the software development lifecycle (SDLC) will be on rule harvesting, design, and implementation. As a service, it needs to support standard best practices around service specification, design, implementation, and governance. Therefore the SDLC should include all the tasks, work products, and guidance to support those new activities. But the technology used to support the implementation of the Decision Service provides a set of features to quickly implement decisions and business rules. It therefore makes sense to adapt the SDLC using an agile, incremental, and iterative approach, leveraging those agile products as early as possible in the development cycle.
Some years ago, IBM delivered the first open source methodology around business rules application, called Agile Business Rule Development (ABRD). The ABRD methodology is an incremental and iterative software development process adapted to the software and business challenges of developing Decision Services. In contrast with a traditional SDLC, ABRD focuses on executable software over documentation and on a strong involvement of business users as the main actors of the development process. The ABRD methodology groups activities into cycles, which build the Decision Service per iteration by growing its scope over time. It is impossible to define up-front all the business rules supporting a decision. Therefore, an agile and iterative approach is the best approach for making the project a success.
The changes start with eliciting requirements, as decisions and business rules are not pure specifications that must be documented at project inception. The business rules that support decisions are discovered, analyzed, and implemented from the very beginning. The project team enhances the scope over time by writing and testing newly discovered rules. Business users identify new rules and new ideas for existing rules. The SDLC must support this highly iterative approach.
This approach is a significant improvement over following a rigid plan that develops a contract between users and developers. The project team follows a loop of activities grouping discovery workshops, analysis, prototyping, implementation, and testing tasks. Feedback is consolidated at the end of each loop. A loop may be completed every day at the beginning of the rule harvesting phase, but it should remain shorter than a week even in later phases. Involving subject matter experts and business users in a continuous feedback loop makes this SDLC unique.
The figure below illustrates the ABRD approach using the different phases of a traditional implementation (Discovery, Development, and Acceptance) and the underlying iterations. Each iteration may contain many loops.
Iterations are time constrained and usually between two and four weeks. During the discovery phase, the team is focused on working with subject matter experts to identify the logic behind decisions. It is a good practice to plan for short iterations to enforce continuous feedback at this stage. During the development phase, the iterations can be longer.
The project plan should organize project activities using different work streams or streams of tasks. Figure 9.1 shows only the business rules and Decision Service work streams, while in Figure 9.2, the other work streams are also represented. Work streams are helpful to develop a work break-down structure, assign work to developers, and organize deliverables.
For Decision Service implementations, the project team has to perform many tasks, including some that are recurring over time. The pentagon in the first figure represents a loop over five of those main tasks: (D)iscovery, (A)nalysis, (I)mplementation, (V)alidation, and (F)eedback. Each iteration includes several such loops. At the beginning of the project, the team may separate the day into two parts, where morning meetings discover business rules and the afternoon is used for the analysis, implementation, and validation tasks. The next morning can be used to gather feedback on the current implementation using test results.
During the “Discovery” phase, the business analyst needs to identify the different decision points of the business application. Decision points represent anchor points in the business process or the use case model where decisions are made. Analysis of those decision points leads to the decomposition of those top-level decisions and creates a roadmap for the discovery, analysis, and implementation of the business rules supporting each sub-decision. Once this roadmap is defined, the team can perform the DAIVF tasks for each decomposed decision.
At the beginning of the project, one of the common challenges the team may face is that of finding the decisions. The team needs to know where they are, how they are enforced, and how to organize the work to discover and implement the supporting business rules. In the case of a business process-based approach (the most common), the search for decision points is done by searching for thinking and action verbs in task descriptions. The process context can be used to determine if people are ultimately taking the decisions or if they can be automated by a Digital Decisioning system. Even if the top-level decisions are not suitable for automation, decomposition may well identify sub-decisions that can be automated. A financial institution may decide that it wants loan decisions to be made by a loan officer, for instance. Within this decision, there may be sub-decisions, such as a checking for documentation completeness or basic eligibility that can be automated. When the business rules behind a decision are numerous, change often, require a high degree of business domain knowledge to define, or interact in complex ways, then the use of a BRMS to automate this decision is worthwhile.
As noted above, using a BRMS modifies the SDLC slightly, as it is possible to develop the data model for the rules and the rules themselves earlier than in a traditional implementation. Trying to document all the rules during inception and elaboration and then use the BRMS for implementation only after rule discovery is a not a recommended practice, and the SDLC should avoid this. A BRMS is designed to allow rapid definition of rule sets in parallel with discovering the rules.
During the analysis and implementation activities the team focuses on understanding the data model used. They build a glossary of business terms and link them to the conceptual, logical, and physical data models. As illustrated in previous figure, the data work stream has to be considered and added to the SDLC. A Decision Service needs to have a rich data model that often has a different scope than the process variables, database, or user interface that calls it. This model is derived from the decision logic and the business rules description. It evolves over time. It begins as a business entity diagram that illustrates the major business entities and their relationships. Those business entities are mapped to concepts used as part of the rule description, and the model is enriched over time to conform to a conceptual data model. Analysis and design activities transform this model in a logical data model from which any implementation of specific physical data models are generated. As it is possible to use a BRMS early in the development cycle, the data model can be built incrementally. The BRMS has to have good support for re-factoring, with the vocabulary used for the business rules permanently synchronized with the underlying physical data model. This will ensure that rules are always using the current data model.
The other work streams illustrated in Figure 9.2 are business process, architecture, and integration. A project manager can also include more streams with related activities like environment, project management, and others. It is important to note that Decision Service implementation impacts the data and integration work stream: for the data model, the architect has to take care of the unique needs of the physical data model. It will likely not be possible to use the same model for the business process, the user interface, the service design, and the database. This is covered in multi-tier application designs, where different models are used for user interface, database, and service tiers. Design patterns have been proposed to support these different views, including Data Transfer Object, Data Value Object, and Data Access Object.
A Decision Service is materialized by an operation definition in a bigger service component. For example, a loan underwriting Decision Service is implemented within a loan software component. This component supports the implementation of a service offering a set of operations such as save loan, load loan, and underwrite loan. The operations are defined as part of the business services classification in the SOA. As such, the service design has to follow the standard best practices for service design and implementation. Service design considerations—such as being loosely coupled, having coarse grained operation, and more—have to be analyzed by architects. Other metadata has to be gathered around service ownership, life cycle, administration, deployment strategy, transaction support, fail over, fault management, performance and scalability, and other factors. Simply exposing a rule set as a web service is not good SOA, and service design has to enforce reusability not a peer-to-peer communication between products. Most current BPM integrations are focused only on plumbing and communication using web services for interoperability.
The final issue in the SDLC is that of coordinating a lifecycle that works for business rules development with one that works for other ongoing IT tasks. While some projects will require changes entirely within the business rules components, some will require broader changes. When broader changes are required the different lifecycles need to intersect so that the business rules components being developed can be deployed alongside components being developed using more traditional tools. The intersection points are usually when new functional requirements are identified and when the various components are ready for deployment. When new functional requirements are identified, it is important to determine what changes are required for both the business rules and more traditional components. Two different approaches may well be taken at this point: one to develop the business rules and one to develop the remaining components. The development of these different components can be managed separately, but, once everything is ready, they will need to come back together for an integrated set of final tests and deployment.