Blog

My '2-hour' project: creating an RFP for APM tools

March 14, 2013 by Marc Borbas — VP, Marketing, INETCO

Last week, I was reminded of how hard it must be to be a buyer of enterprise software these days — especially application performance management software.

It all started with an innocent request from one of our channel account managers: "One of our partners has been asked by the customer to help them prepare a Request for Proposal 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 reread a few analyst reports and a recent blog posting I saw on the AITS website featuring three 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 rewrote 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 three-quarters of the steps a typical enterprise has to complete 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 an individual transaction.

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, 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

Nonfunctional requirements

Deployment: How will your 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 one and two credit card data, etc.). Can it be deployed in a PCI environment?

Project objectives

Consistently identify failing or slow business processes and application before users and customers do;
Reduce the amount of time and number of resources required to isolate performance problems in critical applications;
Look for ways to better leverage IT performance monitoring investments by gaining buy-in across multiple service channels or siloed departments;
Improve collaboration between all the teams responsible for the IT environment (e.g., application team, network team, database team, 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.

If you are considering an investment in application performance monitoring or business transaction management don’t panic or feel overwhelmed — I know of a great place for you to start. The full version of the doc I've described is available as a free "RFP for APM Tools" resource. Just email me for a copy.