Boomi Whitepaper Integration Strategies 1

Boomi Corporate HeadquartersAddress: 801 Cassatt Road, Suite 120, Berwyn, PA 19312Tel: (800) 732-3602Email: [email protected]

West Coast OfficeAddress: 473 Jackson St., 3rd FloorSan Francisco, CA 94111Tel: (800) 732-3602Email: [email protected]

CONNECT ONCE, INTEGRATE EVERYWHERE

INTEGRATION STRATEGIES FOR ISVS: PART I

INTRODUCTIONMost, if not all, analysts covering the SaaS industry today would agree that integra-tion has become a major, if not the number one, barrier to SaaS adoption. The pro-liferation 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 inte-gration 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

WHY INTEGRATION HAS BECOME A BARRIERSo 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.

TABLE OF CONTENTSIntroductionWhy Integration has become a BarrierChanging Consumer AttitudesWhy Integration is Critical to Your SuccessGetting Started with Integration – Building Your APIAPI’s are Only Part of the Solution…Avoid Temptation to “Hard Code”Conclusion

1122

3345





CHANGING CONSUMER ATTITUDESUnderstandably, 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 ap-plication 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 SUCCESSIntegration 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 develop-ment. 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 strat-egy. However, this approach relies heavily on the ability to integrate with other spe-cialized 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 sub-scribe 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 foresee-able future, it is safe to assume that the vast majority of your target customers will be operating in a hybrid SaaS / on premise model.




REASON #3 – “stickiness.” Implementing a well-conceived integration strategy cre-ates “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 re-cent 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 APIThe first step in getting started with integration is to build an application program-ming 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 techni-cal 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.

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.

“Our customers are fo-cused 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 appli-cations. Connecting to AtomSphere solves these integration challenges and gives Zuora a major advantage over competi-tors using legacy integra-tion methods”

Tien Tzuo,

CEO, Zuora




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 vali-dation, 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 cod-ing 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-integrat-ed” 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 combi-nation 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 integra-tion 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.




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.

For more information about Boomi, visit www.boomi.com.

CONCLUSIONConsumers 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 Whitepaper Integration Strategies 1

Technology

Transcript of Boomi Whitepaper Integration Strategies 1