Creating Functional LIS Teams in a Cloudy, Virtualized World

Healthcare IT has been slow to embrace the cloud and virtualization. However and to a large extent, this shift will be driven by vendor acceptance and adoption of this architecture. Nevertheless, a recent article about our future cloudy, virtualized world contained some important recommendations (see: Creating Functional Teams In A Cloudy, Virtualized World). Below is an excerpt from it.

Lately we're talking to CIOs and IT managers who feel more like referees. It used to be, we just had to moderate between end users and security or the helpdesk. But now, as the data center evolves to include pervasive virtualization and a mix of in-house and cloud IT assets, the internal turf battles are threatening to KO agility advances. It's unarguable that virtualization--on premises or in the cloud--has increased flexibility exponentially. Getting a new server online used to take weeks, between the procurement, rack-and-stack, and configuration cycles. Today it takes minutes. Cloud computing, particularly infrastructure as a service, ups the agility ante even further by blurring the relationship between software and hardware....And there's the root of the conflict: Infrastructure staffers feel a certain ownership of the infrastructure product. Everyone else is an outsider who doesn't know jack. And the feeling is returned by your application developers, because, naturally, the infrastructure exists only so that they can work their magic on it. The third leg of the IT stool, the support team, just looks on, wonders why we all can't get along, and just knows that agility, and, ultimately, customer service, will suffer if the posturing doesn't stop....

The problem is that your staff may not be ready to embrace a fundamental new reality: IT is not individual products. From a customer standpoint, it's a blended service. No one cares whether an application is slow because of buggy code or an overloaded server.....Could the bystander, the support team, be part of the solution? Or maybe a new, cross-functional "devops" model, gussied up with a little service management, can help you serve your business in a more responsive and agile way? Devops is a formalized set of principles meant to break down the walls between the application development and IT operations teams. No cooperation, no agility, the thinking goes....[An industry CTO] says CIOs need to help staff understand that they're no longer "infrastructure managers." They're service managers. There's a reason why private and public cloud offerings alike are referred to with the "as a service" moniker. There are different skills involved when operating in an infrastructure manager versus a service manager role. For example, when's the last time that your infrastructure manager had to soothe an upset customer? Right. The support folks do that for them. And, not all infrastructure managers handle vendor SLAs, clearly an important role for them, but sometimes delegated to someone in "the business office."

Considering LIS support groups in hospitals, I very much like the following concept contained in this article: running IT as a blended service. Within these LIS groups, I envision three types of managers, each with the necessary support personnel: (1) end-user support; (2) operations/liaison with the LIS vendor and hospital EMR staff; and (3) infrastructure. As hospital server rooms migrate to the cloud, these hardware personnel will continue to be tasked with managing infrastructure but from a distance. Responsibility for security, disaster recovery, and the deployment of new software will be spread across these three groups.

In the LIS world, there is little requirement for the "dev" embedded in "devops" because most of the software development responsibility remains with the LIS vendor. Back in the day and to a certain extent now, a major hospital pathology department could help establish the development agenda for their LIS vendor. Such large labs also tended to serve as beta testers for any new software. The underlying philosophy of the part of these companies at that time and vis-a-vis their larger clients was the following: if we can satisfy our restless, big hospital clients, we can satisfy our smaller hospital clients. Conversely, the software development philosophy for Meditech and its current clone, Epic, has always been: we will manage all new software development and releases across all clients. This is part of the contractual understanding between large hospitals and Meditech/Epic: these companies offers successful system deployments and managment in exchange for control of the standardized software product.

Comments

[Mark McCuin]

This is such a great quote in your post, "No cooperation, no agility, the thinking goes....[An industry CTO] says CIOs need to help staff understand that they're no longer "infrastructure managers." They're service managers."