Pitfalls of SOA RFPs
In spite of many vendors’ sales pitches, Service-Oriented Architecture (SOA) is something you do, not something you buy. As ZapThink has been saying for years, SOA consists of best practices, plus the discipline to follow them. Expecting to get architecture by buying software is about as likely as learning to play Mozart by buying a piano.
Be that as it may, however, many organizations are struggling today with their SOA initiatives, and as a result, are looking for outside help to move them along their SOA roadmaps. Some enterprises are turning to vendors for help, others are turning to consulting firms, and many find the best SOA assistance comes from those providers who offer a combination of products and professional services. Regardless of which kind of firm you look to for help with your SOA initiatives, though, at some point you must select that firm — and that typically means putting together a Request for Proposal (RFP), and circulating it to prospective providers.
Putting together RFPs for SOA initiatives, however, is fraught with perils. What precisely do you want the third party to do for you? Regardless of whether you’re shopping for software, professional services, or some combination, chances are you’re looking at SOA in the first place to provide a greater level of agility from your IT environment. Yet, the traditional approach to writing an RFP is to specify a particular set of requirements. How, then, should you craft an RFP for SOA that adequately details your organizations true requirements for agility, in such a way that you’re able to compare the responses you’re likely to get and make the right selection?
Basic RFP Mistakes
In order to avoid the pitfalls, it helps to know where they are, so let’s begin by looking at some of the common RFP mistakes organizations make when looking for help with their SOA initiatives:
- Confusing architecture with implementation — In the unlikely event that your architects have already worked out your SOA plan that’s one thing, but if you need help with SOA, that means that you’re not ready to specify any kind of implementation yet. SOA RFPs should say nothing about the specific technology you might expect your provider to bring to bear. As a result, you should steer clear of any vendor who says that you’ll get SOA by buying any specific product.
- Trying to do too much — Your executive team read about SOA in Business Week and now they want one? So you put together this hugely detailed RFP that delineates everything your provider would be expected to do to take you from your current sorry state to the world of SOA nirvana. Sorry, it just doesn’t work that way. There are far too many unknowns as well as a plethora of cultural and political issues to overcome before you can delineate further tasks on your SOA roadmap.
- Expecting providers to put SOA advice in their response — You want to make sure your provider has sufficient SOA chops, but asking them to provide detailed advice in their proposal is unfair, since after all, the best practices they offer are core to the value they’ll provide to you. Customer references are a better way of qualifying providers.
- Expecting to be able to compare proposals via purely objective criteria — Government organizations in particular often have the requirement that they must solicit some set minimum number of proposals, and then compare them using formal criteria to avoid any hint of favoritism or discrimination. Unfortunately, such formal criteria are woefully inadequate for evaluating proposals for SOA-related professional services, because there is so much variation from one organization to another among SOA approaches. As a result, such objective criteria are bound to focus on less important details (frequently technical capabilities), rather than the more important architectural and human interaction skills.
Key RFP Pointers
Now that you know of some of the biggest pitfalls to avoid, here are some pointers for putting together effective SOA RFPs:
- Expect and encourage an iterative approach to SOA — Taking an iterative approach to your SOA initiative that combines both top-down and bottom-up activities to show business value along the way is an established SOA best practice. As a result, it makes sense for many organizations to approach their RFPs iteratively as well. Put out an RFP for a SOA pilot project, and move on to the next RFP only after completing that pilot and evaluating the results. Where you start and which order to tackle the various iterations will depend both on your organization as well as lessons you learn along the way.
- Look for strong organizational change capabilities — The technology part of SOA is the easy part. Much more difficult is dealing with the organizational and political changes your organization must go through to make progress with SOA. You might find that your RFP centers on change management, negotiation and evangelism skills even more so than more traditional architecture skills like modeling, requirements gathering, and system design.
- Allow for subjective evaluation techniques — While considering which provider takes your boss to the best restaurant still won’t do, it does makes sense to evaluate the proposals you receive by considering how good a fit the provider will be with your organization, both technically as well as organizationally. Successful SOA initiatives rely upon change across the organization, so finding a provider who can act as an effective change agent is essential. The most technically astute provider may not have the capability to drive change in your organization, and will thus hit a brick wall, while the most effective provider may not have the deepest technical capability.
- Don’t focus on SOA at all — This piece of advice is the most counterintuitive, yet possibly the most important. You have some set of problems that are prompting you to consider architectural change, or you wouldn’t be writing an RFP in the first place. However, instead of delineating some approach to solving the problems in the RFP, put your energy into describing the problems and let the provider respond with their own approach for solving them. Then, evaluate the responses in part by analyzing how Service-oriented the approaches are. You’re not looking for specific activities here, but rather the overall approach and philosophy of the provider.
The ZapThink Take
As the title of this ZapFlash indicates, the bottom line with SOA RFPs is that the entire RFP process is not well-suited to SOA initiatives. The core business motivator for SOA is business agility, and to be truly agile the business must be able to leverage changes in the business environment for competitive advantage. Traditional RFPs, however, fly in the face of this requirement for agility, as the RFP by its very nature casts requirements in concrete.
Even for organizations with sufficient in-house capabilities to tackle SOA on their own, the traditional requirements ⇒ design ⇒ develop ⇒ test ⇒ deploy methodology is entirely inappropriate for SOA, because of the need to build for ongoing requirements change. So, for an organization looking to bring in a third party, the requirements ⇒ RFP ⇒ design… approach makes no sense either. Instead, organizations should look for providers who can serve as partners to move SOA initiatives forward on both the organizational and technical fronts, with a continual focus on solving the problems of the business.
In fact, the most successful third-party relationships for both the organization and its providers follow this pattern. The most successful SOA consulting firms are those that focus more on solving business problems than delivering an architectural approach, and who work closely with their clients on a partnership basis that delivers more on overall business improvement than on specific, well-defined projects. Similarly, the most successful SOA initiatives that leverage third-party expertise are those that bring providers into many different aspects of the business. Such relationships, however, rarely come through RFPs. In fact, 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.