6 Reasons SaaS May Mean A Return To Silos

Application integration has always been a thorny problem. Add in the inherent design restrictions of software as a service--think islands, not exactly designed to exchange data--and things get even trickier. Fortunately, there are some products and best practices that can make your apps work together.

And make no mistake: Integration is a pressing issue. In our recent InformationWeek Analytics 2011 Enterprise Applications Survey, we found 43% of 314 respondents are using SaaS applications. But when we asked them to rate their satisfaction with nine aspects of these apps, deployment simplicity came out on top--and ease of integrating these services with on-premises systems and data sources landed at the bottom of the list.

So, why are we adopting SaaS at a steady clip if we haven't found a good way to securely link these apps with one another and in-house systems? You'd think IT teams would have learned their lesson, given our sad history with siloed data sets and today's identity management and user access requirements.

We work with a number of CIOs who are determined to create unified IT environments incorporating a mix of platforms and SaaS and in-house applications. We find they run into problems in six key areas:

>> Identity and access orchestration is usually at the top of the list of pain points. The ability to rapidly verify who's accessing your systems is mandatory for security and compliance. With SaaS applications, we find there's a much higher risk of failing to disable access after people leave or to modify permissions as roles change. That's because access is typically a centralized and automated function, using access-control systems with well-established ties into enterprise applications--ties that rarely extend into SaaS provider networks.

>> Compliance reporting is also a challenge. Companies subject to Sarbanes-Oxley, for example, must be able to cull a variety of log information. While most SaaS vendors enable IT to run these reports from within their systems, if you have a number of SaaS apps from different providers, consolidating this data must be done manually. Yet automation is the only way to effectively build compliance reports involving multiple logs.

>> Information silos aren't conducive to business analytics either, and without SaaS integration, reporting capabilities will be limited. As with logs, most SaaS systems are pretty good about reporting within the application, but dynamically analyzing data from multiple services is a whole different story.

>> Business process management and setting procedures for the smooth exchange of data inside and outside the enterprise are also problematic. For example, many SAP users customize to meet business requirements. Now, say you have partners and customers that want to exchange information with you in the SAP iDoc format. SAP has the B2B Gateway to communicate using SaaS, but it has specific requirements around how data is exchanged. This could mean that your business processes need to adapt to the Gateway, rather than the other way around--not ideal.

>> Data enrichment is another problem with SaaS. Often, enterprise data that lives in various systems--say order management, billing, and fulfillment--is contained within an overall ERP suite. But let's say you use a SaaS-based ticketing system. How do you exchange this information with your ERP application to provide customer order information, problem tracking, and other services?

>> Finally, to have any hope of implementing service management and governance across your data, you must be able to apply policies--from retention to security controls--uniformly across both SaaS and on-premises applications. Good luck with that as the technology stands now. We recently discussed the importance of maintaining a master data set, and to that end, IT has spent decades moving away from application-centric approaches to governance and toward unified, enterprise-wide management. SaaS has the potential to dial back the clock.

So what's to be done?

If you have three or four SaaS applications that are critical to your business, you'll probably need to invest in an integration product, commonly called a cloud broker. While this is a new product set for the cloud, the overall concept is time tested: Enterprise IT teams have long used middleware, enterprise service bus (ESB), and enterprise application integration (EAI) products within their data centers. Now, some established vendors have extended these systems to include both in-house and SaaS applications, while a cadre of new offerings are solely focused on, and delivered from, the cloud.

This is a rapidly evolving product area, and one that's opening doors for smaller enterprises. Most pure-play cloud brokers charge based on usage, so the monthly outlay is a fraction of what it costs to purchase, deploy, and maintain enterprise-class ESB or EAI software. That removes a substantial entry barrier. You can even get free trial software before committing. That's a big departure from middleware that sometimes took years to deploy.

If a broker seems like overkill, there are other options. For example, if you use Salesforce.com, the company's Force.com platform offers prepackaged products for integration between Salesforce and systems from JD Edwards, Microsoft, Oracle, PeopleSoft, Quicken, SAP, and others. Oracle On-Demand CRM also includes a set of Web services APIs based on XML/SOAP standards to enable custom integrations, but it doesn't have as many out-of-the-box partner connectors as Salesforce does.

