My husband sent me the following e-mail last week:
I am an SOA god.
I've completed most of the coding on my application that wields the fearsome +1 hell-hammer of SOA. It probably should hold a world record for the smallest, most insignificant use of SOA ever.
My husband, a computer programmer, is proud of himself because he's never bothered with SOA until now. He's heard the trendy marketing hype, and, like many other techies, he's expressed suspicion about SOA.
But my work with this blog piqued his curiosity. So when he was handed this horribly old application and told to "fix it" to do something modern and new, he wondered whether SOA might be able to help him work with the code without totally revamping it -- which, of course, had no documentation and was written by a long-gone consultant.
My husband's company is an SAP customer. Of course, he knew SAP offered SOA services, but everything he'd heard about had been "big picture," involving portals and other major initiatives. No one bothered to mention that there were more granular services he could use to make his daily job easier.
Those of you knee-deep in SOA may roll your eyes at this, since that's the whole point of SOA. But obviously, the word isn't getting out. Especially to the IT workers who don't spend months at conferences and in training.
And that's my point: Everybody's so busy talking about the Big Strategic Value of SOA, they're overlooking the fact that SOA just makes work easier.
Instead of spending months rewriting the code, designing a new interface for the revamped app and outlining new security parameters for the redesigned code, he could just let the code do its thing -- in this case, pull data -- and then use a service to organize that data and put it to use in the business. He explains the whole situation in his blog, if you're really curious.
In less than a week -- much of which he spent figuring out how to access the services and tracking down the service he needed -- his company had a working application. Easy for him, quick and efficient for them.
And if that isn't a business value in and of itself, I don't know what is.
My second point is this: Maybe the reason there's so much SOA apathy among trench IT workers is because nobody's selling them on its potential to change their daily work lives. In your rush to sell the business (or CIO, if you're a vendor) on SOA, don't forget to sell the IT division. After all, they're the ones that will actually be using the services and delivering the business agility you're promising everyone. If they don't know the services exist -- or how to use the services -- then how will SOA ever deliver on its promise of shared services? Or, really, any of its promises?
Gartner used to talk a lot about plucking the "low-hanging fruit" on technology projects. There's a reason it's called service-oriented architecture -- it's because SOA involves a revisioning of how IT functions, particularly for programmers. Doesn't it make sense to show programmers how to pick the low-hanging fruit for SOA implementations?
These "insignificant" projects are the low-hanging fruit of SOA. I'd love to hear more about the "insignificant" uses of SOA. In fact, I'd be willing to print up a nice certificate and mail it to the techie who can beat my husband's claim to the "smallest, most insignificant use of SOA ever."