Monthly Archives: September 2009

Perhaps SOA is More Strategy Than Architecture

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?

Keep Your SOA and BPM Initiatives Separate

Not to beat the dead horse, but during a discussion the other day with a fellow SOA cohort, I came to a realization for the reason SOA & BPM get inextricably tied together in some individual’s thoughts. I’ve written and blogged before on how SOA & BPM have very different goals. SOA is about application rationalization via a service metaphor and BPM is about business process analysis and optimization. The fact that they are discussed in the same breath leads one to believe that they are inherently related, when in fact they are not.

That said, as one performs a top-down analysis of their business as part of a BPM initiative, they are going to discover they need a framework to assist in implementing new business processes that cut across departmental and other organizational boundaries. Clearly, one of the greatest areas for improvement within in an organization is across these organizational boundaries because process improvement tended to be an intra-departmental exercise. When the process needed to cross an organizational boundary, the political, geographic, technological, etc. hurdles led to inefficient crossings.

Historically, SOA and BPM rose in popularity at or around the same time. SOA, led primarily by technological practitioners, responded to the needs of BPM practitioners for a framework to capture and implement newly-designed and efficient cross-organizational business processes with technology. However, for BPM, technology is the least of the problems. Indeed, BPM’s biggest issues are political and geographic in nature. A process that needs to cross continents or rely on participation of a department that is resistant to change pose a far greater problem to process optimization than not having a web service available to invoke.

Still, there is seems to be a natural gravitation toward SOA as providing the necessary framework to capture and implement new cross-organizational business processes. Most likely it is the service façade that allows various business functions to be exposed as technological assets accessible over common Internet protocols. After all, what better way to create a business process that crosses organizational boundaries than tapping directly into the data and systems that support those sub-organizational areas?

However, it’s important to note that SOA should not be viewed as the nail for BPM’s hammer, as is all too popular a notion today. It is not an SOA if you decided to wrap a few legacy systems with web services so that you could easily build out an automated business process. That is just part of your BPMS effort.

This entanglement of SOA and BPM into a single effort is fraught with problems and failure. Each initiative should be undertaken separately and with definitive goals that do not list each other as one of the outcomes. If as part of the rationalization that SOA provides, there happens to be some services exposed that simplify the implementation of a particular business process, then that would certainly be a slam-dunk. However, SOA and BPM each have their own metrics of success and their own barriers to success. Combining them into one, well, the words “boiling the ocean” comes to mind.