WSO2Con Insights: How NYU used WSO2 to become a more agile organization

New York University is one of the largest private American non-profits for higher education; it’s long since expanded beyond New York, and now spans more than twenty schools, colleges, and institutes – including 12 major branches across the world. They’ve produced thirty-six Nobel Prize Winners and the most Oscar winners of any university in existence. It’s safe to say that’s it’s a pretty big organization.

NYC_-_Washington_Square_Park_-_Arch

Washington Square Park in Greenwich Village – the original home of NYU

Underneath all of the education and the alumni achievements lies a deeper, more technical problem. This level of largesse means enormous amounts of data and rather complex services required to keep everything together. Peter Morales, PhD, leads NYU’s Educational Technology Innovation efforts. Speaking at WSO2Con USA 2015, he described his task: to find out how to move away from their New York-centric data center model.

The solution? WSO2’s Enterprise Service Bus.

Swapping out the engines

NYU has a lot of existing processes. The key word there is existing. To innovate, they would have to avoid touching everything else and breaking it.

This wasn’t just code, but people. Bringing in an ESB wasn’t simply bringing in technology. “You have lots of layers and lots of roles and people who are going to be affected, and you really have to be mindful about that, or the whole strategy unwinds,” explains Peter, who likens this to changing the engines of an airplane while the airplane is in flight.”

The task of implementing the ESB wasn’t simply a technological addition: it was a way of bringing in organizational change. Peter outlined several ‘Agility Accelerators’: agile processes, lean investments, cloud services, unified architecture – things that make it easier for NYU to move forward.

WSO2 comes in on a technical level. NYU uses WSO2 to decouple services at three levels – at the UI level, at the middleware level and at the data level. “If you don’t decouple it at those three layers, you’re always going to end up with some degree of coupling that’s going to impede your ability to change,” said Peter.

Screen Shot 2016-04-19 at 11

The decoupling gives them the ability to build a model where existing systems can interoperate with newer services. This, in turn, solves the original problem: they can now add and extend functionality without disrupting the old code, rolling out incremental improvements in a way they simply could not do before.

The bus in the cloud

At the heart of this implementation lies what Peter calls an “ESB in the cloud”: an architecture that runs on Amazon web servers and allows them to build applications. These applications function as cohesive units, but are actually comprised of lots of swappable services running in the background – services that range from anything from identity to ones that detect and write captions for videos. Various WSO2 ESB clusters host these services, which are then delivered through Amazon CloudFront.

This, as it turns out, is a powerful combination that allows them to run everything at low latencies. It also gives them some interesting capabilities: the ability to orchestrate functionality, and the ability to roll forward services and roll them back in real time.

One of the biggest hurdles they encountered, says Peter, was adding a process for innovating – especially when it comes to introducing new technologies. There were a lot of misconceptions about what was needed.

“A lot of us, coming out of the financial services world,  had been involved in enterprise service bus implementations which traditionally were kinda heavy – the TIBCOs, the Jbosses – this is where WSO2 is very different,” he says. “And the other argument we heard was ‘why not to microservices, without an ESB’? And the big one is ‘Is this services bus going to become another point of failure?’ We have a lot of software that needs to run 100% uptime, all the time.”

It’s safe to say that WSO2’s lightweight, high performance ESB overcame all those concerns, because NYU now runs the WSO2 ESB without a hitch. And now, says Peter, they’re looking at building an enterprise service fabric – multiple instances of an ESB on the background, synchronizing data in such a way that you get the same data regardless of where you are in the world or what your latency is supposed to be.

That’s a lot of boundaries to push – organizational, technical, you name it. But whatever NYU does, we’re proud to be there, pushing those boundaries with them.

For more information on how NYU jump-started middleware services, watch Peter’s presentation at WSO2con US 2015.