Realizing the value of SOA

I went to the InfoWorld SOA Executive forum held in New York this week.  The theme of the conference was "Realizing the value of SOA".  There were several well delivered presentations on the importance of understanding business process first, organizing the right team skills and structure and picking the right early projects in order to crawl, walk and then run with SOA.  Without a disciplined approach focused on these basics any technology selection is doomed to either failure or even worse....marginal, limping return.

I also participated in the conference to deliver my point of view on the theme.  Acknowledging that the non-technology components are critical areas of success (see my thoughts on this in the Intel Press Book SOA Demystified in Chapter 2), making prudent technology decisions is also important or what you end up doing is putting a good plan and a good team into a number of comprimising positions.

As discussed in an earlier blog on federated SOA, a practical reality for most organizations scaling their adoption of SOA beyond a single pilot, department or use is that one single unifed implementation is rarely ever a practical possibility.  So often the architecture and technology discussion becomes, which of the currently deployed SOA stacks should be extended to cover the entire enterprise.  My point of view and one shared by other speakers at the conference is that this is really often a comprimise discussion, that is "...which one are we willing to live with more than the others...", where the discussion should be is what are the key capabilities needed to support the top-level federated architecture and what incremental investments are necessary to get to that architecture.  More often than not the practical matter is that security, cost of performance, scalability and managability are key vectors for this top level architecture which may not have been the most important components of the service enabling and compositing layer of a specific application stack that is widely used in one corporate department or region.

Also, as I shared in an earlier post scaling the implementation of SOA when applying open, loosely coupled technology standards like XML, HTTP and SOAP can be a challenging proposition when volume and latency requirements are steep.  Loosely coupled, open standards provide substantial reuse and agility benefits, but often a comprimise discussion ends up happening as to how this aspect needs to be de-featured to support performance and latency requirements.

With a SOA "soft" appliance platform like Intel SOA Expressway, there is no need to comprimise.  It effectively extends across individual SOA deployments by site, department or region creating a unified whole with a scalable and high performance messaging, data integration and workflow compositing / orchestration stack so there does not have to be a trade-off as to whether the open, loosely coupled standards will scale.

With the right technology foundation realizing the value of SOA at an enterprise level without comprimise is readily achievable.

Thanks for getting this far.  I look forward to hearing your thoughts on how you are approaching the question of how to scale your SOA deployments and what trade-offs you are making in those strategies.


For more complete information about compiler optimizations, see our Optimization Notice.