Radovan Jacenek saw my post and others on the SOA-SaaS connection, and puts the relationship in the most concise, to-the-point context I've seen so far:

"I'm kind of surprised there even is such discussion because it seems so obvious to me: you need to implement SOA in order to deliver good SaaS."

'nuff said.

IBM spokespeople are saying that the UDDI standard for registries isn't cutting it, and the "time is now" for a new registry standard more focused on today's SOA realities. In the meantime, IBM will be offering a proprietary solution.

In a new report in ITWeek, IBM managers state that SOAs have stretched the Universal Description, Discovery and Integration (UDDI) web services standard to the limit, and that it's time for a new standard.

"Our clients are telling us that they have an integration pain point," Andrew Hately, a manager at IBM's Software Group, said. "We need to [create a new standard] and the time is now."

A few days ago, I posted news that Burton Group's Anne Thomas Manes had just issued a report that IBM's WebSphere Service Registry and Repository (WSRR) 6.0.1 doesn't fully support UDDI, the commonly accepted standard behind SOA registries.

Manes pointed to the irony that IBM was one of the creators of UDDI, and has stated that the standard is essential for communicating the availability and composition of services among multiple environments. In a recent post, she said IBM's diss of UDDI amounts to a proprietary strategy reminiscent of days of old:

"The soon-to-be released WSRR v6.0.2 [WebSphere Service Registry and Repository] will include a UDDI synchronization framework, which will enable reasonable coexistence between WSRR and a separate UDDI registry. IBM even includes a separate UDDI registry with the product. But I don’t think this makes up for the fact that WSRR does not directly support the UDDI protocol or for the fact that IBM has chosen to implement support for WSRR’s proprietary registry protocol rather than UDDI in its plethora of runtime products. This is clearly a proprietary platform strategy."

IBM, however, says that UDDI was originally designed for Web services, which invoke point-to-point connections across the network. (In fact, it was designed to be the "Yellow Pages" of the e-business world.) But what enterprises need now is a registry standard that addresses the building-block, enterprise approach of SOA, Big Blue says.

SOAs require different information about services than do Web services, IBM claimed. According to Sunil Murthy, a manager for WebSphere Service Registry and Repository at IBM's Software Group, UDDI will not allow for role-based access to services, does not let companies manage a service's life cycle to enable governance, and does not allow for services to be searched.

"There is opportunity to look at this set of issues and look at a concerted industry standard to foster the integration required and that focuses on SOAs," Murthy is quoted as saying. The IBM reps quoted in the article could not predict what a new registry standard would or should look like, but said vendors should take their time in sorting things out.   

Gartner has given the green light to accelerated SOA spending. The concept works, but caution, the payback will be slower than expected.

I like how L. Frank Kenney, research director for Gartner, has summed up the state of enterprise SOA adoption thus far: “Large numbers of successes have been reported, and no major conceptual flaw has been discovered in SOA," he said, speaking at this week's big Gartner confab taking place this week in SanFran.

He advised organizations to "aggressively invest in SOA as it will rapidly become the architectural foundation for virtually every new business-critical application.” Gartner now estimates that more than 50 percent of new mission-critical operational applications and business processes designed this year. This number will jump to more than 80 percent by 2010.

No major conceptual flaws? Hey, what's not to like?  SOA, in its purest form, promotes across-the-board reuse of IT assets, across-the-board standardization so systems inside and outside the business can exchange data and launch services, and breathes new life into the billions and billions invested in back-end legacy systems over the past century. How can there be a downside to all this? 

The downside is that too much is being expected of SOA in too short of a time, and this is creating a lot of tension. In the current hyped-fueled rush to SOA, organizations are spending money on things that don't quite meet the grand promises of SOA.

It's still going to take at least three years to see any return on investment for SOA projects, Kenney estimated. "Despite the falling cost of technology, more widespread know-how and availability of SOA services from systems integrators, the incremental upfront cost of SOA vs. a traditional architecture in most cases can’t be justified for fast return-on-investment, opportunistically oriented projects."

The problem, Kenney points out, is that there's a lot of hoops that need to be jumped through before SOA works as it should. SOA is not a product CIOs "can buy and install," he said. "In additional to adoption of new technologies, it requires changes in people’s behavior."

