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.

Our approach

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:

  1. Having your business rules documented in a format everyone can understand as well as
  2. 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.

This screenshot shows a simple Flow Rule in Visual Rules Modeler calculating a BMI score. On the left side the palette with “LEGO”-like building blocks to create business rules. On the right side is the interface of this Flow Rule with input/output parameters.

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.

My experience

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.

[1] Wikipedia: business rules engine

[2] Wikipedia: business rules approach

About The Author

Arthur Hupka

I have graduated in Computer Science and I am working for Bosch Software Innovations since 2009 as a Java Developer and Technical Consultant with expertise in web applications and batch processing. The past two years I have been involved in several credit risk rating projects and spent months at different customer sites. Recently, I have joined the product development team. I’m interested in all aspects of software development like (component based) software design, architecture, code quality, tests, scrum, etc. In my spare time I'm also experimenting with my own project based on Apache Wicket, Brix CMS, and Google Guice. I enjoy doing sports like bike cycling, beach volleyball and snowboarding. Lake Constance is a great area for doing that btw! I also like reading and visiting festivals during summer. Sometimes I enjoy cooking but I hate housekeeping.

2 Responses

  1. Caroline Buck

    Hi Arthur,
    thanks for sharing your experiences!
    When I was a business rules consultant, I used to hang up wall-sized plotted sheets of graphical rule models (due to the fact, that beamers of those days had no acceptable resolution capabilities) and discussed them with business experts at health insurances, retailers, banks, you name it. This worked definitely so much better for everybody in the projects than agonizing through ultra-longish requirements and target specifications.
    This is old school stuff using the parent technology of Visual Rules, but still appropriate. :)

    Caroline

    Reply
  2. Eddy Baldwin

    While newer software tools are able to combine business rule management and execution, it is important to realize that these two ideas are distinct, and each provides value that is different from the other. Software packages automate business rules using business logic . The term business rule is sometimes used interchangeably with business logic; however the latter connotes an engineering practice and the former an intrinsic business practice. There is value in outlining an organization’s business rules regardless of whether this information is used to automate its operations.

    Reply

Leave a Reply

Your email address will not be published.