'The Only Way is Through SOA' -- Lessons Learned at a University

SOA in Action Blog

« Beware the 'Service-Oriented Stovepipe' | Main | New Association for SOA Leaders Focuses on 'City Planning' as a Metaphor »

January 30, 2007

'The Only Way is Through SOA' -- Lessons Learned at a University

SOA proponents at a major multi-campus university was able to overcome resistance to their proposed architecture in stages -- one use case at a time. In a recent interview in an e-learning journal, Patrick Masson, CIO at the State University of New York's Delhi College of Technology, recently shared his experiences with establishing an SOA for the SUNY system, which encompasses 64 campuses, 30,000 faculty members, and 414,000 students.

The root of SUNY's SOA effort was a distance learning program, the SUNY Learning Network (SLN), originally begun in 1994 at a branch campus, built on top of a centralized Lotus Notes/Domino system. As the system grew, integration of the distance learning system with other campus systems proved to be a real challenge, particularly with student identity. Each campus had its own student information system (SIS), and students taking both classroom and online courses had to go through a double registration process, resulting in double enrollments.

Another issue was the customization that had been made to the Notes/Domino system, Masson said. "SLN had some 100,000 enrollments managed through Lotus Notes and Domino and had customized the system to such an extent that only a few people knew how it worked. IBM couldn’t support SLN's customizations. This meant that central administration, all of SLN as well as the 40 campuses, was dangerously dependent on a couple of individuals."

The major advantage of the existing centralized system was cross registration across all the campuses, Masson said. "If a student enrolled with SLN they could see the entire SUNY online catalog of courses available from all campuses – not just their own." It was for this reason the university eventually decided to upgrade the system to a service-oriented architecture.

Not without plenty of bumps in the road, however. "The administration didn’t like the SLN 2.0 strategy because it couldn't be easily communicated as an 'out-of-the-box' solution," Masson explained. "It’s a huge undertaking to persuade CIOs and campus presidents to abandon a production and deployment model - the ERP way of doing things. ERP allows people to showcase systems and say: 'wasn’t our money well spent?' An incremental and bottom up approach just doesn’t allow management with those showcasing opportunities."

One way Masson and his team were able to overcome objections or reservations about SOA was through use cases. One of the first use cases Masson employed to sell SOA to the university was dates and calendars, he elaborated. Instead of managing multiple calendars, students will have access information aggregated into a single portal. "The only way is through a SOA," he said.

Through SOA, the STN treats every campus student record system "as a legacy system," and routes student and course data to an abstract data object. "In SLN 2.0 we had decided to start by developing a message broker and a service bus (registry) but we also took on the crusade of developing more standards."

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us