And that's not the only tough part, he said: "Compared with traditional monolithic or client/server architectures, SOA needs a more-careful application design. It often requires use of integration middleware. Testing, debugging, managing and securing a distributed SOA are complex and expensive."

No longer can companies go at it alone, said Henning Kagermann, CEO of SAP. 'Every company needs to cultivate a network of business partners to cope with the speed of change in business.' Big SOA is the way to do this. 

At this week's big SAP confab in Atlanta, SOA as a enabler for collaboration between companies was front and center of SAP CEO Henning Kagermann's address to the 14,000 attendees.

The ERP giant announced that its "Enterprise SOA" strategy is on track, and that it intends to deliver a full service-enabled business suite by the end of the year. Kagermann confirmed that SAP has "fulfilled its promise to largely deliver the first service-enabled suite of enterprise software to the market. With SAP ERP as the front-runner, SAP is on track to service-enable all SAP Business Suite applications in 2007."

In his speech, Kagermann observed that collaboration between businesses is the only way to achieve innovation and differentiation in today's blazing fast business culture. Companies must look outside their organizations and more effectively collaborate with their business networks. For this to occur, IT must provide a flexible, adaptable and ever-evolving infrastructure that allows continuous improvement without disruption to core processes.

That's where enterprise SOA comes in, he said.

"In the 1990s, companies combined business process re-engineering with ERP systems to achieve new levels of operational efficiency," said Kagermann. "Today, companies are seeking to combine business network transformation with enterprise SOA to achieve new levels of competitive differentiation. As we observe business network transformation happening globally, we predict it will elevate IT to a more strategic role for the business in the future."

"No longer can companies go at it alone," Kagermann added. "Change is happening at an accelerated pace and every company needs to cultivate a network of business partners to cope with the speed of change in business. The combination of business network transformation and the advent of enterprise SOA form a powerful foundation for creating an even greater competitive advantage for companies."

UPDATE: ZDNet colleague Dan Farber reports how Kagermann also discussed SAP's entree into the Enterprise 2.0 realm.

An industry standard is a great idea — every vendor should have one of its own. 

The industry has made some progress in getting vendors to line up behind standards, but vendors being vendors, they still always insist on releasing their own flavor of standards in products. 

IBM, which proclaims with such persistence that it is the champion of standards, appears to be straying in its own direction with at least one SOA product set.

"Market clout has its advantages," notes Burton Group's Anne Thomas Manes. In a report issued by Burton and summarized in TechTarget, Anne states that IBM's WebSphere Service Registry and Repository (WSRR) 6.0.1 doesn't fully support the Universal Description, Discovery and Integration (UDDI) standard, the commonly accepted standard behind SOA registries.

"IBM has been able to establish a leading position in the SOA registry and governance market with a non-standard offering because of the dominance of the WebSphere superplatform. WSRR v6.0 was released in September 2006, and IBM was able to close more than 40 customer deals in the remaining 65 days of 2006. Market clout has its advantages. In a very short period of time, WSRR has achieved second place in the rapidly growing SOA governance market, following Hewlett-Packard and its Systinet family of products."

"UDDI is clearly not a strategic priority for IBM," Anne said. "The fact of the matter is that IBM wants enterprises to adopt WSRR and abandon UDDI." WSRR-based registry/repository will work well in WebSphere shops, but heterogeneous SOA deployments still need industry-standard UDDI registries, she added. 

Ironically, "IBM along with Microsoft, which also has its own homegrown approach to SOA, were founders of UDDI.org," Anne added.

Anne has been following the UDDI market very closely, and pointed out in a recent interview the time may finally be ripe for the UDDI spec to emerge from the shadows of obscurity. Manes observes that since many SOA projects are moving out of the development stage into production, there's more of a need for UDDI. "You don't need UDDI to get started with Web services," she said. "You don't need UDDI to enable integration among applications. But if you want to do SOA, you have to start managing the environment and UDDI becomes the system that enables communication among multiple environments."

"UDDI is the foundation for governance," Manes also said. "As people start deploying more and more services and their systems get further and further out of control, they realize that they need to do something. And they start by bringing in a registry."

The question is now, will it be UDDI, IBM's registry, or a federation of both?

Dave Linthicum, who has been involved in plenty of IT vendor acquisitions, has been keeping tabs on the churning SOA vendor space, and estimates that anywhere between three to four dozen SOA specialty vendors have been acquired in just in the last couple of years.

