Integration Strategies for ISVs Part 1

8/9/2019 Integration Strategies for ISVs Part 1

1/5

Boomi Corporate Headquarters

Address: 801 Cassatt Road, Suite 120,Berwyn, PA 19312

Tel: (800) 732-3602

Email: [email protected]

West Coast Ofce

Address: 473 Jackson St., 3rd

FloorSan Francisco, CA 94111

Tel: (800) 732-3602


CONNECT ONCE, INTEGRATE EVERYWHERE

INTEGRATION STRATEGIES FOR ISVS:

PART I

INTRODUCTION

Most, 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 ofintegration and have propelled it to the top of the strategic agenda for ISVs.

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 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. Its 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 customers problem to solve.

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

APIs are Only Part of the Solution

Avoid Temptation to Hard Code

Conclusion

1

1

2

2

3

3

4

5



2/5



Tel: (800) 732-3602


West Coast Ofce



Tel: (800) 732-3602



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 signicant 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 dont 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 prospects 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 develop-

ment. As a result, there has been a proliferation of specialized SaaS applications

introduced to the market that focus on solving a specic 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 indenitely. 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.


3/5



Tel: (800) 732-3602


West Coast Ofce



Tel: (800) 732-3602



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 customers business workows.

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 workows as the number one

business consideration when selecting a SaaS provider.

GETTING STARTED WITH

INTEGRATION BUILDING YOUR API

The rst 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 rst attempt at building an API its 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 toyour 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.

APIS 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 theyre not the Holy Grail thats 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 its like an electrical outlet in a wall. Until

you plug something into it, it just sits there.

Unfortunately thats 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 dont 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


4/5



Tel: (800) 732-3602


West Coast Ofce



Tel: (800) 732-3602



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 dont 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 dont handle the vali-

dation, business logic and error processing of the data as it moves between apps.

And they dont handle the interaction with the API of another application thats being

integrated. Even two apps built on the same platform-as-a-service (PaaS) are not

natively integrated with one another. That probably bears repeatingEven 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 aw 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 (le 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

reected in their integrations.

Still, some ISVs have elected to build basic integration utilities such as salesforce.

coms Apex Data Loader and Taleo Connect. These utilities handle importing and

exporting of at les 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 nding they prefer not to become integration experts.


5/5



Tel: (800) 732-3602


West Coast Ofce



Tel: (800) 732-3602



Boomi is the market-leading provider of on-demand integration technology and the creator of

AtomSphere, the industrys rst 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 benet by connecting to the

industrys 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.

CONCLUSION

Consumers of SaaS are driving ISVs 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 ISVs have attempted to solve the integration challenge

with APIs 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.

Integration Strategies for ISVs Part 1

Documents

Transcript of Integration Strategies for ISVs Part 1