You can think of the Business Rules Movement as the catalyst that makes a bunch of other techniques and technologies finally gel. On the business side there’s been the movement towards formalized process modeling with the associated entity modeling typical of the IDEF 1.x style approach; and a focus on metrics-based process improvement particularly via TQM and Six Sigma. On the IT side there been the whole Business Process Management framework implementation with the associated Business Process Monitoring pieces to provide streams of real-time metrics. What’s separated the two is that once IT put the business processes into their Business Process Management framework two things quickly became readily apparent:
1. Details of how the business processes were controlled had no place to be captured so they were still implemented “underneath” the business processes by IT and were invisible to the business.
2. Once the business processes were put into the technology platform, they no longer looked like those that the business provided.
So along came the white knight known as Business Rules to save the day. The business side had known all along that there was some significant complexity underlying the control points in their processes but they didn’t have an effective technique for dealing with the issues. The IT side had written code for this kind of need for decades but before the emergence of Business Rules Management Systems they did not have technology specifically adapted to help deal with this problem. So business and IT read the latest writings of the business rules apostles and they agreed to externalize their business rules from their business process and then the happy business and IT partners rode off into the sunset. Not so fast… While this kind of approach deals with the first problem we identified, the second problem still remains or maybe even gets worse. After all, business agility is the result of getting domain experts to be able to make changes to business behavior at the speed that they can specify the changes. Putting another tool into the mix to capture another part of their problem doesn’t directly address this. That’s where the movement part of the Business Rules Movement comes in.
The Business Rules Movement is about more than just a new technique for business modeling as well as more than just a new technology for IT to deploy. The movement is about delivering business agility. Of course, new business modeling techniques and new IT technology can be key tools in helping to achieve this agility, but there’s more to it than just that. That’s because attacking the business agility problem involves changing the relationship between business domain experts and IT domain experts. Techniques and technology are enablers for achieving the organizational ability to perform with agility, but they are not alone enough to deliver that agility.
Earlier we identified that business agility revolves around the ability of domain experts to make changes to business behavior at the speed that they can specify the changes. What is it that impedes most organizations from achieving this agility? The answer to this question is complex, but if we look at it from the perspective of the business analyst we see the outlines of the problem.
Let’s say that you are the business analyst for a project where some extensive changes are being made to the way that an existing business process behaves. Traditionally, the business analyst acts as an intermediary between the business and the IT elements of an organization. In reality, business analysts sometimes are strictly order-takers for the business side acting solely as a buffer to insulate the business from IT demands and other times they are de-facto domain experts who create a draft design of the business automation solution to a business need. But if the “business” side is going to be able to change business behavior of the automation solution “at the speed that they can specify the changes”, then the individuals designing these solutions must be the individuals that are responsible, from a business perspective, for the correct behavior of those solutions from a business standpoint. That makes it essential that these individuals become what in most industries we would think of as “product designers”.
This is an important first step but even it still isn’t enough. What’s still missing? Traditionally product designers are responsible for making sure that they work with the folks that design the production facility to make sure that the product can be produced efficiently and with quality. Translated into the world we’re discussing, that means that the role we are talking about not only needs to be able to create a fully defined business product specification, they also need to be able to work with the IT area to make sure that it is feasible to produce at a defined cost. What we don’t want to end up with is with a product that meets the business specification but is so complex and expensive to operate that they business can’t afford it. Sometimes the biggest threat that IT can make is to “build it as it was spec’d” because they know that the individuals in charge of creating these specifications often have not made these kinds of considerations and it is up to IT to push back.
Of course, this new type of role on the business side requires a realignment of the role that the IT partners play as well. If we are going to expect that the business side can create complete product specifications then we must be able to eliminate the “translation” that turns these specifications into code or some other representation that cannot be controlled by the business side. Taking this approach involves moving the IT organization away from the idea of coding a business application. Instead, IT is expected to engineer platforms to execute business logic that can be inspected, and ultimately modified directly by the business side. Think of this as the equivalent of IT providing a machine tool that can mill any range of parts whose specification is loaded into it. This kind of approach means that IT is free to focus on engineering instead of being a code translator for business specifications.
While these are major changes to how the business side and the IT side work together there is a strong reason to believe that this kind of change is coming. Probably the key factor driving this change is that the current working relationship has shown itself to be both unresponsive and expensive. The interest in business rules approaches and their promise of increased business agility also indicates that the business side is looking for a change. Most IT organizations would be happy to have the business side take over more responsibility for business behavior as well so that they could focus on what they do well, designing and running the production facilities. It’s a new way of working with your partner, on either side, and there are sure to be missteps on the way. It can take some patience and a willingness to try a few new dance steps.
