Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« Survey: SOA fundamentals still going strong | Main | Visualize SOA (and automate what you can't visualize) » September 07, 2006Sometimes, SOA means 'letting go' When it comes to service-oriented architecture, the prevailing assumption is that IT will be talking and working in synch with the rest of the business. However, IT tends to be a pretty diverse group in and of itself -- will IT people be talking and working in synch with other IT people? Service-oriented architecture differs from most other integration projects in that it's an effort that reaches outside the IT silo, requiring participation from all ends of the enterprise. Surveys I have seen and have conducted find that most SOA projects are still occurring within the domain of the IT department. However, inevitably, business-side executives need to take a co-ownership role in the process for SOA to deliver on its potential. The first challenge, however, may be bringing together participants from across a very wide IT spectrum. Ann Bednarz, writing in Network World, spoke with several thought leaders on the challenges of bringing together enterprise architects, application developers, network specialists, data managers, and storage administrators into a common purpose. Easier said than done, she observes: these groups are "traditionally distinguished by their own tools, methods, and domains." I've seen many instances in which organizations have had several groups of architects, all working for different purposes. Sometimes, on rare occasions, they may actually talk to each other. SOA demands a new way of thinking about the way these various groups communicate. As Dan Foody, CTO of Progress Software, pointed out in the article, SOA moves problems to different parts of the application stack -- from the network level up to the application level, for example. "Things you might traditionally do in the network infrastructure are problems that can no longer be solved the same way -- whether it's compression, load balancing, failover or intrusion detection." Foody adds that "the tendency of the application teams is to assume that the network won't provide all of this, so there's a natural inclination to do it all themselves." Ultimately, this will stymie SOA scalability and manageability. Posted by joemckendrick in SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
