ServiceNow is a fairly widely used cloud software-as-a-service application that IT organizations use to manage the workflow around calls to help desks. But thanks to the Web services functions that ServiceNow built, that application is being more broadly used to create workflow applications outside the IT department.
Fruition Partners has been using the ServiceNow platform to build workflow applications for everything from the human resources department to the call center.
Fruition Partners CEO Marc Talluto says his company initially got involved with ServiceNow because it provided an application that quickly allowed IT organizations to implement workflow applications based on the IT Infrastructure Library (ITIL) framework for managing IT. But once those applications were deployed it became apparent that as a SaaS application with built in integration capabilities, ServiceNow is essentially also providing a platform-as-a-service (PaaS) offering that allows Fruition Partners to build custom workflow applications. Talluto says Fruition Partners then integrates those applications with other SaaS applications such as WorkDay or Salesforce.com to extend the workflow application even further.
With Web services and APIs hanging off of SaaS applications the line between SaaS and PaaS starts to get a little blurrier; a situation that may get even more confusing in time. Right now companies such as Fruition Partners are integrating SaaS applications that all have their own unique user interfaces. But as APIs especially become more robust it’s becoming feasible for organizations to create their own standard user interface on the client that then invokes multiple “headless” application services in the cloud. In essence, the cloud becomes a source of multiple application engines that can be dynamically composes to drive any number of workflows and business processes.
Most organizations are years away from actually doing that, but one of the immediate benefits is that the cost of training end users on the intricacies of multiple user interfaces would go away. In addition, customers would have more control over the application providers because the cost of switching out one application engine for another would be substantially less than it is today.
Naturally, vendors are not in much of a rush to see this benefit of an API ecosystem become a reality. But given the need to make their applications more accessible, application vendors can slow this trend down, but not completely ignore its inevitability. The only question at this point is how long will it take for IT organizations to realize how much real power is being placed in their hands via the ever so humble API in particular and integration technologies in general.