Choosing Your First Cloud Application Initiative
Questions you should ask to help determine which cloud application path you should pursue.
Sometimes, analysts, consultants and other experts enjoy a good argument over semantics. They like to get into disagreements over nuances. If you asked them, they'd tell you these seemingly academic discussions are of great importance. But as you stand there, with squinty eyes and a furrowed brow, trying to puzzle out just what the point is, you begin to suspect that maybe, just maybe, it's not so important after all.
That's kind of how I feel about a recent argument that's broken out about cloud and SOA-and more specifically, about how the word "service" is applied in each context.
Recently, Gartner Research Vice President and fellow David Mitchell Smith warned that companies shouldn't assume that building a service-oriented architecture will prepare them for the cloud. The crux of the problem seems to be that "service" means one thing in terms of SOA and another when it's used to talk about the cloud.
OK, simple enough, right? And not particularly a revelation. One "service" is a sales term-"I'm selling you a service"-and one "service" is a more technical term -- "I'm going to deliver this cloud function as a service." (Joe McKendrick did a great job of explaining this distinction if you aren't following me.)
Of course, as SOA/cloud blogger David Linthicum points out, many of these cloud providers use an SOA built of services (the technical one) to actually fulfill these services (they kind they sell).
Linthicum really took Smith to task on this one, contending that SOA is a critical component of cloud services. He even issued a "virtual glove slap across the face" to Smith, adding a smiley face to soften the challenge.
I've read through all three columns three or four times now, trying to sort it out, and here's what I think:
It's not that Smith is dismissing SOA's role in the cloud. As I read the CIO article quoting Smith, he's actually saying SOA is an important part of preparing for the cloud.
What I see as the big take-away here is a warning that doing SOA won't necessarily mean you're ready for the cloud, just as-to use his analogy-throwing a football down the field won't necessarily result in a completion.
Right now, as Smith notes, organizations are investing is SOA because they're aiming for better IT management. Often, as I've shared previously, companies pursue SOA for better management of legacy systems.
But that's not the same as building SOA and knowing the whole time that you're aiming for the cloud. Oh, sure, if you follow the recommendations of experts about services, your services should be flexible enough to prepare you for the cloud. But let's face it-just because it should be that way, doesn't mean it will be. If you're building SOA so you better manage internal IT resources, that's no guarantee that those same services will be built in a way that automatically prepares you for the cloud.
And I say that because of Smith's football analogy:
In American football there is a saying that you throw the ball and at the other end you catch the ball-so it's important to be where you think the ball will land. It's an analogy to the issues around cloud and SOA. If you are planning around assumptions today and you want to plan for the future you want to know where the future will be which is no small feat.
In other words, if you aim for the halfback, don't expect the same exact play to also reach your wide receiver.
But then again, as Linthicum has warned time and time again, if you've developed a well-rounded team-which, in SOA, means focusing on architecture and the future, rather than today's short-term goals-you should be able to pass to both.