Advice for Writing a Useful SOA RFP

Loraine Lawson

If you've written -- or are preparing to write -- a SOA-related RFP, you might want to start by reading what David Bressler has to say about keeping it simple.


Bressler is one of the bloggers at SOA Infrastructure Blog, which is a vendor blog operated by Progress Software. Not surprisingly, Progress is an application infrastructure software company that offers several SOA-related solutions, including an ESB and service management tools. He's Progress Software's SOA Management Evangelist, a title that always conjures images of an older Southern gentlemen with a gray pompadour and a bad suit, urging me to send money now.


Bressler doesn't have gray hair and so far, he's not urging me to send money at all. What he is requesting is a bit of common sense and simple goals when it comes to defining what you want your SOA to accomplish.


His perspective is unique in that, as a vendor, he's on the receiving end of Request For Proposals for SOA and Web service projects. In the post, he shares a particularly bad RFP that apparently asked for every type of Web services standard, plus the kitchen sink. The requirements, he writes, "were too vague and decoupled from the implementation."


He contrasts this with another customer, who managed to define their key needs for a SOA and Web services management solution in five simple bullet points. If you're unsure where to start, he also shares how one company jump-started its RFP process by sending vendors a single question about their product: "What ten things should we consider when evaluating your product?"


Not surprisingly, that helped them know what solutions were available and who could best address their business needs.


Bressler's post prompted me to do a little searching for more on how to write an RFP for a SOA project -- probably because you can't do SOA in one big RFP since, obviously, SOA is not something you just build or buy in one huge step. To be honest, I didn't find a lot, and what I did find was all written earlier this year. But, upon review, these two pieces are still pertinent and offer useful guidance for approaching SOA RFPs:


Jason Bloomberg of ZapThink wrote about the "Pitfalls of SOA RFPs," which was published on TechTarget's in March. Bloomberg points out that the typical process for writing an RFP -- specifying a particular set of requirements -- is tricky with SOA, since the goal is to create agility, not lock you into a particular solution. Among the specific pitfalls he mentions are trying to do too much with one RFP and applying one set of objective criteria to all the proposals, which will inevitably vary too wildly to be evaluated against static criteria. He offers remedies, but is ultimately skeptical of the whole process, warning that:

... the best SOA consulting and advisory firms avoid responding to RFPs altogether, because the organizations that spit them out are frequently not ready for SOA in the first place, and thus don't make very good clients.

Eric Roch, chief technologist at Perficient Inc., where he leads the national SOA Practice, believes the RFP process can be useful for SOA, if you break SOA engagements into steps. First, he offers a SOA Readiness Assessment, which he describes as "a week long engagement to identify high-level SOA benefits and requirements." This is followed by an assessment of processes and IT readiness, he writes, although you'd think that would be part of the first SOA Readiness Assessment -- which just goes to show why it's important to do an RFP and outline what you'll be expecting at each stage of the process. Roch also explains why you should resist the temptation to start with an RFP for an ESB and offers a few general resources for writing RFPs. However, when you are ready to write an RFP for an ESB, he's written this excellent piece on questions you should include in either an RFP or an RFI.

Add Comment      Leave a comment on this blog post
Nov 29, 2007 12:12 PM David Bressler David Bressler  says:
Loraine,Thanks for the discussion here. You've got me thinking...However, I feel in good conscience, I must correct a few things:1. Alas, I do have grey hair - buried underneath the blonde highlights.2. While I haven't requested money, it's always welcome. Cash or gifts sent to Progress HQ do eventually get to me. 3. I'm not requesting common sense - I'm begging for it!But seriously, as I read your post, I couldn't help but wonder about something that was on my mind (and therefore coming out of my mouth) all day yesterday. When it comes to collaboration technology (Facebook, Second Life, etc.) I've realized that unlike a lot of technology in the past, it was very difficult to "figure this stuff out" without just "doing it". And, it seems that with these technologies it is OK to make mistakes and fix them. There seems to be more tolerance for "less than perfect". I wonder if it's because, as Jason points out, that the SOA goal is agility, and at some level, this agility is showing up as more tolerance for mistakes because they can be fixed more quickly than in the past? Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.