When Portals Retire — What's Next?
A Q&A with Joy Lynam
At the University of Delaware, an ERP system upgrade led to the retirement of the university's legacy portal. The search was on for a portal replacement. Director of IT Web Development Joy Lynam explains how the university replaced the portal with a search-based solution called OneCampus — ultimately modernizing the experience of finding campus resources for users.
Mary Grush: You've deployed OneCampus at the University of Delaware. What were your main goals when you decided to do this implementation?
Joy Lynam: I'm responsible for business applications, so I was initially looking for a portal to aggregate them so that people could go to My UD Business and find forms and applications much more easily. It could sometimes be difficult for people to find what they needed to do business with the university, so this was my first and biggest goal.
There was a second, but just-as-important goal: We had run a portal — uPortal — for several years. But it had all custom-coded channels, so that when we upgraded our ERP system, it essentially broke the portal. To fix the campus portal, we would have had to go back and redo a lot of custom coding. We didn't have time to do that, so we needed to replace the portal.
And our third goal was to update the user experience. We wanted our customers to be able to access their data and run our applications on any device, at any time — what they expect in the 2010s. It's important that the applications that we write for the University of Delaware display on your phone, your tablet, your desktop, whatever device you want to use. That was a requirement.
Grush: So your portal no longer worked because of your ERP system upgrade? When did that happen?
Lynam: Yes, we changed our enterprise system, where all our data is stored for HR, student, and financial applications. We worked on the ERP upgrade for several years and retired our portal in 2007 because the old portal was incompatible with how the upgraded ERP system managed our data.
For several years, we had known we would need to replace the portal. But we didn't have the time and resources to bring up all our applications in the new enterprise system and in a new or re-coded portal. So a what-must-we-do-now task had to be postponed.
Grush: When did you find your solution for all this?
We discovered OneCampus and looked at a vendor demo — with IT staff and rSmart — in November of 2014. I was sold. When we saw OneCampus, we just knew — this was it. Our CIO attended that meeting and agreed. And we signed by December.
We have studied portals for a long time. We were always aware of the development work and custom coding that would be required for us to bring up most portals.
We got a better feeling when we saw OneCampus. When OneCampus came along, we saw that we wouldn't have to do all that custom coding. And because OneCampus handles all the user interfaces, it was clearly just a big win.
Grush: So you replaced your old portal with OneCampus. But OneCampus isn't really a portal — how do you characterize it?
Lynam: I think of it as an optimized search portal — one that you can own and brand.
So, take registration for example. Years ago, we wrote Delaware's registration application — IT collaborated on the project with the University Registrar's Office. The application has all our business logic and all our security safeguards. The OneCampus "search" now functions as a pointer to that registration system. It sounds simple, and the concept is simple. But the real beauty of it is that we don't have to load any logic or any data — there is no custom programming required to get OneCampus up and running. As with any application, our programmers did have to integrate OneCampus with CAS (Central Authentication Service), but our Web designers completed all the tasks involved with setting up and configuring OneCampus.
We replaced the portal, not with another old-fashioned, menu-based portal, but with a modern search-based experience for our users.
Grush: How does this scale on your campus? I guess you were the first content owner on your campus… Where did it go from there — did you expand this to other departments?
Lynam: I'm in IT, and we wanted to scale this up quickly, to benefit more content owners on campus. We decided we would load everybody's data ourselves — including metadata.
We linked to 700 forms representing many departments and content owners around campus. We loaded the data for all the business units. We did all the definitions; loaded the links; identified the business owners, descriptions, and keywords. So we loaded all that was needed for the 700 forms. Then we showed the system to our business owners and worked with them to refine and test the final implementation.
Grush: Would it have taken longer if you had gotten the content owners to do the data definitions and load their own forms?
Lynam: If we had taken the time to train our business owners and then waited for them to load the information, implementing OneCampus might not have been as high in their individual units' priorities as it was in ours. Providing a campus-wide solution was a top priority for us in IT. We wanted to load the system to show them how well the system would perform for them. It worked. Our content owners worked with us, and stuck with us. All that we had started in January to scale up OneCampus went live by August.
Grush: Is this model typical of how scalability works on other campuses? I've heard that OneCampus can scale using a much more distributed implementation model.
Lynam: It depends on the culture and climate of any given institution. What they say about scalability is correct, and we could have worked that way. But we were invested in getting this done quickly.
Grush: Was it used right away? How did you know whether your choice to implement this was a success?
Lynam: Yes, it was used right away! We had about 50,000 unique users the first month, coming in from the campus and from all over the world. OneCampus integrates with Google Analytics, so we can go to Google Analytics to track on- and off-campus activity and see who is visiting. We see in the numbers that it is being used.
And our help center phone was not ringing. We didn't have support issues.
I think we are on the right track. Implementing OneCampus has made it much easier for people to locate forms. That's the feedback I get, and we do regular outreach, where we are in front of groups asking whether they have trouble, and so forth. We are on the right course.
Grush: In general, is OneCampus proving to be affordable?
Lynam: Yes, it is affordable, and when we look at our budget, it is not one of our high-ticket items. In terms of budget constraints, I don't get pushback on this.
Grush: What about security and authentication?
Lynam: Security is a high priority for the university. OneCampus works well for us, because we don't have to load all the security for our applications into it. Security is still handled by the applications on our servers.
And then it has single signon, meaning that if I've already signed on to a system on campus, it will pass me through to the application I choose in OneCampus — I don't have to sign on again.
Grush: So, OneCampus takes what you already have defined for your campus, for applications and authentication, and provides a more modern, intuitive, search-based user experience?
Lynam: Precisely.
Grush: In general, where do you have to put the most work into the system on the back end?
Lynam: Behind the scenes, the stuff you can't see, what we are configuring is search terms, keywords, and descriptions… that's where we invest most of our work.
Let's keep using registration as our example. Someone might search for "drop/add," someone else might look for "register," still someone else might type in "swap courses." So, no matter what they type, we want registration to come up. Of course, our entire goal is to make sure search results will be meaningful.
Grush: What about the context-sensitivity of these searches?
Lynam: When you have 700 forms, of course, there is some overlap on terms. So, we do have the additional dimension of audiences, like faculty, or students, or parents.
Grush: OneCampus has its own lingo — "tiles," and words like that. Was it easy for departments and data owners to opt into this?
Lynam: Well, it was easy for us from the beginning, as we had filled out the forms and had everything at least initially set up — then it was very simple for us to go to the owners to demonstrate this to them, and get immediate feedback. It's easy for them to understand what this system is, and what a "tile" is, when they see this working with their own data.
For example, we took 20 faculty in a group and 20 students in another group. We had them look at the system — just click around and try things for themselves. Then, we'd try scenarios: We'd tell a faculty member, "Look, a student just walked into your office and wants to take a winter field service course. How do they sign up?" Or, "I owe the registrar $25. How do I pay?" We had something like 20 questions, and we learned that these faculty and students could find the answers without any training in the system. At the end, we asked the faculty and students whether they needed training to use the system, and they all said "No."
The students put it best when they said: "No, we get it… it's easy!"
