SOA Software Inc. says its acquisition of LogicLibrary Inc., announced today, creates “a dominant Integrated SOA governance automation company.”

The two companies were both rated as leaders in respective governance areas by two major analyst firms, said Roberto Medrano, SOA Software’s executive vice president, in making the argument that the new whole will be greater than the sum of its parts.

Pointing to a Gartner Inc. magic quadrant for “Integrated SOA Governance Technology Sets” published at the end of 2007, he said, “Why do we say we’re leaders? It’s not because we say it. Gartner says SOA Software is a leader in SOA governance. LogicLibrary is there as a visionary. The combination of SOA Software as a leader and LogicLibrary as a visionary certainly puts us up there.”

Medrano then points to a Forrest Research Inc. wave chart for ”SOA Service Life-Cycle Management,” published in the first quarter 2008, which shows LogicLibrary and SOA Software in the running for leadership roles in a graphical scrum with IBM, Hewlett Packard Corp., and Software AG. BEA Systems Inc., now being acquired by Oracle Corp., rises above the rest in the Forrester view.

The acquisition of LogicLibrary by SOA Software follows a trend among governance vendors that is likely to continue, writes Dana Gardner, principal analyst of Interarbor Solutions LLC., in his blog today about the deal.

“The merger underscores not only the SOA vendor consolidation trend (ongoing), but also highlights the market driver of more end-to-end governance and management aspects of SOA deployments,” Gardner writes. “HP and TIBCO also had recent announcements that point up a wide and more automated approach to SOA governance/management.”

“What’s more,” Gardner added, ”I expect to see more of this ‘total management’ approach to SOA coming from the open source SOA infrastructure providers, too.”

The strength of the SOA Software/Logic Library combination, Medrano argues is that while the two companies are highly rated on the same analysts’ charts, their technologies are complementary, adding to the greater whole with little overlap.

“There is no real competition between us and LogicLibrary in terms of the assets and products that we have,” the SOA executive said. Concluding that with their product lines merged: “We become one of the few if not the only one that provides the entire SOA governance for all the enterprise assets.”

Alan Himler, who until today was CEO and chairman of LogicLibrary and is now senior vice president, product management for SOA Software, said the combined governance technologies cover more than Web services.

“The beauty of it is that it covers not just services but other types of assets,” he said. “We can offer a solution from the distributed level up to the mainframe.”

The executives of the two companies points to the individual technologies they offered:

SOA Software technology included:

• policy lifecycle governance
• SOA registry, service lifecycle, compliance policy
• operational governance
• service security, mediation, management, operational policy

LogicLibrary offered:

• SOA asset lifecycle management
• SOA development governance and SOA repository
• IDE and SCM integration

Medrano pointed out specific areas where LogicLibrary products will strengthen SOA Software offerings. He said the LogicLibrary Logidex product complements its SOA Service Lifecycle Management position with added capabilities including:

• Compliance policy definition and validation
• Mainframe artifact discovery
• Management policy definition and integrated implementation and enforcement
• Depth of support for service definitions
• Enhanced standards support
• Richer RBAC model and IDM system integration
• Federated identity and trust mediation

SOA Software’s Workbench is strengthened with capabilities from LogicLibrary including:

While financial details of the acquisition involving privately held companies was not released, Medrano said it involved a stock transfer. He said Los Angeles-based SOA Software will maintain the LogicLibrary offices including the Pittsburg, PA headquarters, and the Rochester MN research lab. The majority of the staff will also be retained, he added.

Java EE 6, now in the development stage, needs to embrace the service component architecture (SCA) specification, argues Sanjay Patil, standards architect at SAP AG.

The Java Community Process Web page for Java EE 6 indicates that SCA is being considered for the next version of the enterprise platform. So in a conversation at this week’s Java One with the SAP standards guru, SearchSOA editors asked Patil if consideration should move to implementation.

Should SCA be part of Java EE 6?

