How many times have you heard that SOA is the next big thing? It's particularly fascinating how the perspectives of customers and vendors evolve on "the latest thing" and where they find the value. The Service Oriented Architecture (SOA) wars have been interesting to watch for exactly this reason. Integration vendors, pure-play BPM vendors and leading application platforms all have an SOA story. The major vendors have focused education efforts on teaching people what SOA is, and how it can make their infrastructures more "agile". And while attendance in forums on the topic is still high, SOA strategy and execution is failing in many companies.

Take, for example, a recent Forrester Research Survey that found 38% of companies with more than 1,000 employees are not using SOA and have no plans to. Of the companies that are using SOA in some form or fashion, 40% haven't begun or are using SOA with no clear strategy in place. The 80/20 rules seems to imply that 80% of people don't and won't get SOA in the organization.

One key reason is that the SOA value proposition is fundamentally unimportant to business people who, after all, bankroll new technology initiatives. It's just another way to implement an application. What's more important to business managers is how they can change, through technology, how their businesses are run. And that's where BPM comes in. If the world's biggest-budgeted software vendors really want to have sponsors in both IT and business units, and keep selling software, they need to elevate the role BPM plays in their suites.

To add some color to these statistics, these vignettes illustrate the trouble SOA, on it's own, faces:

At a major industry conference an IT executive from a major bank was expounding on their success in migrating to an SOA in the business. He had SOAPs and WSDLs and fine grained web services--he had API wrappers, BPEL orchestration and data models. About 20 minutes into his exposition on the architectural approach that this 24 month project has taken, the attendee sitting next to me leaned over said "who cares about this anyway? Does this guy think business people CARE?!"

I led a panel discussion--this one geared solely to an IT audience. I asked a question of the panel. "SOA--friend or foe of the business?" Every person on the panel, including one employed by a Fortune 50 company said "it should never be discussed with the business"--it needed to be neither seen nor heard.

At a recent conference a successful SOA architect / project program leader laid out a few different options for deploying SOA. These included:

1. Creating a global SOA strategy and push it into every bit of the business-force SOA everywhere, all at once.
2. Implement SOA as part of each point project. He referred to it as the "bury approach" as it was designed to bury the costs of SOA implementation under the radar.
3. Just "say you're doing SOA" and then ignore it altogether--the rationale being that most business people don't know what it is anyway. So long as you can say that "it's a priority" you sound like you're doing the right thing--then the pursuit of the status quo is at least given a veneer of "service-centricity"

All of these stories as well as the statistics make me cringe. SOA is yet another buzzword--separating the technology haves from the have-nots. A shift is already underway.

Gartner first proclaimed that SOA was entering the trough of disillusionment in 2005. While everyone's hoping it is the trough, SOA is certainly ebbing in terms of expectations. But what's interesting about the cycle this go around, as opposed to the hype shifts in other technology areas, is who's driving the shift.In the cases of integration (message bus I vs. point to point ) business intelligence (centralized vs decentralized data-warehousing) or even programming itself (functional vs object oriented design), the "trendiness" "mood" or "hype cycle" of the particular architectural movement was solely in the realm of technologists--technocrats identified an approach, recruited converts to the new way of thinking, adopted it, and inevitably morphed it into something more practical or palatable in real world application.

With SOA however, the people who are changing the mood aren't technologists--they are business people that own mission critical areas of the business. The shift in budget control post-dot-com is not the only thing that has emboldened business people. The ebb of SOA is a revolt by business people against yet another buzzword invented by IT.

SOA started as an architectural philosophy of "good hygiene" for technology buildout. No one would or does argue that treating the discrete functions of the business (as embodied in technology systems) as reusable web services is inherently bad. But the push of big platform companies to make SOA into a compelling sales situation turned it into a front page news story. Business people read the story--and they immediately put their guards up around IT's new buzzword.

The reaction on technologists' part has largely followed the usual path, as the examples above illustrate. They say "just don't talk to the business about it," or "that's technology stuff, they don't have to worry about it," or "just bury this architectural approach into your project scope, even if it raises the cost a bit." Effectively, IT says, "there is a wall here based upon my ability to understand these complicated things--don't cross it--it's my problem not yours."

The message delivered is not meant to be divisive, nor condescending. Rather, over time, working with business people who don't want to deal with "unnecessary details," IT people have grown accustomed to just taking the lead on IT implementations without the necessary input from the business team. Today, it's becoming a critical divide.

More and more business people recognize that the company's ability to meet core objectives like customer satisfaction, profitability, and compliance are inextricably bound to the technology systems which support the business' operations. This time around business people aren't willing to be held at arm's length. They want a role and if they don't get it, they'll stop any initiative and pull budgets ruthlessly.

This new role for the business has taken IT by surprise in some situations. Business people are getting into their world more and more. The places where IT has been used to being undisputed ruler has evolved into more of a partnership. There is no king.

SOA, therefore, is not like other technologies, typically absorbed over time into the usual day-to-day operations of the IT organization. Rather SOA's success as a technology approach is faced with a shift in the fabric of the relationship between business and IT. Organizations that successfully cope with both the technology trend and the cultural shift will gain the elusive "agility." Those that don't will find that SOA dies a lingering death amidst a cry for more business-user driven solutions.

As I mentioned earlier, I heard a technical architect suggested three different options for "doing SOA." All three reflected the old way of thinking about the cultural fabric of the business. I propose a fourth approach for enabling an SOA strategy. Give business people a reason to care about SOA--give them business process management.

Business Process Management (BPM) gives many businesses an approach that balances the architectural benefits of SOA against the cultural shift which business people are demanding. BPM embodies both a technology approach to support business agility as well as a management philosophy that promotes it. SOA, or any other framework to integrate it into a company's systems, is a means to the end--a better run business.

On the technology side, BPM suites bring to the IT organization the tools they need to build open, web-service enabled infrastructures that leverage their underlying systems and span traditional functional silos like sales, marketing, engineering & finance. BPM technology includes capabilities for designing secure yet flexible mission-critical solutions that scale to the needs of the largest businesses.

The management philosophy of BPM empowers business people to think about the processes that affect their day to day lives and operations. It gives them a new role in defining requirements, on their terms, and creates a common language for business & IT to address real implementation level concerns (like scope, objectives, and end-user expectations).

Putting BPM into play in your business achieves two things. First, it creates a common language between business & IT to discuss real-world business problems stripped of buzzwords. It enables people with different skill sets and perspectives to sit down and model out (using modeling tools) business issues. This common communication layer (the process model) evolves into a running solution in the business. This gives business a sense of ownership in the technologies that support it.

Secondly, BPM supports IT's drive for system flexibility and reusabity. By pushing more capabilities to business people in identifying project objectives using modeling tools, IT is freed to focus on building clean, web service enabled applications based on the architectural concepts embodied in SOA.

This role of BPM as the business face of SOA is not just a possibility. It's happening now. The same Forrester study which found people struggling to adopt SOA drilled into the details of those with successful SOA strategies. It found that of the North American businesses with clear SOA strategies, more than 90% of them felt that BPM was an important part of that strategy.

If you're thinking about pursuing SOA in 2007, aren't making much progress or haven't even started, remember: SOA is SOL without BPM.

Rob Risany is Director of Product Marketing for Savvion.
http://www.soainstitute.org