Challenge #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 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 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.

Challenge #2: Business Communication

Do people in your company always mean the same thing when they use the same terms? Almost certainly not, right?! So ask yourself, how good are your business communications and requirements likely to be if people don’t mean the same things by the terms they use? And how good is your automation likely to be?

Gurus talk about application or functional silos in organizations. I believe the problem is even more basic than that — organizations today essentially have semantic silos. Look under the covers of any broken process or poor set of requirements and you inevitably find poor communication practices.

These days you don’t have the time not to define, structure, and manage your business vocabulary. A concept model is no luxury.

Challenge #3: Managing Operational Business Knowledge

Many or most IT methodologies remain essentially in the Dark Ages with respect to knowledge management. They focus blindly on pumping out code faster and faster. We may be living in a knowledge economy, but we’re sure not acting like it.

When I say knowledge management I don’t mean what probably comes to mind. I’m not talking about fuzzy text in vast e-mail archives or tacit knowledge in people’s heads. I’m talking about explicit business rules. Business rules (done correctly) represent knowledge — core operational knowledge. Many companies today are in peril of losing or outsourcing that knowledge.

Who’s to blame? Business managers for not ‘getting it’ of course. But that’s just where the buck stops. Ultimately practitioners are to blame. They’re not making core operational knowledge tangible to their managers.

How do you make that kind of knowledge ‘real’? Business-side rulebook management. That’s no longer optional either. In a knowledge economy your company simply can’t afford to lose its business rules!

Next Article: A Clear Path – Part 2 of 4

In the second part of this four-part series, Ron discusses the steady progress in ideas, tools, and techniques for business rules that has taken place over the past two decades.


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