“I certainly think it should,” Patil answered. “The main reason is SCA is really about assembling applications in a technology neutral way. If it was about a specific platform, such as Java EE, you could say there are enough APIs and libraries for Java applications. But if you look at the key value of SCA it’s about recognizing the fact that customers have different technologies, Java EE, BPEL, BPM systems, traditional EAI systems. They have a variety of communications mechanisms including Web services, JMS, and EDI.”

Facilitating SOA development in these heterogeneous environments was the driver behind the creation of the SCA specification by a vendor group that included SAP, IBM, Oracle Corp., and BEA Systems Inc. SCA is now making its way through the standards process at OASIS.

While there was a dearth of official talk about enterprise Java in the Java One keynote, Patil said the Java Enterprise Edition will be a major player in service component development.

“One of the main component technologies is going to be Java EE,” he said. “Our NetWeaver product is based on Java EE 5. So in our view it is important that Java EE support this high-level composition standard, SCA.”

One of our sister sites, SearchNetworking.com, just published a story on how networking pros need to collaborate with people on the applications more often these days because service-oriented apps and Web 2.0 technologies put a greater and/or different strains on the network.

The article comes out of an Interop 2008 session and quotes Shankar Ramaswamy, vice president of product management at Sonoa Systems:

“Often, we start talking to customers in the application side of the house,” Ramaswamy said. “And we say: ‘Hey, we need the infrastructure guys to buy into this. Our customers are starting to recognize that this discussion has to happen outside of our technology. We are pushing it along because we are providing something that makes these people collaborate. We urge you to talk to your application people more.’ “

The piece goes on to quote others and talk about why networking pros and app dev pros need to be locked in the same room until they figure out how to work with one another. Mind you, this isn’t revelatory news. I remember writing essentially the same story after talking to users attending the 2002 NetWorld+Interop conference. John Gage declared “the network is the computer” more than 25 years ago. All SOA and Web 2.0 technologies are doing is taking the network up on the offer.

What baffles this observer of the IT industry is why we’re still having this discussion. The connection between an Internet-enabled network that can go anywhere and applications that try to combine disparate systems and data is so blatantly obvious that you’d need to disable all five of your senses to miss it. CIOs should have demanded app dev and networking get on the same page a decade ago. Instead the conversation seemingly revolves around domain pros wondering why folks in the other domain must afflict them so?

There’s no real big secret to that one. It’s because what you do and what they do are intimately tied together. SOA stands for service-oriented architecture, not service-oriented applications. A big part of that architecture is the nervous system that enables the loosely coupled, discoverable services to operate.

We spend a lot of bandwidth these days talking about technology and ROI (or the lack thereof). I’ll hazard a guess, absent any broad-based data to support it, that ROI is as much tied to getting disparate groups like app dev and networking to work with each other as it is to anything else. It gets to the simplistic beauty of Occam’s razor. Why can’t your IT department operate more efficiently? Because it doesn’t. If it did, then you’d likely see faster and bigger ROIs. Obviously levels of collaboration and dysfunction vary company to company, division to division, but far too many people aren’t having this conversation and you know who you are.

When all else fails, you might want to try working with the people with whom you work.

I’ve been having an extended conversation during this calendar year about SOA and the telecom industry, namely that the European telecoms are often the reference models for what a service-oriented business looks like while U.S. telecoms seem to be mired in the 1990s.

Today we’ve got a curious development with the announcement of the OASIS Telecom initiative, designed to help businesses in that industry embrace SOA. It’s a fine idea and somebody needs to do it, but it’s the equivalent of the short bus. I can tell you who this isn’t aimed at: companies like BT and Deutsche Telekom. They get SOA. In fact, they do it as well as anybody on the planet.

This OASIS effort is geared toward U.S. telecoms and telecoms in emerging economies. It begs the question, “How did the U.S. get lumped in with emerging economies?” We’re talking about corporate giants which apparently require extra hand holding to help them do something that has already delivered for their overseas brethren.

As I’ve been talking with analysts, vendors and users this year about the telecom services in the U.S. market, I encounter a lot of head shaking. I keep hearing that the services available in Europe put to shame what’s being offered in the U.S., which they say mostly revolves around access rather than services.

