eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In the current issue of eWEEK, I report on a conversation that I moderated late last month among players on the field of service-oriented architecture (SOA). The group included representatives from several vendors of SOA technologies and services, plus an enterprise IT buyer to keep those vendors focused on reality.
It seemed to me that there were two key points to the discussion:
- The use of Web services technology does not inherently lead to the creation of a service-oriented environment. This point, made by several participants, bore out an argument that I made last fall: that brittle, slow and costly systems can be built with any technology.
- On the other hand, many enterprises are seeing significant financial returns from SOA-based initiatives, often begun with earlier generations of technology and architected to include but not depend on emerging Web services implementations. Such efforts are now becoming easier to undertake and expand because of the low barriers to entry that Web services tools can provide.
The resulting climate encourages three results.
- SOA construction is increasingly being driven by financial rather than technical imperatives, resulting in broader and more vigorous management support for the direct and indirect costs of such a transformation.
- Web services adopters are less inclined to walk around the technology seeking excuses — such as gaps in multivendor standards — to postpone trying it out. Theyre more likely to see the standards glass as nine-tenths full rather than one-tenth empty, and to build what they can with what they have today.
- The advent of a genuine services platform in an organization paves the way for a service-based organization that has the leverage to break down silos of data and code and start building more efficient and strategic systems.
In discussing the remaining gaps between the possibilities and the current realities of SOA, I found both vendors and customers agreeing that theres still a lot to do in making services discoverable through catalogs, rather than relying on development teams and configuration management disciplines to know what services exist and how they can be usefully hooked together. Business Process Execution Language gets approvingly mentioned as a productive development aid, but UDDI is the technology that seems most often mentioned as having the potential to change the basic model of applications from one of static assemblies of modules to one of dynamically assembled confederations of services.
More powerful, though, and therefore more interesting, is the change in the organizational role of IT that comes from being the enabler of business function rather than the steward of technology. When electrical power was a leading-edge technology, it was common for a company to have a VP of electricity; when electrical service became ubiquitous, it became in most organizations a domain of contract administration rather than technical leadership. Being a leader of technology adoption today, paradoxically, may lead to redefining yourself as something else tomorrow.
Tell me what youd like to have as your job title in 2010 at peter_coffee@ziffdavis.com