If you have only a few SaaS applications or a limited need to exchange data, you can use API, SOAP, or REST interfaces in a point-to-point architecture, though this route is limiting and will require programming. Clients we work with generally use XML to encapsulate data so it can be passed among SaaS applications, which have nearly ubiquitous support for Web services as an interaction mechanism.

Still, taking the point-to-point route is risky, especially if you're developing your own integration interfaces. First off, whenever SaaS or enterprise application versions change, you'll need to test to ensure the upgrades don't break existing integration. If you add applications, increasing the number of point-to-point links adds complexity and hobbles your ability to share data through a centralized hub or bus architecture. Relying on your own developers for integration also has risks. How well will they document the integration, and how robust are the connections they're able to build? Paying external developers, meanwhile, could surpass the cost of a cloud broker.

If you take a point-to-point approach, at least start the process of evaluating brokers so that you'll have laid the groundwork to upgrade your integration capabilities.

Shopping Checklist

In our full report, we profile eight cloud broker options. Generally, vendors offer products as either SaaS-only or a SaaS/on-premises hybrid. The latter model will add some cost and complexity but will increase your options around security and integration. Vendors also line up around whether they limit integration to a predefined set of applications or allow more openness via custom connectors, and whether they provide SaaS-to-SaaS only or SaaS-to-enterprise integration.

While a year ago there were just a few players in the cloud broker space, the field is expanding quickly. Generally, vendors provide prebuilt adapters and connectors for the most common SaaS applications, supplementing where needed with open Web services interfaces for custom design. When evaluating cloud brokers, you'll want to look for the range of prebuilt adapters and connectors offered, and also the ability to create a custom interface using open APIs.

In our survey, we found more than 50 SaaS applications commonly in use. It will be difficult for any single integration vendor to keep up with version changes alone, much less all the new SaaS applications springing up. Those products that attempt to support the broadest range of applications will provide flexibility but also will increase the upkeep required. Can the vendor keep up?

Also consider: How robust is the workflow orchestration engine? Can you easily generate reports to monitor transactions, compliance, governance, and performance? How is licensing constructed: per user, transaction, or server/CPU? For high-volume transactions, how does the product scale? What about disaster recovery and failover?

In looking at integration options, products that are designed for a specific application category may provide richer integration, but they may have limited choices outside that application area.

If you have only a few applications and all of your vendors provide the necessary connectors and adapters, you may be set no matter which route you choose. But while pay-as-you-go models seem appealing, ensure that you'll be able to import and export business rules. If you ever decide to change providers, or move the function in-house, you need the ability to bring this data with you. However, since many of these systems are configured through wizards that the vendors offer, this can be a tough requirement to fill. At minimum, document your workflow rules outside the integration broker, so you can recreate them. Also, adopt a few best practices up front to minimize the problem of retrofitting for integration later.

Best Practices

While the SaaS vendor community in general, and the integration broker sector in particular, continue to evolve, some best practices will keep your applications talking:

>> Select SaaS offerings that have the broadest possible customer adoption. While that limits your choices, it expands your integration options, a fair trade in our opinion.

>> Before selecting a SaaS vendor, get details on how it handles data import and export and real-time exchange of information. The capacity to exchange information outside a vendor's environment varies widely.

>> When exploring cloud brokers, look for those that offer a wide variety of out-of-the-box adapters and connectors; the more variety, the better the company's commitment to a breadth of support.

>> Security is key to integration. Ensure you're able to safely pass credentials to and from a SaaS provider's site.

Integrating SaaS applications is always going to be tougher than linking software hosted behind the firewall because of the need to manage remote access and IT's lack of control over the provider's environment. Extending integration in a hybrid SaaS/in-house model can be even more difficult, especially if you've done a lot of customization. But you can't stand by and watch the business erect a new set of data silos, either.

Avoid point-to-point integration, which is always going to be limiting. Job one for a cloud broker is to provide a sufficient level of workflow orchestration for your needs--both now and in a few years. That's because if there's anything more painful than getting all your applications hooked into a broker, it's getting them unhooked while keeping your business rules and processes intact.