Enterprise Systems Replacement Project (ESRP) -

Course Availability and Planning in the New World

bourgeot — Thu, 23 Apr 2009 15:13:41 -0700

As one of the co-directors of the Student Administration part of the Mosaic project, I would like to respond to Paul Cervantes’ Op-Ed piece in the Daily Wildcat published on 4/23/2009, ‘The Problem with WebReg.’ Paul’s article makes a number of good points that I’d like to remark on. First, the problem of appropriately matching the supply of seats in courses to the demand for those seats is a hard one to solve. Airlines have thrown a lot of money at this problem, and they do it pretty well with seats on planes; but, as many of us have experienced at one time or other in our lives, sometimes they get it horribly wrong. One simple and unavoidable reason behind this is the long lead times required to support class scheduling and registration—did you know that preparing the class schedule for the fall semester (in August) begins around January/February? A lot might happen in those intervening months that can lead to big problems on the first day of classes. The lead times shorten for the spring term, but only slightly, so there isn’t much relief there either. Furthermore, scarce resources (budgets), inadequate controls (technology), and the ever-changing availability of instructors to teach and students to learn only increases the difficulty for all the parties concerned. PeopleSoft’s Campus Solutions, the product we are installing via the Mosaic project, will actually give colleges and departments a number of tools beyond aesthetics to manage the availability of courses and course seats; some of these tools are the very ones that Paul mentions in his article. By way of example, CS can be configured to enforce prerequisites; it has wait-listing capabilities; seats can be reserved in courses for students who meet various characteristics such as their career, academic program or classification level; it can cap units; it has a ‘ticketing system’ whereby a specific student can be given permission to enroll in a particular class. It’s important for us all to understand, however, that these tools will require some wisdom and experience to wield for the benefit of all. I don’t really want to be dramatic, but when a system enforces prerequisites, or reserve capacities, or enrollment permissions, it *enforces* them. This enforcement has the potential to be welcome relief for departments which need it, but a nightmare for everybody concerned if this strict enforcement leads to more frustration, manual exception processing, and severe restrictions on choices for students. As an institution we will have to take some time to tune this new functionality so that we don’t end up turning it off as soon as we enable it. On the planning side, CS also has tools to help students select the classes they want to take in current and future semesters based on their SAPR. This is just the kind of information that a college or department might make use of to anticipate future demand. Again, however, while the availability of course planning tools for students and a central place to store the results make important contributions towards anticipating future demand more exactly, it’s not a slam dunk by any sense. Intentions of future behavior diverge from actual behavior for all kinds of reasons: existing students leave and new students arrive; students’ interests change; faculty take sabbaticals; department and student cash flows change; etc. Nevertheless, thanks to our new software, we will very soon have the potential to bring to bear on this problem some of the creative ideas Paul has shared. Over the course of the next several months, the project teams will be working to understand how best to ‘roll out’ these new tools (along with the rest of the suite’s functionality) in ways that provide rather than constrain services, and that maximize the acceptance of our new capabilities while minimizing our regrets about how we choose to use them. I’m confident, however, that with a little patience and goodwill, we will have a future that will let us do more towards managing classes more effectively than we can at the present.

To Host or not to Host?

dmasseth — Tue, 14 Apr 2009 11:08:17 -0700

UA Campus Community,

We’re no longer in a deciding mode—we’ve made a decision…Last fall we issued an RFP for the Mosaic Project hosting solutions. We tailored the RFP in such a way as to solicit responses for hardware alone, data center co-location facilities alone, or a combination of the two. We received a number of viable responses to the RFP and after painstaking analysis and discussion awarded the hardware purchasing component to Dell. At that time we did not award this particular RFP to any of the respondents for the data center co-location and/or environment management RFP.

We realize that it has taken a while for this decision to be made. This is in part due to the fact that we had the time. However we now have production go-live dates on the horizon, so now is the time to commit to a direction so that equipment can be purchased and prepared for deployment.

After much consideration we have made a decision on the hosting of the Mosaic environments. The question hasn’t been “can we?” but rather “should we?”. Based on our experience building and managing the various configuration, development, test, etc environments we are confident in our ability to take this challenge on. Additionally we know that UITS operates a first class operations environment complete with capacity, redundancy (in power, network and facility), and personnel.

We’ve decided that hosting ourselves is the better choice, so we will. That means that the systems and storage devices will be housed in UITS data center facilities and managed by University staff. In addition this will mean that the database administration and application configuration and administration will be handled by University employees.

