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:
Key RFP Pointers
Now that you know of some of the biggest pitfall
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
s to avoid, here are some pointers for putting together effective SOA RFPs:
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.
