Orchestrations are just simplified Studio Integrations, right?

One of Workday's powerful features is its Studio integration development platform. With fully functioning Java at your disposal, Studio can take care of just about any data problem you have. This means that every Workday customer has leveraged it against one data need or another, and many have doubled down on Studio as their main integration approach. Now that Workday has introduced Orchestrations, all of those customers are wondering how this will impact their existing codebase.

To put it simply, Orchestrations can solve any data problem that you have already solved with Studio. Given Studio's power, it also represents a lot of opportunities for bad actors to disrupt services. To combat this problem, Workday intends to phase Studio out of production (over many years), and move customers to Orchestrations instead. Orchestrations are more secure, easier to get right, and less prone to being affected by decisions by outside parties (read: Java adding a licensing requirement).

The main thing this means for Workday customers is that Workday does not intend to leave you without solutions that you already have. There are some caveats, but by-and-large Orchestrations can address any problem that Studio can.

This does not, however, mean that converting your Studio integrations to Orchestrations is a trivial matter. Not only is there the raw development cost to account for, but the underlying premise for how Orchestrations behave and "think about" data flow is fundamentally different. Almost all Studio integrations will need to be re-designed to accommodate the different way that data processing is handled by Orchestrations.

If you need a developer to help convert Studio integrations to Orchestrations, or some tutorials on how they're different, or even just a consultation on how big a lift that conversion might be, give me a call and we'll see how I can help.

Matthew Hurley

Workday Integration Consultant

matthew.hurley77@gmail.com