<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1194005000700189&amp;ev=PageView&amp;noscript=1">
VizuriBlogHero.jpg

From Vizuri's Experts

A healthcare use case for Business Rules in a Microservices Architecture [+source code]

A Business Rules Management System (BRMS) is a perfect complement to a Microservices Architecture. The reasons for implementing a BRMS are even more compelling in a Microservices Architecture.  

In this blog, I will discuss the reasons for using a Business Rules Management System (BRMS) in a Microservices Architecture and then explore a use case to demonstrate these benefits.  

Microservices Architecture is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms called an API. These services are built around business capabilities and independently deployable by fully automated continuous integration/continuous delivery (CI/CD) pipelines.  

The following diagram illustrates the difference between a traditional Monolith Application and an Application using a Microservices Architecture.  

Monolith Application vs. Microservice Architecture

Benefits of a Microservices Architecture:
  • Software built as microservices can be broken down into multiple component services. These services can be deployed and redeployed without compromising the integrity of the entire application.  
  • Services can be independently scaled.
  • If one microservice fails, the others will continue to work.
  • Code for different services can be written in different languages.
  • Services are easier to modify and understand. New team members can become productive more quickly.
  • Increased autonomy of individual development teams within an organization. Ideas can be implemented and deployed without having to coordinate with a wider IT delivery function.
A Business Rules Management System is a software system used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise. This logic is referred to as business rules. Business Rules include policies, requirements, and conditional statements that are used to determine the actions that take place in applications and systems.
A BRMS includes:
  • A repository, allowing decision logic to be externalized from core application code
  • Tools, allowing both technical developers and business experts to define and manage decision logic
  • A runtime environment, allowing applications to invoke decision logic managed within the BRMS and execute it using a business rules engine
Benefits of Business Rules Management Systems:
  • Externalize rules from application code
  • Write rules in domain language
  • Test rules independently from application code
  • Make consistent and efficient decisions
  • Quickly build resource optimization solutions
  • Shorten development cycles for faster time to market
  • Empower business experts to manage change directly
  • Reduce or remove reliance on IT departments for changes in live systems. Note that QA and Rules testing will still be needed in any enterprise system.
  • Increased control over implemented decision logic for compliance and better business management
  • Ability to express decision logic with increased precision, using a business vocabulary syntax and graphical rule representations (decision tables, trees, scorecards, and flows)
  • Improved efficiency of processes through increased decision automation

Bringing the Two Together

In a Microservices Archicture, Business Rules become Polyglot Microserivces that are incorporated in the Microservices Architecture. The autonomy of the rules services can reach deeper into the business because they are managed by the BRMS. These rules services then gain the benefits from the Microservices Architecture. 

Rules As a Microservice diagram 1

Business Rules Management Systems in a Microservice Architecture Use Case

To demonstrate Business Rules in a Microservice Architecture, let's explore a use case from the healthcare industry. In this use case, we have a series of SpringBoot Microservices based on the FHIR STU 3 data structure standard. These services allow the input of Patient, Family History, Medical Observations and Questionnaires to gather information about a Patient's health. The Business Rules Management Platform is utilized to implement business rules to perform Risk Assessments for Heart Disease, Heart Attack and Diabetes based on the Patient's medical information.  

The following diagram illustrates the components of the FHIR Medical Repository Microservice Application.  

Business Rules As a Microservice Medical Use Case

The Architecture to implement the FHIR Medical Repository Microservices Architecture Application includes the following:

  • 2SpringBoot - FHIR Microservices
  • Red Hat JBoss Business Rules Management System (BRMS) - The Business Rules Management System
  • Docker - Package Microservices for Deployment
  • OpenShift - Platform as a Service for Orchestrating deployments of Microserivces
  • Jenkins - Perform CI/CD pipelines
  • Git - Source Code Repository

Rules As a Microservice diagram 3 

Learn More

The code for the FHIR Microserivces and Business Rules is pushed to a Git Repository. From there, a CI/CD process is followed to build, package and deploy the services on the OpenShift Container Platform.

You can check out one of our recent webinars, viewable on-demand, detailing the FHIR Medical Repository Microservice Architecture Application here. The source code for the Microservices is located at https://github.com/Vizuri/openshift-fhir-rules-microservices. The source code for the business rules is located at https://github.com/Vizuri/openshift-fhir-rules-rules.

Next Steps

If you'd like additional information, or to schedule a complimentary consultation please don't hesitate to contact us.

Kent Eudy

Mr. Eudy is an Executive Director responsible for overseeing Service Oriented Architecture (SOA), Enterprise Integration and Java Enterprise Edition (JEE) practice areas. He has over 27 years of experience including 16 as a consultant. He has extensive experience in Enterprise, Application and Systems Architecture. He has led development efforts on these technologies for clients in various industry sectors such as retail, medical, government, and insurance.