A SaaS masterclass in how to do SOA

If you want to understand what service-oriented architecture is all about — and how to do it really well — you should of course be reading my ZDNet colleague Joe McKendrick's SOA blog. But for a blinding 'a-ha' moment, go take a look at Employease Extend, unveiled today by on-demand HR management vendor Employease.

 

What you'll see is an at-a-glance masterclass in how to expose services. Take a look at the partial list of services that I've grabbed in the picture above. Notice how every one of them has a name that conveys exactly what you get when you use the service, in language that even a non-programmer can understand. Notice also that, while some of them (GetJobTitle, AddJobTitle) are concerned with simply getting data out or putting it in, others execute a complete business process, such as HireEmployee or TerminateEmployee. This tells you that Employease has thought very carefully about granularity, and has exposed services based on whether they deliver complete results that will be useful to customers. Many web services implementations elsewhere merely expose data or else provide services that are functionally either too coarse or too fine to be of practical use to anyone else. Employease has gone out of its way to provide services that are of real business value to its customers.

Now click on any of the services listed and take a look at the detailed information Employease provides.

Here's a partial screengrab of the detail provided for TerminateEmployee — I know I've made it too small to be legible, but the image gives you a feel for the range of detail included. This is proper documentation designed to make the service really usable, rather than merely fobbing off developers with having to look at the WSDL and work out for themselves what they're supposed to do. It includes essential information such as what network rights are required and what the most common exception responses mean, along with request and response examples. Even more impressive is the overview, which concisely gives you vital information about options, dependencies and interpretation. Here's what it says:

"The TerminateEmployee action allows for terminating the status of an existing employee in the Employease Network. The service allows for options of terminating benefits, suspending user accounts, and performing a COBRA event related to the status change. Additionally, leave policy associations will be terminated and leave will no longer accrue for terminated employees. A termination date may be either the last day worked ('ActionDate::LastDayWorked') or by the effective date of the termination ('ActionDate::EffectiveDate')."

The default assumption of course is that all of those optional dependent actions will be executed within the Employease application, but there may be cases where a customer has their own legacy system for COBRA processing, for example, and in that case the overview provides a useful warning to make sure this action gets executed.

There are very few openly accessible examples on the Web of such a perfectly executed implementation of a service interface, which is why I'm commending this to you. But of course I'm also doing so to make a point about SaaS, or more particularly about on-demand applications, which are the subset of SaaS that are architected as exclusively hosted, multi-tenant, Internet-based applications.

My point is that any vendor who has committed itself to this way of delivering applications has implicitly chosen a services architecture. Especially a vendor like Employease, which not only delivers its application as a service to customers, but has also been linking into back-end HR and benefits suppliers since 1998, as I described when I last wrote about Employease. So these vendors inherently understand the services model. As they begin to execute service-oriented integration with their customers they will inevitably do a great job, effortlessly becoming role models to be emulated by those less indelibly steeped in the services ethos.

They're also going to be leading pioneers of what some have termed the "enterprise mashup". When Jeff Beinke, VP of product strategy at Employease, talked me through the announcement today, I asked him about the potential for mashups. He said a popular mashup will be one that allows trusted advisors, such as benefits providers, to connect their call center applications into the Employease application so that when an employee calls up they can automatically pull up that employee's data and work with it on-screen without having to switch applications. Other applications that would mashup well with Employease would be in fields such as recruitment, expense management, talent management and so on.