Pragmatic SOA: Adoption Project by Project

Posted by Mark Little on Jan 31, 2007

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

SOA ,

Methodologies ,

Governance ,

Stories & Case Studies

The latest release from Zapthink discusses that age-old axiom of how you shouldn't run before you can walk and it's applicability to SOA. According to ZapThink:

"... success with SOA rarely necessitates comprehensive change; instead, architects who choose their SOA battles carefully can deliver on SOA's promises to the business via projects of limited scope. Architects who miss this point often set the bar for SOA success too high ..."

This isn't particularly new: for example, we had the same problems when CORBA and DCE first came on the scene and everything just had to be distributed and object-based. Some could argue that this in turn lead to a lot of backlash. Therefore, lessons like this should be learned and it's good to see the article, particularly given the large amount of hype that still surrounds SOA. Hopefully most people are experienced enough to realise this, but it's often the case that the obvious tends not to be so obvious after all.

The authors discuss that an iterative approach to developing with SOA is extremely important, along with solution-oriented thinking. Pragmatic SOA combines these two things with a risk/benefit analysis and should (in theory), help projects to experience some/many/all of the benefits SOA offers. According to Zapthink, Pragmatic SOA should be taken on a project-by-project basis and  they give some interesting examples, such as:

• SOA Governance: as the report mentions, most governance challenges don't involve IT directly and aren't automatable. Therefore, with Pragmatic SOA, governance initiatives could focus on Service security policies, then followed by QoS policies etc. Creating these building blocks allows IT to leverage SOA in increments and prioritize specific policies.
• Reuse: in theory SOA offers better reuse characteristics than object-oriented systems, but practice is currently different. There are often technical and political reasons that affect reuse within organizations; cross-organization/cross-company boundaries add more complexity. The authors correctly indicate that reuse builds over time and shouldn't be forced: it will grown "at its own pace".

The report concludes that:

"When architects are implementing SOA, this need to focus on pragmatic efforts is particularly important, because of the immaturity of the architectural approach on the one hand, and the need to build and maintain business support for SOA initiatives on the other."

Do you have examples of other scenarios where pragmatism and SOA go hand-in-hand?

• Older >