DEC 26, 2012 7:14am ET

Related Links

Cloud Services Becoming Foundational
SaaS: The Increasing Risk of Vendor Lock-in

Web Seminars

IBM & Teradata Compared: A Total Cost of Ownership Study
May 22, 2013
What Is Data Science? You Might Be Surprised!
June 3, 2013
AARP: Embracing Dynamic, Agile Analytics Platforms for Big Data
June 5, 2013
feature

Moving to SaaS? Five Considerations for Your Application Integration Strategy

Print
Reprints
Email

The first few years of this decade have seen consumers develop an unprecedented level of interest in the power of connecting devices. For instance, the integration on a smartphone can be mind-boggling. Your phone, camera, email, contacts, calendar, Internet searches, mapping software and even social networks and restaurant review applications are all connected. Integration is seamless, personal and transparent.

So, how does this experience translate to enterprise data systems that span the globe with data sets in the petabytes? It’s easy to integrate apps and have them tied into a network, but enterprises must manage the ever-increasing volume of data generated by this vast level of integration.

IT departments face challenges integrating the organization’s growing number of cloud-based services with the enterprise’s internal systems. They must do this in a way that meets business priorities and provides high-quality services for the user, while respecting governance and data security policies. They need a corporate-wide integration strategy to get the most out of current SaaS offerings and also have the flexibility to shift those offerings and priorities as new opportunities arise. This approach can make integration easier and help lay the groundwork for your organization’s future in the cloud.

Where Do You Begin?

With SaaS, you are integrating an external service, hosted by an external party, with your internal systems. The SaaS integration involves connecting the clouds and well-articulated interfaces, along with defining the data that is traveling back and forth. With the right integration strategy, SaaS integration can be simple, straightforward and easy. It can position your IT organization to effectively leverage SaaS and migrate from one SaaS solution to another to avoid vendor lock-in. Here’s a word of caution: Avoid locking yourself into a SaaS contract for more than 24 months because you may wind up with technology that is outdated.

Be sure to consider these factors when developing your integration strategy.

1. Determine the People and Processes Required

Identify the “people and processes” portion of the equation. You need to understand how processes are orchestrated and defined inside of the SaaS solution and inside of your business as a whole. Then think about how the data moves — the data definitions. Ask yourself, “How is the data represented in each system along the way? How do systems communicate with each other?” Because SaaS is based on more agile technologies than on-premise solutions, the “plumbing” portion of the equation is generally taken care of for you, typically in the form of Web services.

2. Understand How you are Processing and Integrating Data

You must know what you have in the infrastructure. The main cost of integration isn’t just about connecting into the SaaS provider, it is also about exposing your existing systems. If you already have the key services you require (along with the service bus) and you have defined the services, then integration with SaaS can happen very quickly. With SaaS, it’s really mostly a matter of how fast you can get the businesspeople to agree upon the processes and the deployment date, and less about coding and deployment itself.

Data definitions and representations will often differ between systems. Data management is challenging, and without a common data model and logical mappings integration becomes unwieldy.

3. Know how SaaS Facilitates Efficient Delivery

Service delivery is really about focusing on the software and the service. Many parts of the stack are being handled for you by the vendor. One of the ways the vendor does that is by abstracting data services, as well as other applications and services that you link into, so you no longer have to focus on those services.

It’s almost like imagining an integration project where one side of the integration is already very well-defined, using the latest and greatest standards. At that point, all you have to worry about is whether the customer’s infrastructure operates like yours. If so, the primary concern is to identify what objects you are passing back and forth between the two systems.

The process for identifying what objects are passed back and forth is easy to define. Plan to spend more time with your management team and business analysts discussing which objects are shared and how a process works than you do on writing the software. This approach helps increase efficiency with SaaS integration. Some businesses have been able to complete major integrations in less than two weeks, rather than many months, because all they had to worry about was how the data was moving back and forth.

From an agility standpoint, these abstracted data models can be changed very easily without rewriting the entire integration. As a result, you can start off with a simple integration where you’re merely passing an object from one place to another. Then, using an agile model, you can release that capability to your end users and improve it over time. Since you need to do a full rewrite every time you make changes — and, of course, the SaaS vendors allow for this model — you should be able to iterate and deliver integrated capabilities in a much faster, more agile way with SaaS.

4. Tackle the Most Important Challenges

With IT service management integration, you can expect to encounter the same integration challenges as you did with on-premise initiatives. With SaaS and on-premise models, you must deal with data definitions and processes. In the on-premise world, if some of the software is older, it may not have sufficiently defined interfaces. This creates challenges in terms of development and maintenance. Therefore, in the on-premise world, you would expect to do more of the heavy lifting yourself because you need to — in some cases, coding all the way down into challenging application programming interfaces. With SaaS, however, the providers should offer a well-defined set of APIs, instead of interfaces, and a well-defined data dictionary.

Advertisement

Comments (3)
Great read Chris for an IT novice like myself. I've also noticed a lot of business services shifting away from hardware and towards SaaS. It seems sensible that there's a shift towards scalability and flexible pricing for processes that are too expensive to do in house.
Posted by Ryan C | Friday, December 28 2012 at 9:12AM ET
Very well written article, Chris. We have a variation in the SaaS implementation wherein the service is hosted in our data centre for security reasons. The challenges we encounter are mainly around the supportability (i)compatability with the infra in the data centre requiring us to do extensive testing for upgrades (ii) lack of adequate logging when investigating situations end to end involving internal apps and SaaS app. These factors should also be borne in mind to make SaaS work better for the organisation.
Posted by Sudhakar N | Sunday, December 30 2012 at 11:17PM ET
Add Your Comments:
You must be registered to post a comment.
Not Registered?
You must be registered to post a comment. Click here to register.
Already registered? Log in here
Please note you must now log in with your email address and password.

Where do young IT professionals (30 and under) obtain information to aid with daily role responsibilities and career development?

Trade publication websites 14%
Social media 23%
Vendor websites 4%
Vendor/community forums 7%
Newsletters 1%
Trade conferences/meetups 2%
RSS feeds 6%
Web search 44%

 

Twitter
Facebook
LinkedIn
Login  |  My Account  |  White Papers  |  Web Seminars  |  Events |  Newsletters |  eBooks
FOLLOW US
Please note you must now log in with your email address and password.