Microservices enable developers in healthcare and other industries to create applications made from loosely coupled services, making them easier to develop, test, deploy, and upgrade. These benefits are leading healthcare developers to embrace microservices over the previous generation of IT integration technology, the Enterprise Service Bus (ESB).
Like any large enterprise, a healthcare organization's IT environment is a sprawling collection of diverse systems that need to share mission-critical data. The admission/discharge transfer system (ADT), scheduling system, lab system, radiology system, and billing system, just to name a few, all need to communicate—and that data can be vital during a medical emergency.
In the digital era, healthcare providers have adopted Electronic Healthcare Records (EHR), but there is limited value to EHR unless the data can be shared between those many applications. The challenge of healthcare system integration goes back decades, to 1987 and the establishment of Health Level Seven (HL7), the global standard for transfer of clinical and administrative data between applications used in healthcare. After this common language was established, the healthcare industry needed a way to connect applications so they could communicate via HL7.
Years ago IT practitioners learned that making direct point-to-point connections between each application is not practical and becomes more challenging as the enterprise grows. In addition, although HL7 offered a universal format, there was not a common way to interpret the fields, so some data transformation was needed, as well as connectivity, to support communication between healthcare systems.
The first integration technology adopted by healthcare providers was the Interface Engine (IE), a server that acted as a hub between all systems inside a hospital. Each system would connect with the IE, which would transform the data and route it to the other systems as needed. Then the Enterprise Service Bus (ESB) emerged about 20 years ago. Similar to the IE, an ESB serves as a hub to exchange data between healthcare applications, primarily using HL7. An ESB provides data transformation, protocol conversion, routing, and support for web services, JMS, HTTP and SOAP — as well as easy management and monitoring. ESB has been the most popular solution for integration (in healthcare as well as other industries) for two decades.
Since the introduction of the ESB, application development has evolved significantly. One of the most important changes is the move towards agile development and DevOps, leaving ESBs behind.
The DevOps pipeline is a development lifecycle based on incremental changes and continuous automated testing. In the age of DevOps, the characteristics that once made ESB popular now serve as a hindrance. An ESB has all integrations deployed into one monolith. While that had advantages in the past, it is now the problem that makes ESB incompatible with DevOps.
In the modern development environment, ESBs present the following limitations:
- Incompatibility with agile developers and DevOps tools: Many of today's new developers, just out of college, are trained in a DevOps environment. These agile developers are most productive when using their preferred tools, the latest DevOps solutions on the market — but ESBs were not designed to support these tools.
- Changes impact the entire system: When you need to make any change to rules on an ESB, even small changes, you need to pause the entire engine, which means any application interacting with the ESB will experience disruptive and unproductive downtime. Similarly, any error introduced by the change could potentially impact all your integrations. The result is a counterproductive team mentality that resists upgrades and fixes.
- Single point of failure: Because all integrations are routed through the same hub, an ESB represents a single point of failure for the entire enterprise. If the ESB goes down, all your integrations go down.
- Inability to automate testing: Automated testing is a key component of DevOps. In the DevOps pipeline, every update is tested independently, so it does not disrupt the development process. This is accomplished through automation. However, the ESB's proprietary GUI and version control make automation impossible.
Healthcare, like other industries, has embraced the new development practices of microservices, devops, and agile. This embrace has extended to healthcare integration as well; the new applications and digital touchpoints require integration in HL7, REST, and other protocols. Microservices developers in the healthcare world want to control their integrations along with the other code they develop (e.g. data, streaming, GUI, command and control, etc) and package all changes in deployable units that travel through CICD. The limitations above inhibit this goal of CICD for integration code with other code.
Microservices are the future of development, and the ESB is simply not compatible. While ESBs are monolithic, microservices are the opposite—enabling developers to create applications and integrations using building blocks of loosely coupled services. By breaking applications into independent modules, it is easier to develop, test, make changes, test again, fix, deploy, test in production, upgrade and so on.
Microservices make DevOps possible because they enable automated testing. Since microservices represent small components, they easily fit into containers, which can automate the testing process and facilitate continuous integration and continuous delivery (CI/CD). On the other hand, a monolithic ESB is too large to fit into a container, and cannot be broken down into components, and therefore cannot be tested the same way.
But maybe the most important reason to adopt microservices-based integration is to support agile developers and allow them to use their favorite DevOps tools. By removing ESB from the equation, you are freeing developers to work in an agile development environment they are not only familiar with, but also prefer. Without ESBs, developers do not have to be trained on a proprietary system, but instead can focus on a more productive development approach.
In addition, microservices democratize integration by allowing developers to explore their own integration needs, rather than restricting integration to an isolated team of ESB specialists. This makes more sense because no one understands the data requirements of the application better than the application developer.
Microservices also support API management, allowing for API-based integration when necessary.
Meanwhile, microservices-based integration offers you the same advantages that you gain from an ESB, such as graphical transformation and the logic to create sophisticated rules about how data flows through your enterprise. For example, you may like the ESB's graphical development canvases, but you can find similar canvases that support microservices-based integration.
Microservices-based integration delivers several bottom-line benefits including:
Comprehensive monitoring and management: Microservices can be monitored by state of the art tools preferred by agile developers (ie. Kibana, Elasticsearch, Grafana, Prometheus, etc.) to pinpoint points of failure so you can solve issues before they become problems that impact the business.
Automated testing: One of the greatest advantages of microservices and DevOps is the ability to do automated testing. Each integration is treated as an independent component as it goes through the testing process, without disrupting other components of the application or other applications.
Superior software quality: Ultimately, more efficient processes and improved testing results in higher quality software.
Accelerated development: By streamlining the integration development process with DevOps and automation, and eliminating formerly manual processes, you speed up the development lifecycle.
Greater scalability: Because applications are composed of independent modules, each service can be scaled up independently without impacting the rest of the application.
Advanced Innovation: Microservices and DevOps together empower your developers to innovate integration solutions to enable your organization to introduce new services, and serve your customers better.
Business agility: Agile development naturally leads to business agility, the ability to react quickly to changes in the market. For example, new partners or vendors that require data sharing can be quickly onboarded as the agile development team leverages microservices to rapidly build the integrations necessary to support the business relationships.
Improved customer experience: Your fundamental goal is to serve your customers — the patients that depend on your healthcare services every day. By improving processes and seamlessly sharing data between systems and departments, you ultimately ensure a satisfying patient experience.
You may see the task of migrating your integration to microservices as a daunting undertaking. Why make the change? After all, your team is already familiar with the proprietary aspects of the ESB you have depended on for so many years. But therein lies the problem. What if one or two of your ESB experts leave the organization? What would it take to regain that level of skills?
The fact that it seems to be too much trouble to move beyond this monolithic ESB is the very reason to go through with it. When you break free from the limitations of the ESB, you can enjoy the benefits that come with a whole new world of integration.