Thursday, September 24, 2009

"You're the CIO of a Fortune 500 company and you step into an elevator with your CEO. He asks why we should approve your seven figure SOA budget request. So what's your "elevator pitch" for SOA? Make it short and to the point – the elevator is already rising fast."

So, what would my answer be?

"SOA is the centerpiece of our IT strategy in direct alignment with the board of director mandated enterprise-level risk management initiative that ensures IT continuity, resilience, compliance with regulatory requirements such as SOX, asset protection, and minimization of negative financial exposure."

Monday, September 21, 2009

Without a doubt, the economic downturn has taken its toll on IT but did all of the technology cost-cutting organizations were forced to perform end up being a good thing? I'll answer this question with a short story...

Once upon a time there was a very obese person... sort of a "super size me" kind of guy. One day, he got a terrible scare with his first heart attack at age 34. Fortunately, he survived, and is now a much fitter and leaner individual at 35 years age. Is that a good thing?

Of course it is!

Well, to play devil's advocate, it would not have been so good if he had just starved himself. But this individual joined a gym, started a regular exercise program that included both aerobic and anerobic exercises, and went on a nutrition-balance diet. In a similar "vein", a "balanced and strategic" technology cost cutting initiative is a good thing too since most organizations were long due for such an effort having become "obese" with the long period of economic prosperity.

Finally, to bring our story full circle, just as a balanced diet and regular exercise is good for anyone to maintain good personal health, technology cost cutting initiatives should be ongoing and continuous as well to maintain good IT health.

* Originally posted in the ebizQ Cloud Computing Forum on September 21, 2009

Friday, September 18, 2009

When SOA first started climbing up the hype cycle, it was pushed to developers as a way to increase the "reusability" of their code by making everything into a service. This created at least two problems with the first being a massive service proliferation as developers eager to jump on the SOA bandwagon made everything into a service, which in turn led to poorly performing architectures (not SOA's fault) and huge issues around service management and governance. The second problem was that upper management and the mainstream media also started "drinking the reuse Kool-Aid" served by the bottom ranks.

The fact is that reuse is only a by-product of SOA. Adopting SOA for reuse is like saying that you're working out to sweat (instead of for losing weight, building muscle, or improving overall health). In fact, I would contend that the re-use provided by SOA is only marginally better than what we've had in previous architecture generations. We've gone through libraries and modules in procedure-oriented architectures, objects in OO architectures, components in component-based architectures, and now servces in SOA. A key issue around reuse is not the technology but the identification, segregation, and granularity of "reuse" items - none of which are dependent on what architecture style you are using. The real value of SOA is as a building block of the larger enterprise-level strategy of aligning IT with the business to ensure that IT value is justified, IT supports the business objectives, and IT has an equivalent level of agility to adapt with changing business needs. In some cases, SOA even becomes the catalyst that spurs the IT alignment to business objectives.

In a nutshell, SOA is about strategic IT alignment with business goals and objectives. Service reuse is only an operational - not even tactical - outcome of SOA. A corollary to the discussion is that many bottom-up adoptions of SOA start with lofty reuse objectives and either quickly become disillusioned or fail to demonstrate adequate value to the rest of the organization because their original reuse goals are far from being met. That is why SOA has the best chance of success with a top-down adoption with the long term sight on strategic alignment objectives rather than operational reuse objectives.

Most SOA and Cloud practitioners have probably wondered about this very same thing. I definitely have asked myself this question - albeit in different forms - many times over the past couple of years. A while back (2007) I had written an article in ebizQ titled Leveraging Synergies: RTI and SOA Unite in which I talk about using RTI (think an internal, private cloud) and SOA together for two main reasons:

They share similar objectivesBoth RTI and SOA seek to maximize ROI albeit at different layers of the technology stack; RTI at the infrastructure (hardware) layer and SOA at the business application (software) layer.

They complement each otherUsing one concept (SOA or RTI) without the other leads to an impedance mismatch between the infrastructure and application layers resulting in suboptimal benefits realization.

The same logic applies to application architecture targeted to cloud environments. In fact, you could say that the cloud is the "A" in SOA :). With clouds, SOA has a winning partnership such that if there were ever any doubts about the long-term strategic benefits of SOA, clouds help alleviate most if not all of them.

Wednesday, September 9, 2009

This is the question posted by Phil Wainewright in the Web 2.0 ebizQ forum where I am one of the panelists. Here's my answer:

A "private" cloud is just as much of a cloud as any other.

The typical private cloud is a cloud in which the cloud infrastructure is operated solely for an organization. It may be managed by the organization or a third party and may exist on premise or off premise. Since all consumers of the private cloud are “trusted” (i.e. within the organization’s legal/contractual umbrella such as employees, contractors, & business partners), multi-tenancy, which is a big deal in the public clouds, becomes less of an issue.

However, a private cloud still satisfies the essential characteristics of what a cloud is.

NIST, for example, defines five essential characteristics of a cloud: On-demand self-service, Broad Network access, Resource Pooling, Rapid Elasticity, and Measured Service. Now consider the Cloud Security Alliance, which also defines the cloud in terms of five principal characteristics: Abstraction of Infrastructure, Resource Democratization, Services Oriented Architecture, Elasticity/Dynamism of Resources, and Utility model of Consumption & Allocation. Every other authoritative definition that I have come across defines the cloud in the context of similar essential characteristics. There is no reference to ownership of resources, sharing the cloud between organizations, competitors, across national or international boundaries, or the use of the public Internet as the backbone. It is because they are not essential characteristics of a cloud.

So, no, a “private” cloud is not an oxymoron. Would "public" cloud providers like us to believe so? Sure, but the fact is a private cloud is a necessity at times due to organizational maturity/capability/culture constraints, regulatory requirements, or SLAs that cannot otherwise be met.

About Tarak

Tarak is a highly experienced, results-oriented, business leader, skilled enterprise architect, and published thought leader. He has demonstrated the ability to lead diverse teams of professionals in achieving mission critical results in a variety of highly competitive industries, cutting-edge markets, and fast-paced environments. His broad professional background and excellent education provides a solid foundation to his ability in solving challenging business problems with innovative enterprise solutions that leverage and align IT capabilities with evolving business needs.
As a testament to his thought leadership, he has authored Living in the Innovation Age and co-authored Professional Java Web Services. He has also published over 80 articles on Innovation, IT Transformation, and Enterprise Architecture.