Welcome! This article kicks off a series that will go through an implementation of a Fantasy Football web site that is powered by the JBoss/Red Hat business rules and process management suites. Along the way, we’ll go through the design and implementation of the system, and for the adventurous, how to build, run and modify the application.
Why Fantasy Football?
There are some great demonstrations of the JBoss BRMS and BPM platforms that demonstrate things like bank loan validation and mortgage approval processes . We wanted to make a demo app that was both fun and had ample use cases to play with all the toys that these platforms offer, and Fantasy Football seemed like a good fit to us:
- Rules can be used to validate the leagues and teams (e.g.. making sure a player is only used once per league, players are assigned to correct slots etc.)
- Another rule set could be used to create a flexible scoring system that reacts to incoming play data
- Business processes can be setup to orchestrate trades and the draft system
- The planning engine could even be used to power an auto-draft engine
We also wanted to put together something that although not fully functional (there’s way too much pressure in that line of business), had a decent level of complexity to it. We’ll explore how to make a flexible scoring system (so different leagues can have different rules) and even outline how the core of the application could power other fantasy sports applications (Fantasy Basketball? Baseball? Cricket? ChessBoxing?).
First, let’s take a look these types of tools and why they are compelling:
What are business rules/process management systems?
Business rules and processes (in software terms) are declarative approaches to expressing logic and workflow. This means that they allow us to:
- describe “what” we want, while glossing over the “how”
- decompose problems rather than solving everything all at once
Structured Query Language (SQL) is a well-known example of a similarly declarative means for interacting with technology: we describe the format of what we want and rely upon the database to materialize that request.
Not surprisingly, business process and rules frameworks are typically driven by a higher level language/format that is concise and specific to the task. JBoss
Drools uses a custom “language” expressing individual conditions and consequences, whereas jBPM (java Business Process Management) uses the Business Process Model and Notation v2.0 (BPMN2) XML format to describe high-level workflow.
Modeling business rules and processes in this way is great, because it “un-buries” the important gist of the problem domain and untangles the cyclomatic complexity that a mountain of “if” statements produces.
But these frameworks on their own are still low-level and solely developer controlled, leaving a gap between those with the deep domain expertise and those that implement the logic in code.
How can BRMS and BPM systems help?
A Rules/Process Management system bridges this gap by supplying:
- Graphical representations of business processes to clearly communicate their flow to everyone on the team
- Web based authoring tools, that allow business analysts to inspect, test and even author rules and processes
- A platform to monitor and interact with the business processes that are running
This is precisely what the JBoss Community projects and corresponding Red Hat Subscription products offer that we will be using in this series of articles.
- JBoss Drools Workbench/Red Hat Business Rule Management System (BRMS)
- Author, test, and manage rules artifact
- JBoss jBPM/Red Hat JBoss BPM Suite (BPMS)
- Author, test, manage and execute business processes
- A superset of Drools Workbench, it also handles the rules components
- JBoss Optaplanner/Red Hat Business Resource Planner
- Embeddable planning engine for solving planning problems, e.g. employee work schedules based on job duty and work schedule preferences.
When they are a great fit…
These frameworks and tools are an excellent fit when trying to implement complex business domain knowledge that must adapt to change. The process of decomposing these problems in a standard way forces an upfront understanding of how to tackle the challenges. Once the general approach is established, the tools can be used to clearly communicate what’s important, and allows the non-technical users a means to adjust and test changes.
...And when they’re not
These types of frameworks definitely come with additional technology overhead and each component has a bit of a learning curve. In larger, mission critical use cases, the benefits will quickly justify these costs. A small project with few rules that rarely change, the overhead may not make sense.
In our next installment we’ll go over the high-level design of the system and how to get the application up and running. Each additional installment will take an in-depth look at one of the components. Subscribe to our blog below to receive our latest posts in your inbox once a week.
Are you looking for help with a Business Rules or Process Management project? Contact us today to request a complimentary consultation.