I wish every organization had used this more strategical approach as mentioned by yourself but I see many organizations still getting influenced by these vendors who use these buzz words to sell their expensive products (and even services if they are able to) to the ignorant and confused IT/Business senior executives.

So a practical question : What should a SOA Architect/Designer do if he is working on a SOA project where SOA is not a strategical solution but just tactical/project level “IT” Solution “sold” by vendors and SCA is vendors promoted SODA/SOBA implementation/development methodology? You probably would agree that there are lots of such places and the role of SOA Architect is just limited to a tactical Solution Architect and Organization is not ready and yet prepared to listen to and think in a Strategical SOA way. Should s/he take a bold (and revolutionary to some extent) decision to just design simple SOA services using the vendors tools? OR s/he should make the best use of SCA to build the services as “SOAed” as possible keeping in my mind that the complexity introduced by SCA is not just an architectural complexity instead could even be a runtime complexity becs introducing unnecessary layers in a software design means more iterations or pass thru points at runtime which may well have some performance impact as well.

Thanks.

Actually I am trying to provide approaches with some IBM tools to achieve productivity. And we have to overlook the practices recommended by the vendor with the ones deviced by us. Just doing this our whole of SOA governance has got streamlined.

I truely agree with your views and have personally experienced in around 4-5 projects till now.

I’m not 100% sure what you meant by including SOA in the integration list. SOA is not about integration, it’s about the alignment of business function into a services model that may be provided using technology, but is not required.

JP

SOA (done right) is certainly one of the best (easiest, most cost effective, most adaptable, etc) integration methods I have seen yet, and also one that is most amenable to re-archtecting initiatives.

I’m not sure exactly what this SCA beast is yet – it must be a fairly new vendor-led buzzword designed to sell otherwise non-moving lines of products and services:)

I believe that Enterprise Architecture is primarily about the business. SCA can provide an excellent standard for defining enterprise integration points, since it requires the definition of both services and all service references.

Imagine having all of an organization’s integration points so well defined that the flow of information or the steps of processes could be tracked and reported. Corporate management could begin having a better understanding of IT complexity resulting in better decisions.

I believe helping management make better decisions is part of our CAEAP oath.