A tale of two service oriented architectures

Service oriented architecture can be part of a top-down enterprise-wide transformation, or bottom-up grassroots revolution. Either way, a successful effort needs to kept out of the silos.

No two service oriented architectures are the same, and, if anything, there are two distinct styles: large-sclae corporate implementations, and small-scale, technically focused projects.

Chris Haddad says over the past decade, as service oriented architecture has evolved, and has been finessed within enterprises, two distinct approaches have emerged: "big SOA" and "small SOA."

Big SOA, as the name suggests, are enterprise-scale initiatives, usually planned and promoted by top managers. It usually occurs as part of a sweeping transformation effort, such as shifting the emphasis of enterprise focus from product-centered to customer-centered.

Big SOA reaches across enterprises, is usually driven from the top, and requires coordinating a lot of moving parts:

"Big SOA initiatives focus on enterprise governance processes, enterprise-wide re-use, and portfolio consolidation.  Achieving these big goals requires structurally changing design-time processes and overcoming significant cultural bias that lead to inhibiting design, accounting, control, and operational ramifications. Traditional Big SOA initiatives can succeed, but only if top-level organizational support (e.g. C-level) overcomes organizational inertia and project teams bridge silos and operate as one team."

Small SOA usually occurs as a result of individual initiative, with developers and professionals introducing SOA practices one application at a time. It usually is bottom-up, and is put into practice on a project-by-project basis within small teams:

"Small SOA initiatives often focus on run-time environment concerns instead of design-time concerns.  Popular run-time environment concerns include enabling flexible communication styles, interaction patterns, and mediation mechanisms that facilitate integration and promote loose coupling.  Example communication styles include synchronous, asynchronous, one-way, and request response messaging.  Commonly supported interaction patterns include peer-to-peer, brokered delivery, hub-and-spoke, publish/subscribe, and orchestrated workflow, which are used to bridge the gap between consumer-provider availability, reliability, and topology."

The bottom line is all SOA is a form of communication. As Norm MacLennan cautions in a recent post, SOA tends to "inherently set up silos."  Multiple teams work on their own loosely coupled services or APIs, but ultimately, those services need to interact. The key is to get everyone on the same page with essential standards:

"If you have a shared source code server - a GitHub Enterprise, an Atlassian Stash, something like that - developers can put up some small modules to help with common problems. Cross-cutting, domain-specific items can be solved once, and the best modules will "float to the top" and propagate through different services."

Of course, there is shared infrastructures and shared expertise that can come from keeping communication open in SOA efforts.

(Thumbnail photo: Joe McKendrick.)


You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All