“According to CIO magazine, up to 71 percent of IT project failures are caused by an ineffective requirements process.”
Business Rules are the orphan child of the requirements process, and our failure to address this issue continues to contribute significantly to IT failure.
What follows are seven deadly sins that continue to relegate rules to a second class status. We discuss the root cause of the problem, and postulate on potential solutions.
#1: Business rules are captured during design, if at all.
This has become a common practice for various reasons. Sometimes it is a matter of politics, budgeting, and the way it has always been done. Whether waterfall or iterative approach, sufficient time is not allotted in requirements and analysis for capturing business rules. Therefore, by default, most often, their capture happens, if lucky, during design. If less lucky, it happens during implementation. Worst case, and most expensive, during testing.
Another reason such capture is delayed is the belief that business rules represent “details” or “specifications for implementation.” Nothing can be further from the truth. John Zachman taught us that, lower rows in his framework do not represent more detailed representations. Rather, they represent different perspectives of the same details. That said, to a business person, the business rules represent core business logic, not really design or implementation artifacts, and they may be the most valuable aspect of a system.
Practice #1 is deadly because:
- The true core of business logic requires and deserves sufficient time and creativity to think through (which does not happen in design).
- There is no opportunity to steer the system’s business rules directly toward business alignment
- There is no opportunity to deliver “skinny” business process flows and “skinny use cases.”
#2: Business rules, if captured, are buried in use cases or process models.
This has become common practice simply by history. In fact, most people do not understand the essential difference between a simple process task and a business rule. Hence, business rules again take on the role of being “detailed process specifications” and not an artifact in their own right. Process models and use cases actually “model” the business rules themselves, making them resistant to change.
Practice #2 is deadly because:
- It leads to sloppy and unnecessarily complex process models that can spread out across entire walls in conference rooms.
- The opportunity for revealing creative “skinny” and manageable process models and use cases is lost.
- The distinction between “procedural” processes and “declarative, non-procedural” business rules is totally lost.
- The opportunity to manage the buried business rules as reusable assets is lost.
#3: Business rules are separated from use cases, process models but are connected to them one at a time and not as a disciplined set.
Even in cases where business rules are deliberately separated from process models and use cases, most often the business rules are connected to such artifacts one at a time. It turns out that this is not much better than #2.
This practice is deadly because:
- Management of single attached business rules prevents reuse of sets of business rules
- Management of one list of business rules becomes overwhelming very quickly
- The opportunity to manage sets of business rules as cohesive, tightly coupled logic is lost
- The recognition of business rules as declarative versus procedural remains unimportant since the declarative nature of one business rule has little value (the declarative nature of whole sets of related rules has extremely high value)
- The rigor of normalizing business rules and analyzing them with standard, predictable integrity properties is lost
- The opportunity for business creativity in devising new business rules is made a very complex process.
#4: There is no standard for a model of business rules that is technology-independent and against which testing can occur early on.
Even with the recognition that business rules are important enough to the business to pay attention to them earlier in the systems development life cycle, the delivery of all business rules is time-consuming and costly. That is because, while we have ways of delivering early UI prototypes, early object models, and early iterations of other aspects of a system, we do not routinely treat business rules in the same way.
This practice is deadly because:o It leads to the perception that gathering business rules takes too long and costs too much money.o There is no way to test business rules until late in the project.o It encourages big projects without focusing on big ROI (where “big ROI” can be gained from a focus on correct sets of business rules, not necessarily “big” sets of business rules)
#5: Because there is no standardized business rule model, it follows that there is no detailed deliverable for a fully populated model business rules that is verifiable from a business perspective and technology-independent and against which fewer test cases, less time, and less money can test.
Today, we lack a rigorous but simple mechanism for grouping and relating business rules into a stable structure that allows for change and guarantees predictability in delivery of the business rules themselves.
This practice is deadly because:o Business rules remain a lost asset, whose essential value and structure is elusive.o Design of business rule systems remains a rare art.o Testing of business rules remains costly.
#6: There is no clear differentiation between what belongs in a process model and what belongs in a business rule model.
Because there is no standard theory leading to a declarative model of business rules, what goes into a process model and what goes into business rule capture is most often based on the opinion and preference of an analyst. Hence, it differs from project to project, analyst to analyst, process to process.
This is a deadly practice because:o Many benefits of process modeling and use case modeling are lost because the deliverables are not “true” process models or “true” use cases.o The benefits of the business rules approach is lost because business rules remain elusive.o The implementer – whether it be programmer or technical rule writer – is left to make the decisions on the “real” meaning of the business rules, and the accuracy of the interpretation can only be determined at testing. A well defined model would eliminate guess work, and would greatly facilitate, if not automate, the implementation and deployment phase.
#7: There is no formal correlation of business rules (or sets of business rules) to business objectives and corresponding business performance metrics.
Most analysts, designers, and implementers are not trained to focus on business performance. Once a project is sponsored with a high level of ROI, development proceeds until it finishes or fails. There is no continuous monitoring of ROI delivery.
This is a deadly practice because:o There is no direct correlation of deliverables to business ROIo There is no on-going management of the delivery of ROI.
In summary, the realizable benefits of adopting a business rule model approach to BPM, SOA, and other business-focused or technology-focused projects are extremely significant. For a rule model to deliver on these benefits, it must be (1) theoretically sound (2) teachable and predictable, and (3) simple to use.
In a future article I will discuss the theoretical underpinnings of an emerging business rule model that promises to address these – and other – issues, and experiences in the field with its deployment.
