My “2 hour” project: Creating an RFP for APM Tools

Last week, I was reminded of how hard it must be to be a buyer of enterprise software these days – especially Application Performance Management (APM) software.  It all started with an innocent request from one of our channel account managers at INETCO: “One of our partners has been asked by the customer to help them prepare a Request for Proposal (RFP) for APM software. Do you have a list of questions I can send him?”

“Sure” I said. After all, I hear questions from customers and prospects every day and have a library of RFPs kicking around. I figured it would take me an hour or two, tops, to pull together a list of questions for him to forward.

I started by leafing through old RFPs, highlighting interesting questions. Many were unique to the customer or the situation, so I ended up with a pretty short list of “generic” questions.

Then I thought I’d re-read a few analyst reports and a recent blog posting I saw on the AITS website featuring 3 tips to gain executive buy in, and see what key criteria they were suggesting.

Then I went back through the notes on all the accounts I’d been involved in last quarter.

I sorted the questions into functional and non-functional requirements, and then I started to create sections (see below).

I agonized over the wording of the questions, trying to get them just right.

Finally, it just all felt ungrounded, so I went back over all the sources I described above to look for the commonalities in project objectives and expected benefits our customers and prospects cited. I wrote an executive summary based on this.

Then I sent it out for internal review. Based on this, I re-wrote large sections of it. Another review, some final tweaking and off it went to the partner.

My two-hour project that I started last Wednesday wrapped up yesterday (Thursday). And I probably skipped ¾ of the steps a typical enterprise has to in crafting and issuing an RFP.

Other than how long it took, a few other things surprised me:

  • How many questions were oriented around understanding deployment, security, and performance characteristics.
  • How many questions it took to understand/describe effectively whether an APM system will cover enough dimensions of the application environment to be useful in isolating problems
  • How concerned buyers were about the instrumentation process required to get at individual transaction. See my blog last year on this topic.

Here are the main section requirements.

Functional requirements

  • Coverage/scope: Ability to monitor all transactions in production, cover all the platforms you run on, correlate information to make sense of it, and provide visibility into network performance as well, etc.
  • Alerting: Ability to surface meaningful transaction events and forward them up to the console of choice for your NOC team (e.g. OpenView, Solarwinds, etc.)
  • Dashboards: Ability to tailor per user, drill-down into details, and/or perform ad-hoc analysis of performance data
  • Searching: Ability to find recent transactions/interactions so you can react quickly to reports from users/partners
  • Problem isolation: Ability to drill into transactions and see all the detail from the high-level outcome, down to the individual application/network messages

Non functional requirements

  • Deployment: How will our APM service be delivered? What will it take to instrument your environment for monitoring. Are you capturing off the network, inserting agents into the OS, or monitoring at the application layer via bytecode instrumentation? Do you need any special hardware?
  • Performance: Can you monitor everything you want to in production, without incurring too much overhead? Can the system scale to the kind of transaction rates you run in production?
  • Security: (probably a big one for you!) How does the product handle the kind of sensitive/forbidden information running in financial networks (e.g. Track 1 and 2 credit card data, etc.). Can it be deployed in a PCI environment?

Project Objectives

  • Consistently identify failing or slow business processes and application before our users and customers do
  • Reduce the amount of time and number of resources required to isolate performance problems in our critical applications
  • Look for ways to better leverage IT performance monitoring investments by gaining buy-in across multiple service channels or silo’d departments
  • Improve collaboration between all the teams responsible for our IT environment (e.g. the application team, the network team, the database team, our service provider partners, etc.)
  • Provide senior IT and line of business executives with real-time, end-to-end visibility into business process performance
  • Demonstrate fast time to value by selecting a solution that can deploy easily and be configured to scale easily in our environment

So if an investment in application performance monitoring or business transaction management is something that you are considering, don’t panic or feel overwhelmed – I know of a great place for you to start.  The full version of this doc is available for your as a free “RFP for APM Tools” resource.  Just e-mail me for a copy:

And if you have 3 minutes, you can also take a moment to find out why our favorite customer, Marty, purchased INETCO Insight twice: