The following was a guest blog post on HealthcareScene.com.

Healthcare as a whole is finding new ways to use technology to improve population health and patient experience. Population health is looking for a spectrum of precision in patient and provider data as well as clinical cost metrics and matching that data to patient communication, metrics and clinical outcomes. Patient experience requires streamlining information that is both timely and personalized, which is hard to accomplish with monolithic systems.

A monolithic system is usually one that has grown over many years and performs numerous functions that are not architecturally separated. These systems tend to be brittle and not easily changed.  The proliferation of mergers and acquisitions in healthcare further exacerbates the complexity of operating multiple monolithic systems within a healthcare network. It is not unheard of to operate 5, 8 or even 12 billing systems in parallel, because combining them would take so much more time, and it is more cost effective to let them operate individually.

Read the full post.

All 3 parts of this Blog Series can be found at InfoWorld.

Previously in this three-part series, I wrote about how to introduce microservices in a legacy environment and provided an overview of domain-driven design (DDD) and how this development philosophy can be used to represent the real world in code, while also being well-suited to a microservices implementation. This time, I cover some of the tools and frameworks that can be used when implementing microservices.

I deliberately saved the tools discussion for last because I often find clients like to jump into tools before they have completely thought through why, and if, a new architectural approach can or should be implemented in their environment. After you have decided that you should move to microservices then it’s appropriate to think about how it can be done and with what tools.

...Read blog 3 of 3

How the domain-driven design development philosophy can be suited to microservices

In November, I delved into explaining how microservices can be introduced into a large organization with well-established legacy systems. In this post, I cover domain-driven design (DDD) and how this development philosophy can be used to represent the real world in code while being well-suited to a microservices implementation.

Read blog 2 of 3.

It is critical to balance risk with reward and, when it comes to microservices, embrace an evolutionary approach and process

While no consensus exists on how to define microservices, it is generally agreed that they are an architectural pattern that is composed of loosely coupled, autonomous, fine-grained services. The services are independently deployable and communicate using a lightweight mechanism such as HTTP/REST. Enterprises that need to make frequent changes to their systems—and where time to market is paramount—need to be investigating how to introduce microservices in their legacy environments to realize a digital transformation that drives tangible business results.

The benefits and potential hurdles associated with adopting microservices are well documented. On the plus side, the modular and independent nature of microservices enables improvements in efficiency, scalability, speed, and flexibility. Detractors, however, frequently point to management and security challenges, especially when they pertain to customer-facing applications and services.

It’s all about the monkey

Read the full blog post on InfoWorld.com: