Workday’s Approach to Integrations, Part 2: Q&A with Sonal Nuckols

This is the second in a two-part blog about application integration. We discussed the topic with Workday enterprise architect, Sonal Nuckols, who works with prospects and customers to create an integrated application framework in their IT environments.

In part 1, Sonal emphasized the importance of having an integration strategy, and typical customer concerns around connecting enterprise applications. In this blog, Sonal talks about what Workday does to ease integrations with other systems and the importance of using open standards.

What else does Workday do to help make integrations easier?

From the beginning Workday has focused on ensuring that integrating with our applications is as easy as possible. This may seem like a no-brainer, but traditional enterprise software companies don’t think as holistically about integrations as we do. They typically will recommend a third-party integration solution.

We stick to open standards and make our APIs public. It’s relatively easy to find talent that knows Web services like SOAP and REST, and using open standards keeps all the integration points in and out of our applications consistent.

Another advantage of standard Web services is they allow for some repeatability. For example, maybe I have to build an integration to load data from a time clock as well as an integration to load revenue data from a claims system. Once I’ve built a Web service request for the time clock, the request I build for the claim systems will be quite similar; the only difference is the data requirements.

We also learn from the Workday customer community, looking for common patterns and use cases related to integrations. Having all customers on one version of Workday and one codeline helps us gather a lot of valuable data for making decisions about what connectors to build, and what integration functionality to build into our applications. We develop and maintain integrations to a lot of popular services, and they’re available to all of our customers.

Can you explain the importance of Workday’s Enterprise Service Bus (ESB) on integrations?

Our ESB is critical to the scale and performance of how real-time data is managed across applications. Workday decided early on that we would set a very high standard in terms of how we manage enterprise data of large proportions, for both people and financial data. This type of data does not live in a bubble; it needs to be available to be shared at any time, and from any location that can get Internet access.

Our ESB has always looked at software as Web services, and enables communication and transactions among different applications. With the ESB, our customers’ non-Workday applications communicate directly with Workday applications programmatically to get to true scale and automation of data entry.

How does Workday advise customers to approach cloud application integration?

We start with having an approach that is both open and public. Consumer companies like Amazon, Google, Twitter, and many more make their data available through APIs. Because of their openness, their apps are widely used. We do things in a similar way. What’s most important to us is that customers have access and flexibility to use third party data in Workday in a way that is meaningful to them.

It’s pretty exciting to watch the API marketplace bloom. As a simple example, if you want to bring in foreign exchange rates into Workday, there are so many service providers customers can choose from to get the best deal and service. And because there is only one Currency Rate API in Workday to write the integration, the customer will always have choice and room to negotiate.

Workday is one of the only cloud enterprise application vendors that puts a vast majority of its APIs on the public Internet. We believe such openness is one of the greatest values we can provide to the broader community.