Telecom is probably the industry most worth tracking to see how early SOA adopters are able to compete and respond to market changes as opposed to service-disoriented competitors. To be fair, there are some U.S. telecom companies that have pursued big SOA projects, but I have yet to run into anyone during the last four months, where this has been a running point of curiosity for me, who hasn’t said the U.S. is lagging behind in this industry (at least in terms of modernizing services delivery capabilities), particularly as applications incorporate more Web 2.0 technologies and unified communications.

Kudos to OASIS for trying to spearhead this sort of modernization, but the real point of interest for this observer will be watching the what happens with the telecom players who took the SOA initiative and gave themselves a head start.

In the early days of client/server adoption in the 1990s there were lots of articles lamenting the fact the client/server wasn’t living up to its promise. It was just another theory that didn’t really work all that well in practice.

But after a few years client/server was just the way application development was being done. It wasn’t a theory any more, and too some extent it ceased to be a hot topic for debate. It was old hat.

New technologies including XML, Web services and finally SOA became the hot topics. Of course, as a Gartner Inc. analyst pointed out in a talk a few years ago, SOA pretty much began in the mid-1990s as an extension of client/server.

“Customers were doing SOA then although they weren’t calling it that,” Massimo Pezzini, vice president and distinguished analyst Gartner Inc., said in a 2006 talk. They tended to use the terms of the 1990s for their projects, calling them client/server. Pezzini said that is the secret few SOA gurus want to let out of the bag: SOA is an update of classic client/server.

In a recent article about the problems with SOA adoption, Ron Schmelzer, senior analyst with ZapThink LLC., also credits Gartner with the transformation of client/server into SOA in 1996.

So it seems client/server, which didn’t live up to its promise, has morphed into SOA, which isn’t living up to its promise. But lots of organizations did client/server even if they did it imperfectly, and it appears organizations are now doing SOA albeit imperfectly.

The nature of things humans do is that they are generally not perfect and almost always could be better. With the exception of 4.0 students, most of us got educated imperfectly. The interstate highway system in the U.S. is far from perfect but we’ve been getting around on it for decades. City planning, which Schmelzer says may be the best analogy to SOA because both are always works in progress, does not produce perfect cities. But it could be argued that city planners in many cases help design more liveable and workable cities.

Interviews with CTOs, architects and developers who are actually doing SOA indicates that progress is being made despite the lack of perfection.

In a user story this week Manny Montejano, CTO at Cars.com explained how he is achieving the elusive SOA goal of getting business executives and managers to drive SOA initiatives. But at the same time, he pointed out that his SOA implementation is only about 30 percent of the way to achieving its ultimate goals. And there have been bumps in the road but he views them not as failures but as learning experiences.

 ”I’m not saying we’ve done everything perfectly every single time from the get-go, which is where our lessons come from,” Montejano said. “We’ve learned lots of lessons specifically that this is a business initiative not an IT/technical initiative.” 

Most of the people who are actually doing SOA talk about it in turns of evolution, or to use Schmelzer’s city planning analogy, an on-going project that is always changing and evolving but is never complete.

Shibashis Mukherjee, lead enterprise architect at Con-Way Inc., the transportation company, actually began work in 1996 on what has become his company’s SOA implementation. 

In his account of more that a decade of working on the evolution, Mukherjee recalled: “We started with the component-based development methodology. At that time SOA wasn’t the big thing yet. We realized it would help us develop faster if we had reusable components to build applications. As our development process matured and SOA came into play, we figured out how to compose the services.”

Perhaps if SOA is viewed as a process we would be less impatient with its lack of perfection.

A lot of analysts I respect have been pushing the concept of Web-oriented architecture, or WOA, of late. For those unfamiliar with the term, Dion Hinchcliffe has covered it extensively and Dana Gardner has been singing its praises. To be honest, it looked like a term in search of a foundation to this observer. We’ve already got RIA and composite applications and mashups and Web 2.0 and SaaS and SOA, but I figured I should ask a few architects what they think of the concept to see if it’s got traction in those circles.

