However, a relatively small sub sector of the technology market seems to have found recession armor – its business model provides it with what seems to be a recession defense mechanism. Companies in this sub sector offer their services as internet-based business processes or what is known as “Software as a Service” (SaaS). Getting started with SaaS is relatively painless because the deployment procedures, hardware procurement, software installation, maintenance schedules are all taken care of by the SaaS vendor. It also can be much less expensive than custom applications or even in-house deployed 3rd party software. However, very quickly into the cycle the customer realizes giving it all away (valuable enterprise information along with management of the software) is only feasible if it can get it all back. As soon as it goes out, the information created and stored in these 3rd party Software Services needs to flow right back to the customer and vice versa. Sounds like yet another integration but it’s not when you consider various types of information manipulation required to get data in the appropriate form as well as myriad systemic idiosyncrasies of each application and SaaS vendor involved in such information exchange.
At one of our clients, we moved to Salesforce.com – a SaaS vendor for sales information storage (things like price, purchase history, etc). A few questions arose immediately. Sure it’s less headache if the Salesforce.com manages sales related data. But what about the in-house ERP system needing it for order management purpose? How many other in-house or SaaS systems will need it later? What platform, formats, and protocols, should we support/address with perceived information exchange needs in future? And which of these systems is source of truth for a data element at a certain point in the lifecycle? While some such questions have generic answers, a significant chunk needs tailored solutions. SaaS vendors have way too many customers to create or support custom integrations for each one. The integration needs generated from “giving it all away” are too enormous for any SaaS vendor to take on. Oddly (or mystically) enough, just around the time that SaaS vendors started to take shape an answer to this problem also was brewing. Yup. If you are thinking, “this is an SOA Musings blog so the answer must be SOA”, you win our critical reading comprehension test!
Service Oriented Architectures and the standards that come with that provide self-service integration for customers of SaaS vendors. As long as the vendor provides standards-based interfaces, I can take those interfaces and publish data to the vendor or retrieve data out and massage it to any format I need
. We recently did just this for the aforementioned client. This doesn’t mean there are no catches and gotchyas. There are plenty along the integration brick road but at least the heavy lifting is done and for the most part you are left with some XML manipulation, configurations, and business process development.
It’s no wonder SaaS vendors seem to be the stalwart of the technology sector. Look at the checklist for an IT manager:* Easy to Install: installation handled by SaaS vendor
* Easy to Manage: management handled by SaaS vendor
* Easy to Upgrade: Upgrades handled by SaaS vendor
* Easy to Ingrate: Standards-based integration can be done using SOA technology (however, in
general, no custom programming code to manage and maintain)
* Easy to Secure: YES (def. compared to 5-10 years back)
* Relatively Inexpensive: Yes
I saw how relatively painless it was to integrate with salesforce.com. Looking back over my 15 years in the industry, I can def. say that SOA has brought 3rd party integrations to a new level of ease and comfort. SaaS vendors would never have been the strong horses they are now before SOA. It was a really big deal to move company information outside the stone and iron gates of corporate