Is Buy to Build as David is to Goliath???

In the January CIO Connection (the CHIME newsletter, no I'm not a member but a friend is) there was an interesting article on some questions asked by Insurer Executives at a Healthcare IT Summit. One of the questions was "Should our organization take a build versus buy approach to BI?". This is a good question.

When I first came to my organization it was literally in the basement as an operator changing tapes and printing UB94s. Well, before that I was a dialysis equipment tech but that was before my IT days while I was still in college. Once I got out of the basement I started working as a UNIX admin and that's how I got involved in a custom clinical portal development project. Basically two developers, a DBA and a UNIX admit had built a system that slurped up DI and Medical Records dictations in HL7 messages, dumped them to a UNIX box, loaded them into an Oracle database and presented them on the web via Cold Fusion. There were some other interesting apps that enabled physician to physician messages (almost a pre-twitter twitter really) and the ability for a MD to grab a rounding list from a Kiosk when they walked in the door. All of this before cascading style sheets and widespread use of XML. It was cool!

Until one of the key developers left and those of us who stayed behind were left the legacy of several undocumented VB4 programs running on an NT4 server that used a weird set of spaghetti like database links and PL/SQL scripts. For a long time we were afraid to touch a lot of it until we rewrote the pieces that we wanted to keep and a few years later we implemented our preferred vendor's physician portal product with great success. Now we spend some time customizing that portal so that it integrates well with some other apps that the physicians need.

So the CIO Connection article went on to point out pros and cons of both the build vs buy BI approaches. In a nutshell, build gives you depth and control while requiring more business engagement and solid processes. Buy gives you shorter time to value with less flexibility and more risk of creating information silos. Analysis like these make deciding the right path about as clear as mud. It also makes the article pretty accurate.

I've rolled the connundrum around in my head for a long while. Given the emerging maturity of the HITSP standards for integration (considered a "glimmer" on the Gartner Hype Cycle), accelerated adoption of EMRS, economic pressures and moral obligation to continue improving patient care I've fallen on the customize/build side when it comes to Business Intelligence. The need to understand, care for, manage and secure our organization's data REQUIRES that we have high levels of business engagement/sponsorship and effective process. The deep expertise required to customize/build that environment forces the issue and the facilitation in a way that "packaged" tools don't. Plus the addition of the packaged tool vendor adds a third relationship to an already complicated mix.

I feel less strongly about building other key functions, web and collaboration tools aside. The thing that might change the game over time would be widespread adoption of HITSP standards as the glimmer brightens to a beacon. Then the art of integrating systems or delivering information to the right stakeholders becomes much easier. The interfaces between systems become predictable and the data that passes in between is better defined. Organizing the components using techniques like SOA and SAAS improve flexibility and ability to respond without sacrificing supportability.

Then build would be to David and buy would be the Goliath...