e-Literate

Present is Prologue

Tag: LTI

  • The IMS at an Inflection Point

    The IMS at an Inflection Point

    A few weeks back, I had the pleasure of attending the IMS Learning Impact Leadership Institute (LILI). For those of you who aren’t familiar with it, IMS is the major learning application technical interoperability organization for higher education and K12 (and is making some forays into the corporate training and development world as well). They’re behind specifications like LIS, which lets your registrar software automagically populate your LMS course shell with students, and LTI, which lets you plug in many different learning applications. (I’ll have a lot more to say about LTI later in this post.)

    While you may not pay much attention to them if you aren’t a technical person, they have been and will continue to be vital to creating the kind of infrastructure necessary to support more and better teaching and learning affordances in our educational technology. As I’ll describe in this post, I think the nature of that role is likely to evolve somewhat as the interoperability needs of the sector are beginning to evolve.

    The IMS is very healthy

    I’m happy to report that the IMS appears to be thriving by any obvious measure. The conference was well attended. It attracted a remarkably diverse group of people for an event hosted by an organization that could easily be perceived as techie-only. Furthermore, the attendees seemed very engaged and the discussions were lively.

    On more objective measures, the organization’s annual report bears out this impression of strong engagement. They have strong international representation across a range of organization types.

    From the IMS Global 2018 Annual Report

    Whether your measure is membership, product certifications, or financial health, the IMS is setting records.

    From the IMS Global 2018 Annual Report

    This state of affairs is even more remarkable given that, 13 years ago, there was some question as to whether the IMS was financially sustainable.

    From the IMS Global 2018 Annual Report

    If you look carefully at this graph, you’ll see three distinct periods of improvement: 2005-2008, 2009-2013, and 2013-2018. Based on what I know about the state of the organization at the time, first period can most plausibly be attributed to immediate changes implemented by Rob Abel, who took over the reins of the organization in February of 2006 and likely saved it from extinction. Likewise, the magnitude of growth in the second period is consistent with that of a healthy membership organization that has been put back on track.

    But that third period is different. That’s not normal growth. That’s hockey stick growth.

    I am not a San Franciscan. By and large, I do not believe in heroic entrepreneur geniuses who change the world through sheer force of will. Whenever I see that kind of an upward trend, I look for a systemic change that enabled a leader or organization—through insight, luck, or both—to catch an updraft.

    There is no doubt in my mind that the IMS has capitalized on some major updrafts over the last decade. That is an observation, not a criticism. That said, the winds are changing, in part because the IMS has helped move the sector through an important period of evolution and is now helping to usher in the next one. That will raise some new challenges that the IMS is certainly healthy enough to take on but will likely require them to develop a few new tricks.

    The world of 2005

    In the first year of the chart above, when the IMS was in danger of dying, there was very little in the way ed tech to interoperate. There were LMSs and registrar systems (a.k.a. SISs). Those were the two main systems that had to talk to each other. And they did, after a fashion. There was an IMS standard at the time, but it wasn’t a very good one. The result was that, even with the standard, there was a person in each college or university IT department whose job it was to manage the integration process, keep it running, fix it when it broke, and so on. This was not an occasional tweak, but a continual effort that ran from the first day of class registration through the last day of add/drop. If you picture an old-timey railroad engineer shoveling coal into the engine to keep it running and checking the pressure gauge every ten minutes to make sure it didn’t blow up, you wouldn’t be too far off. As for reporting final grades from the LMS’s electronic grade book automatically to the SIS’s electronic final grade record, well, forget it.

    If you ignore some of the older content-oriented specifications, like QTI for test questions and Common Cartridge for importing static course content, then that was pretty much it in terms of application-to-application interoperability. Once you were inside the LMS, it was basically a bare-bones box with not much you could add. Today, the IMS lists 276 officially certified products that one can plug into any LMS (or other LTI-compliant consumer), from Academic ASAP to Xinics Commons. I am certain that is a substantial undercount of the number of LTI-compatible applications, since not all compatible product makers get officially certified. In 2005, there were zero, because LTI didn’t exist. There were LMS-specific extensions. Blackboard, for example, had Building Blocks. But with a few exceptions, most weren’t very elaborate or interesting.

    My personal experience at the time was working at SUNY Systems Administration and running a search committee for an LMS that could be centrally hosted—preferably on a single instance—and potentially support all 64 campuses. For those who aren’t familiar with it, SUNY is a highly diverse system, with everything from rural (and urban) community colleges to R1s to everything in between, with some specialty schools thrown into the mix like the Fashion Institute of Technology, a medical school or two, an ophthalmology school, and so on. Both the pedagogical needs and the on-campus support capabilities across the system were (and presumably still are) incredibly diverse. There simply was not any existing LMS at the time, with or without proprietary extensions, that could meet such a diverse set of needs across the system. We saw no signs that this state of affairs was changing at pace that was visible to the naked eye, and relatively few signs that it was even widely recognized as a problem.

    To be honest, I came to the realization of the need fairly slowly myself, one conversation at a time. A couple of art history professors dragged me excitedly to Columbia University to see an open source image annotation tool, only to be disappointed when they discovered that the tool was developed to teach clinical histology, which uses image annotation to teach in an entirely different way than is typically employed in art history classes. An astronomy professor at a community college on the far tip of Long Island, where there was relatively little light pollution, wanted to give every astronomy student in SUNY remote access to his telescope if only we could figure out how to get it to talk to the LMS. Anyone who has either taught a been an instructional designer for a few wildly different subjects has a leg up on this insight (and I had done both), but even so, there are levels of understanding. The art history/histology thing definitely took me by surprise.

    A colleague and I, in an effort to raise awareness about the problem, wrote an article about the need for “tinkerable” learning environments in eLearn Magazine. But there were very few models at the time, even in the consumer world. The first iPhone wasn’t released until 2007. The first practically usable iPhone wasn’t released until 2008. (And we now know that even Steve Jobs was secretly skeptical that apps on a phone were a good idea.) It is a sign of just how impoverished our world of examples was in January of 2006 that the best we could think of to show what a world of learning apps could be like was Google Maps:

    There are several different ways that software can be designed for extensibility. One of the most common is for developers to provide a set of application programming interfaces, or APIs, which other developers can use to hook into their own software. For example, Blackboard provides a set of APIs for building extensions that they call “Building Blocks.” The company lists about 70 such blocks that have been developed for Blackboard 6 over the several years that the product version has been in existence. That sounds like a lot, doesn’t it? On the other hand, in the first five months after Google made the APIs available for Google Maps, at least ten times that many extensions have been created for the new tool. Google doesn’t formally track the number of extensions that people create using their APIs, but Mike Pegg, author of the Google Maps Mania weblog, estimates that 800-900 English-language extensions, or “mash-ups,” with a “usable, polished Google Maps implementation” have been developed during that time—with a growth rate continuing at about 1,000 new applications being developed every six months. According to Pegg, “There are about five sites out there that facilitate users to create a map by taking out an account. These sites include wayfaring.comcommunitywalk.commapbuilder.net—each of these sites probably has hundreds of maps for which just one key has been registered at Google.” (Google requires people who are extending their application to register for free software “keys.” Perhaps for this reason, Chris DiBona, Google’s own Open Source Program Manager, has heard estimates that are much higher. “I’ve seen speculation that there are hundreds or thousands,” says DiBona, noting that estimates can vary widely depending on how you count.

    Nevertheless, even the most conservative estimate of Google Maps mash-ups is higher than the total number of extensions that exist for any mainstream LMS by an order of magnitude.

    There seemed little hope for this kind of growth any time in the foreseeable future. By early 2007, having failed to convince SUNY to use its institutional weight to push interoperability forward, I had a new job working at Oracle and was representing them on a specification development committee at the IMS. It was hard, which I didn’t mind, but it was also depressing. There was little incentive for the small number of LMS and SIS vendors who dominated specification development at that time to do anything ambitious. To the contrary, the market was so anemic that the dominant vendors had every reason to maintain their dominance by resisting interoperability. Every step forward represented an internal battle within those companies between the obvious benefit of a competitive moat and the less obvious enlightened self-interest of doing something good for customers. This is simply not the kind of environment in which interoperability standards grow and thrive.

    And yet, despite the fact that it certainly didn’t feel like it, change was in the air.

    Glaciers are slow, but they reshape the planet

    For starters, there was the LMS, which was both a change agent in of itself and an indicator of deeper changes in the institutions that were adopting them. EDUCAUSE data shows that the US LMS market became saturated some time roughly around 2003. At that time, Blackboard and WebCT had the major leads as #1 and #2, respectively. The dynamic for the next 10 years was a seesaw, with new competitors rising and Blackboard buying and killing them off as fast as it could. Take a look at the period between 2003 and 2013 in Phil’s squid graph: ((By the way, if you haven’t subscribed to Phil’s new blog yet, then you really, really should. Like, right now. I’ll wait.))

    It was absolutely vicious.

    None of this would materially affect the standards making process inside the IMS until, first, Blackboard’s practice of continually buying up market share eventually failed (thus allowing an actual market with actual market pressures to form) and, second, until the management team that came up with this decidedly anti-competitive strategy…er…chose to spend more time with their respective families. (I’ll have more to say about Heckle and Jeckle and their lasting impact on market perceptions in a future post.)

    But the important dynamic during this period is that customers kept trying to leave Blackboard (even if they found themselves being reacquired shortly thereafter) and other companies kept trying to provide better alternatives. So even though we didn’t have a functioning, competitive market that could incentivize interoperability, and even though it certainly didn’t feel like we had one, some of the preconditions for one were being established.

    Meanwhile online education growth was being driven by no fewer than three different vectors. First, for-profit providers were hitting their stride. By 2005, the University of Phoenix alone was at over 400,000 enrollments. Second, public access-oriented institutions, many of which had been seeded a decade earlier with grants from the Sloane Foundation, were starting to show impressive growth as well. A couple were getting particular attention. UMUC, for example, may not have had over 400,000 online enrollments in 2005, but they had well over 40,000, which is enough to get the attention of anyone in charge of an access-oriented public university’s budget. More quietly, many smaller schools were having online success that were proportional to their sizes and missions. For example, when I arrived at SUNY in 2005, they had a handful of community colleges that had self-sustaining online degree programs that supported both the missions and the budget of the campuses. Many more were offering individual courses and partial degrees in order to increase access for students. (Most of New York is rural, after all.)

    The third driver of online education, which is more tightly intertwined with the first two than most people realize, is that Online Program Management companies (OPMs) were taking off. The early pioneers, like Deltak (now Wiley Education Services), Embanet, Compass Education (now both subsumed into Pearson), and Orbis (recently acquired by Grand Canyon University) had proved out the model. The second wave was coming. Academic Partnerships and 2Tor (now 2U) were both founded in 2008. Altius Education came in 2009. In 2010, Learning House (now also owned by Wiley) was founded.

    Counting online enrollments is a notoriously slippery business, but this chart from the Babson survey is highly suggestive and accurate enough for our purpose:

    If you’re a campus leader and thirty percent of your students are taking at least one online class, that becomes hard for you to ignore. Uptime becomes far more important. Quality of user experience becomes far more important. Educational affordances become far more important. Obviously, thirty percent is an average, and one that is highly unevenly distributed across segments. But it’s significant enough to be market-changing.

    And the market did change. In a number of ways, the biggest one being that it became an actual, functioning market (or at least as close to one as we’ve gotten in this space).

    When glaciers recede

    Let’s revisit that second growth period in the IMS graph—2008 to 2013—and talk about what was happening in the world during that period. For starters, online continued its rocket ride. The for-profits peaked in 2010 at roughly 2 million enrollments (before beginning their spectacular downward spiral shortly thereafter). Not-for-profits (and odd mostly-not hybrids) ramped up the competition. ASU launched its first online 4-year degree in 2006. SNHU started a new online unit in 2009. WGU expanded into Indiana in 2010, which was the same year that Embanet merged with Compass Knowledge and was promptly bought by Pearson. (Wiley acquired Deltak two years later.)

    Once again, the more online students you have, the less you are able to tolerate downtime, a poor user interface that drives down productivity, or generic course shells that make it hard to teach students what they need to learn in the ways in which they need to learn. Instructure was founded in 2008. They emphasized a few distinctions from their competitors out of the gate. The first was their native multitentant cloud architecture. Reduced downtime? Check. The second was a strong emphasis on usability. The big feature that they touted which was their early runaway hit was Speed Grader. Increased productivity? Check.

    Instructure had found their updraft to give them their hockey stick growth.

    But they also emphasized that they were going to be a learning platform. They weren’t going to build out every tool imaginable. Instead, they were going build a platform and encourage others to build the specialized the tools that teachers and students need. And they would aggressively encourage the development and usage of standards to do so. On the one hand, this fit from a cultural perspective. Instructure was more like a Silicon Valley company than its competitors, and platforms were hot in the Valley. On the other hand, it was still a little weird for the education space. There still weren’t good interoperability standards for what they wanted to do. There still hadn’t been an explosion of good learning tools. This is one of those situations where it’s hard to tell how much of their success was prescience and how much of it was luck that higher ed caught up with their cultural inclination at that exact moment.

    Co-evolution

    The very same year that Brian Whitmer and Devlin Daley founded Instructure, Chuck Severence and Mark Alier were mentoring Jordi Piguillem on a Google Summer of Code project that would become the initial implementation of LTI. In 2010, the same year that Instructure scored its first major win with the Utah Education Network, IMS Global released the final specification for LTI v1.0. All this time that the market had felt like it had been standing still, it had actually been iterating. We just hadn’t been experiencing the benefits of it. Chuck, who had been thinking about interoperability in part through his work on Sakai, had been tinkering. Students like Brian and Devlin, who had been frustrated with their LMS, had been tinkering. The IMS, which actually had a precursor specification before LTI, had been tinkering. While conditions hadn’t become visible on the surface of the glacier, way down, a mile below, the topology of the land was changing.

    Meanwhile in Arizona, in 2009, the very first ASU+GSV summit was held. I admit that I have had writer’s block regarding this particular conference the last few years. It has gotten so big that it’s hard to know how to think about it, much less how to sum it up. In 2009, it was an idea. What if a university and a company that facilitates start-ups (in multiple ways) got together to encourage ed tech companies to work more effectively with universities? That’s my retrospective interpretation of the original vision. I wasn’t at many of those early conferences and I certainly wasn’t an insider. It was hard for me, with my particular background, to know what to make of it then and even harder now.

    But something clicked for me this year when it turned out that IMS LILI was held at the same hotel that the ASU+GSV summit had been at a couple of months earlier. How does the IMS get to 523 product certifications and $8 million in the bank? A lot of things have to go right for that to happen, but for starters, there have to be 523 products to certify and lots of companies that can afford to pay certification fees. That economy simply did not exist in 2008. Without it, there would be no updraft to ride and consequently no hockey stick growth. ASU+GSV’s phenomenal growth, and the ecosystem that it enabled, was another major factor influenced what I saw at IMS LILI this month.

    There is a lot of chicken-and-egg here. LTI made a lot of this possible, and the success LTI (and IMS Global) have experienced would not have been possible without a lot of this. The harder you stare at the picture, the more complicated it looks. This is what “systems thinking” is all about. There isn’t a linear cause-and-effect story. There are multiple interacting feedback loops. It’s a complex adaptive system, which means that it doesn’t respond in linear or predictable ways.

    Update: I got a note from Rob Abel noting that a lot of the growth in the last leg came from an explosion of participation in the K12 space. That’s good color and consistent with what I’ve seen in my last couple of LILI conference visits. It’s also consistent with the rest of this analysis. K12 benefitted from all of the dynamics above—the maturation of the LMS market, the dynamics in higher education online that pushed toward SaaS and usability, the massive influx of venture funding, and so on. All of those developments, plus the work inside IMS, made the K12 growth possible, while the dynamics inside K12 added another feedback loop to this complex adaptive system.

    But respond it finally did. We have some semblance of a functioning market, and with its rise, blockers preventing the formation of a vibrant interoperability standards ecosystem of the type we have today have largely fallen. Now we have to address the blockers of the formation of the vibrant interoperability ecosystem that we will need tomorrow. Because it will be qualitatively different. Tomorrow’s blockers are not market formation problems but rather collaboration methodology problems. They are about creating meaningful learning learning analytics, which will require solving some wicked problems that can only be tackled through close and well structured interdisciplinary work. That most definitely includes the standards design process itself.

    After the glacier comes the flood

    What I saw at the IMS LILI this year was, I think, a milestone. The end of an era. Market pressures now favor interoperability. The same companies that were the most resistant to developing and implementing useful interoperability standards in 2007 are among the most aggressive champions of interoperability today. This is not to say that foundational interoperability work is “over.” Far from it. Rather, the conditions finally exist where it can move forward as it should, still hard but relatively unimpeded by the distortions of a dysfunctional market.

    That said, the nature and challenges of interoperability our sector will be facing in the next decade are fundamentally different from the ones that we faced in the last one. Up until now, we have primarily been concerned with synchronizing administration-related bits across applications. Which people are in this class? Are they students or instructors? What grades did they get on which assignments? And how much does each assignment count toward the final course grade? These challenges are hard in all the ways that are familiar to anyone who works on any sort of generic data interoperability questions.

    But the next decade is is going to be about data interoperability as it pertains to insight. Data scientists think this is still familiar territory and are excited because it keeps them at the frontier of their own profession. But this will not be generic data science, for several reasons. (I will tell you right now that some of them disagree with me on this. Vehemently.) First, even in the most richly instrumented fully online environments that we have today, they are highly data impoverished relative to what we need to make good inferences about teaching and learning. For heaven’s sake, Amazon still recommends things that I have already bought. If I just bought a toaster oven last month, then how likely is it that I want to buy another one now? And I buy everything on Amazon. If they don’t know enough to make good buying recommendations on consumer products, then there’s no way that our learning environments are going to have enough data to make judgements that are orders of magnitude more sophisticated.

    Well then, some answer, we’ll just collect more data! More more more! We’ll collect everything! If we collect every bit of data, then we can answer any question. (That is a pretty close paraphrase of what one of the IMS presenters said in one of the handful of learning analytics talks I went to.)

    No. You won’t collect “everything”—even if we ignore the obvious, glaring ethical questions—because you don’t know what “everything” is. Computer folks, having finally freed themselves from the shackles of SQL queries and data marts, are understandably excited to apply that newfound freedom to the important problem space of learning. But it is not a good fit, because we don’t have a good understanding of the basic cognitive processes involved in learning. As I wrote about (at length) in a previous post, we have to employ multiple cutting-edge machine learning techniques just to get glimpses of learning processes even when we are directly monitoring students’ brain activity because these are extraordinarily complex processes with multiple hidden variables. Trying to tease out learning processes inside a student’s head based on learning analytics from running machine learning algorithms on LMS data is a little like trying to monitor the digestive processes of a flatworm on the bottom of the Marianas Trench based on studying the wave patterns on the surface of the ocean. There are too many invisible mediating layers to just run a random forest algorithm on your data lake—it all sounds very organic, doesn’t it?—and pop out new insights about how students learn.

    That doesn’t mean we should just throw up our hands, by any means. To the contrary, IMS Global has some extraordinarily good tools close at hand for tackling this problem. But it does mean that they are going to have to take some of the stakeholder engagement strategies they’ve been working at diligently to the next level, to the point where the standards-making process itself may evolve over time.

    Theory-driven interoperability

    There is an excellent data and processing resource that the learning analytics folks have yet to think deeply about how to leverage, as far as I can tell from the conference. The computational power is impressive (and impressively parallel). It is the collective intelligence of educators and learning scientists. Because there are too many confounds to making useful direct inferences from the data, educational inferencing needs to be theory-driven. You need to start with at least some idea of what might be going on inside the learner’s head. One that can be either supported or disproven based on evidence. And you need to know what that evidence might look like. If you can spell all that out, then you can start doing interesting things with learning analytics, including machine learning. There is room for learning science, data science, and on-the-ground teaching expertise at the table. In fact, you need all those kinds of expertise. But the folks with those respective kinds of know-how need to be able to talk to each other and work together in the right ways, which is really hard.

    The IMS has an outstanding foundation for this sort of work, because their Caliper specification turns out to provide the basis for a perfectly lovely lingua franca. To begin with, its fundamental structure is triples, which is the same basic idea as the original concept behind the semantic web. If you’re not a computer person and this is starting to make your eye’s glaze over, don’t worry, because this is plain English. Three-word sentences, in fact. Noun, verb, direct object. Student takes test. Question assesses learning objective. Student highlights sentence. Sentence discusses Impressionism.

    IMS Caliper expresses learning analytics in statements that can easily be translated into three-word plain-English sentences. These sentences can be strung together into coherent paragraphs. Notice, for example, how the last two example sentences are related. Three-word sentences in this format can be chained together to form longer thoughts. New thoughts. With this one, very simple grammatical structure, we have a language that is generative in the linguistic sense. As long as you have words to put into these grammatical placeholders, you can string thoughts together. Or “chain inferences,” to sling the lingo. And it turns out, unsurprisingly, that Caliper has a mechanism for defining these words in ways that both humans and machines can understand them.

    That has to be the bridge. Humans have to understand the utterances well enough to be able express their theories on the front end and understand whatever the machine is telling them it may have learned on the back end. Machines have to understand them specifically enough to be able to parse the sentences in their own, literal, machine-y way. Theoretically, Caliper could be an ideal language to enable educators and computer scientists to discuss theories about how to better support students as well as how to test those theories together.

    The challenge is that the IMS community, at least based on what I saw in the sessions I attended, is not using the specification as an interdisciplinary communication tool in this way yet. What I saw happening instead was a lot of very earnest data scientists pumping as much Caliper data as the can into their data lakes. They come to the conference, give a talk and, to their credit, shrug their shoulders and admit that they really don’t know what to do with those data yet. But then they go home and build bigger pipes, because that’s their job. That’s what they do.

    It’s not their fault. I’ve been friends with some of these folks for a very long time indeed. There are good people here. But if you work in the IT department, and you’re not a learning scientist or a classroom educator, and the faculty are somewhere between dismissive and disdainful of the idea of talking to you about working together to improve teaching and learning, then what can you do? You do what you know how to do and hope that things will change for the better over time.

    It’s not the IMS’s fault either. The conference I attended was called the IMS Learning Impact Leadership Institute. That’s not a new name. Caliper has board that helps guide its direction. That board includes educators who are the kind of advocates that I would like to see on such a body. They are productive irritants in the best possible way. But that’s not enough anymore. This is just a really hard problem. It’s the challenge of the next decade. To meet it, we need to do more than just make sure the right people are in the room together. We need to develop new ways of working together. New roles, methodologies, ways of talking with each other, and ways of seeing the world.

    I’m going to preview a bit of a post that I have in my queue for…I’m not sure when, but some time soon…by mentioning “learning engineering.” This term has gotten a lot of buzz lately, along with some criticism. I’ll be writing up my own take on it, but for now I’ll say that one reason I think the term is gaining some currency is that it represents a set of skills for being a mediator in the kind of collaboration that I’m describing here.

    As it turns out, it was coined by Nobel prize-winning polymath and Carnegie Mellon luminary Herb Simon, after whom Carnegie Mellon University’s Simon Initiative was named. And, as it also turns out, the Simon Initiative hosted this year’s EEP summit and made some news in the process by contributing $100 million worth of open source software that they use in their research and pratice of…wait for it…learning engineering.

    Here’s a slide that they used in their talk explaining what the heck learning engineering is and what they are doing when they are doing it:

    Copyright Carnegie Mellon University, CC-BY

    (By the way, the videos of all talks from the summit will be posted online, as promised. Please be patient a little longer.)

    This post has already run long, so rather than unpacking the slide, I’ll leave you with a question or two. Think about this graphic as representing a data-informed continuous improvement methodology involving multiple people with multiple types of expertise. What would that methodology need to look like? Who would have to be at the table, what kinds of conversations would they have to have, and how would they have to work together?

    I’m not suggesting that “learning engineering” is a magical conjuring phrase. But I am suggesting that we need new approaches, new competencies, and likely a new role or two if we are going to get to the next updraft.

  • How and Why the IMS Failed with LTI 2.0

    How and Why the IMS Failed with LTI 2.0

    While at EDUCAUSE last week, we heard from several sources that the IMS is walking away from LTI 2.0. I’m not sure what term the organization is using to characterize what they’re doing; there’s nothing on the public web site that I can find at the moment. But the reality is that they are no longer encouraging the adoption of LTI 2.0 and are actively investing their energy in developing the 1.x branch, starting with something that they’re calling “LTI Advantage.” (More on that in a bit.)

    To be clear, I believe this is a good decision, and I also believe the fact that they felt the need to do so is not particularly scandalous. Everybody makes mistakes. The important thing is to learn from them. So, with that in mind, and with the IMS quarterly meeting coming up this week, I thought it might be useful to write a post-mortem that could potentially be of use going forward.

    Interoperability Standards as Multilateral Trade Deals

    One of the biggest problems the IMS faces is that a lot of the participants on the specification committees don’t fully understand the big picture of how standards adoption works in the real world. They are mostly technologists with a sprinkling of product managers. They usually have the best of intentions. But they do not have the right roles to see the business ramifications of spec development clearly, and they very often do not get adequate guidance from the stakeholders in their respective organizations that do have the right roles.

    First and foremost, interoperability specifications are a lot like multilateral trade agreements. They are agreements that everybody will operate according to certain rules under certain circumstances. The fact that these agreements are written in engineering language and implemented in software code doesn’t change the fact that they are multi-party treaties. One of the major implications that falls out of this circumstance is that organizations will not adopt the standard—or “sign the treaty”—unless they believe the benefits will outweigh the costs. If a specification is going to be broadly adopted, then it needs to be designed so that all the adopting parties will see direct benefit. Remember, every minute of developer time spent implementing a standard could have been spent developing a feature or fixing a bug instead. If their customers don’t care about the benefits of the standard and developers don’t see internal benefits (like reducing the time they have to spend on one-off integrations), then the rational decision for product or project owners is to not implement the standard.

    Such a decision does not mean that all progress grinds to a halt. In the trade world, there are many more bilateral trade agreements than there are multilateral trade agreements. In the software world, the equivalent to a bilateral agreement would be a proprietary integration. Many companies today that want to provide richer integration with another platform—especially with an LMS—will use the multilateral agreement that is LTI 1.x as a baseline and extend it with the bilateral agreements of proprietary integrations. This is as it should be. Not every integration needs to be standards-based. In fact, a lot of innnovation happens beyond the edge of the standard as software developers come up with new ideas about how their products can work together. They hammer out a bilateral trade agreement to get that new idea implemented and to gain a competitive edge for a while. Eventually, enough products may choose to implement the same pattern that it makes sense for everybody to adopt the same way of integrating so that developers don’t have to build slightly different versions of the same integration over and over.

    Interoperability standards, being multilateral trade agreements, are rarely innovative or sexy if they are done right. Once in a while, a working group may come up with a new spin that is generative. But this is always a risky proposition. The technologists and product designers on these working groups, being creative people, want to come up with cool stuff. But “cool” isn’t what drives their employers to adopt. There always needs to be a cost/benefit analysis for each potential adopter. If that analysis doesn’t look good, then no amount of coolness will matter.

    As far as I can tell from the outside, this is precisely what went wrong with LTI 2.0.

    Please Pass (on) the SOAP

    Back in the early days of service-oriented architecture (SOA) in software engineering, everybody was using a complex XML-based protocol called SOAP. The idea was that everybody had data to pass around, and if there were discrete services that could be called for that data, then we could have a lot more interoperability. SOAP was considered secure (or securable, anyway), so it could be used for sensitive data. SOA advocates envisioned a world in which all software provided lots of services for other software to use, creating rich opportunities for interoperability. In fact, they thought there would be so many services that it would be impractical to connect them all up by hand. So they invented something called a service bus that helped each piece of software automagically discover the services available to it from other software in the system and also to offer up its own services to any other software that needed them.

    As you might imagine, this all turned out to be horribly complex and expensive. I happened to work at Oracle at the time that all this peaked, so I had a ring-side seat. The company was selling hugely expensive service management software that was often implemented by hugely expensive consultants. Some of that stuff took off and is in use in some places—usually big IT shops like moneycenter banks. But it never got the ubiquitous adoption that the enthusiasts expected because it was too much work for not enough payoff. There just weren’t that many services to justify the management costs.

    That was roughly ten years ago. Fast forward seven years from then. What is the essence of LTI 2.0? It was essentially an attempt to implement the same idea using the more modern REST style of web programming. It was going to have a strong security model and service discovery. Predictably, it was really hard to implement. A senior development manager from a major LMS vendor—somebody who has been in the industry and involved with the standards process for a very long time—said that LTI 2.0 was by far the most complex standard he’s ever had to implement. If the major LMS providers struggled to implement it, then what are the chances that lots of small LTI-compatible tool makers will implement it? To answer that question, start from zero and subtract a significant number.

    But I don’t think LTI would have had a high chance of success even had it been less complicated, because it wasn’t designed to be a multilateral trade agreement. What problem would a secure service bus with discoverability solve for each of the treaty signatories? The LMS companies do get a clear benefit. For them, many of the customers have LMS systems administrators who spend their days hooking up tools for individual instructors. The LMS gets most of the blame for this situation, not because it’s primarily their fault but because their customers perceive it as a pattern of weakness when they use the product. Automagic integrations would make some of their key stakeholders very happy.

    On the other hand, if you’re a tool vendor, you usually only get blamed for the challenges of one integration: your tool into the customer’s LMS. And even then, the LMS vendor gets most of the heat. At the same time, hardly anybody is passing data to you, and it can be a struggle to even get the LMS vendors to accept the data that you want to give them. So LTI 2.0 offered most tool makers a lot of pain for no obvious benefit.

    The people at the negotiating table for LTI 2.0 were apparently not the right people to negotiate a trade agreement. They were the right people to think of something really cool. For a standard to work, you need the former and want the latter, but only if the people thinking of cool stuff are in close communication with their colleagues who are making the cost/benefit decisions.

    Now, I believe there is an opportunity to get to the cool world that the LTI 2.0 working group envisioned. But to get there, you need to flip the script.

    Services First

    Let’s try another analogy for a moment. In the early days of the telephone, human operators connected every call manually. There was interoperability in the sense that all telephones operated the same way over the network of wires and switchboards, but each individual connection between callers had to be hand-configured. In the early days, that was fine. It made sense. There were few enough callers that it was worth the cost of the operators. But eventually, the number of phone connections grew to the point where hiring humans to manually wire connections was no longer viable for anybody. Call connection times grew, as did service provider costs. At that point it made economic sense to create an automated switchboard.

    LTI 2.0 was an attempt to invent a very fancy automated switchboard at a time when there are still hardly any callers. Once we reach the point where many tool providers are offering multiple data services and, in some cases, also receiving them, then they will see direct benefits from a secure and automated service discovery mechanism. At that point, the negotiations can begin regarding feature richness versus cost of implementation.

    To get there, the IMS needs to flip the script and start by creating a world that is rich enough in services that people need to care more about managing them all. The IMS has made a good (re)start with LTI Advantage, which just adds roster provisioning, grade return, and deep linking to LTI. These are basic hygiene needs. Basically, this means any tool can find out from the LMS who is in the class and what their roles are, which a lot of tools need and is a step up from the way LTI passes user information along now. LTI Advantage can also enable the tool provider to give the LMS links that support single sign-on to specific places within the tool, and it can enable tools to return multiple grades to the LMS. Lots of apps would find these capabilities handy.

    I’ve heard through the grapevine that the next challenge is improving security. Obviously, securing student data is critical. There are a lot of data sharing services that shouldn’t be offered until that security can be guaranteed. (I won’t comment on the security of rostering and grade information in LTI Advantage because I don’t know anything about it, but obviously that is one very sensitive area where schools should be asking questions about security.)

    Once security is in place, the next step beyond that should be to focus on generating enough call connections to keep the switchboard operator busy. I have been arguing for some time that Caliper should be used as a data interoperability exchange standard between apps that operates through the LTI window. This could work for bilateral agreements. For example, let’s say that you want to integrate a blog with an LMS so that posts with a certain tag could be automagically submitted upon publication for a particular assignment. Let’s further suppose that the IMS has not yet developed a standard, a multilateral trade agreement, for that kind of integration. If LTI and Caliper provide tools that make developing that integration easy enough, then the two integrating parties could do the work in the style of an official integration, saving time by drawing on the LTI and Caliper infrastructure that’s already in place. If enough other tool makers become interested in the integration, then it could be submitted for ratification as an official extension of the standard. This only works if designing and implementing a new Caliper profile is easy. But if it’s done right, then we should see the number of services explode.

    At some point, it will become obvious to all parties that they need autodiscovery to manage all these integrations. Then and only then will it make sense to come up with a hopefully simpler implementation of service discovery for the next run at LTI 2.x.

    Open It Up

    To reiterate, the path to getting to the next era of interoperability is to make it easy for many developers to build bilateral integrations that draw on the building blocks of the standards and are easy to incorporate as extensions to the standards. Some of this involves prioritizing the work on LTI and Caliper to make this easy. But it also likely will require the IMS to consider changing its policies in ways that will make some stakeholders uncomfortable.

    A little history is in order here. A bit more than a decade ago, the IMS nearly died. It wasn’t generating enough revenue to sustain the work. While IMS Global is a non-profit, it still has salaries to pay, rent to cover, and so on. Operating it is not free. One of the steps that the organization made to save it from potential insolvency was to put a lot of the work behind a paywall. I don’t like it, but I get it. And it worked. The IMS appears to be much healthier now and has produced some of its best work in a very long time. Life is about trade-offs.

    It may be time to consider a new trade-off. Just like getting the telephone to take off required a network effect—the value of the network increases exponentially with the number of people on it—the value of a world of standards-based services increases exponentially with the number of services on it. To get there, it’s time to at least consider lowering the pay wall. The IMS needs to create an environment with very low barriers to creating standards-compatible integrations. A membership fee, however reasonable it may seem to the membership organization, is a barrier. The IMS leadership should think creatively about how to lower this barrier while maintaining the financial stability of the larger organization.

    The Nub of It

    To sum up, here’s what I think the IMS should do to recover from the LTI 2.0 misstep and foster a step-function change in interoperability:

    1. Promote LTI Advantage and build from there.
    2. Focus next on creating a simple security model that is trustworthy for common use cases.
    3. Focus Caliper efforts on turning it into a quick and easy to use method for creating data interoperability extensions that take advantage of the existing LTI infrastructure.
    4. Make a giant push to get developers to build their bilateral integrations using the LTI and Caliper infrastructure, whether or not they submit those integrations as extensions to the standard. This should explicitly include re-examining policies about giving non-members early access to the work being done inside the IMS in cases where such access will increase the velocity of new Caliper-compatible service generation.
    5. Wait for demand to build on both provider and consumer side before attempting another run at discoverability.
  • The Case for Learning Platform Grade Book

    The Case for Learning Platform Grade Book

    A little while back, I wrote a post reflecting on how close we are to getting a next-generation, modular learning platform and how the next steps in the IMS standards-making process can influence whether and when we might actually see this elusive beast in the wild. Today, I’d like to zero in on what I believe is the next logical step, given the current state of the ecosystem: namely, making LMS grade books fully interoperable with courseware and other ed tech tools.

    No, it isn’t sexy. No, it won’t revolutionize education. But I believe that it will benefit vendors and educators alike in a way that will shift relationships among ed tech tools, reduce wasted effort reinventing the wheel, and open up new design possibilities.

    (more…)

  • A Flexible, Interoperable Digital Learning Platform: Are We There Yet?

    A Flexible, Interoperable Digital Learning Platform: Are We There Yet?

    In 2005, some colleagues and I had been tasked with identifying a single LMS that could serve the needs of all 64 campuses of the State University of New York—from Adirondack Community College to SUNY Stony Brook to the two medical schools. We came to the conclusion that no single LMS at the time could meet such diverse needs. We proposed instead that SUNY should build a modular system from which each campus, and indeed each educator, could create their own fit-for-purpose digital learning environment. We called this idea the Learning Management Operating System, or LMOS.

    We were neither the first nor the last group of people to propose such an idea. We had been preceded by e-Learning Framework, which had been put forth by the UK’s Joint Information Services Committee (Jisc) a year or two earlier. In 2012, Phil wrote about the idea of  Learning Platform here on e-Literate. In 2015, the EDUCAUSE Learning Initiative (ELI) started promoting the idea of a Next-Generation Digital Learning Environment (NGDLE).

    There are some conceptual and implementation differences among these different formulations, but they share two things in common. First, they all posited that contemporary learning environments were insufficiently flexible to meet a diverse range of teaching and learning needs. Second, none of them have been implemented. An upcoming issue of EDUCAUSE Review will focus on NGDLE, in part to try to build momentum for it. I have contributed an article.

    Nearly a decade and a half after the idea of some kind of modular learning environment surfaced, why hasn’t it happened yet? How close are we? What are the barriers? Having recently returned from IMS Global’s annual Learning Impact meeting, I am convinced that we are closer than ever. But how quickly the remaining barriers fall and how well the end result works will depend heavily on what happens next in the standards-making process.

    (more…)

  • UT Austin and SMOCs: What do we know about whether they work?

    In episode 1, we looked at an effort by the College of Liberal Arts at the University of Texas at Austin to develop SMOCs – Synchronous Massive Online Courses – where the core of the redesign centers on the synchronous online experience for large lecture courses (1000+ students in some cases) courses. ((Disclosure: Our e-Literate TV series of video case studies and explainer videos is funded by a grant from the Bill & Melinda Gates Foundation.)) In episode 2, we took a deeper look at how SMOCs work as well as a discussion of high-level course design costs. In this concluding episode, we ask the question of whether SMOCs work, in terms of improved learning outcomes and / or learning experiences.

    (Video source: https://youtu.be/yoIppZ97Ko4)

     

    (more…)

  • UT Austin and SMOCs: What these synchronous courses look like and cost

    Last month we shared a video describing how the College of Liberal Arts at the University of Texas at Austin is taking a different approach than some of the courseware-based or other course redesign efforts. ((Disclosure: Our e-Literate TV series of video case studies and explainer videos is funded by a grant from the Bill & Melinda Gates Foundation.)) In many of these other redesigns, there is an emphasis on the asynchronous elements of lab section and lecture preparation and even fully flipping the classroom (no lectures in class on the course content). In contrast, the UT Austin approach to improving the large lecture course centers on SMOCs – Synchronous Massive Online Courses – where the core of the redesign centers on the synchronous course lecture. Watch episode 1 to get a better feel of what problem they are trying to solve and how this SMOC approach appears to keep faculty in their traditional role, albeit with additional preparation time and video production.

    In this episode, we’re taking a deeper look at how SMOCs work as well as high-level course design costs.

    (Video source: https://youtu.be/MAHm_JU6upU)

    (more…)

  • LMS Is The Minivan of Education (and other thoughts from #LILI15)

    During yesterday’s K-20 learning platform panel at IMS Global’s Learning Impact Leadership Institute (the panel that replaced the LMS Smackdown of year’s past), Scott Jaschik started the discussion off by asking “what is the LMS?”. As I have recently complained about our Saturn Vue that replaced a Chrysler Town & Country, the answer I provided was that the LMS is the minivan of education. Everyone has them and needs them, but there’s a certain shame having one in the driveway.

    The Car Committee

    It’s popular to gripe about minivans, but in reality they reflect what we (the family set with kids still at home) actually are and what we do. Sure, the minivan encourages us to throw everything in the car and continue soccer mom lives, but they do offer great seating, storage, smooth rides (on boring roads at least). Likewise, the typical LMS is in actuality still a Course Management System (CMS), which reflects how courses are organized and managed in large part.

    We’re done with the boring minivan and have moved on to SUVs, but the SUV has morphed into a minivan with bad gas mileage and poor seating. It feels so nice to call it a different name, but it’s still a CMS minivan at its core.

    There are new innovations in the car market, like the Tesla. The risk we face in education is falling back on our RFP-driven habits. Great car demo, but the committee is using a family-driven process.  Item #142 includes having more than 5 seats, with a place for little Kenny’s sippy cup in each. You know what, let’s just make it taller and add a hatch in the back. Item #275 requires ethanol percentages (and we read an article that batteries are risky), so  could you add in an standard engine? Two years later . . . “dammit, the LMS”.

    Put it together, and the LMS is important and ubiquitous, but we all know we need better options. Despite this, take away the LMS and see if students like a different method to submit assignments or check grades for every class. (more…)