Alterations may be needed to make SaaS fit
Suits you, Sir?
Software as a service (SaaS) may be a great way to shirk some capital expenditure by not having to buy servers and software, but how will it fit in with what you already have?
Whether you are farming out CRM, document management, contact management or procurement, you probably have some locally hosted applications that you want it to work with.
It might need to manipulate local datasets, or use functions embodied in locally hosted code. Or vice-versa. How do you make such things work?
As the SaaS world matures, more people are mulling this question. A report from Saugatuck Research, commissioned on behalf of Dell Boomi, a SaaS integration middleware vendor, surveyed nearly 1,800 participants worldwide.
It found that just over a fifth of the survey base expected speedier implementation as a business benefit. Yet almost a third worried about integrating SaaS with their enterprise applications, and 27 per cent were concerned about how to tie it in with existing data structures.
Your inflexible friend?
You can see why such concerns are a problem. SaaS has been a relatively inflexible mechanism. In the days of the application service provider (ASP) at the end of the 90s, you took largely what you were given. Integration was not a serious proposition.
Since then, Web 2.0, XML-based data structures, REST and JSON have simplified the whole sticky mess. You can pass complex data and methods along an HTTPS connection far more easily using today’s SaaS. Zane Freame, Office 365 lead at tech consulting firm Content and Code, says that many SaaS integration projects are code-free – for the most part.
“We’re so much further than we were even five years ago,” Freame says. “Especially if you’re looking at a single SaaS provider such as Microsoft. Its CRM online service integrates into Sharepoint online. A lot of systems have ways of plugging in without code.”
Even if your systems are more diverse, thanks to vendor frameworks such as the Facebook Platform, and authorisation standards such as OAuth, integration is becoming easier from a technical perspective. Yet it is still a challenge, which revolves more around process than technology.
In truth, the two are often linked because one affects the other. For example, one of the biggest challenges to effective integration involves changing APIs, a procedural issue with a technological effect.
Customers may find themselves unable to predict when and how APIs will change over time, and if they are not on an appropriate contract an API could potentially break any integration they have put in place.
“You have to be sure that what you’re using today will be supported in the future”
SaaS vendors such as Salesforce have complex sets of APIs designed to address different kinds of front-end services, from Facebook to Flex. Companies need to ensure that they understand changes when they occur and keep up to date. The more sophisticated the level of integration, the more important this is.
“You have to be sure that what you’re using today will be supported in the future,” Freame says.
“Vendors won’t pay for your business to modify your integration points, so you want to be getting some guarantees from your server supplier that they will maintain those APIs.”
This also applies to changes in back-end systems. There are mission-critical systems, developed 20 years ago and held together with duct tape and bubble gum, that will never be changed on pain of death. But they are in the minority. Many systems will be updated, either with feature enhancements or bug fixes, and a truly competent IT department will needs to test them.
There is also a security issue to consider, Freame says. You will be opening the kimono by giving a SaaS service provider access to data stored on your internal systems, or on third-party services that you are binding together. It is important to ensure that the cloud services provider you are integrating with treats that connection securely.
For the most part, SaaS providers secure their APIs, although you will find that some need further work that incurs overheads, says Freame.
Microsoft just announced support for Sharepoint Business Connectivity Services in its Office 365 SaaS offering, which makes it easier to pull in third-party data sources while enforcing a baseline of security.
You want to create a secure means of authentication with your SaaS provider as part of that secure integration process. Federated identity therefore becomes a useful tool for companies integrating SaaS with their own systems. Many federated identity systems work by connecting or extending directories so that users can authenticate with a third party (such as a SaaS provider) via single sign-on.
So far, we’ve talked about the problems of integrating SaaS into your environment, but it can also be a means of drawing together pieces of an organisation. It can be the glue, rather than the thing that needs to be glued.
Global media and entertainment firm Clear Channel deals with new business acquisitions regularly and has to find ways to integrate them. It used Office 365 to fuse together an acquisition in Turkey with its own email system. The Turkish company had been acquired years before, but had been using a Turkish country code for its address systems.
“They had clearchannel.com.tr, and we had clearchannel.com, and never the twain would meet,” says Tom Noble, IT service delivery manager at Clear Channel. “We decided to get a tenant of our own in the cloud and bring Turkey in along with any other business units that we wanted.”
Normally, Clear Channel would have migrated the Turkish business to its domain first, and then switched it to the firm’s Exchange servers in the US, but legal and policy decisions at head office precluded data from the Turkish systems from going to the US servers.
The company had two choices: buy some Exchange servers for 50 Turkish users, or go to the cloud.
Clear Channel purchased an Office 365 licence and created 50 contact objects in its Active Directory implementation, each with a .com.tr primary address and a secondary proxy clearchannel.com address.
“If someone sends mail to their clearchannel.com address, it hits our mail system and is immediately redirected to their mailbox in the cloud,” Noble says.
The implementation saved Clear Channel some capital expenditure costs because it didn’t have to pay for servers, and it also saved Noble’s team travel costs because it was able to administer the setup from its UK office. He also transferred the mailboxes from the Turkish company’s former provider into the cloud-based service.
“Not only can they send and receive mail on the clearchannel.com email address, but they can also pick our names off the [company directory], and their names appear on our list,” Noble says.
”So we haven’t federated fully, but there was enough flexibility there for us to be able to integrate them to that level.“
The SaaS pilot has blazed a trail for further integration. “Sharepoint does have a lot of features out of the box. We are not using it yet but we will run some workshops and explain the benefits,”says Noble.
He may also begin bringing other, smaller business units in so that they get the same enterprise-class email service.
That is a key message from the Clear Channel project: you don’t have to boil the ocean when integrating SaaS services.
In fact, incremental integration may be more suitable because you may not need a plethora of features, and also because it can reduce up-front costs by letting you ease into the integration process.
A more measured approach to integration can also give you the chance to fully understand your own business processes, which may be more nuanced than you realise.
The more sophisticated the integration becomes (moving beyond basic directory and mail integration into workflow, for example) the more business processes you will butt up against, and the more opportunities there will be to refine them and strip out inefficiencies.
Perils of DIY
Faced with considerations such as these, you have to make a choice between doing the integration yourself or having the SaaS provider do it for you, either directly or via a preferred partner.
The decision presents customers with an interesting trade-off. Self-integration provides a high degree of control, which can make it possible to integrate systems at a fairly deep level. Customers get to control the resources used and the specifications for the project.
On the other hand, it carries some risks. Customers may miss a level of flexibility that might have been available if the SaaS vendor carried out the integration in-house.
Ultimately, the level of integration required, the budget available, the willingness of the business to play ball, and the vendor’s own features and offerings will inform your roadmap for SaaS integration. But the simpler you keep it, the better off you will be. ®