Granted, I only polled half a dozen people (though I’ll note here that they are half a dozen really smart people). The response I got from all of them is that WOA strikes them as redundant and nothing particularly new, an empty suit if you will. One wrote, “It reminds me a lot of the attempt by someone to gain some name recognition with the ‘SOA 2.0′ concept (which one vendor did try to use and then dropped after it was rejected by the SOA community).” Another responded, “It’s the same old thing, relabeled with an even MORE unwieldy name.”

Yet another noted, “This is just composite Web apps.”

Not a single one of them voiced a problem with the notion that Web-based development is an excellent place to concentrate your resources. In fact, some of the architects stated they are eagerly pursuing these sorts of development strategies.

That said, no one showed any love for the “WOA” acronym. “God forbid this take hold because it could complicate something the industry has been trying to simplify,” said one of the architects. He listed numerous reason why WOA, as a term, could do more harm than good:

• Users should have exactly one enterprise architecture, many don’t and they don’t need the confusion of “which architecture should I use?”
• WOA doesn’t really have an underlying architecture, it’s more a set of best practices around REST, RIA and composite apps.
• If users perceive WOA to be outside the principles of SOA, it could prove an excellent vehicle for building Web-based stovepipes.
• WOA toes and sometimes crosses the line of being technology driven. “We plan on using Google Apps, but Google Apps needs to fit into our structure, not the other way around.”

That last point about the potential technology driven nature of WOA was a point of contention for another architect. “One of the big problems we’ve had to fight is people who act as if SOA is tied to middleware or specific standards like SOAP or to a specific data format like XML. Nothing could be farther from the truth. Just because you’ve got some new technology to use doesn’t mean you go back to shoddy engineering. Everyone should know better than to let a specific hot technology drive the bus. It will cool off and you still need to be in business.”

Strikeiron CEO Dave Linthicum has also blogged about the upside of WOA. He pitched WOA as a potential gateway to SOA.

What is changing quickly is that enterprises are finding that the path of least resistance is in essence to build their SOAs on the Web, using Web resources, including content, internet delivered APIs, and Web services. Once there is success with WOA you’ll see the same patterns emerging behind the firewall, or SOA.

The polled architects viewed that as a perfectly legitimate approach, but one noted, “It’s still SOA. I just don’t see where WOA adds anything. Terms like this tend to make people in the field angry. In this case, it’s an attempt to sell them something they’ve already bought. I don’t know anyone who doesn’t want to use REST or build composite apps using Web tools.”

Time will tell whether WOA gains traction, but these architects expressed an unequivocal desire to have no more than one something-oriented architecture in their lives.

It’s amazing what happens you put a few thousand SOA users together. Suddenly you start to get a clearer picture of what service orientation can achieve at both the business and IT levels. That was probably the biggest takeaway for this attendee at IBM’s Impact 2008 conference last week: a lot of users are well down the road with this stuff. They’ve thought about it, put it into action and it’s responsible for a significant amount of mission critical business.

(The other revelation was that the B-52s have a keyboard player who looks like Jose Canseco, but I digress.)

Here’s a smattering of comments made by SOA users at the show:

John Roach, director of architecture and governance at Wal-Mart, focused on using SOA to help manage store stock levels and customer demand. “If SOA doesn’t trace back to you finding the right thing when you walk into our store at the time you need it, then it isn’t material for us,” he said.

Kumar Murugan, application development manager at pharmaceutical manufacturer and marketer Novo Nordisk, talked about centralized policy management and stressed the need to view all SOA projects as part of a continuous process improvement cycle. He also highlighted the importance of having a rigorous QA process.

“You need to do a system discovery for any new service,” he said. “You need to understand how reuse affects your existing services.”

Manny Montejano, CTO at Cars.com, called governance “the key thing we need to resolve to be successful” as his company deals with explosive growth.

“It’s important to say no sometimes,” he said. “You have to let people know that some things are going to be more trouble than they’re worth.”

Anne McDiarmid, CIO for Australian fabric and crafts retailer Spotlight, made a case against trying to solve every problem with a software purchase.

“I’ve got middleware hanging out of my middleware,” she said. “I don’t need more middleware.”

