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:
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.