In-Depth

Business Rules a Tough Sell to Veteran IT Pros

Some suggest that BRM is just a crazy notion in a technology utopia

• By Stephen Swoyer
• 05/31/2005

Judging by the responses we received to last week’s story on business rules management (BRM), BRM is going to be a particularly tough sell to one constituency in particular: IT pros.

“Who are these idiots? And why do they think this?” demanded one exasperated reader. “Most business users can't think their way out of a paper sack.”

This reader and others reacted strongly to a business rules vision that proposes to let business users make changes to application code and implement these changes, via a business rules management system (BRMS), in production environments. In its most radical version, some proponents concede, the business rules vision promises to reduce—or eliminate altogether—the degree to which business users depend on IT.

Some readers suggested that BRM is a pipe dream.

“I remember a computer science teacher I studied with — in 1983, who thought we would ‘talk’ to computers,” says Rich Pletcher, a programmer with a prominent business intelligence vendor.

By "we," Pletcher explains, his computer science professor also meant business users, such that a user would be able to ask a natural language question—e.g., “How many people working in NY make more than $100,000 a year and are older than 45?”—and get a natural language response. While today it’s possible to “ask” a computer such a question, Pletcher concedes, it typically isn’t done using interrogative statements. “We ain't there yet. As a matter of fact, I know many IT people who couldn't write the aforementioned query.”

More to the point, he argues, even in cases where business users are able to interact with information systems in an interrogative, declarative, or quasi-natural language context, such capabilities are typically enabled by a boatload of complexity (e.g., ETL, OLAP, and reporting systems) beneath the covers. “All of the technology I have seen developed in terms of the gut, day-to-day, run-the-business-arena — attempts to solve three systemic problems,” he says. “The talent pool is shallow, companies are unwilling to train staff, and when they have talented people, they are unwilling to retain them by appropriate compensation.”

Dr. Lucian Russell, a veteran IT pro with a global services firm, sees another problem with the BRM vision.

“Given a set of business rules, adding a new one may create inconsistencies. This has been the issue from the beginning in all logic-based systems, and [that] is what is behind the need for regression testing,” he writes. “In the end, it is unlikely that many users will do their own business rules. Back in the 1980s, it was thought that SQL would allow users to create ad hoc queries. How many users write their own SQL today?”

Few BRM proponents, of course, are willing to advocate the use of business rules independent of thorough testing, much less oversight from IT. What’s more, the most sophisticated business rule management systems (BRMS)—such as those marketed by Fair Isaac Corp., ILOG Corp., and others—feature inferencing technology that’s able to make logical decisions about which rules to use in certain cases. That said, it’s unlikely any BRM vendor would say that inconsistencies between and among business rules aren’t at least possible.

There’s also something to be said for Russell’s second point. Namely, inasmuch as we’ve come a long way from the days of flat files and file management systems, we still haven’t come far enough—at least from the perspective of most business users. The question, of course, is whether we’ll ever come far enough—or whether there’s a kind of Zeno’s Paradox at work.

For example, says Russell, think back to the pre-relational days. “Databases in the 1970s emerged as a desirable alternative to file management systems. They were created, however, for a batch-processing environment where reports were hard copy. Management then complained that when questions occurred to them—new reports about data—that the only way they could get the answers was to have a programmer spend two weeks writing a program in COBOL,” Russell explains, noting that IT developed automatic report writers and query languages to address this problem. “As relational databases did not yet exist, the query languages required ‘navigation’ and thus were still the domain of the programmer.”

Ditto for relational databases and SQL, he continues. “Relational databases did not require navigation in the old sense. Also, when relational back-end databases were being developed there was a parallel development of query languages. As there were only, in theory, three operators needed to combine any data fields. The idea was that end users should be able to write queries that gave them any information they would be interested in,” he says.

The problem, of course, was that management upped the ante—or, much like the tortoise in Zeno’s Paradox, incrementally changed its own position—even as IT sought salvation in the relational model. “[I]t generally turned out, as it did on my project, that the key sticking point of management was being able to get the answers within a day, not necessarily immediately. SQL was found to be too hard for most users to master,” he indicates. “This led to a compromise where SQL procedures were normally written by the IT department and were run on separate platforms using data extracted from the operational data.”

With this, and other, examples in mind, Russell takes a similarly pessimistic view of the business rules approach. “The common thread with business rules and SQL, however, is to make things so ‘simple’ that a functional specialist does not need to bring in an IT person to do the job,” he says. “This will not happen. — To get a computer to produce a result, you really need somebody to understand exactly what the computer needs to do, and end users do not think with the necessary amount of logical precision and detail to do it cost effectively.”