I realized yesterday that people might not know what the SOA Consortium is, so I thought I would publish some quick notes. The SOA consortium (www.soa-consortium.org) is a time-limited (2010) advocacy group for business-driven SOA.
In other words they are going to “Promote and enable business agility via SOA to allow businesses to compete, innovate and thrive” but expect to cease needing to do so by 2010. By then it should be so established that SOA is key to business agility that they won’t be needed. Their success measure is that 75% of global 1000/major government agencies and 50% of mid size businesses will self proclaim SOA success by 2010. SOA success being defined in terms of business value generation, business agility, IT agility and productivity, business/it collaboration not in terms of services created or reused. I like both the business focus and the time limitation.
They are also doing some work around Enterprise Architecture as they feel that EA often contains business architecture separate from technology architecture with minimal overlap and a much greater focus on Technology. They feel this is a mistake and want to ensure that in 2010 there is a much more balanced view between business and technology architecture with lots more overlap. Again, no complaints on this either.
They have some nice, if short, case studies here. I have not had a chance to review these but they look interesting if brief.
My only complaint is one that regular readers will recognize – that agility cannot be delivered by BPM and/or SOA alone as true agility sometimes means changing the details of the behavior of a company. If the services I have, for pricing or underwriting or cross-selling, are still written the same old way then I won’t have agility even if they are wrapped in nice standard interfaces and composited into a process I understand. If a programmer still has to make changes to procedural code then my agility runs slap bang into that limitation. The solution, of course, is to make sure that decision services are part and parcel of your BPM/SOA strategy.
Comments on this entry are closed.
Hi James,
Thanks for joining us at, and posting on, last week’s SOA Consortium meetings. I know many of our enterprise practitioner members agree with your statement above that agility (and practices to maximize agility) needs to be reflected from the business strategy through the code base, and yes, that includes the externalization of business rules. In fact, one of our enterprise practitioners is working on an independent paper on this very topic.
As for the SOA-C, our community of practice charter includes the sharing of good and bad SOA practices, but stops well short of declaring, “precisely how SOA should be done”. Our thinking here is that actual needs and practices are situationally inspired. That is, organizations and practitioners need to define a business agility strategy (business architecture, SOA, BPM, EDA etc) that fits their business, technology and organizational environment.
I’m looking forward to discussing the role of decision services with you.
Enjoy the Holidays! – brenda
[Oh, I’ll include my disclosure: Among other roles, I am Program Director for the SOA Consortium]