INTEGRATION STRATEGIES FOR ISVS: PART I

Transcription

1 INTEGRATION STRATEGIES FOR ISVS: PART I INTRODUCTION Most, if not all, analysts covering the SaaS industry today would agree that integration has become a major, if not the number one, barrier to SaaS adoption. The proliferation of SaaS applications, an intensifying competitive landscape, and changes in consumer attitudes and buying patterns all contribute to the rising importance of integration and have propelled it to the top of the strategic agenda for ISV s. Whether you are a new to the SaaS arena or perhaps rethinking your current integration strategy, this two-part series of whitepapers will help you to understand the shifting landscape of SaaS integration, identify what your options are to address the integration imperative and select the integration strategy most appropriate for your business TABLE OF CONTENTS Introduction Why Integration has become a Barrier Changing Consumer Attitudes Why Integration is Critical to Your Success Getting Started with Integration Building Your API API s are Only Part of the Solution Avoid Temptation to Hard Code Conclusion WHY INTEGRATION HAS BECOME A BARRIER So why has integration become a barrier to SaaS adoption? The problem lies not in SaaS technology itself but in the attempt to use conventional integration products for SaaS integration. It s a technology mismatch. Conventional integration products were built for traditional on premise software implementations not SaaS. The fundamental limitation of conventional integration products (whether hosted on premise or in the cloud ) is that they are single-tenant. As such, each customer must buy, install and maintain its own copy of the product and must do so at every location where integration is to occur. As a result, using conventional integration products to integrate SaaS applications greatly increases cost, complexity and time to deploy while also greatly limiting scalability. The result is that the overall value proposition of your SaaS application is greatly diminished when viewed in the context of time to value, implementation costs and total cost of ownership. To date, ISVs have had little choice but to pass the cost and complexity on to the end customer. The underlying premise of this model has been that integration is the customer s problem to solve. P 1

2 CHANGING CONSUMER ATTITUDES Understandably, this mismatch of value delivery has not gone unnoticed by SaaS consumers. Whereas SaaS consumers were once willing to shoulder the burden of integration and agreed to incur significant upfront costs to engage professional services or traditional system integrators, that is no longer the case. SaaS ISVs have reported that integration comes up in the vast majority of, if not all, sales calls and prospects are demanding answers to integration questions early in the sales cycle. Increasingly, consumers of SaaS are looking to SaaS ISVs to include integration as part of their offering. SaaS consumers don t understand why they can buy an application as a service but not the associated integration. They want a complete and integrated solution that works out of the box, can be deployed rapidly, and begins delivering value immediately. Also gone are the days when consumers were willing to let integration be a phase II project without understanding how integration will be accomplished. They want to see it work as part of the sales and product demonstration process. You must be prepared to address your prospect s questions or risk losing the sales opportunity to a competitor who can. WHY INTEGRATION IS CRITICAL TO YOUR SUCCESS Integration has certainly always played a key, if not somewhat painful, role in information technology so why has it become more critical with the advent of SaaS technology? REASON #1 SaaS is very modular. Because SaaS employs a highly services oriented architecture it fosters a very modularized approach to application development. As a result, there has been a proliferation of specialized SaaS applications introduced to the market that focus on solving a specific business function (e.g. sales compensation management) but with very deep and rich functionality. By recent estimates, there are as many as 1,500 SaaS companies now in existence. Unlike traditional enterprise applications which tend to be monolithic suites, SaaS ISVs (with a few notable exceptions) are pursuing a point solution application strategy. However, this approach relies heavily on the ability to integrate with other specialized applications to deliver a complete and holistic solution to the end customer. REASON #2 hybrid application strategies. At the same time, SaaS consumers by and large are pursuing a best of breed strategy for adopting and deploying SaaS applications. The adoption of SaaS technology by an enterprise typically occurs in stages as early adopters in the organization experiment with and eventually subscribe to an initial SaaS application such as CRM. It may take some time before all applications in the enterprise have been converted to SaaS and some organizations may choose to continue to run applications on premise indefinitely. For the foreseeable future, it is safe to assume that the vast majority of your target customers will be operating in a hybrid SaaS / on premise model. P 2

