Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘hard-coding rules’

Fundamental Challenges Facing Your Business: #1 – Business Agility

Charles Darwin is reported to have said, “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” Becoming more responsive to change is simply not optional these days. Consider the current state of affairs in IT today. The statistics are depressing. Reliable sources indicate that over 75% of all IT resources go toward system ‘maintenance’. That’s not agile! In the second of edition of Building Business Solutions: Business Analysis with Business Rules, Gladys Lam and I describe this world as like living in change deployment hell[1]. You might say that legacy systems are poorly engineered, but I believe that misses the mark. Rather, perhaps they are be over-engineered. What happens when you over-engineer something? The solution you produce is too stiff or too rigid or too cumbersome for the real-world problem. Think ‘tree that doesn’t bend with the wind’. The speed of business is accelerating, yet the architecture of traditionally-built systems is rigid and static. The fundamental problem in this regard is embedding business rules within the systems themselves. If you hard-code business rules into application logic, they will be hard to find, hard to understand, and even harder to change. Do we really want to keep building systems that way?! Make no mistake about it – many business rules will change. So if you continue hard-coding business rules into systems, you will be revisiting the code … a lot! That might be a good thing for service providers, but it’s not a good thing for the business. The obvious solution is to engineer business rules separately from functional requirements. Can you do that cleanly and effectively? Absolutely. It’s been proven many, many times. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1]Building Business Solutions: Business Analysis with Business Rules by Ronald G. Ross and Gladys S.W. Lam, 2nd edition (to be published in mid-2015), an IIBA Sponsored Handbook, pp 8-9. http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment

What Role for Business Rules in *Enterprise Architecture*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #6 Question: What role should business rules play in enterprise architecture? Reverse-engineering business rules from legacy systems accurately is virtually impossible. The full, original business intent is simply lost. Reconstruction of business logic has been tried time and time again, often aided by automated tools, but measured against time and cost, seldom achieves satisfactory results. What a waste! The solution is simply to stop hard-coding business rules into procedural languages. Rules will change and they will be needed for new business initiatives and platforms. The opportunity costs of continuing to follow traditional practices – not to mention the ‘maintenance’ costs – is simply too great. The alternative is applying rule technology that can support rules expressed in more natural (declarative) form. The Manifesto summarizes these points as follows …

6.2. Executing rules directly – for example in a rules engine – is a better implementation strategy than transcribing the rules into some procedural form.

With computing power so vastly improved, there is less and less reason every day to support business rules using procedural languages. Why are we still programming the evaluation of rules ourselves?! Just as a DBMS removes data management as an application concern, so too does a rule technology for the evaluation of rules. A related issue is compliance – not just regulatory compliance, but compliance with contractual obligations, deals, agreements, licenses, warranties, and so on. If you want to delight customers, keep your commitments. To do so you must be able to determine how your systems actually got the outcomes they did. That way, if there’s a mistake you can correct it. So the Manifesto says …

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

Today, demonstrating compliance is a largely hit-or-miss affair, always after the fact. Does it have to be? No! A state-of-the-art enterprise architecture is one that logs the rules used to make evaluations and decisions just as a DBMS logs all transactions. Compliance based on rules can and should be built-in.


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading

What Role for Business Rules in *Business Agility*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #5 Question: How do business rules support business agility? Think of business rules as expressing business practices. These practices can cover a wide range of business concerns, including the composition of products, the customization of services for individual customers, operational hand-offs with suppliers, implementation of regulatory constraints, and so forth. Historically, rules have been embedded (hard-coded) in processes, in many different places and often inconsistently. There is no easy traceability for any given rule. Changing rules inevitably requires IT intervention, along with the associated cost and delay. From a business perspective, the resulting business support is simply not agile. Business rules support business agility by providing pinpoint means to evaluate and modify business practices. Rules are expressed and managed independently of processes (a.k.a. rule independence). By that means they can be consolidated (single-sourced) and evolved more rapidly and reliability. From a platform point of view, the Manifesto says it this way …

6.1. A business rules application is intentionally built to accommodate continuous change in business rules.  The platform on which the application runs should support such continuous change.

Clearly some platforms are far better than others in this regard. The quality of their support for rules should be a critical factor in selection and design. Unfortunately, many organizations are trapped as much by legacy platforms as by legacy systems. True business agility requires migration to new platforms as quickly and easily as possible. For example, a central concern of many organizations these days is mobile computing and social media – capabilities not even on the horizon ten years ago when the Manifesto was written. There’s no end to platform innovation in sight – and companies will always want to get on-board faster and faster. Is there any way of doing so without knowing your business rules? No! So the Manifesto recommends …

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

Always remember that business rules are what you need to run your business, not to design systems, at least directly. There will never be a future platform for which you do not need to know your business rules.  


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading