What Your Mother Forgot Tell You About Delivering SOA
The recent quarterly SOA Leaders Forum ( www.soaleaders.com ), has provided me more opportunity to listen to the experiences of IT professionals who are engaged in real deployments of Service Oriented architectures.
These people have a thoroughly pragmatic view of the technology that is independent of the requirements that the marketing folks espouse. The degree of agreement about issues in different parts of the country is surprisingly uniform across these events.
The most recent revelation from this community is well worth consideration. As architects, vendors and analysts we have long touted the technical benefits of SOA - selling the business organization on investing in the infrastructure to implement and deploy a grand SOA architecture. However, the business units (who we expect to be the major beneficiaries) are skeptical of the achievable benefits. The business has heard it all before. Just invest in this technology and IT will be able to perform miracles - object oriented development, DCE, CORBA, DCOM, EAI, ESB’s and the list goes on. The business just wants us to deliver our systems on time and to address their needs - just once, please. They have become much cagier. “If this new technology will increase reuse and reduce our overheads then we should be able to reduce your budget next year, right?”
Large scale infrastructure deployments are rare these days. I have been involved in any number of them previously… OSI Networking, PKI, X.500 etc. What I like about Web Services is that you can build really useful systems incrementally (yes Thomas, you too can be “a really useful engine”). The most successful deployments have been those where a small but important project used Web Services in a limited way. Even without repositories and management systems, they proved that delivery of a system take place quickly and demonstrate integration with a range of systems or provide access to customers in a way that supported the business. Then rather than trying to argue the business folks into spending money, the business units became the proselytizers demanding that more of this web services and SOA stuff be used to get their needs met.
Of course the danger in this approach is that clean architectures may not result from such organic roots. On the other hand I have seen some extremely beautiful architecture built, that nobody came to. The job of XML, Web Services and SOA infrastructure at this point in the maturity cycle needs to be providing quick and secure deployment in a way that buffers you against enough change so that the first small projects do not lock you into short-term decisions that prevent a scalable architecture from developing. However, the first task is proving that the job can be done in an effective way. Otherwise no one is going to fund our grander visions of reliable messaging, transaction systems and business process rule execution.
Trackback URL for this post: http://www.webservices.org/trackback/id/70658