I am the CIO of a large enterprise, the budget dedicated to our IT systems is consistently getting squeezed, yet the level of service demanded from these systems is always increasing. In this case, our main focus is on strengthening the laboratory capabilities. Let’s take a look at how our IT systems are supporting it.
To improve the laboratory capability, I first must understand the various elements that make up Lab.
In the graph to the right I can see how the capability breaks into business processes, then further into activities, and then the data objects required to perform each activity.
I’ve extended this graph from the Patient ID data object to see which systems create, read, and/or modify that data. Explore for yourself what systems are related to the other data objects by double clicking the other DataObjects (orange nodes) and then selecting ‘System’ from the dropdown in the upper right of the graph.
We now have a holistic view of all the systems that support the laboratory capability. It stands out that Patient ID is held by a large number of systems. Let’s take a look at the different systems.
Our application healthgrid calculates and presents the business value, technical maturity, and sustainment budget of each system or application to give insight into each one’s “health” relative to the portfolio as a whole.
These three coordinates depict how well each system is supporting the enterprise, how well the enterprise is supporting each system, and finally how much each system is costing the enterprise, providing a comprehensive high-level view of the portfolio.
In this case, System 5 on the left has large sustainment costs but is not driving significant business value, which signifies potential for decommissioning. On the other side we see System 6 with one of the highest business values and technical maturity score as well, meaning it is essential to the enterprise despite its high costs.
Let’s take a look at system similarity to uncover redundancies that exist among our systems and discover unique functionality that may make a system crucial to the enterprise.
Duplicated data and functionality among systems leads to unnecessary costs, but these duplications are hard to find because they can exist at various levels of an enterprise.
SEMOSS makes uncovering redundancies simple by mapping and displaying the similarities that systems have with each other across a wide range of characteristics, such as where it is deployed and who are its user types.
Earlier, we identified System 5 as a system to further investigate. Now let’s click on System 5 along the top of the map so that the column lights-up. We see that all of its properties are duplicated by other systems in the enterprise--it provides nothing unique. System 6, on the other hand, has a number of properties that no other system in the enterprise currently provides. This further suggests that it is a critical system that should be well maintained.
Let’s take a look at this network of system-to-system communications to see how each system uses and passes Patient ID data.
The connections are easily visualized through SEMOSS, exposing complex hidden dependencies within the enterprise and revealing the relative importance of each system.
In particular, we see that System 6 is one of only two systems with a direct relationship with the data object, meaning that it is a creator of Patient ID data, and the vast majority of the other systems depend on System 6 for their own Patient ID data. System 5 in comparison has no systems below it, meaning that no systems depend on System 5 for Patient ID data, and is thus relatively less important.
Through these various visualizations, we have just completed a holistic analysis of our portfolio and have begun to get an idea of what systems can be looked at for retirement and which should be upgraded and maintained.