“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:
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:
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:
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)
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.
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.
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.
Larry has over thirty years of experience in building technology based companies, in which the focus was rules-based technologies and applications. Prior to joining KPI as Managing Partner, he was Senior Vice President of Sapiens Americas, Inc., which he joined when he sold his company, PowerFlex Software Systems, Inc to Sapiens.
There are no products in your shopping cart.
0 Items |