The SOA, SaaS, Web 2.0 Connect

Loraine Lawson

Gartner predicts that SaaS could become a $19.3 billion market by the end of 2011, according to a recent Computerworld article. Gartner also reports that SaaS reached $6.3 billion by the end of last year.

 

Big numbers. Big money.

 

As I shared yesterday, organizations that have embraced multiple SaaS solutions are experiencing integration problems. One of the options for resolving this problem is to move to a service-oriented architecture. But that solution is still some ways off as most organizations are still in the planning or early implementation stages of SOA.

 

The question then becomes: How well will SaaS work with SOA?

 

The answer, fortunately, seems to be: very well, indeed. Particularly when you add Web 2.0 technologies, which can help address the data integration problems that SOA doesn't touch.


 

Robert Schneider wrote a fantastic article, "SaaS, Composite Applications and SOA: Understanding their Differences and Making Them Work Together." In it, he explains how they can work together to make work life much easier and simpler for IT and business users.

 

Here's what Schneider had to say about SaaS vendors and SOA:

From an SOA perspective, what makes SaaS so interesting is that, by and large, these vendors "get it": their offerings are much more SOA-friendly, and often comply with many of its best practice guidelines. Of course, there are some horrendous exceptions to the rule, but SOAP-based, WSDL-defined services have become the de-facto standard for integration with SaaS solutions. Many SaaS vendors also understand the value of composite applications, and are only too happy to facilitate deploying these user interface-based integration components.

The seven-page article walks you through a hypothetical company that runs a SaaS CRM system and how IT uses SOA and mashups to give customer service reps access to billing history from within the CRM system. In effect, the mashup - a Web 2.0 technology - gives the appearance that IT has integrated the data into the SaaS CRM system without actually allowing critical financial data to leave the company.

 

SaaS vendors aren't blind to the potential benefits of SOA and mashups to extend their reach, as this recent article on E-Commerce Times explains. The article uses Salesforce.com as an example.

 

Salesforce recently updated its Apex code to allow companies to build their own on-demand applications. The company is calling this Salesforce SOA and has implied it's SOA as a service - a marketing strategy that makes SOA architects hiss with anger, since they argue, with good reason, that you can't "subscribe" to an architecture. Developers can tap Web services and use them to build on-demand applications.

 

To get this functionality, you subscribe to the Salesforce Platform Edition, which allows you run to these on-demand apps on Salesforce.com's servers.

 

By the way, the ECT article was part one, implying there will be at least a second article on SOA and SaaS. Part one appeared in the E-Commerce Times on Friday - my guess is part two will run this Friday.

 

As for the Web 2.0 connection to SOA, this is still being hashed out. Web 2.0 is still in its early stages, but Gartner predicts that by 2011, 63 percent of products in the software infrastructure market and 56 percent in the software application market will support Web services and Web 2.0 technologies, according to the Computerworld article mentioned earlier.

 

As Sean Rhody, founding editor and editor-in-chief of SOA World Magazine, pointed out recently on SYS-CON Linux, you can do SOA without Web 2.0. And you can do Web 2.0 without SOA. But should you? One reason vendors and developers may want to marry the two is simply that SOA doesn't offer a user interface beyond the browser and Rhody contends that Web 2.0 and Ajax could lead to a better user interface for SOA applications.



More from Our Network
Add Comment      Leave a comment on this blog post
Aug 29, 2007 2:44 AM Frank Guerino Frank Guerino  says:
Hello Loraine,This is a very interesting article. Thank you for it.As a former SaaS practitioner in a large and very well-known financial firm and now as a vendor of SaaS solutions, I figured I'd throw in some information, based on experience, that I hope will add value to your points. I certainly hope you find them useful...1: As I'm sure you're aware, the integration problem isn't unique to SaaS. It has always existed, even with the traditional model of owning software. The difference is that with the traditional model, most of what you had to integrate was inside the boundaries of your enterprise. With the introduction of SaaS, the integration of systems includes systems that are, both, inside and outside of your enterprise's borders, those on the outside being owned and managed by 3rd party SaaS providers. So, to pitch the work and complexity of "integration" as a risk or downside to SaaS is really not a big deal, since this issue has always existed, even with traditional systems. Your portfolio of systems to integrate has just "shifted" to include more external systems than it used to.2: There are two broad forms of integration to worry about...The first is "Data Integration", which is at the lower levels, such as what you would achieve with Extract, Transformation & Load tools (ETL) or transformation scripts. This is about answering the question: "How do I share data between systems?"The second form of integration to worry about is "Reporting & Business Intelligence", which is at the higher levels. This is about answering the question: "How do I share data between systems and people?"Anyone that has used SOA, successfully, can attest that it will work as good as any other option, for low level data integration. However, SOA is slow and clunky for high level Reporting and Business Intelligence integration. It tends to break down when you have to look across or deep into large volumes of data. As an example of proof, try and bring ten sets of unique data from ten unique systems, using SOA, to create On-Demand, Real Time Dashboards, with live and up-to-the second data. It will take a very long period of time to generate them, let alone interact with them. A good architect will tell you that SOA has its place(s), however it is not the right answer all the time. SOA is simply one of many paradigms to leverage and one should be cognizant of when to use it and why they're using it.3: An alternative to trying to integrate so many different solutions together, yourself, is to find the SaaS vendor(s) that is/are already doing it for you.The old model of SaaS (if you can believe SaaS is already "old" to some people) is that each SaaS provider provides you with a "single" tool to solve a single problem (i.e. One vendor provides you with CRM, another provides you with Project Management, another provides you with XYZ, etc.). The new model, which is what companies like our own are doing, is to provide you access to a "platform" of tools and technologies that are already integrated.Old SaaS helps to effectively drive your cost of tool ownership down but does not address the cost to integrate. New SaaS also helps to effectively drive your cost of tool ownership down AND helps to effectively drive your cost of integration down. For larger firms who already spend a fortune on integration, this will be the next significant differentiator in the SaaS value chain.Anyhow, I certainly hope this information helps and you find it useful.If you or any of your readers have any questions or comments, please feel free to reach out to me, at the email address below.My Best,Frank Guerino, CEOTraverseITOn-Demand ITFrank.Guerino@TraverseIT.comhttp://www.TraverseIT.com Reply
Oct 2, 2007 10:52 AM Robert Dizon Robert Dizon  says:
I need to point out regarding the comment on Data Integration as an area to worry about. All SOA projects I have been engaged since 2004 while working for one of the big 5 tackle the data integration via canonical data model. So this area is not an issue at all, as for the comment on performance issue, if the data model was done correctly with performance as one of the primary objective then the web services responsible for the retrieval of data will perform optimally. Again, we did this on a large financial firm in New York where every web services integrating multiple data sources in addition to the a live stock quote from Wall Street took under a second (milliseconds) to execute - where the actual data is presented for investor's strategy positions for presentation layer. Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.