A whirlwind of corporate acquisitions in foreign countries has created an integration challenge for SEB, a Swedish banking and insurance company. Enterprise architect Anders Jader targeted data as a key element in bringing together this international banking conglomerate.

“We are now in a phase where we need to transform everything into one data model and then be able to use that data as a service,” he said.

Tony John, domain lead architect at Allstate Insurance, echoed the importance of data in all things service-oriented, stating “we need more data analysts and data architects.” He noted that the bulk of a $30 million mainframe-to-SAP project “was spent on understanding the data.”

John also made the case that technologists have to understand the business they work for, not just how their niche of IT functions.

“No matter what machine or network it goes through, it’s still a group of people doing some business activity,” he said.

Things Kate Pierson surely never thought she’d say during a concert when the B-52s were taking off 30 years ago: “Happy birthday WebSphere!”

Now, THAT is what I call a mashup.

Artists who debut high on the Billboard charts plugging your products is also what happens when a company pulls off a big show, which is what IBM has done at Impact 2008. It’s easy to be cynical about these sorts of events. In fact, I’m paid to be cynical about pretty much everything. It’s a job requirement. Yet it’s impossible not to notice all the users in attendance and presenting in the sessions. Anyone who doubts whether SOA is happening at the corporate level only needs to spend an afternoon here and it will quickly prove that SOA is not only happening, but it’s happening in a big way.

After four days I’m starting to wonder if there’s a company that isn’t pursuing service-orientation. One interesting observation from a senior IT exec with whom I had lunch the other day was that a lot of his developers and IT ops people probably don’t even know the company is heading down the SOA path because the higher ups don’t use the term. The company just happened to build a loosely coupled, modular order-to-cash process. Only the folks with an enterprise architectural view tossed around the SOA acronym. Everyone else was working on an order-to-cash overhaul.

By the way, this is how SOA dies — not with obsolescence, but with ubiquity.

The event has also generated a ton of coverage. Dana Gardner has a great recap of the first day highlights in his BriefingsDirect blog. In it he’s got a killer quote from WebSphere GM Tom Rosamilia:

“You can do BPM without SOA, but I wouldn’t recommend it,” says Rosamilia.

I’ll note here that SearchSOA.com did a special report on this very topic two years ago. Business process management has always been a good idea, but without service orientation it’s largely unimplementable. How you compose those processes and manage them is critical.

In his OnStrategies Perspectives blog, Tony Baer recaps his conversation with IBM software head honcho Steve Mills about whether SOA is getting boring and then talks about the parallels between SOA and enterprise databases.

There’s yet another parallel between SOA and the evolution of databases. Twenty years ago, there were debates over whether SQL databases could handle the load and deliver the performance of legacy databases or file systems. The answer was throwing Moore’s law at the problem. Today, there are similar questions regarding SOA, because if Web services standards are used, that means a lot of fat, resource-hungry XML messages whizzing around. Mills’ answer is that there’s a glut of underutilized processing capacity out there and a crying need for virtualization to make that iron available for XML.

A lot of software-oriented folks tend to miss out on how much of a role hardware has to play in SOA. We’re talking about architecture here, not software. Hardware, networks, databases, storage — each one comprises a major component of the enterprise architecture. IBM’s talking about monster transaction volumes this week, the sort of thing you’d associate with TPF. So don’t be surprised if you’re in an app dev meeting in the future and you’re sitting next to the corporate mainframe guru and a data architect. Comfortably living within the artificial barriers created within IT shops is probably a luxury you won’t enjoy much longer. Those imaginary cubicle walls are coming down.

James Taylor has been a one-man Impact blogging machine this week over at Smart (enough) Systems. One entry covered a customer panel comprising Michelin, The Hartford, Health Care Services Corporation and the U.N.

Randy [Wallace from Michelin] discussed how far they had come from having a very small percentage of IT spend aligned with key business goals (6%) to one that is much more so (81%). For instance, in the past business units in different regions picked i2 and Manugistics at the same time and both were implemented resulting in separate systems. A stronger governance process and overall architecture are now established, driven by business ambitions and regularly updated. Far fewer and more focused projects as a result. Senior executive user satisfaction has risen steadily.

