caveats in SOA adoption..
Much has been made of hyped technology waves over the past few decades as the effectiveness of the technologies at the frontier of each wave. Is the current wave of SOA any different? Will SOA be able to bridge, if not obliterate the gap between business and IT? The real question is whether there is actual gap between the desired expectations and the delivered value of SOA?
Read on...
Much has been made of hyped technology waves over the past few decades as the effectiveness of the technologies at the frontier of each wave. Is the current wave of SOA any different? Will SOA be able to bridge, if not obliterate the gap between business and IT? The real question is whether there is actual gap between the desired expectations and the delivered value of SOA?
It might be too early to make judgement on this front, because as a mainstream trend in distributed computing it is a fairly new phenomenon. However some thoughts on overcoming the key challenges and pitfalls in SOA adoption as outlined below are elucidated in the editorial of SETLabs briefings Vol 1, 2007, on Service Oriented Architecture, pages 95-99.
Key points include:
Adopt a meet-in-the middle approach with a top down business services with a view to automating business processes, while leverage fine grained design from existing systems.
Governance is best thought through the life cycle right from design through organizational change through runtime monitoring..
Read more at http://www.infosys.com/technology/setlabs-briefings-soa.pdf
Comments
Adoption gaps have little to do with the technology. 1) Frequently the wrong type of resource (often a technical one) is put in charge of SOA initiatives. SOA is an architecture -- not all technologists can be architects. 2) SOA fits into a larger architectural suite: data, process, well pretty much the columns of the Zachman Framework (http://www.zifa.com/framework.pdf) SOA is the function column.
Posted by: Paula Thornton | July 19, 2007 01:03 AM
Hi, What i think about the hyped situations is that every technology however successful it is today has been ridiculed in the past and it's only the test of time and its feasibility and user acceptance that has paved the way for them. The most important point I would like to emphasize here is that SOA alone is not sufficient and considering it to be an IT initiative or responsibility would be a big mistake. Take for example the SOMA methodology which clearly states that there has to be an All-The-Time involvement and participation of the business process and business priorities team on the call for an initiation or development of a SOA project. Please correct me if I’m wrong!
Posted by: Neil Naidu | October 22, 2008 02:02 PM