Why Business Intelligence is a Bad Word

We're off and running with discovery (in depth evaluation) of an initiative that could be termed Business Intelligence or Analytics but we aren't going to call it that. Business Intelligence has become a bad word and in the never ending quest to support the needs of our hospital administrators we can't afford bad words. The challenge of communication between the clinical and IT communities is much too important. I was once told by an ex-boss that "why?" is my favorite question. Actually "how?" is my favorite. I like to understand things sooooo....

How is it that Business Intelligence became a bad word? In looking back I think there have been a variety of factors.

• Business Intelligence (BI) is a technology label and technology labels are usually dreamt up by salespeople to make product offerings sound cool. Over time best practices cause the labels to refer to some sort of architecture or other anatomy that is recognizable. The label endures however and lacking the newly evolved context suffers.
• Recently in reading an enterprise architecture text the difference between deploying IT solutions vs IT capabilities was highlighted. Deploying IT capabilities is a more forward looking and strategic endeavor. The difference however isn't always clear and when (as I have on occasion) heard IT folks talk about deploying a "robust business intelligence application" the wrong picture emerges. BI is an IT capability and should be treated strategically. Individual projects should focus on solving problems.
• When working with business leaders on developing IT capabilities it's extremely easy to fall into the "solution looking for a problem" trap. Unless the value of the capability can be defined in terms of business value or mitigation of risk it's like telling a joke and forgetting the punchline.

So again the challenge of communication between the clinical and IT world highlights itself. So if you want to start being pro-active and develop IT capabilities you best watch your language.

Application Porfolios and Old Data

At last count we had about 480 applications in our portfolio. The 80/20 rule applies here. We spend about 80% of our time and energy on 20% of those applications. We also have run about 30% availability for our staff to support projects although following our big EMR implementations we are now probably around 15%. The portfolio keeps growing too!

There are a lot of companies out there working to write software to make the hospital experience safer, more efficient, better for physicians and better for patients and they market very aggressively to our business leaders. Fortunately we have process in place to partner with them early on to evaluate these solutions. I can still remember the old days however when a department manager would walk on over to the IS office, drop off a couple of CD's and ask if we could have their software up and running next week. We've come a long way. Now we have IT governance reviewing the major IT investments and other bodies to assist our PMO's and facility specific PM's.

So where is the portfolio growing? We support three acute care facilities and they often have different application solutions for the same problems. We can sometimes achieve standardization between them but only when the departments see value in collaboration. Even when we do achieve collaboration or the time comes to swap out an application something has to be done with the old one or more specifically the old data. We need to archive it. We have to keep it around.

This creates weird artifacts like flat file dumps of data that get shoved into Oracle database. Applications up and running without support maintenance agreements because the end-users still like the old front end. Data conversion routines that leave some minute field leftover. Requests for 130 reports against a legacy database and engagement of vendors who specialize in taking old regulatory data and making it available.

It's wacky and it keeps our portfolio from shrinking. I'm curious to hear if anyone out there has a better solution.... Seriously....

Curve Ball City

All successful projects have sponsors, formal or informal, and formalizing the role is best practice. This applies to traditional IT implementation projects as well as process or organizational change projects.

We ask a lot of our sponsors. The IT Governance group is chaired by a non-IT leader and all of our key hospital leaders participate. It takes a lot of work to keep the content and focus on track. As sponsors we ask them to add to their own complex lives of caring for patients and communities in an ever changing regulatory environment. We add PMOs, processes, architecture and the costs of infrastructure, support and licensing. I can tell that it can be borderline traumatic. I have the utmost respect for them and do my best to support and serve them.

Language is of the utmost importance. In IT and healthcare we live in a sea of acronym soup. DR, ADT, ICDs, TQM, EIGRP, RAC, AD, LDAP and hordes of others. As IT leaders the burden is on us to learn the business, jargon and culture of healthcare while not burdening our business partners with the arcane (yet exciting) nuances of technology.

Technology projects are occasionally sponsored by members of the IT leadership and so I just celebrated my first anniversary as the sponsor for a huge forklift upgrade to our clinical application suite. We're scheduled to complete 3rd quarter of next year and while this challenge is not the same sponsorship required to rip out a ADT/billing system I'm starting to get a feel for what we put our business executives through.

It's been curve ball city or perhaps more like standing at the plate looking at Jamie Moyer wondering what in the heck is he gonna show you next. He winds up, the pitch comes flying down the plate breaking low and inside [scope doubles before the charter is signed], swing and a miss. He winds up again for the 0 and 1 pitch and lets fly, 89 miles of fastball, swing, get a piece of it and foul it off behind 1st base [ehr project schedule change delaying start project due to resource collisions]. Now the 0 and 2 pitch, a high arching curve ball, but it's high so hold the bat [vendor overcomes issues getting resources to the table]. I have no idea what the next one will be but I'm starting to get the hang of it.

Our hospital sponsors are mostly like a bunch of lead-off or designated hitters. I just hope I can knock a base hit in for the team.

Launching

In healthcare IT I sometimes feel we see governance best practices as a way to "customer as king". Combined with tight budgets and multiple priorities this gives us a good way to align with the patients, physicians and other customers that we support. It also keeps us in a supporting actor role. We don't often have the lead role. The times are a changing though.

I've been spending a lot of time thinking about architecture lately, and not the baroque kind. I've watched our HIS applications evolve from monolithic mainframe apps (PCS on a Tandem) to open n-tier architectures that separate the data, business logic and presentation layers. It's exciting to watch. One of my favorites is an emergency room app by Picis. I remember standing up an old version and being excited to see that it was built out of Apache and Perl. It's architecture lent itself to our ability to deploy it with load balanced redundancy for the presentation layer and clustering for the data layer. This opportunity allowed us to deploy it across several emergency rooms without having to purchase totally separate infrastructure.

That is the kind of opportunity that a well considered architecture will provide for you. Yesterday I attended a meeting where an extremely complex report specification was being worked out. Part of the report requires the aggregation of data that is easy to extract at a point in time but not pull retrospectively. Fortunately our DBA team and our report writers have agreed to a set of best practices that include the development of stored procedures behind the crystal reports. Again architecture comes to the rescue because the aggregation of the snapshot data is easy to accomplish by modifying the stored procedure to save the results in a timestamped custom table.

Many of the vendors we work with still consider their architectures proprietary (even though they are built on open systems) or the separation between development and implementation is stark enough that their support can't answer questions about how the app is built.

The punchline is that good architecture can make or break new opportunities. It can launch IS out of the supporting actor role into the emmy winning lead spot. Architecture can accelerate service delivery and new architecture is being developed every day. I think there are two challenges to unlocking it. First, choosing the right elements so that they create rather than restrain opportunities. Second, capturing and selling the value of nuts and bolts that can make the delivery of service so much easier and faster. A third just occurred to me. That is making sure that we have the right organization and processes in place to deliver.

We have the right talent in place to help us with the first and most of the third. The second is vexing to me at times. Initiatives get off the ground with the help of a lot of players. Launching the right projects is the key to a better life through architecture.