SaaS - Software as a Service > SaaS Business Fundamentals > Integration

By Bob Moul, CEO of Boomi

For as long as there has been more than one computer system in existence, integration has been a challenge for vendors and users alike. In the earlier days of information technology, integration challenges were the result of proprietary hardware, data formats and/or file retrieval methods. I spent the better part of ten years at EDS converting applications and files or databases from one proprietary solution to the next as organizations looked to continually upgrade their computing capacity in the "dinosaur" age of mainframe computers.

I had a manager back then who used to say, "Nothing in IT ever changes. The issues are still the same - we just call them different things." I can remember thinking how wrong he was at the time. Today, I hear myself saying exactly the same thing.

As the SaaS industry matures, we are essentially solving many classic IT issues all over again – security, performance, customization, reporting, analytics/intelligence, and of course the age old challenge of integration. New SaaS applications arriving in the market on a daily basis need to integrate with other SaaS applications as well as on premise applications.

There is a major problem brewing however: the integration experience for end customers is completely incongruent with the SaaS paradigm, particularly in terms of cost, complexity and time to implement. Most SaaS ISVs find themselves in the predicament of offering great "enterprise-grade" functionality for $50 per month per user (or similar) – which customers can buy, log on to and begin using immediately – but then are faced with an integration challenge that may take many months and tens of thousands of dollars to address. Your elegant solution is suddenly not quite the "no brainer" to your prospect you would like it to be.

As a SaaS ISV, integration has no doubt cropped up as a sales and/or implementation hurdle for you. Perhaps a big one. And if it hasn't yet, it may well become one for you soon. I'd like to offer my thoughts in three areas for your consideration as you think about your approach to this critical issue.

1. Know your target market clients.

In my discussions with SaaS ISVs, the general approach I tend to hear regarding integration is to tell the client or prospect, "Don't worry. You can integrate using our Web services – no problem." However, many companies making the move to SaaS are small to mid-size businesses (according to Saugatuck Technology, 17% of SMBs are already using more than one SaaS application) and most SMBs don't have the developers on staff who would know how to use Web services. The truth is there are a lot of "enterprise" companies who don't have these skills either. And SOA and Web services are not the Holy Grail. According to a recent study by Nucleus Research, only 37% of firms using SOA technology have seen a positive return on their investment. In addition, the study found that SOA impacts only 27% of an average company's IT projects. If this is sounding vaguely like the EAI movement, it's because there are many parallels. So it's critical to understand your target clients and develop your integration strategy accordingly.

2. Don't downplay the integration challenge in the sales cycle.

This is a client satisfaction issue just waiting to happen. Here again, in the drive to make the sale (which I totally get) I hear SaaS ISVs say – "No developers? No problem. We'll build your integrations for you," and attempt to sell a professional services engagement. There are a number of problems with this strategy:

•	The cost and time involved are once again incongruent with the SaaS world.

•	The scalability impact on your business model. In the "conquer the world" strategy that we all have, you don't want to be bogged down building Web services and custom integrations for every client on your way to amassing 20,000 clients in five years.

•	The maintenance of these custom-built integrations becomes complicated each time business processes or APIs change.

Moreover, a backlog of implementation projects will begin to build and soon you'll have unhappy clients that are unable to implement the complete business processes they need to run their business efficiently and effectively. This point cannot be stressed enough, particularly if you are a "best of breed" vendor. Generally speaking, business processes are not contained within the boundaries of your application alone. Tight integration with other applications in your client's portfolio is critical to unlocking the full value of your own application. Just as importantly, applications with little to no integration with other applications are more easily "ripped and replaced."

3. Consider partnering for your integration needs.

This is a classic build-buy-partner analysis. If integration is not your core competence, why divert critical R&D resource away from perfecting your application? Consider partnering with an integration solution vendor for your integration needs. When evaluating potential integration partners, consider the following factors: Scalability Will the vendor's solution expedite or slow your implementation projects? Solutions that require software packages or hardware appliances to be installed and maintained on the customer's site or require integrations to be built and maintained by developers are less scalable to your business model than solutions that are delivered in a SaaS model.

Speed

Is the vendor's solution available on demand? Will your customer be able to integrate as rapidly as they were able to log on and begin using your application? Will the integration experience be seamless? Solutions that require installations on site are not congruent with the SaaS paradigm and will slow your implementation progress.

Cost

Is the cost of the vendor's solution congruent with your pricing? Can the vendor's pricing be easily bundled with your pricing and adapted to your basic billing unit (e.g. number of users, sites, etc.). Solutions delivered in a SaaS model will generally have more flexibility in subscription pricing than the traditional license fee model.

Ease of Maintenance

Will a change in integration processes or your APIs necessitate that your integration vendor change all of its installations? Can changes be made one time centrally and populated to all of your installations?

Technical Competence Required

Is the vendor's integration solution simple enough that it can be accomplished by your target customer's in-house staff, or will it always require specialized developer skills? Configuration-based solutions have been on the market for some time now that allow non-developers to build and maintain integrations without coding.

The challenge is that many integration vendors still take a very "1.0" enterprise approach to their offerings like requiring that software or hardware appliances be installed and maintained on the end customer's system. You've made the decision to deploy your software on demand because you've bought into the value the SaaS model delivers. Why should integration be any different? There are new on demand integration options beginning to emerge that are true SaaS offerings themselves and available with true SaaS-style subscriptions that won't break your client's bank.

Done well, integration can not only be removed as a hurdle to customer acquisition, but can become a great source of competitive advantage for you in the market as well. Happy selling!