Selecting New Applications

Every week, I'm asked by customers to collaborate with them to choose new applications.

Here's how we do it.

1. First, we take an enterprise view of each application request, since we would much rather consolidate applications and reduce the number of vendors than provide a new niche application for every evolving departmental need. If an existing enterprise application cannot meet the user's requirements, we then survey the marketplace.

2. We do not believe in Requests for Proposals (RFP). RFP means Request for Prevarication, since most vendors do their best to answer RFPs with as many positive responses as possible. Instead, we review the marketplace, often via the web and and by reviewing summary evaluations from KLAS reports. We pick the three or four applications which seem to best meet our stakeholder functionality requirements.

3. Once we have a small number of applications identified, we evaluate them for their suitability in our infrastructure environments using a formal process. In 2003, we created a Change Control Board to orient the infrastructure team to new applications that are being proposed. The forum meets weekly and has broad representation, including help desk, desktop, servers, storage, networking and security staff. The checklist of issues we review is here. Note that this screening sheet evolves as technologies evolve. Two years ago, we would not have asked about compatibility with VMWare/Virtualization technologies. Also, this list is expanded to address those issues arising from bad experiences, so we do not repeat them.

4. Once an application is approved for suitability in our infrastructure environment, application teams then work collaboratively with our customers to

a. Manage all vendor relationships including scripted demonstrations, contract negotiation, installation/training and life cycle maintenance of the application.
b. Manage integration with our existing applications. Typically this is done via our eGate messaging engine or via web services, since we have widely deployed a service oriented architecture.
c. Define service levels, a disaster recovery strategy, an escalation plan for issues, and division of labor for support of the application. Typically, IS manages the infrastructure and keeps the application running smoothly. Power users in the department document workflow and ensure the application's functionality is optimized to support that workflow.

Over the past ten years, we've found that this collaborative approach with IT, rather than having each department select its own applications, ensures stability, maintainability and scalability. At this point, most departmental IT systems and staff at BIDMC have been replaced by services from the central IT organization. It's a win/win for everyone, since costs decrease, quality increases, and the frustration of choosing an application which does not work in our infrastructure has been eliminated.