Connecting the Dots Between SOA and the Business

Loraine Lawson

There's a lot of conflicting advice about SOA success these days. In one instance, you're told it's dead as a business initiative, so don't even use those three letters when you talk to the business. On the other hand, you're also told the only successful SOA projects are those that start with the business, not IT, and therefore you'd better focus on the business case.


I suspect a lot of you roll your eyes and do what you want to do, or forget the whole thing. And I can't blame you. Heck, even some of the experts are ready to wave the surrender flag and move-but in their own, annotated way.


But after reading both sides, I've got good news. Both are actually bringing you back to the same, basic smart principles of IT/business alignment: Talk to the business in its own language and tie all your IT investments to delivering concrete value to the business.


To be honest, I didn't see it either until I listened to a recent podcast discussing Gartner's new framework for building an SOA business case.


I have to say-I think Gartner's got a real winner here, even though I haven't seen the complete framework. That's because I've asked tons of experts how to build a SOA business case, and I always received helpful advice, but it was always a bit vague. It felt incomplete somehow, but I couldn't pinpoint what was missing.


When I heard this podcast, I knew immediately what that missing element has been: a means for tying SOA, the tech value and the business value together in a way that's measurable and concrete. And it sounds to me like that's exactly what this framework does.


Gartner Research Director Anthony Bradley explained that the problem with SOA is it's like a toolbox. There are a lot of useful tools in the toolbox, but how do you explain the business value of a toolbox? You can only talk in generalities-unless you know what you're building with the toolbox.


For example, it's pretty easy to explain how your toolbox is going to help you if you're building a birdhouse. That same toolbox will also be helpful if you're hanging a picture, though the tools may be different.


Likewise with SOA:


"You need to know what you're building in order to deliver a business case. It's impossible to build a generic business case with SOA but you can build a SOA business case for X, and that X being a specific SOA-related application initiative, or effort or project. That's what you build a SOA business case around."


Okay, so far, that's a nice metaphor, but how do you connect the dots?


Gartner's framework promises to help you target the business case down to a very specific opportunity, which in turn allows you to build a business case. A fundamental component of the framework is 30 elements of SOA, which capture the value of SOA-so, for instance, modularity is an element of SOA. And these elements are divided into four categories:


  • SOA principles, like modularity
  • SOA tech benefits, which I suspect would include things like agility
  • Business benefits
  • Bottom line impact


And now we come to the smart part. You chain those four categories and elements together to tell an end-to-end story of how SOA principles lead to technology benefits, which in turn leads to business benefits, which affect the bottom line. Bradley said you can start at any point in the chain, and work out.


The bottom line here: SOA's not over for IT or the business. Even Anne Thomas Manes, who originally pronounced SOA dead, stresses she's talking about the term SOA-and not the actual practice of it.


Now, whether or not you use the term "SOA" when you talk to the business-that's up to you.


If you choose to use the term "SOA," you're going to need an approach that ties that term and its tools firmly to the business benefits and bottom line. Or, as Forrester's Randy Heffner put it, "Although SOA is far from dead, it should be buried inside a larger vision."


And if you don't use the term, guess what? You've still got to tie the relevant services and related investments firmly to the business benefits and bottom line.


In the end, when the hype cycle levels out, there's just no getting around those basic business rules.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
May 29, 2009 8:40 AM Rob Eamon Rob Eamon  says:

IMO, the error is in thinking of SOA as an initiative at all. Apply SO principles to business organization, to planning (architecture), to implementations, etc. Don't set out to "create an SOA"--that is the wrong focus completely, IMO.

"Talk to the business in its own language and tie all your IT investments to delivering concrete value to the business." is a good viewpoint, though I'd prefer to not reference "the business" and IT as though they are disconnected, independent entities. All groups in the company need to understand the business and be driven by the business goals and objectives. Chasing SOA with the hopes that following the style alone will deliver great benefits is risky.

By way of analogy using building construction (I used this in another SO discussion): I might want a house built for me with particular aesthetics. The architect collaborates with me and we find that those characteristics are met nicely by Victorian design elements (architecture). I'm going to get a Victorian house. During design and construction it is important that the Victorian aspects are included but it is infinitely more important that the result be a house. A Victorian barn might delight the Victorian enthusiasts but I'll be bunking with the cows?

Clearly, business systems are not this black and white. That's why it is important that business focus remain on the front-burner so that the style aspects don't overshadow it. Business aspects guide the use of the style, not the reverse.

Jun 3, 2009 12:20 PM Frank Millar Frank Millar  says: in response to Rob Eamon

Architectural context might be another dimension in these scenarios.  Of course, it's paramount that business requirements drive initiatives, but also important is the context of enterprise standards already in place.  Ideally, those standards declare the SOA as part of the enterprise architecture.

In other words, considering SOA to be "merely" a part of Enterprise Architecture supports Rob saying, 'Don't set out to "create an SOA"--that is the wrong focus completely'.  By subordinating SOA to the 'bigger picture', SOA can sometimes be established as a standard with less contention.

Frank Millar

Millar Consultants, LLC



Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.