Here’s where I note Michelin sells tires. We’re not talking about a financial services company that stands to make a killing if it can combine information in new and dynamic ways or some Web business. These folks have a supply chain, logistics and customer care to manage and they’re finding value in SOA. This is why I really start to wonder who isn’t doing this stuff. It’s working in the tire business. The tire business!

Floyd Marinescu has a great summary of IBM’s “Smart SOA” vision up at InfoQ. In it, he lists five SOA best practices that IBM showed off a few times during the event.

1. Linking business and IT from the beginning. Set the business vision first and see how IT can support it.
2. Develop an architecture with a vision for the future. Not just one that will satisfy one process or one LOB, but something that can work over time.
3. Skills and culture, governance.
4. Scalabilty and process integrity – how do you plan for the spikes?
5. Maintain end-to-end operational visibility

That’s a solid list. I’ll add one of my own, make the QA folks a central player in all of this. I don’t think I’ve spoken with one person over the past year who claimed to have a working SOA who didn’t tell me that service-oriented QA was essential. You’ve got to know what to test, what architectural principles need to be followed and whether your service can be expected to meet its service-level agreements. From everything I hear, it’s one thing to say that, but no mean feat to do it.

As such, it won’t surprise me overly much if at Impact 2009, IBM is pounding away on the theme of quality SOA.

And speaking of new themes, there was a presentation on “Green SOA” that I admittedly didn’t make, but there is a summary of the presentation up at Greenmonk Associates blog. The nut of the case made by RedMonk’s James Governor for “Green SOA” is:

My argument at the event is basically that if SOA is a means to better alignment between IT and the business, then we should also drive sustainability into the mix. Componentising services gives you freedom to leave, for example, potentially allowing you to swap a provider out for a greener, or more importantly from a bottom line perspective, more energy efficient service.

Now that is what I call a forward-thinking take on the whole consumer-provider relationship. At the end of the day, that’s what SOA is: an arrangement between producers and consumers. People classically think about it in IT terms. IBM is pitching it in pure business terms, but the model can be extended beyond that. Choice is perhaps the greatest product of a truly decoupled world and, as Governor points out, profit isn’t the only choice on the menu.

Two interconnected debates are raging in the blogsphere over how service-oriented architecture (SOA) may be running into resistence in 2008.

One debate covered this week in a SearchSOA article is about whether SOA is reaching it’s goal of linking IT and business people, or is just becoming an IT-only initiative that is stalling out in most companies.

The other related debate concerns whether the R-word a.k.a “the current economic downturn” will hurt SOA adoption.

These questions were raised when Gordon Van Huizen, vice president of SOA at Progress Software Corp., called this week discussing how his company is putting all its SOA products under the umbrella of the Progress SOA Portfolio.

The portfolio offers a broader SOA marketing message by covering all the Progress products for:

·         Enterprise service bus (ESB)

·         Business process management (BPM)

·         Complex Event Processing (CEP)

·         Registry/repository

·         SOA management

·         Data interoperability

·         Mainframe integration

From a sales and marketing perspective this seems like a good approach. But Van Huizen was asked about the larger marketing challenge posed by current economic conditions.

Does Progress have a strategy for coping with hard times?

“We have this built-in strategy at Progress that is relatively unique,” Van Huizen said.

He noted that his company’s Open Edge development platform is sold through an ISV channel that has been in place for a long time. The 1,500 ISVs target “very specific, narrowly defined segments of vertical industries.”

By throwing the net so wide, the ISVs reach customers in a variety of industries, not all of which are hurting in this economy, he explained.

“So if there’s a slow down in financial services we don’t feel it so much in that product line,” Van Huizen said. This is also true of the SOA products, he added.

“Our orientation to the market was initally around financial services and telco, perhaps because of the messaging orientation of Sonic MQ,” he said. ”But with the SOA management product, with Actional, there’s been opportunities to branch well beyond that.”

The Progress SOA Management product is penetrating into healthcare and higher education, two areas generally considered recession proof, he noted.

