Back to a Better Future

Back to a “Better” Future

How Boston College’s EagleApps is Flexibly Dealing with Rules

Throwing the Red Flag

On Oct 21, 20151 the Boston College EagleApps Enrollment team huddled to discuss adding a "flag" to courses that trigger automatic full time status for a student. BC had such a “flag” in their current home grown system and they were looking to add a “flag” like that to the Course Service. Several of us balked saying that adding a ‘flag’ is itself a RED FLAG to good service design. Like most schools the calculation of the full time status at BC is much more complicated than simply adding up credits. The threshold varies by program and whether or not it is a regular term or Summer. It also depends on whether or not the student was taking one of these special thesis/internship type courses. To understand why some of us took the stance we did we have to flash back nearly 10 years ago to the Summer of 2006. One year before the “Next Generation Student Services System” group joined the Kuali consortium.

1 OK the actual date of the meeting was Oct 22, 2015 but hey... close enough.

Was it possible to build a system that would meet all our needs?

It was July 11, 2006 and hot in MIT’s concrete bunker style Student Center. The workshop had been convened with a dozen schools in attendance. Small groups were chatting during a break from the intense modeling sessions. The sessions were centered on such mundane topics as curriculum development, student registration, financial aid and student billing. These are mundane to most people but to the group gathered here this was serious business. Some attendees came from the business side, Registrars and Financial Aid Officers. Some came from the technology side. All had decades of experience in higher education.

The workshop was the second in a series designed to explore the possibility of developing an Open Source Student Information System. Could a consortium of colleges join together and actually build such a system?  Was there enough commonality in all of our business processes to even think that building an open source student system was possible?

We’re not modest in our goals

My group had just finished modeling Financial Aid and we were listening to Chris Mackie, Associate Program Officer for the Mellon Foundation explaining why he was attending this workshop. The Mellon Foundation, he explained, didn’t really care about information technology, per se. The foundation’s core mission was to support the Arts, Music, Culture and Learning. However, we’re not modest in our goals, Chris announced, we want this group to change the way higher ed software is developed. From our perspective, he continued, billions of dollars is wasted on administrative systems that no longer support innovation and value.

Not “What” but “How”

We broke up and I went back to my modeling session on financial aid. I kept asking myself, was this Chris guy crazy?  What was so groundbreaking about what we were doing?  Sure we were trying to build an Open Source Student Information System but how was that going to change how higher ed software was developed?  Perhaps it might be cheaper and easier to modify because the source was open but it would still be just one more package to acquire, install and configure, wouldn’t it?  Most of the costs go to integration anyway so what is so “innovative” about that. Then I thought... Perhaps it wasn’t WHAT we were doing that was so important, perhaps it was HOW we were going to do it that was revolutionary.

We’re all the same except for all the “crazy” rules?

At the end of the workshop the groups came back together and I helped present our team’s results. Financial Aid in the US is on the surface very different than that of Canada. We struggled for the first day just to get past terminology differences. To our amazement, I continued, we found that all the universities actually shared the same basic processes, Canada and US. We called things by different names, did them in a different order, some skipped steps that others followed but the basic processes were all the same. We could agree on everything -- we could build a single system that would meet the needs of all the schools -- we’re all the same except for the “crazy” rules. To my further astonishment each group got up and reported essentially the same result. Everyone left the workshop convinced that the whole grand scheme was possible if we could find a way to handle each school’s own “crazy” rules.

Rules as First Class Citizens

Flash forward one year later and the Kuali Student Services System Program Charter is written and signed. The word “rule” appears 215 times in the charter. The configuration of business rules is called out as one of the major functions of the system -- clearly separated from the service contracts and the rest of the system:

Principle 5: Abstraction of Business Processes and Business Rules

Business rules and business process logic will be abstracted from the code base.

(p. 21)

The entire architecture of the system has been designed to move all that “crazy” rule logic out of the data objects and out of the main services and put them into their own services as first class citizens. This was the principle that some of us on the EagleApps team felt was being violated when we were asked to add a “flag” to the course.

Back to a “Better” Future

Boston College is now working hard to complete it’s EagleApps system based on the original Kuali Student source code, architecture and vision. After 15 minutes of discussion the EagleApps Enrollment team had come up with a “better” plan. Instead of adding a “flag” to the course object we would leverage two key technologies:

1. The use of several “rules” oriented services that allow us to cleanly separate the various aspects of the writing, configuring, viewing and executing credit load calculation rule.
2. The creation of a domain specific language (DSL) that will allow the detailed authoring of BC’s full time status rule by a technically minded business user.

This DSL technology is new and deserves some explanation. It leverages drools and was originally developed by Sigma Systems, Inc for the Kuali Student Accounts system. Boston College is currently using this technology to author it’s own Fee Assessment Rules and Payment Application Rules. Additionally Sigma Systems and Boston College just completed a POC leveraging the technology to calculate a GPA. Having done this, the jump to applying the DSL to load level is not that hard to imagine.

What the EagleApps team is completing is truly a Next Generation Student Services System. We are not following the traditional ERP patterns such as adding flags everywhere and burying the rules in code. If we did that we would end up with a “higgly piggly” mess of service contracts and code that would never be stable and around which no other schools could find agreement. The EagleApps team is not designing this kind of flexibility out of the goodness of their hearts. They are not doing this simply so other schools who want to leverage the source code can configure the system to meet their own needs. They are doing this because they know that the really cool thing is that this same ability will allow Boston College’s future self to easily refine their own rules and innovate educationally and help them produce a “Better Future” for their students.