« SOA Practitioner'€™s Forum: Service Version Management or Mayhem? | Main | SOA Consortium Hot Topics Roundtable Podcast: SOA Governance Roundtable from Brussels Meeting »

08/13/2007

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

udin

Hi Shekhar,1. What do you mean with finalized?2. I don't know if there are any oiifcfal or unofficial mock exams, the self-study kits contain some sample questions.3. I think all SOA certifications lack recognition because few people actually know about them compared to the masses of developers that take .net or Java certifications. The certifications are based on a respectable source, Thomas Erl, so I think that people and companies that are really working in SOA delivery should recognize its value.4. They can be expired, as all certification programs, but currently there is no expiration date. On their website they state that they'll inform you one year in advance if a certification would expire.I hope this helps, if you have other questions don't hesitate to contact me.Steven

Richard Soley

While I would love to agree with you Victor, I just can't. There's a big difference between a reference model which can be used to check the particulars of a distributed system infrastructure for compliance with a set of guidelines, and an approach to managing a business (and its accompanying IT infrastructure) based on recognition of processes and services. While I certainly agree that the first is useful, it's not SOA; we already have enough distributed computing infrastructures! I'm with you on an enterprise strategy based on a set of architectural principles however!

As to your general problem: those are precisely the things we learn from experience, and why the SOA Consortium is focused on sharing experiences, at many different levels. Today's new Consortium deliverable from the Executive Suite SOA working group (http://www.soa-consortium.org/case-study.htm) is a great example of the kind of experience our members are sharing!

Victor Harrison

I would argue that all three are orthoginal and required. As a set of principles SOA represents ways of measuring value and outcomes; as a strategy (yea!) it couples value to business and mission needs, and as a technology it provides a way of confirming that a particular design is good, bad, or inbetween along with providing a communal understanding of how to "do" it.

The general problem I have is that definitions are necessary but not sufficient. And from these three orthoginal contexts for SOA (a) the devil is in the details, (b) what are the feeds and speeds between the three contextful views of SOA, and (c) how are the objectives and outcomes of one contexful view affected by the others? That, I think, is a quest worth pitching after.

The comments to this entry are closed.