On Thursday, September 10th, 2009, I moderated a panel at the 1105 Group’s Enterprise Architecture Conference in Washington, DC entitled, “SOA Goes Mainstream – An Industry and Government Roadmap.”  On the panel we had two Federal government agency representatives and two industry representatives, with one of the industry representatives providing a FedEx case study as the basis for their SOA experiences.

As expected, each of the panelists’ SOA experiences was varied, with no two taking an identical approach.  However, the interesting tidbit of information I garnered from moderating this panel is that after a couple of years of effort, some approximation of a methodology that is termed “SOA”, which is specific to each organization, emerged and started delivering value to the organization.

Granted, I have been one of the louder proponents calling for agreement on the use of the term ‘SOA’ because I believe that without common agreement a term is relatively meaningless—I still believe this is true.  However, in opening myself up to the idea that SOA may be more of a concept than an actual architectural approach, it became clear to me that that each organization may also organically formulate their own approximation of SOA that meets the needs of their business as functional components, or services.  Moreover, each business’ approach toward SOA will most likely look completely different than any other business’ approach, their pain points will be different and their approach toward measuring success will be different.

For me, this is a startling revelation surrounding SOA.  If one looks at the supporting industry infrastructure that has built up around the term SOA—software, training, methodologies, blueprints, etc.—the realization that each organization may ultimately need to tailor the general concepts into something that is different from organization to organization, minimizes these efforts to nothing more than templates or patterns to use as a starting point.  Moreover, it’s quite possible that the only consistent aspect of SOA from organization to organization may be the road to adoption.

This also raises the need to re-evaluate earlier claims regarding the “Death of SOA” and SOA’s “trough of disillusionment.”   If a consistent part of each organization’s early SOA efforts is represented by this tailoring effort, then perhaps some of these early failures are nothing more than part of the process analogous to the caterpillar spinning its cocoon and then working its way into becoming a butterfly.  It does seem from my research that there is a consistent pattern among SOA adopters that successes seem to be more prevalent in the second and third years of SOA initiatives.  Moreover, if we know this information going into an SOA effort, we can better manage expectations of the business with regard to Return-on-Investment (ROI) and time frames.  Most of all, if the tailoring effort is a known part of the process, then unrealistic expectations can be removed from the practitioners, allowing them to focus on reaching successful ends.

Note, this realization does not mitigate the enterprise architecture efforts that must accompany, or more accurately, precede an SOA effort in order to ensure success.  This realization is focused solely on the transformation of the business based on the EA artifacts and a building a service-oriented methodology to support that transformation.  Thus, SOA is effectively the transition plan for the organization to maximize its resources, applying a ‘once-and-only-once’ mantra toward development efforts and align the technology imperatives with the business goals and functions.

So, based on this thesis, is SOA really architecture, or is it simply a strategy for business transformation?