That’s a pretty impressive level of awareness and mind share. Let’s not consider this a “mission accomplished” situation though; there’s still a lot to do to mature our current approach to SOA. For example, we need to improve the clarity and completeness of the various Web services standards and, when they become available, we have to ensure that this more complete, mature, coherent set of standards is broadly adopted.

Consider the issues of building and maintaining the federated identity management frameworks that are necessary to provide the foundation for secure SOA implementations. Sure, our early SOA applications can be made fairly secure with user IDs and passwords, local LDAP directories and SSL. However, real-world SOA deployments link applications from multiple enterprises across multiple network and organizational boundaries. Security for those deployments is several orders of magnitude more complex to implement.

We also need to be constantly aware of the need to standardize the format and semantics of the data that we send and receive over our SOA. We need to be just as clear as to the process semantics that surround and govern each of the exchanges as we are of those that make up our SOA-based composite applications.

Finally, don’t forget the challenge of connecting our composite applications with all of the small and very small enterprises that don’t have the technical capability to implement Web services stacks, data transformation programs, orchestration solutions, and all of the other technologies that generally go into building an enterprise-class SOA infrastructure.

How do we address issues like this? While there are approaches that are entirely valid for fixing each of these problems individually, we need a Web services intermediary of some kind to fix all four.