Isn't that a good thing? For the investors in these companies, yes. But for SOA innovation, no, Dave says. In fact, we may be losing our competitive edge in SOA as a result.

Enterprises can't forever rely on startups to piece together SOA strategies. But larger vendors aren't known for innovation and flexibility

"The number of organizations out there that are actually doing service-oriented architecture are diminishing," he said in a recent podcast. "This is not due to lack of interest in the space, or a failure of the technology… the larger players out there, the big stack guys, are actually purchasing SOA companies and taking them out of the market." (Dave also posted a blog piece on the same topic here.)

Dave's observations were triggered by Rich Seeley's latest article in TechTarget, which also explored the question of the incredible shrinking SOA market. In the article, Forrester's Randy Heffner believes that having too many entrepreneurial ventures around make it difficult for end-user customers to establish coherent enterprise strategies.

One-off bits of software from small vendors, innovative as they may be, may hamper SOA adoption in Heffner's view. "It forces leading shops to have to do a bunch of software infrastructure integration on their own," he said. "What that does is restrict the market for adoption of new technologies. Though they (small vendors) may be innovative and interesting and add something to the mix, their value is lessened by fact that they are a one-off. An enterprise wants to get a coherent SOA platform."

Consolidation through mergers and acquisition may be a plus if the large vendor integrates the acquired technology into their platform, thus saving developers from having to work on infrastructure integration before they can tackle application integration.

Dave Linthicum points out that larger vendors, of course, don't like to take risks, and are slow to adapt. Only small startups are in a position to take risks with new technologies and approaches. "Most of the innovation, the interesting stuff, takes place among the startup companies," Dave says. This is being lost as larger vendors take over, and absorb the smaller vendor's products and people into the bellies of their operations. 

Investors in these startups prefer the acquisition exit option because regulations make it much more difficult to take a company public, Dave says.

