The Data-Centric Hospital

Why software change is not as graceful

‘The Graceful Adaption of St Frances Xavier Cabrini Hospital since 1948.

This post has been updated to reflect the current corona virus crisis. Joe Pine and Kim Korn authors of Infinite Possibility: Creating Customer Value on the Digital Frontier say the coronacrisis will change healthcare for the better. Kim points out that although it is 20 years late. It is good to see healthcare dipping a toe in the 21st Century. However, I think, we have a long way to go.

Dave McComb in his book, ‘The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems, suggests that buildings change more gracefully than software does. He uses Stewart Brand’s model which shows how buildings can change after they are built.

Graceful Change

I experienced the graceful change during the 19 years that I worked at Cabrini Hospital Malvern. The buildings changed whilst still serving its customers. To outsiders, it may have appeared seamless. To insiders charged with changing the environment, it took constant planning and endless negotiation with internal stakeholders and the surrounding community.

Geoff Fazakerley, the director of buildings, engineering, and diagnostic services orchestrated most of the activities following the guiding principles of the late Sister Irma Lunghi MSC, “In all that we must first keep our eyes on our patients’ needs.”

Geoff, took endless rounds with his team to assess where space could be allocated for temporary offices and medical suites. He then negotiated with those that were impacted to move to temporary locations. On several instances space for non-patient services had to be found outside the hospital so that patients would not be inconvenienced. The building as it now stands bears testament to how Geoff’s team and the architects managed the graceful change.

Why software change is not as graceful

Most enterprise software changes are difficult. In ‘Software Wasteland: How the Application-Centric Mindset is Hobbling our Enterprises’, McComb explains that by focusing on the application as the foundation or starting point instead of taking a data-centric approach this hobbles agile adoption, extension and innovation. When a program is loaded first, it creates a new data structure. With this approach, each business problem requires yet another application system. Each application creates and manages yet another data model. Over time this approach leads to many more applications and many additional complex data models. Rather than improving access to information this approach steadily erodes it.

McComb says that every year the amount of data available to enterprises doubles, while the ability to effectively use it decreases. Executives lament their legacy systems, but their projects to replace them rarely succeed. This is not a technology problem, it is more about mindset.

From personal experience, we know that some buildings adapt well and some don’t. Those of us that work in large organisations also know that this is the same with enterprise software. However, one difference between buildings and software is important. Buildings are physical. They are, to use a phrase, ‘set in stone’. They are situated on a physical site. You either have sufficient space or you need to acquire more. You tend to know these things even before adaption and extension begin. With software it is different, there are infinite possibilities.

Software is different

The boundaries cannot be seen. Software is made of bits, not atoms. Hence, we experience software differently. As Joe Pine and Kim Korn explain in their book, ‘Infinite Possibility: Creating Customer Value on the Digital Frontier’, software exists beyond the physical limitation of time, space, and matter. With no boundaries, the software provides the opportunity for infinite possibilities. But as James Gilmore says in the foreword of the book, most enterprises treat digital technology as an incremental adjunct to their existing processes. As a result, the experience is far from enriching. Instead of making the real world experience better, software often worsens it. In hospitals, software forces clinicians to take their eyes off the patient to input data into screens and to focus on the content of their screens.

More generally, there appears to be a gap between what the end-users of enterprise software expect, the champions of the software, and the expectations of software vendors themselves. The blog post by Virtual Stacks makes our thinking about software sound like a war of expectations.

The war of expectations

People that sell software, the people that buy software, and the people that eventually use the software view things very differently:

  1. Executives in the C-Suite implement an ERP System to gain operational excellence and cost savings. They often put someone in charge of the project that doesn’t know enough about ERP systems and how to manage the changes that the software demands in work practice.
  2. Buyers of an ERP system expect that it will fulfil their needs straight out-of-the-box. Sellers expect some local re-configuration.
  3. Reconfiguring enterprise software calls for a flexible budget. The budget must provide for consultants that may have to be called in. It needs to provide for additional training and more likely than not major change management initiatives.
  4. End-users have to be provided with training even before the software is launched. This is especially necessary when they have to learn new skills that are not related to their primary tasks. In hospitals, clinicians find that their workload blows out. They see themselves as working for the software rather than the other way around.

The organisational mindset

Shaun Snapp in his blogpost for Brightwork Research points out that what keeps the application-centric paradigm alive is how IT vendor and services are configured and incentivised. There is a tremendous amount of money to be made when building, implementing and integrating applications in organisations. Or as McComb says, ‘the real problem surrounds business culture’.

Can enterprise software adapt well?

The short answer is yes. However, McComb’s key point is not that some software adapts well and some don’t, it is that legacy software doesn’t. Or as the quotation in Snapp’s post suggests:

‘The zero-legacy startups have a 100:1 cost and flexibility advantage over their established rivals. Witness the speed and agility of Pinterest, Instagram, Facebook and Google. What do they have that their more established competitors don’t? It’s more instructive to ask what they don’t have: They don’t have their information fractured into thousands of silos that must be continually integrated” at great cost.’

Snapp goes on to say that ‘in large enterprises, simple changes that any competent developer could make in a week typically take months to implement. Often the change requests get relegated to the “shadow backlog” where they are ignored until the requesting department does the one thing that is guaranteed to make the situation worse: launch another application project.’

Adapting well

Werner Vogels, VP &CTO of Amazon provides a good example of successful change. Use this link to read the full post.

Perhaps as Joe Pine and Kim Korn say the coronacrisis will change healthcare for the better. I have written about using a data-centric model to query hospital ERP systems to track and trace materials. My eBook, ‘Hidden Hospital Hazards: Saving Lives and Improving Margins’ can be purchased from Amazon, or you may obtain a free PDF version here.

Len Kennedy
Author of ‘Hidden Hospital Hazards’

Scroll to top
Skip to content