How BRMS empowers business people to rule their business
Unchain your business from IT! This article is about how Business Rules Management Systems (BRMS) can change software crafting and bring IT and Business together.
Nowadays traditional IT Systems are a bottleneck when it comes to aligining enterprises to our rapidly changing world. Traditional software is sluggish and not able to adapt reasonably to our everchanging world and society. On the other hand, software is the backbone of companies and crucial for business success. The detriment of having a business that runs on sluggish software is two-fold: You are addicted to the software system running your daily business, but you are not able to reasonably react to changing market situations. Not being able to react means your company is lost. Because competitors can. If you’re curious to find out why I think that traditional software systems are sluggish and about my personal experience with BRMS in practice:
Why is traditional software sluggish and constraining for business?
Let’s reflect on how a change to a traditional system is initiated and sketch the lifecycle of a change request.
- New requirement arises by business.
- Requirement is analyzed and specified by business department using sophisticated requirements gathering techniques.
- Requirements specification document is thrown over the wall to suspected freakin’ IT zombies*.
- IT department takes the document. After 2 weeks of analyzing they claim that requirements are unclear/not understandable and throw the document back over the wall to the snobbish suit wearers* of the business department.
- Business department does not have a clue why IT claims the requirements are unclear. They try to specify the requirements in more detail using the language they are used to. The document is thrown over the wall again.
- After the document has been picked up by IT again, the requirements must be translated into software:
- Technical design, implementation, unit tests, module tests, documentation, system tests, acceptance tests, release, deployment.
- After only 17 months changes reflecting the business requirement are shipped and ready to use. But not relevant any more.
*The stereotypes freakin’ IT zombie and snobbish suit wearer are joking exaggerations. They don’t necessarily reflect reality but underline sometimes present prejudices between both parties.
What is the root problem here? I think the problem is that both parties talk substantially different languages including different media breaks resulting in potential information conversion errors:
Business department -> requirements specification -> IT department -> technical design -> code
The information is converted at least three or four times, before it finally reaches its code-end-stadium. Each conversion results in loss or misinterpretation of the original requirement, ultimately resulting in unsatisfactory or wrong results. Thats the waterfall problem we all know of. Scrum tries to weaken this problem by introducing shorter feedback cycles. The root problem however, remains: Information loss due to the known “Chinese whisper” effect, media breaks and room for interpretation. We all know that this is highly inefficient and frustrating.
Chinese whisper is a nice game for kids. Stop playing it to develop mission-critical software systems.
What can we do? Let’s think about it: The main problem is information flow and loss of information. What if the snobbish suit wearer* implemented the new business requirement on his own? What if business departments were decoupled from IT, being responsible for their business domain? What if IT could concentrate on building and running software thus empowering people to improve their business? Each of us uses mail clients to deal with E-mails. None of us wants to wrestle with IT each time we send an E-mail. It’s a no-brainer. So why do we still build software requiring business people to beg IT for even the smallest changes in order to improve their efficency or worse, in order to stay competitive?
Give users the power to rule their business by providing the right tooling and runtime environment. Encourage business people to be responsible for their business.
This, of course, requires a change in the way how we construct and build software. We need tooling that both, business people and IT people understand, use and talk about. Tooling and/or techniques that make both parties work together and be creative instead of throwing documents over the (language) barrier. Interaction and direct communcation is much more our nature, thus much more useful than writing documents. A model-based approach or a domain-specific language are techniques to reduce the langugage barrier and get rid of the prejudices and instead start working together . People tend to be smart and creative. Software should encourage this potential instead of handicap its users.
Visual Rules (VR) is such a tool. It acts as a mediator to make business people and technical people understand each other, effectively eliminating the language barrier. Personally, I see Visual Rules as kind of a LEGO abstraction for programming. Visual Rules Modeler provides a palette of building blocks to model business rules AND visualize them at once. You’ve killed two birds with one stone:
- Having your business rules documented in a format everyone can understand as well as
- having it executable because VR has a code generator on board taking care of transforming your Business Rules into executable Java code!
That´s cool. I tell you why: It is pure separation of concerns and separation of responsibility. It is possible to enable business people to model their business logic (or at least review it), while IT people take care of integrating the executable models into solutions. I’ve seen business departments doing regular “model reviews” where the business rules were plotted and pinned or beamed on the wall in order to verify and review the business rules in collaboration.
The Dynamic Application approach of Bosch Software Innovations stretches this concept even further, enabling business users to create and maintain whole application logic. It is a runtime and modelling platform built for creating model-based business applications where decision, presentation, workflow and even integration logic can be implemented using VR Models. The runtime environment acts as a frame and deployment container for VR-Model-based Dynamic Applications, as we call it. A classic example is a Credit Rating Application, where the core scoring logic is encapsulated in one model. On top of that, there is an application model that defines the (typically) form-based user interface. A credit decision typically follows an approval process, which is encapsulated in a workflow model, namely the Stateflow. A clear separation of concerns.
I have been working as an on-site consultant in different business departments, e.g. in a credit risk rating department of a big mortgage bank for more than 6 months. (If someone from the team is reading this: greetings to the team room!) I have been responsible for customizing the runtime platform where the business models are executed and also for replacing a legacy batch processing engine. The department has been in the process of developing a new risk rating system with the goal to replace an inflexible legacy system. The cool thing about the project was that the people of the business department actually implemented their complex rating models, even the whole credit rating core applications on their own, using the mentioned Dynamic Application approach.
As consultants, our job was to enable the business department to gain responsiblity for their business logic, by mentoring, teaching, reviewing, and with any other collaborative work needed. Most rule consultants have IT background which is, in my opinion, a must at the initial phase of a project. Ultimately, the result is still software which should follow programming key principles like Dont’t Repeat Yourself, Separation of Concerns, etc. Someone is needed who knows those principles, who is able to adapt it to rule modeling and the most important part: Who is able to share this knowledge and guide modelers with no IT background. Collaboration between IT and business at its best.James Taylor considers collaboration as being the key benefit of using a BRMS. He mentions in his article that domain experts don’t want to “code” business logic. In many customer projects, I have experienced that business experts really like being able to model their logic and actively “craft” something using Visual Rules. Credit rating domain experts might be predestined for their mathematical background. Who knows. We have also experienced the contrary, of course. However, even if analysts refuse to implement the logic on their own, the other advantages of using a BRMS are still valid.
Back to the risk business department of the spoken mortgage bank: The department now is responsible for the core application logic. Changes and even new rating models are implemented, tested, documented and brought to production by the department with very little IT involvement. IT is responsible for the runtime environment only. The Chinese whisper is history for them. The risk department is able to immediately react on external factors, improve their own models, fill gaps or fix breaks, etc. without being constrained by IT or 3rd party. The business department has become agile and decoupled. A self-organizing unit within the company when it comes to improving their business logic and also their department-internal processes.
Let’s share experience!
Whew, this is a long article. Anyway I hope I was able to share some valuable thoughts from my personal experience using BRMS in practice. Now I would like to learn: What has been your experience using BRMS at customer projects? I’d be happy to discuss different experiences!
Last but not least: If you’re curious about trying Visual Rules, go ahead, fill in the evaluation form and start building your rules here.