Decreasing the Cost of Upgrades – System Integration

Decreasing the Cost of Upgrades – System Integration
George Hislop, Associate Vice President of Consulting – April 7, 2014

With the radical changes in health care, you’ve likely recently upgraded or are considering upgrading your key systems to keep pace with the needed features that the ever changing health care environment requires. Chances are, whether now or later, a problem you will face is the burden of upgrading all of the integration points attached to your core system. The reality is that many of the costs, delays, and performance issues associated with the upgrade were determined years ago when these interfaces were initially developed-and now you’re trapped into maintaining them.

Most upgrades have extreme time pressures so the impetus is to get them working as is, typically without examining if the customizations are even necessary as the feature may already be supported in the core system. These kinds of decisions have an anchor effect, not just on cost, but on performance and capabilities. The reality is that you have to examine all of these surround systems and ask yourself “what is the business purpose and is what we are doing it being accomplished in an efficient way?” in order to be able to move forward. Waiting for an upgrade to look at these systems will almost guarantee you won’t be able to do anything systematic or strategic to improve the overall system. This being the case, here are some recommendations to keep in mind:

Don’t Tightly Couple with Core System

In the past, the temptation was to make highly customized components that directly connected to the data source. We thought we knew better and could get the exact data we needed more efficiently than the vendor of the software. Inadvertently, we assumed the responsibility of updating and changing this code every time an upgrade occurred. This has by itself dramatically slowed the timing and increased the cost of upgrades. Wherever possible, these kinds of extensions should be decommissioned and instead use web services or other components that the vendor supplies. Generally speaking, you will now be able to consume that portion of your upgrade when you are ready for it through versioning, removing those applications from the upgrade critical path.

Look for Ways to Change the Metaphor (Real Time versus Batch)

Many systems were indirectly connected using extracts. This meant that the systems were out of sync for large periods of time, required reconciliation processes, and that they created periods where we could not update the data in both systems. With changes in the way data can be accessed, it may now be possible to update the data between systems on a more real time basis. Depending on the business purpose of the application, this can have significant operational and financial benefits for the company.

Make Changes via Rules Engines or Other Reusable Code Elements

Rules engines and SOA software have made significant strides and can now be used to automate many of the interfaces we used to write custom code for. This means that if done right, a change like an upgrade could be implemented by only making a configuration change. The benefit of using this software is that it not only reduces the time of upgrades, but it also reduces the time to market for new applications. Unfortunately, the software itself has a cost, so the implementation needs to be carefully evaluated and designed before just plunging in.