“As one part of the market goes down others remain somewhat boyant,” Van Huizen said. “So if there’s an offsetting strategy I believe we have one. Of course, if everything tanks, we’re all in trouble for awhile, and that’s just the way it goes.”

As for the other related debate about how to keep SOA from stalling out even in companies that have the budget to do it, Van Huizen suggested two strategies.

The first one is to reach across from IT to business people by explaining SOA not in terms of technology with acronyms, but through business case studies that show the dollars and sense success of the approach.

The second is to begin SOA projects at a tactical level, even as simple as application integration, sometimes called EAI 2.0. This allows IT to show the business managers and executives the advantages of SOA without asking them to shell out big bucks for a massive implementation.

These two approaches are also echoed in a recent blog by analyst Joe McKendrick, who quotes fellow analyst Tony Baer’s view that this will be a year of lower expectations for SOA.

“Recessions tend to discourage the kind of long-term thinking that grand enterprise architectural exercises are supposed to support,” Baer said. ”In that sense, SOA has been caught up in the middle - roughly six years after the current incarnation of the concept emerged with Web services, there remains considerable debate as to whether it makes sense to take a project or architectural approach.”

However, McKendrick makes the interesting point: “It’s worth noting that the case for SOA, in tandem with Web services, was forged during the worst IT spending slump in a generation - the 2000-2002 time period. Companies and IT professionals were attracted to the SOA/Web services concepts because they offered the attractive advantage of building or exposing existing applications at minimal cost and disruption.”

Recently we polled SearchSOA.com site members on their RIA and composite application plans. What we discovered is there’s a massive overlap between the SOA and RIA audiences.

In all we received 395 responses and 44% said rich Internet applications were part of their enterprise IT/business strategy. Another 30% reported that RIA would become part of that strategy in 2008. 85% reported that RIA was an important to extremely important piece of their SOA strategy. Only 2% said RIA wasn’t important at all to their SOA plans.
Most strikingly, 74% reported they expect the importance of RIA to their IT/business goals to increase this year. In other words, for 3/4 of our survey respondents, RIA is a big deal that will be getting bigger. Rich Web front ends were the most popular type of app being built or planned (79%), with Ajax (81%) being the most popular technology employed to build those apps. Yet 55% also reported they are building/planning database composite applications and 35% reported they have entered or will enter the fairly new space of enterprise mashups. That’s a fairly massive amount for a category that would have been in the low single digits two years ago.

Oddly, mobile apps only drew a 29% response rate. That could be read a few different ways. Our respondents were mostly senior folks in the app dev or IT department. It’s possible rich mobile development is being done outside their auspices. Yet the fact that the more senior people in the app dev arena aren’t connected to it would also mean that rich mobile development hasn’t become a major enterprise initiative. The other way to read it is that mobile devices have yet to become a major business initiative. In fact, mashups using unified communications might be the path that mobile devices take rather than strict mobile app development.

The top two benefits sought by those building out rich/composite apps were improving the user experience for customer facing apps/services (65%) and providing expected levels of business functionality to end users (61%). Lack of internal knowledge/resources ranked as the number one obstacle to adopting Web 2.0 technologies (21%). It also ranked high as a secondary issue (35%). Yet a whole host of issues fell in the 27-38% range for secondary issues: techinical readiness/back-end support, selecting the right technologies, security, data/application integration issues and application performance issues.

Finally, IT management ranked as the top evangelist (28%), technical decision maker (34%) and financial decision maker (40%) when it comes to Web 2.0 technologies. Yet an interesting person ranked second in evangelism (27%) and technical decision making (26%) - the architect. Maybe this has something to do with polling the membership of an SOA site, but it speaks to how architecture is becoming a primary concern in all applications work these days.

It should be remembered that for years analysts have been saying that a primary benefit of pursuing SOA is to get ready for whatever comes next, to be able to deploy new technologies on top of the existing IT infrastructure in a way that makes sense. It would seem from our survey that those predictions are now taking shape in reality. RIA is happening parallel to and in conjunction with SOA and it looks like many users will have interesting stories to tell later in the year.