Are we getting ahead of ourselves with SOA?

We talk a lot on this blogsite about Web services standards, specifications, and protocols, which are supposed to make up most of the building blocks for SOAs. But how many have a grasp the intricacies of these services? 

The latest Web services survey I helped compile for Evans Data still finds an enormous gap in overall understanding of the various standards and specifications being put forth.  These figures have changed little since the last survey in 2004.

Here are some specs that are critical to robust and secure SOA development:

eXtensible Markup Language (XML):

Know and use:  74%   Don't know: 10%

Business Process Execution Language (BPEL): 

Know and use:  26%   Don't know: 73%

Universal Description, Discovery, and Integration (UDDI): 

Know and use:  25%   Don't know: 45%

WS-Security: 

Know and use:  15%   Don't know: 60%

WS-Policy: 

Know and use:  10%   Don't know: 67%

What these numbers tell us is that the industry still has a lot of education it needs to provide the market if it is to help fledgling SOAs to reach their full potential.  Much of the industry may be getting ahead of itself in its rush to embrace SOA, without full understanding the mechanisms that will make it all come together in an orchestrated fashion.

Too many organizations are being asked to lay out funding for "SOA" initiatives that will not bear fruit, only to be looked upon two or three years from now with disdain, as money pits that never delivered their promised potential.  (Joining the list with CRM, sales force automation, ERP, executive information systems) What's troubling in this case is SOA is an even more amorphous term and concept than other more IT-centric projects. We run the risk of having SOA dismissed as a failure.

How can we address such perceptions-in-waiting?  Education, education, education. Through education about what the building-block standards really do for the business; through targeted, well-focused, specific implementation projects, such as saving development resources through reuse of code that formerly required many hours of development time, or connecting up several back-end legacy systems through a Web-centric interface. And, most of all, SOA needs enlightened management, goaded by an individual taking on an evangelist role inside the organization.  SOA can work, but it runs the risk of being derailed by inflated expectations and under-educated management.