Service Oriented Architecture Field Guide for Executives

4.4. OTHER RISKS

So far we have discussed factors that can sabotage SOA from delivering on its promises. On top of that, SOA itself, due to its very nature, brings in new risks. That is not to say that SOA is an unsound idea. Any technology or thought process has weaknesses. We must know what they are, be vigilant about them, and find ways to deal with them.

Immature Standards

Standardization makes a service readily usable by a consumer. Let us say that you are a manufacturer. A new dealer will be able to quickly integrate you into its order processing system if your organization provides a standards-based service. Without standardization, the dealer will have to write a lot of custom code just for you.

SOA, not surprisingly, puts a lot of emphasis on standardization. Some of the earlier standards, such as, XML, SOAP, and HTTP have been successful. But, these standards are only the tip of the iceberg. We need standards around a whole slew of other areas, such as security, encryption, compression, transaction, and guaranteed delivery of messages (see the Appendix, "Standards in SOA," for more details). The need for these technologies is well understood by the software developers. They are not new by any means. The need for standardization is new. Going back to our example, if the dealer sends an encrypted message, the manufacturer's service should know how to decrypt it. What if not all dealers use message encryption? In that case, the manufacturer needs to set up different policies. ...