We know SOA depends on cultural shifts, but -- like the weather -- we still don't do much about it

Recent observations on SearchSOA.com on lack of meaningful SOA adoption suggest that the technologies and techniques have amounted to but a mere improvement on EAI. Some conveniently calling it EAI 2.0, but admit the effects are not yet wide nor deep.

We have yet to see SOA adoption lead to substantive transformation, surveys and primary research will no doubt indicate.

The acknowledgment that SOA requires top-down, bottom-up, organizational and behavioral, ie "cultural," change to proceed to its potential is well documented and debated. We have come back to this topic again and again, for example, on the BriefingsDirect SOA Insights Edition analyst-powered podcast series.

So let's recognize that a higher purpose is at work here, and that SOA is a subset -- not even a leading driver, perhaps -- of the end-game. Also augmenting and influencing the IT transformation journey in addition to SOA are several mega IT trends and shifts (in no particular order): SaaS, RIA/mashups, virtualization, cloud computing, open source adoption, ITIL adoption, business process outsourcing, applications modernization, data center consolidation, SAN adoption, BI, BPM, master data management, etc. etc. etc.

There are great new tools and effects that can make IT perform better. The tech folks obviously have their hands full with them, and are often expected to implement under the "do more for less" ongoing mandate, the unfortunate business-side takeaway from Moore's Law.

But these IT efficiencies are the means, not the ends. The end-game is business transformation. Contingent to and in coordination with that is IT transformation. The relationship between the two is intrinsic, interdependent and highly variable -- from enterprise to enterprise, IT department to IT department -- often an enigma in motion. While the IT trends deeply affect the trajectory of the IT-centric transformation, they to do necessarily have an understood or appreciable influence on the business transformation processes.

Frankly, it's all too complex, too unwieldy, too unmanageable -- this bridging of the "business side" with the "IT side." People and passions play a huge role, too. Agendas get crafted. Sides are taken. Leaders and followers emerge. Politics permeates the process, regardless of how well the IT performs. And then any means to meaningfully simplify the complexity (tactically or strategically) become themselves highly complex. And so on. And so on. Transformation remains a distant vision.

There remains therefore an ongoing, pernicious reinforcement gap between the change agents of IT, the change agents of business requirements, and the means to engender change in cultures, groups and individuals. In other words the politics of change in large, complex organizations remains a mystical, quizzical patchwork of leaps, lunges and stumbles.

Let's not necessarily blame SOA or IT, any more than we should blame the rain. SOA in of itself is not enough to overcome the many obstacles on the path to ongoing and effective business and cultural transformation.

And yet, companies do succeed. Profits are made. Solutions are crafted and delivered to markets. Buyers keep buying, and workers keep working. Productivity seems to emerge and proceed at a certain scale, at the right level of decentralization. They say our brains are constructed to work best in close groups of 8-10, and to seek cooperation in larger groups up to about 140. Family and village are the scales we've been designed for. People therefore naturally seem to gravitate back to the scale that works, and perhaps even subconsciously resist moving beyond the perceived scale (and perhaps natural order) that actually functions for them.

There's a fascinating new essay by Paul Graham, "You Weren't Meant to Have a Boss," that relates this to developers and software development, but there may be a larger lesson in it, too. IT is great and keeps getting better by leaps and bounds, but biology and evolution are destiny. IT needs to line up behind this fact, not seek to side-step it -- or worse, ignore it. It's not nice to fool mother nature, as the margarine commercial used to say.

Politics is the process by which groups of people make decisions. SOA's expected role and virtue is closely tied to politics. And the decisions being made by IT executives, by business management, and by the line of business implementors often have very little relationship, little in the way of interchange between the people and the processes in a natural order.

SOA's great promise is to help align people, process, and processing. But something remains in the way. SOA lacks a political context. It lacks power over the people, and so far the power of the people has not been much interested in embracing SOA. Why should they?

We in the industry have not answered this question: Why should the people promote SOA as a means for them to get their jobs done in the ways they know work best in real life. What's in it for the average bear? What are the incentives to SOA adoption for those carrying the load?

The politics of SOA needs to succeed if SOA is to succeed as a lynchpin of both IT and business transformation. When SOA's virtues are translated to real improvements to real people, we may see the myriad gears of adoption mesh.

There should be a good story here. I think SOA is part of the answer, not the problem. But looking to SOA to change cultures seems to be a moot expectation. Politics changes cultures, and cultures are reflected in politics.

When the business consumers of IT services demand SOA and its effects, then we'll see the real transformation.

Elastra emerges to make cloud computing more attainable for enterprises

Cloud computing as a concept has been gathering significant interest in the past months, but aside from developers, testers and startups, the ability to exploit the efficiencies and cost-benefits of cloud computing for average enterprises have remained hard to grasp.

Startup Elastra unveiled its approach today to making cloud computing more practical, introducing two markup languages -- one (ECML) that helps pull applications together to deploy to a cloud environment, and a second (EDML) to help define and organize the right cloud-based infrastructure to support those applications.

In general the Elastra approach provides onramps to compute clouds based on descriptive tools that help reduce complexity for IT departments. This should encourage experimentation and ultimately lead to ramp ups in the use of public clouds, as well as the build-out and use of home-grown, so-called private clouds. Less attention has been given of late to the promise of private clouds, which are really a natural extension of current datacenter consolidation, clustering, application modernization, ITIL and virtualization initiatives.

As virtualized software has become the primary layer over now-buried hardware that architects and engineers must deal with, we should expect more tools and "bridging" technologies like Elastra to emerge to help grease the skids for what can (and should?) be deployed in clouds. The software then becomes agile services that can be provisioned and consumed via innovative and highly efficient business models and use-based metering schemes.

I suppose we can coin this as "middleware for cloud computing," or maybe "APIs for cloud computing." In any event, let's hope these onramps become highly visual, automated and increasing based on widely accepted standards.

Because Elastra's approach allows applications to be deployed to public (like Amazon's EC2/S3) or private clouds (like the ones many enterprises are likely to build out as they virtualize datacenters), it aims to become a de facto standard for accessing cloud resources. Packaged under the Elastra Cloud Server, the database-driven product can help bring applications rapidly to a pay-as-you-use model. Enterprises may be able to provide more applications as services, charging internal consumers as a managed service provider.

I had a chance to sit down last week and discuss the arrival of ECML and EDMl with Kirill Sheynkman, president and CEO of Elastra. He was a major force behind integration and enterprise portal provider Plumtree Software, which was acquired by BEA in 2005. Indeed, there are a lot of former BEA folks under the hood at Elastra.

Sheynkman is obviously a fan of cloud-based infrastructures, and also has had experience on what it takes to practically define and introduce a new category to the enterprise IT mind. His vision for the cloud opportunity is compelling, but his feet seem firmly on the ground, with a strong sense of what will work in real-world use.

Part of Elastra's DNA is putting more data in the cloud, where it can be used assiduously to support apps, services and business processes. And once the data layer makes its way to the cloud (private, public or both), can the rest of the support infrastructure be far behind? We're already seeing a lot of talk around integration as a service, and infrastructure as a service. And we're also increasingly seeing tools and development as a service.

Once the IT support infrastructure is effectively abstracted to a cloud, with specific languages to manage and access those resources, then the move to Nick Carr's utility vision seems well under way. What remains is for the tools and architecture definitions to be readily described, communicated, and managed for the compelling economics of cloud-based support to take off.

I'm beginning to think the segue to the cloud could happen sooner than many think, and be very much a mainsteam enterprise endeavor after all.