3 REASON #3 stickiness. Implementing a well-conceived integration strategy creates stickiness for your application. Integrated applications are less likely to be replaced than stand alone applications. While pay-as-you-go and avoiding vendor lock in are part of the SaaS ethos, you can improve your potential for long-term retention by being fully integrated into your customer s business workflows. All of this means that your application must be able to play nicely not only with other SaaS applications but with a range of on premise applications as well. A recent survey by Saugatuck Technologies underscores this point. Survey respondents ranked the ability to integrate SaaS and on-premise workflows as the number one business consideration when selecting a SaaS provider. GETTING STARTED WITH INTEGRATION BUILDING YOUR API The first step in getting started with integration is to build an application programming interface (API) for your application. APIs are the basic building block for any integration strategy. Be sure to begin thinking about and designing your API as you build your application. Too many ISVs leave this work until after the application is built and in production. In addition, best practice is to approach your API like any other module of your application led by product management and not just a technical project for the development team. APIs currently available in the SaaS market today vary greatly in maturity and capability. If this is your first attempt at building an API it s advisable to engage consulting resources during the design phase to help address issues like security, web-services granularity, metering and throttling. Think of your API as a channel to your marketplace not just a connection point for other developers. A well designed API lays the foundation for not only successful integration, but the overall adoption and retention of your application. Our customers are focused on solving their subscription billing needs and don t want to be bothered with complex integration issues. We needed an end-to-end, on demand solution to keep up with our Z-Billing and Z-Payments applications. Connecting to AtomSphere solves these integration challenges and gives Zuora a major advantage over competitors using legacy integration methods Tien Tzuo, CEO, Zuora API S ARE ONLY PART OF THE SOLUTION There is a common misperception in the market that if two applications both have APIs, then the integration challenge is solved. This is not the case. Well constructed APIs are essential to SaaS integration, but they re not the Holy Grail that s been promised. An API opens up secure access to data but it does not accomplish the integration itself. Developers know when they call an API what result to expect, what data gets returned, in what format etc. But it s like an electrical outlet in a wall. Until you plug something into it, it just sits there. Unfortunately that s where the analogy to electrical outlets ends. Even though there are web services standards, developers implement the standards in different ways. Things like authentication, session management, protocols, metadata browsing, and exposing customizations are rarely implemented the same way from application to application. Hence all the integration outlets look different, require different plugs and run at different voltages. P 3

4 But even if all APIs were standardized, there would still be a need for integration. Why? APIs are only one end of the equation they do not complete the end-to-end integration process between applications. Two apps with APIs still need a cord with plugs to connect them together. For example, APIs don t handle the transformation of data between applications (required because every app describes data in a different format, even when multiple apps are describing the same thing such as a Customer). They don t handle the validation, business logic and error processing of the data as it moves between apps. And they don t handle the interaction with the API of another application that s being integrated. Even two apps built on the same platform-as-a-service (PaaS) are not natively integrated with one another. That probably bears repeating Even two apps built on the same PaaS are not natively integrated with one another. AVOID TEMPTATION TO HARD CODE Early attempts by ISVs to address integration requirements have included hard coding their application with other strategic SaaS applications. This approach seems seductively simple but fraught with pitfalls. On the surface it would seem that you can get something coded quickly and begin advertising that you are pre-integrated with other key applications. The major flaw in this approach is that in the vast majority of cases, your customers will have customized their tenant of one or more of the applications in question. You would need to code a separate instance of the integration process for every combination of customized tenants raising maintenance costs exponentially. And hard coding in general leads to maintenance issues as APIs and schemas (file and record formats) change regularly. Integration processes become brittle and will invariably break. The alternative of limiting the integration to a standard vanilla process will result in a loss of competitiveness. Customers always want their customizations reflected in their integrations. Still, some ISVs have elected to build basic integration utilities such as salesforce. com s Apex Data Loader and Taleo Connect. These utilities handle importing and exporting of flat files and databases to and from the ISVs application. Building integration infrastructure for SaaS is not an effort to take lightly. ISVs tend to underestimate the overall effort and costs of building and maintaining an integration solution. A complete integration solution goes well beyond the integration process itself, and must include functionality to handle connectivity, security, monitoring, redundancy and resiliency etc. There is considerable effort involved with learning the proprietary APIs of applications to be integrated and keeping up with frequent release cycles of SaaS applications and changes to those APIs. Unless integration is a core competency within the organization, building integration infrastructure is not recommended. Development resources are best utilized for mission-related projects and building competitive advantage in your application. ISVs are generally finding they prefer not to become integration experts. P 4

5 CONCLUSION Consumers of SaaS are driving ISV s to provide out of the box integration to the applications they purchase as they realize the value of having a fully integrated business. Though many ISV s have attempted to solve the integration challenge with API s or hard-coding to strategic applications, neither solution has proven to be scalable. Most consumers are no longer willing to bear the burden of the extensive IT and development resources required to manage and maintain the frequent API updates of every SaaS application in the organization. Part II of this whitepaper will explore the integration solutions that have proven successful for ISVs. Boomi is the market-leading provider of on-demand integration technology and the creator of AtomSphere, the industry s first integration platform-as-a-service. AtomSphere connects providers and consumers of SaaS and on-premise applications via a pure SaaS integration platform that does not require software or appliances. ISVs and businesses alike benefit by connecting to the industry s largest network of SaaS, PaaS, on-premise and cloud computing environments in a seamless and fully self-service model. Leading SaaS players rely on AtomSphere to accelerate time to market, increase sales, and eliminate the headaches associated with integration. P 5 For more information about Boomi, visit