Should circumstances change in a material way we might re-evaluate this thinking. That is true of any and nearly every decision that is made, but for now we are no longer in a deciding mode – we have made a decision and will commence the delivery of same.

Nothing Common About It

bourgeot — Mon, 23 Feb 2009 07:03:17 -0700

Locations, organizations, people...these sorts of very tangible things have associated attributes that show up a lot in administrative systems--attributes like names, addresses, and so forth. In fact they show up so much in so many different systems that collectively are often referred to as 'common data.' These attributes, and the entities they describe, are so real in our physical world that one might be surprised to learn what a problem they pose for folks in the information system business. But they do. And it’s a big problem too...

Consider names, for instance. Most western civ. folks have a first name and a last name, and some use middle initials or names too. There are also some who have a suffix, like ‘Jr.’ or ‘IV’, and a few with an honorific prefix like ‘Rev.’ or ‘Gen.’ Of course there are also a few individuals whose names have only one part, ‘Cher’ and ‘Pele’ are famous examples which come to mind, and some have more than three parts. Different systems react to this real variation in different ways, and although there are many schemes for putting data in, the fun begins when two or more systems need to talk to each other. There’s a fairly low probability that the variation in the data and the schemes implemented to account for it in one system will blend harmoniously with the same set of activities going on in another without a LOT of planning up front.

There aren’t very many opportunities for this kind of planning to take place, because systems are rarely implemented at the same time by the same organization. But this is Mosaic, and we are doing lots of system replacement all at the same time. So I’m happy to report that Hank Childers, Mosaic’s director, is capitalizing on this opportunity to try and make some headway into some of these very vexing problems. He has assembled both policy-oriented and practice-oriented teams to see if we can find some common ground and purpose. I have been fortunate to be included in the practice-level team.

It has actually been a hard, not-very-glamorous slog through some of these issues, but we are getting close to a solution for organizations and departments that will work across the Mosaic implementations. Even if it is only for a moment in time, it will be an important, if unsung, success story for this project if we can actually resolve some of these issues. Stay tuned--if we can pull it off--your occasional *lack* of annoyance about common data will speak volumes.

To those about to communicate...

bourgeot — Thu, 12 Feb 2009 13:49:18 -0700

...we salute you. I haven't written in a long time; too long. It turns out timing is everything here. If I don't write just when the mood strikes and don't keep things short enough, I get distracted, or have to go to one of many meetings, or I just get too tired. I can't imagine I'm unique in this way.

In case you don't already know, we have selected Hobsons EMT as our partner for student recruiting. They are offering us a hosted solution, so they will handle all of the software and hardware. It was a good process and the competition was strong. In the end the team felt Hobsons would help us move forward in the directions we want to go.

The implementation is being led by Nikolas Hodge, a longtime recruiter and generally high-energy young woman whose enthusiasm is contagious. She and her team have telephone calls every week with Hobsons to discuss UA's requirements, and they expect we will be up and running this very May!

More info relative to the hosting discussion

dmasseth — Tue, 10 Feb 2009 08:19:21 -0700

UA Campus Community,

Sorry I haven’t posted earlier, but there’s been a lot of progress and at the same time one of the key questions remains open.

In my previous post I mentioned two initiatives that we were involved in, the pilot PeopleSoft deployment in partnership with ASU and an RFP for hardware and co-location facilities, I would like to share the available results with you.

As noted in blog my post on September 6, 2008, the pilot partnership with ASU has reached completion and with measurable success. It is fair to say that during this process we learned a lot about deploying, managing and sustaining PeopleSoft environments. We have continued this deployment effort locally with the assistance of a consulting firm known as The Burgundy Group and have continued to deploy environments in support of each initiative in the Mosaic realm. It is fair to say that we continue to learn about the many nuances associated with building and maintaining these very complex environments, and without the assistance of our partners at The Burgundy Group we would be distinctly lower on the learning curve than we are today.

Our second challenge was to issue an RFP for hosting solutions. If you remember we tailored the RFP in such a way as to solicit responses for hardware alone, data center co location facilities alone, or a combination of the two. We received a number of viable responses to the RFP and after painstaking analysis and discussion awarded the hardware purchasing component to Dell. We did not award this particular RFP to any of the respondants for the data center co-location and/or environment management RFP. However, we remain open to the possibility that these systems be hosted offsite and/or managed as part of a managed services arrangement. That discussion is ongoing with the goal of reaching a conclusion prior to taking any of the production Mosaic deliverables live.

I sincerely hope that explains the current situation in the hosting discussion and answers any questions anyone may have. Please do feel free to post comments to this blog and/or bring any comments or questions to me directly.

Thank You!