Monthly Archive: April 2016

the great unbundling

There has been a lot of discussion on “unbundling” of traditionally single-vendor, monolithic systems, especially the Learning Management System (LMS) and the Enterprise Resource Planning (ERP) solutions.Essentially, rather than relying on a single solution that does 100 things, why not break out the functions into perhaps 20 products that are all efficiently and seamlessly tied together? Those 20 would be chosen because they meet operational needs better than that single solution could.

This is different than a straight “Best of Breed” approach. Gartner handles it pretty well in their discussion on the “post-modern ERP.” Best of Breed is focused on selecting products that are best in industry, in any given field. Being purposely black and white, it’s the best of that type of application, and that’s what we’re going to use. A post-modern ERP approach is based on business processes. The results might be the same – the best product in the field might be the one that fits your business processes the best. But one institution might do something very differently than another, and while both might be looking for “best fit,” the result might be two completely different products. Perhaps a subtle difference, but one that I think is important.

Unbundling an ERP, especially in higher education, is pretty straightforward. Perhaps the admissions module that came with the ERP isn’t an effective CRM. Let’s go out and find one, and spend our time integrating the two systems. We might see similar decisions with Advancement and its CRM needs, or perhaps analytics and data visualization.

At first ,the ERP would be the hub with other systems attached to it. Over time, the ERP is completely broken up, and all the systems revolve around a data warehouse. Energy is spent on governing the data integrity of that warehouse and on maintenance of the flow of data. The ERP (which by this point is probably just a Student Information System) is actually attached to the data warehouse, rather than fueling it. The great thing about using the data warehouse as the hub is that all reporting stays consistent from group to group.

This isn’t remotely my idea, by the way. I can’t seem to find the trail but I know I first heard of it from Theresa Rowe (@oucio) who was in fact retweeting someone else. I’ll provide the reference if someone can send it my way. Also, all you (what, 2 readers?) should note that I’m in the middle of a comprehensive ERP roll-out right now. Just because I get the idea of the unbundled ERP doesn’t mean it’s the right time for me to pursue it for my specific institution.

The data warehouse could be the center for the components that make up an LMS, too. I get the idea – find the right assessment tool for the learning outcomes your institution has chosen and integrate that, rather than using one that came from a vendor. Do the same with e-portfolios, quizzes, cloud storage integration, just about anything. If student data is all managed effectively in that warehouse, and all the systems are connected properly, you could have a pretty powerful solution.

My concern, however, is that whereas an unbundled ERP likely won’t lead to a lot of user confusion, an unbundled LMS could. The finance office uses its software and Admissions uses theirs, and rarely shall the twain meet. But students all use the LMS components, and this could lead to confusion. Sure, we can implement single sign-on so at least it’s one portal and one login, but how do we manage this user experience?

This remains to be answered. I’m eager to see what comes of all this unbundling.

the other end of the Personal API

A lot has gone on lately about the “Personal API.” Getting information on it gets to be a bit meta, with one link leading to another article to a blog post then all the way back around to the first reference but start off with a great post from Jim Groom that in turn links to an article by Tim Klapdor that really captures the key ideas, then check out some talk on the Indie Ed Tech discussion from 

A massive oversimplification of an idea as expansive as a personal API is that it’s a way for the user to control how his or her own data is being used and accessed. An API in the software world is a defined interface for accessing data from a system like Twitter or Facebook. A personal API, therefore, is about controlling how personal data is accessed. It puts the power back into the hands of the individual, rather than the system. This discussion is taking place in higher ed, so the practical example would be a student deciding when personal data such as a phone number is available, rather than the institution controlling that information through access into, say, the Student Information System (this is the example Kelly Flanagan, the CIO at BYU, provides).

This is an amazing idea, and one worth pursuing regardless of your type of institution. It’s worth rethinking how you approach everything from digital learning in general to the LMS specifically. But it also has a flip-side challenge that is non-trivial.

Earlier this week, I was in a demo from an SIS vendor where we talked about ways to access data in the system. Not surprisingly, they discourage direct SQL database access, so the options were to either use reports (e.g. – giant Excel file, which requires more work to use) or build hooks into their APIs. The latter is preferred since it would inherently include getting the data into the right format for whatever the intended use, plus it would be more secure. The vendor was touting how they have well-documented and extensive APIs so that we can do what we wish in terms of software development.

APIs – whether for a Student Information System or a person – are great and indeed quite powerful. It’s like an extended hand in a way, but one that carries with it all the information about how high up the hand is from the floor, how far away it is from the body, whether it’s the right or left hand, etc. Taking this metaphor a bit further, the key is that the person extending the hand – the student in the personal API example – gets to decide all of those variables. The angle of the hand, the distance extended, etc. What data is included or excluded, and exactly how a secure exchange should take place.

However, having an API isn’t a complete solution. The problem with an API is that it’s only half of a two-part process. The hand is extended, but someone does indeed have to walk up, take hold, and offer that firm handshake. It’s great to offer access to data, and it’s even better to give control over that process to the individual, but it still takes two to tango.

Now, BYU and some schools involved in projects related to digital identity (see Domain of One’s Own – another Jim Groom brainchild – for a good starting point on this topic) are already or will soon be investing time and resources into the other half of this relationship. And this is undeniably something that every institution should explore as we find ways to empower students and create the Next Generation Digital Learning Environment, but there is part of me – the cynical half? – that keeps wondering about the resources needed. Looking with blinders on only at our department at Muhlenberg, I don’t see us being able to engage in a meaningful way for some time. We’ll take advantage of tools that others build, sure (and of course there is nothing wrong with that IMO). But as far as us being the other end of the handshake, building our own tools? I don’t know. Can we disaggregate the LMS on our own? Not likely in the near future.

Absolutely worth it, without a doubt, to work to find a way to get involved. But it will take work to get to a meaningful outcome with the personal API.