- Developing adaptors / appropriate transformations to and from SaaS and target systems
SaaS providers can make their WSDLs and APIs available to developers, but they can’t predict every known / legacy data source in your environment that you want to hook up to the service. They need to keep their expenses down, and can't afford to integrate with every different application that comes along (including databases, content, applications, forms, etc.). Guess who gets to write those adaptors and do the data transformations?
- Navigating network security policies outside of the corporate firewalls
y using software that's not hosted in their infrastructure, developers are finding it increasingly difficult to control the network permissions to access their core elements. Even if there's a VPN or other secure connection from here to there, this doesn’t change the fact that the client's core system can accessed from outside.
- SLA monitoring / maintenance
There is a major service guarantee (or lack thereof) issue around the management of SLAs – which are critical and complex in both SaaS and SOA. Typical issues include defining appropriate penalties for not meeting service levels and then the ongoing monitoring of the service levels. It boils down to defining control / ownership with SaaS and generalized governance with SOA.
- Routing availability and reliability
Mission critical applications tend to have very high data volumes. Moving data between an order management and a fulfillment system, for example, can be a daunting task. It's not a one-to-one correspondence where an order coming in simply converts to a single order going out. The real challenge, in other words, arises when there are multiple candidates for a given request and handling routing of those requests to the appropriate endpoint. The biggest headache is when a given request could be routed to any one of hundreds of endpoints that need to be registered on the fly to maintain 5-nines availability of the solution. This is a serious challenge for SaaS applications that bid services out to numerous potential suppliers.
- Latency overhead of XML / web services
SaaS implies Web Services, which means all messages going to and from your managed application are wrapped in SOAP XML. There is already an associated overhead with SOAP parsing but securing your confidential information using something like WS-Security will add an even greater burden on performance. Coupled with the performance hit is the fact that consumers of SaaS service will have to comply to nuances of the SOAP implementation used by the SaaS provider; lets face it, .Net and java integration is not as easy as everyone hoped.
- Mis-matched data models
When your SaaS applications are integrated with one or more internal systems / data sources, new dependencies are created, and data models must match up for proper synchronization. So beyond the mere data movement, typically transformations must be done on the back-end to make sure that each of the endpoints are receiving the data in a format they can understand.
The growing adoption / success of the software as a service ("SaaS") delivery model tends to obscure the integration challenges that developers are facing today. For those not entirely familiar with SaaS: it emerged out of the ashes of the ASP and Hosted service provider models that sputtered the late 90's. The SaaS model extended the promise of hosted apps (i.e. hosting applications off-site and theoretically relieving customers of the ongoing maintenance / operations burdens) and took it a step further to actually create new types of applications (read: "services") that they served to users. Today, Salesforce.com – with its hosted CRM solution – is the best-known player in the SaaS category, with a reported 646,000 paying subscribers. From the adoption rate of Salesforce.com (to the success of other SaaS players, like NetSuite & RightNow) -- you might infer that users have already reached a point where they feel entirely comfortable running mission critical applications outside of the corporate firewall. But this is not the case. SaaS Integration Pains Widely Felt by Developers User feedback tells us that architects and developers (both on the SaaS consumer and provider sides) are having a tough time with SaaS integration, and that existing solutions only partially solve the problem of extending infrastructure outside your firewall. In a survey that MuleSource is currently conducting a surprisingly high volume of respondents have not only have identified SaaS integration as a challenge, but as the single greatest overall integration challenge that they are currently wrestling with. The SaaS integration challenges that developers are wrestling with today are in some cases the same type of tedious coding burdens that are indicative of any enterprise integration work … but in other cases, we're seeing uncharted waters with no specific "best practices" in place to follow. Here are some of the specific SaaS integration challenges that we’ve heard emphasized by developers:
- Posted by: Joseph Ottinger
- Posted on: February 28 2007 13:28 EST
- Really only two problems ... by paul browne on March 01 2007 05:17 EST
- Better to emphasize problems specific to SaaS by sdfsdf sdfsdf on March 01 2007 13:38 EST
In some ways integrating with SaaS is easier than most integrations (including standard web services) as most of the service providers provide a (Java or other) client and samples to communicate with their product / service. The two main problems that I've found are:
- Corporate Firewall: Not only the technical part (writing the bare minimum firewall rules to let your traffic through and no more) but getting the business permission to do so.
- Reliability and Scalability:These may be just as good (or better) than internal systems, but failure tends to be 'higher profile'. Your coding needs to be robust enough to cope. This 'robust coding' should also be done for integrating with internal systems, but too often is left to be done 'sometime later'
Interesting post but a little bit misleading as most of the mentionned integration challenges are not related to SaaS itself - they occur within the bounds of an enterprise as well. Actually, adaptors/transformations should also be developed when integrating any system be it SaaS or not. Even the problem of adaptors is not so sound in SaaS wourld because of wide adoption of Web-sevices, which are more easy to use than any other proprietary API that you might meet inside an enterprise. Also, I would not emphasize the fact that SaaS vendor cannot support links to any system - this is the case for any system be it SaaS or not. The same could be said for the "Mis-matched data models" challenge - this is not the SaaS challenge this is ordinary problem that occurs everywhere where two systems must communicate to each other. I think it would be interesting to point out specific integration problems brought by SaaS. The only potential areas of specific SaaS integration problems I see are security and network latency. I think SaaS poses problems that are similar to those found in B2B and require using techniques such as message payload encryption and so on. Anyway, the good point of this post is that role of ESB in SaaS is much more important. And SaaS is definitely a ESB adoption driver. So good chance to the Mule team!
Interesting post but a little bit misleading as most of the mentionned integration challenges are not related to SaaS itself - they occur within the bounds of an enterprise as well.I agree but as I am currently working on an integration project to an SaaS vendor (guess who), the problem I am seeing is there is an assumption in the organization that SaaS eliminates a lot of problems that it does not resolve. A lot of those issues are listed above. One good example of one that is not listed is that the user believed they would be able to change whatever they want on the vendor's side without internal IT support. So my biggest problem with SaaS is the panacea aura around it. I agree that this is basically just like B2B as that's what I did at my last employer and the challenges and pitfalls are basically equivalent, although coupling seems to be tighter than in B2B where you are usually sending requests and notifications and not data loads (in my experience.) In either case, however, uou must document your mappings and transformations in such a way that a layman can understand and get everyone involved to sign-off as if it were a contract. If you do not, you are asking for a world of hurt.
One of the things that I think people (like you guys mention) are just starting to see is that many SaaS apps are really just silos. There are some definite advantages to SaaS but an obvious path to extend the enterprise to a hosted app is not obvious--and sometimes not acheivable in a standardized manner. I think the fact that large-scale multi-tenant architecture on the internet is so new that most people haven't really run into these situations yet. We built the Mule for Salesforce.com component because we found several very large users who were looking to move an SOA-esque type of design and found themselves missing the connection to the endpoint. Thanks for the feedback, it's good to know we aren't the only ones seeing these issues :>