I think another factor is that a lot of the entrepreneurial excitement and energy that is part of emerging markets seems to be directed at the Web 2.0 space these days — not SOA. Many startups are gearing their innovations toward Software as a Service, mashups, and collaborative environments. (Witness this week's Web 2.0 conference.)

Miko Matsumura, VP of marketing at webMethods, took issue with a recent post in which I relayed an opinion that '50' seems to be the threshold at which Web services may require some better care and feeding, with governance, registry, management, and all that good stuff.

Robert Meyer of TIBCO observed in a recent podcast that he has observed that "SOA efforts fall into confusion once a company has several development teams and about 50 services built. That’s also the point where there are too many services for informal management. Once companies hit this number, they quickly can lose the benefits of SOA unless they take time out to set up SOA governance."

Miko's response to this threshold: "Nuts." He observed that "a lot of people define services at different levels of granularity, therefore some companies that have smaller numbers of services may need governance capabilities sooner. Having a magic number like that smacks to me of dangerous and vague advice and frankly seems silly."

As Miko put it:

"Institute governance as soon as the services you deploy actually matter to your business. This can be as early as your first service, depending on granularity and on whether the service is low value or high value (mission critical)."

Okay, time to mix it up more with the SOA-Software as a Service connection. 

I just got word that StrikeIron reports it had a very good first quarter, adding over 175 new customers in the first three months of 2007, with revenue increasing six-fold over the same period in 2006. 

StrikeIron now calls its category as "Data as a Service" (DaaS? Hey, I'm the one who's supposed to come up with bad acronyms), in which it vets, tests, hosts, and delivers individual services, via a Web service marketplace, to consumers over the public Web. These services can be consumed as is, or are delivered as components of ISV and SaaS partners' applications.

Examples of deployable and consumable services offered through StrikeIron's marketplace include D&B Business Prospect, which provides access to basic business prospect information with D&B's data product;  Email Verification, which provides instant verification of email addresses, and Foreign Exchange Rates — current and historical foreign exchange rates.

In previous posts, I have talked about the StrikeIron approach, which plays well to the rising phenomenon of the loosely coupled enterprise, which aggregates services on an on-demand basis to meet new business demands. Many, if not all, of such services may be provided from third parties such as the StrikeIron Web Services Marketplace, and consumers of such services are charged on a per-transaction basis.

SOA is converging with SaaS in other ways. Also in today's news, one SOA software vendor announced it was going to SaaS route to offer customers SOA capabilities on on-demand basis. LaborLogix Inc., which provides tools and application adapters that streamline integration and access between business applications, announced that it has moved to a SaaS managed subscription pricing model for its core SOA products.

 Loading …

ZDNet blogging colleague Larry Dignan broke the story of Oracle's 'Project X' announcement, which the software giant is now branding as its Application Integration Architecture. This is clearly aimed at helping customers bring together various enterprise applications now under the Oracle tent (Siebel, PeopleSoft, JDEdwards, and Oracle e-Business Suite, of course), but also is a another step on the road to service-oriented architecture. SOA the Oracle way, of course — Big SOA.

Oracle shifts gears to gradually move its captive constituencies to Big SOA

The news Oracle brings to the table is that the software giant is emphasizing process, not product. Oracle is introducing what it calls "Process Integration Packs" (PIPs?) that employ BPEL (Business Process Execution Language) and leverages Oracle's Fusion Middleware SOA Suite. The first two PIPs now available include quote-to-order and order-to-cash process bundles, built upon the Siebel CRM product.

I agree with Tony Baer, who closely tracks all things Oracle, who noted that Big O recognizes that it would be impossible to try to force its greatly expanded and captive constituency (Siebel, PeopleSoft users, etc.) into some type of new Oracle mold. Instead, Oracle has shifted its strategy to accommodate and support a very gradual and incremental migration. And moving functions out to the SOA middleware layer is a good way to do that.   

As Tony put it so aptly:

"When you have a large enough customer base, you’ll attract more flies with honey and that maintenance can become quite a lucrative business. …conventional wisdom was that maintaining multiple incompatible lines would drain the business. But once you have accumulated such a large chunk of the market and so many product lines, the costs of convergence get far outweighed by the revenue potential of simply maintaining and gradually enhancing them. Anyway, with Y2K over, customers hardly in the mood to rip and replace once more."

Oracle VP Paco Aubrejuan said as much: "We're being as pragmatic as we can and picking the greatest hits of solutions we already have. Service oriented architecture shouldn't be about reimplementing. The costs are too high so you have to evolving existing assets into SOA."

Tony adds that Project X "might try to accomplish what has so far eluded cross industry organizations like the Open Applications Group (OAG): defining a set of common business objects so one enterprise system could exchange its customer object or order-to-cash process with another." The ability to integrate processes — beyond simple standards — is the new value proposition that vendors can offer the market. And Oracle gets that, as does its arch competitor, SAP. Expect to hear about more Big SOA.

Have you heard about SOA as a SaaS? Okay, sorry to go haywire with the acronyms. 

Ian Thomas picked up on my initial post "Is SOA Software as a Service, Delivered Internally?", and has been pondering where the relationship between SOA and SaaS will take us.

SaaS pushes the right buttons in terms of reuse, economies of scale, standardization and cost transparency — providing a frame of reference for SOA

For the most part, Ian disagrees with the idea that SOA is actually SaaS embedded within the enterprise, and, therefore, he says, the answer to the question "Is SOA SaaS, Delivered Internally?" is "no." SOA is weighted down by heavy internal enterprise infrastructures, while SaaS offers far nimbler and cost-effective third-party service options, he says.

In my initial post, I posited that SOA is, for all intents and purposes, a form of SaaS delivered inside the corporate walls. For starters, it's a great elevator speech to help line-of-business managers grasp the SOA concept, but there's much more value beyond that.

Rather than building, maintaining, or delivering their own services, business units subscribe to services from a publisher somewhere else in the enterprise (SOA), or outside the enterprise (SaaS built to SOA specs). Someone else worries about upgrades, maintenance and testing; you consume the service, and pay on some pay-as-you use arrangement. That's SOA; that's also Software as a Service.

Ian does agree that framing an SOA pitch to business managers as an "internal SaaS" is an idea that has merit:

"Many people now get SaaS - 'I’m buying something that I can get more quickly  and more cheaply and which makes my life easier' - whereas SOA is still a pretty ephemeral concept for most. SaaS pushes the right buttons in terms of reuse, economies of scale, standardization and cost transparency that I feel are absolute imperatives for the organization of the future and gives us a frame of reference to start moving the conversation up the value chain to business services."

As the SOA-SaaS interplay gains critical mass, Ian predicts that the outside services — which have greater economies of scale and value propositions — will overtake internally delivered services. "As organizations increasingly grasp the concepts of service provision - driven by SOA, ITIL and SaaS - they will need to grapple with the idea that as a service provider they will need to deliver services quickly, cheaply and reliably with inclusive service management, reporting, billing etc. in order to be competitive. As a result, organizations will unlikely be able to sustain   expensive, bespoke and plodding enterprise infrastructures and will start to look at external utility computing platforms."

Looking further into the future, Ian predicts that ultimately, enterprises will be subscribing to "Business as a Service" (BaaS) propositions, in which they "construct an overall value chain rather than just buy software." I agree, and have posted some thoughts on the emerging "Loosely Coupled Enterprise" that SOA-SaaS is making possible.

But will enterprises simply end up entirely on the consuming side of business services? What if part of their core business (no matter what industry) becomes service provision as well? We may see the rise of 'Intrapreneurial' SaaS, in which corporate units (probably, but not limited to, IT) that build, maintain, test, and offer libraries of SOA-enabled services for consumption either by customers within the organization, as well as external customers willing to pay for those services on an incremental basis. 

With SOA, Web services, and SaaS, we can all be both publishers and consumers of services. That's the beauty of it all. 

I've talked plenty about JBOWS architectures (Just a Bunch of Web Services), which are essentially services that are point to point and have no cohesion in terms of governance, registry/repository, orchestration, process testing, or flow.

At what point should higher-level SOA qualities kick in? I've heard plenty of discussion, but it seems the general consensus is that if a company only has a few Web services, it simply may not yet require the trappings of SOA. Of course, it depends a lot on what those few services do — a single service handling ERP transactions from 10,000 end users takes on a lot more urgency than 100 services each handling a few corporate lunchroom transactions.

Lorraine Lawson just surfaced a discussion on this very topic, and reports that there is a formula that can be applied to determine the threshold of when JBOWS crosses into the SOA realm. And when that formula is applied, 50 comes up as that magic number.

Lorraine quotes a recent podcast (link to MP3 file here) on the topic:

"Time and time again, SOA efforts fall into confusion once a company has several development teams and about 50 services built. That’s also the point where there are too many services for informal management, says Robert Meyer, the senior product marketing manager for TIBCO. "Once companies hit this number, they quickly can lose the benefits of SOA unless they take time out to set up SOA governance. 'The people who don’t put this in place can actually spend more than they would on traditional application development,' Meyer says.

Again, it depends a lot on the quality and scope of the services involved, but 50 seems like a good threshold to begin thinking about introducing SOA methodologies. From surveys I've seen, most organizations aren't there yet, but, make no mistake, they're rapidly approaching the Big Five-O.

Aberdeen Research has just completed and published a survey of 950 companies, and concluded that "between a third and half.. are having serious difficulties getting their SOA-enabled applications into stable deployment." The survey was underwritten by three SOA specialty vendors — iTKO, Mindreef, and Progress Actional.

Many companies can't measure results around SOA, and don't know what, exactly, should be measured

I'm not surprised to hear about SOA deployment issues, and frankly, expected a higher number. One finding did grab my attention: Aberdeen sorted out the "best-in-class" companies — the top-performing 20% of companies — and found only a third (33%) of this group has more than two years experience with SOA technology, which means two out of three of the most advanced SOA sites don't even have at least two years' experience yet. We're all new to this animal called SOA, and even the best and brightest are still trying to learn what it's all about.

With everything just getting out of the starting gate, it's no surprise, then, that most of the overall survey group, 77%, say they have not yet seen a "payback" from their SOA. However, most of the best-in-class segment, 68%, claim they are "achieving positive ROI on their SOA investments" (whatever that means), as well as lower application development costs under SOA. 

So, why are the "best-in-class" companies seeing so much success from their SOA at such an early stage — especially when most companies are still struggling with SOA?

Aberdeen says that it's because most, if not all, of the best-in-class companies have implemented design-time governance and re-use policy to minimize lifecycle service costs, compared to 26% overall. As part of this, more than 80% of the best in class groups have implemented an automated solution to SOA operations and governance.

This study provides vivid proof that governance and reuse do help deliver successful results for SOA efforts. This particularly holds true for the cost-saving aspect of SOA, such as cutting application development and deployment times. An especially important element is the adoption of design-time governance. As the report observes, "design-time governance is where programmers can be 'encouraged' to re-use existing services, saving the initial coding time and long-term maintenance costsof writing new but duplicative program code."

However, measuring and reporting SOA success — whatever that may be — is a tricky thing. The best-in-class companies got to where they are because they have the wherewithal and know-how to establish measurable performance metrics, and how to apply them directly to the business. Thus, they have more visibility to see more precisely how SOA methodologies (as well as other technology initiatives) may be saving money in certain areas, or enhancing aspects of the business, such as sales growth.

Can we assume that because those companies that can measure results are seeing good results from SOA, that there are many hidden success stories happening out there? Perhaps. But those firms that know how to measure results tend to have higher success rates at things anyway.

Many companies don't have the resources to measure results around SOA, and may not even know what, exactly, should be measured. You can't blame them — it's an inexact science. When it comes to business growth (versus cost savings from development costs), even the most advanced companies I've spoken with do not have specific metrics they can use to track the impact of SOA. Right now, it's all anecdotal evidence, such as increased developer or user satisfaction.

Figuring out what impact, if any, SOA is having on driving new sales and customer wins is still unexplored territory. And, as the survey reminds us, even the best of the best don't even have two years under their belts yet.

IONA Technologies just announced it is acquiring LogicBlaze, an open source SOA tools company.

ZDNet blogging colleague Dana Gardner provides a compelling overview of the acquisition, and what it means to the SOA market. Namely, that this is just the latest in a series of acquisitions, partnering and product announcements now going on in the SOA space.

With all this activity, Dana concludes: "Do you think SOA is all hype? Not a chance."

A couple of months back, Dana, I and several other analysts had a chat with a Wall Street guru who opined that Wall Street didn't really quite "get" SOA yet. Maybe the Street is starting to get the message.

I just posted some observations on how the best SOA governance may resemble the way the US Constitution is set up, with separation of powers and jurisdictions. I held up Citigroup as a shining example of this thinking, as they have an SOA governance structure set up with a "national" (corporate) government overseeing overall direction; "state" (divisional) governments to make things happen; and "local" (line of business; departmental) governments to manage specific applications.

Now, ZDNet blogging colleague Larry Dignan reports that Citigroup may cut 17,000 jobs as the result of a three-month efficiency review designed to cut annual expenses by $1 billion. Larry observes that Citigroup CEO Charles Prince has expressed concern over the financial services giant's rat's nest of separate and redundant middle and back office businesses. Citigroup's challenge is to "rebuild and connect old — sometimes very old — technology systems," he said.

Such a challenge is tailor-made for SOA. Citigroup appears to be ahead of the curve in SOA thinking, which was no doubt prompted by the recognition that this huge Spaghetti Oriented Architecture needed to be brought under control and integrated. The long-term success of this integration effort will someday be a good case study for SOA, if it all comes together.

Evans Data just released details of its Corporate Developers Survey, which measured the pace of SOA adoption among companies with more than 1,000 employees.

I authored the final survey report for Evans. Surprisingly, adoption of ESBs is trailing that of full SOAs — I had expected ESBs to be more in the vanguard of SOA early deployments, and deployed well beyond existing SOAs. Currently, 15% of companies have ESBs in place. While that percentage that will more than double over the next two years, it lags overall SOA adoption, which will jump from 24% to 52% during that time.

Previous and related surveys in recent years also reflect an uncertainty around ESBs. Apparently, many companies are moving into SOA without ESBs to serve as intermediaries between various parts of the infrastructure.

About the photo: That's a model of the largest known "ESB" in the world — even built using a "Lego-block" approach! 

Readers — Is there an ESB in your plans? 

 Loading …

I've been meaning to surface one of Dana Gardner's latest SOA BriefingsDirect podcasts, in which we were joined by Miko Matsumura, VP of marketing for webMethods (now Software AG/webMethods of course). Miko has a gift for translating complex SOA topics into mentally tangible metaphors, and the chat turned to an interesting analysis of how SOA governance closely parallels national governance.

Does SOA work better as a federated democracy or as a benevolent dictatorship? And who pays the taxes?

Dana has a link to the podcast and transcript here. 

The discussion first focused on what SOA "failure" is, and Miko predicted that "in 2007 we’re as likely to see catastrophic failures as we are limited success. There are a huge number of moving parts within SOA…" Miko went on the explain what he saw as the most dangerous moving parts of the SOA assemblage: people.

"The system is sort of cybernetic; half-human, half-machine. The human pieces of SOA are the parts that we’ve seen in failure mode. It’s not necessarily just the human beings themselves, but the interfaces between the human world and the machine world, whether those interfaces are the specifications used to design applications, or the mechanisms used to manifest constraints and policies."

Good governance is a reflection of the way people are organized and motivated to contribute to the greater good, and for guidance in this department, Miko suggested looking to the way national governments are set up and powers are separated. The federal government of the United States provides a good model as to how to set up SOA governance, he pointed out.

"You have a bunch of business units called states, that each have their own legislation, their own competency centers called state legislatures, and even their own executives called governors. Those look a lot like business units to me."

That's where the principle of jurisdiction kicks in. "Ultimately, competency centers become the legislative bodies within these organizations," Miko said. "All of the efforts that I’ve seen to codify methodologies around SOA tend to focus on these competency centers or centers of excellence, primarily because there needs to be an inclusive organization for adjudication and jurisdiction, as opposed to having a model, where it’s just a single iron-clad dictator that controls all policy."

To which Dana added: "We’re getting at the point where world political history is perhaps a guide to how to approach SOA. Do you want a Third World dictatorship? Do you want empires extending their influence? Do we want a Pax Romana approach? Or do we want a pure democracy or a federated democracy? I’m thinking more about Star Trek, when the Romulans and the Klingons get together. If you could only get that to happen in IT, would be in a lot better shape."

Of course, there are plenty of companies that tend to approach such efforts in a dictatorial fashion, but its likely SOA approached this way may end up in the ash heap of history.

Some large companies are already framing their SOA governance structures in the model of the US Constitution. Skip Snow, senior vice president and chief SOA architect for Citigroup, said overseeing SOA at a company with 300,000-plus employees and more than $1 billion in revenues every 11 days would be just too onerous and overwhelming for one governance committee, or even series of committees — just as it would be impossible and dangerous to manage a nation of 300 million citizens with a one single government entity. (My original post on the Citigroup story is here.)

Citigroup’s SOA initiatives are divided along a separation of powers between the federal (enterprise) level, state (divisional) level, county (line of business), and municipal (departmental) level. 

Citigroup’s SOA governance structure is federated in nature, with a "separation of powers" similar to the way the US federal government is structured:

• An “executive branch” (IT) oversees operational aspects, as well as development and design; 
• A “legislative branch” (executive management and board of directors) establishes the goals and directions of SOA efforts; and   
• A “judicial branch” (enterprise architectural boards) deals with conflict resolution and compliance audits.

Of course, there's also the whole issue of raising revenues for governments, one that is particularly on the minds of US taxpayers this week in April.  Fellow ZDNet blogger Robin Harris adds a new twist to the governmental analogy, observing that "IT services are paid for by taxes, not prices, so users have little incentive to support SOA. Since IT can’t relate costs to service prices, any SOA cost advantages are buried. SOA means uncertain application execution, so users will hate and fear it."

Neil Ward-Dutton of Macehiter Ward-Dutton has weighed in on today's announcement that Software AG intends to acquire WebMethods, but doesn't see it as a highly effective union.

Neil is not surprised that a larger company swooped in and grabbed WebMethods — which has been an active player and thought leader in the SOA and integration space.

However, he is surprised at the suitor, Software AG. "Software AG is a company with a long history as a middleware company, but it's not a glorious one," he says. Software AG's current portfolio, which includes its Centrasite (SOA registry/repository) and Crossvision (BPM, ESB, legacy integration, composite application development) lines, overlaps a lot of WebMethods' offerings.

"Given the huge portfolio overlap, from a product and technology - and ultimately a customer - standpoint, this will be a difficult integration to pull off," Neil said. 

What's the deal with this $546 million acquisition, then? Neil feels its more about geography than technology — WebMethods has a strong North American presence and brand recognition, which Software AG, based in Germany, lacks.

Who knows the underlying reasons why acquisitions happen? Many companies get acquired simply for their customer lists, or to take them out of the game as a competitor. Geographic positioning makes perfect sense as well. But Software AG has also strengthened its claim into the great, open legacy-to-SOA frontier.

Software AG just announced it is acquiring SOA and integration vendor WebMethods, and ZDNet blogging colleague Dana Gardner is on top of it with this perspective, posted here.

The purchase price was $546 million. Within that acquisition, of course, comes Infravio, the SOA registry provider, which WebMethods bought last September for $30 million.  

I've often said that legacy systems are a vast, great, untamed frontier for SOA, and this acquisition may be part of the land rush (or gold rush) to stake more claims in this space. Software AG's offerings include tools for the Web and SOA-enablement of mainframe and legacy systems. WebMethods has also focused on the legacy integration space, so it seems natural that these two should join forces.

Dana observes that this is part of a continuing trend toward industry consolidation. "Bigger is better in terms of SOA solutions provider survival, regardless of the chatter about the virtues of best-of-breed product approaches." Plus, it appears that the bigger infrastructure players continue to actively seek the best-of-breed providers that are offering solid SOA solutions.

Dana also makes another interesting statement — that not only is SOA governance and management of SOA becoming "the tail that wags the dog of general IT management," but "perhaps even the way businesses are managed, controlled and directed in total."

This suggests a hefty enterprise role for SOA, as well as the governance tools that can make SOA happen.

You know the drill. Vendors trip over each other working to reach the Big Enchiladas — the enterprise SOA market, the Global 1000s.

It's like that Capital One commercial, where one stuffy banker says to the other, "…but we only care about BIG business!"

Open source software may help bring SOA to the masses

Of course, everyone pays lip service to that great, vast SMB in the sky. (small to medium business) But SMBs are the fruit higher up on the trees. They're fickle, they have limited budgets, and the people making purchase decisions wear multiple hats — everything vendors hate.

Hence, SMBs remain the great unserved (or underserved) market. One of the most consistent criticisms of SOA vendors is that they push expensive software and service arrangements on companies, promising more agility, but with no guarantee of successful outcomes. And, of course, these offerings are beyond the reach of the budgets of most smaller companies. SOA just has not been a small company thing.

Open source, in combination with SOA, may bring SOA closer to the masses. On Monday, SOA Software and Red Hat announced a partnership in which SOA Software would supply governance and management capabilities to open source SOA projects.

JBoss is an interesting story because it's main goal in life has been to make SOA-compliant middleware available to the masses. Its target market is the small business sector, as well as departments within larger enterprises. More than anything, the open source convergence with SOA may be more of a disruptive force than anything else.

A couple of days back, I had the opportunity to chat with Hugh Taylor, VP of marketing for SOA Software, and Shaun Connolly, VP of product management for Red Hat/JBoss, about such implications. First of all, by teaming up, SOA Software and JBoss clearly are looking at building up a suite-like capability that will compete with the likes of Oracle, IBM, and BEA. With one clear difference — SOA SOftware/JBoss are targeting the great "unserved" market in a serious way.

Shaun pointed out that the unserved market consists of "the people who have to roll their own, because they can't afford the licenses for the [SOA] projects they're doing. That's why we've been very diligently building out on top of our application platform, the business process, business rules, and portal-based offerings. That's why we're focused on our ESB-based service integration and orchestration platform."

Hugh states that small-business SOA is being propelled by the trading requirements of the larger companies. "You might have a very large company, like a Boeing, or Ford Motors, which will specify a SOAP-based interface, or connecting with a supply chain that may affect a lot of smaller companies. They'll need to have a solution that they can use to be a part of it. That's the sort of leadership that will drive SOA adoption to smaller companies."

It seems that no matter how hard Greg tries to evangelize SOA to his CIO and the suits upstairs, the organizational stars always seem to align against him.

Scott Fingerhut at TIBCO alerted me to a new installment of the "Greg the Architect" series over at YouTube.

In this latest edition, even though Greg successfully replaced the company's CORBA components, installed a rules-based policy management system, consolidated onto a single ESB, installed a registry, and integrated the data warehouse with real-time updates (whew) — he still gets the rug pulled out from under him.

"The big guy just doesn't think the SOA is delivering ROI…" his CIO informs him.

Now, follow Greg's adventure across the enterprise in pursuit of the elusive "ROI"! And yes, ice cream does play a role.

This video is a great follow-up to the original Greg adventure in which he's draawn into a dizzying swirl of vendor FUD.