The title of this post was also the title of a talk by Barbara Taranto, the Director of the Digital Library Program at the New York Public Library at yesterday’s FIT conference. I just love it. An “education inflected architecture” is exactly what I crave. But beyond that, Barbara poses exactly the right challenge:
For faculty and the organizational structures that support their work, it has been a bit of a rough ride –mastering new tools for collecting, analyzing and organizing information and at the same time accepting the responsibility of managing the outcome of all the collecting, analyzing and organizing activities that so persistently carry on. But for software developers, including some very prominent academic ones, it has been a free-for-all, an ideal market for real life R&D. Every week, or perhaps even every day, there is a new tool or a “better way” to do one’s job, a new piece of software to have and to learn and to use, a new widget, gadget, and for some, a new toy that needs no marketing other than to say it is a solution to a problem we didn’t know we had. And so for a very long time the focus of administrative activity has been on this shifting, volatile environment and how best to adapt to the “new student” and how best to create the “new university” in order to meet the needs of the “users”, generic-faced as they may be, even when the idea of the new university is not even well articulated by its greatest proponents.
But amidst all the busyness, the balance and direction of the academe seems to have moved beneath our feet. The lauded best practices of instruction and research are often driven by software development and the overbearing individualist psychology of the consumer rather than by any higher purpose. We are encouraged qua instructors to describe our work –even our passion– as a “service” to others, and to proscribe future work as a functional unit –an economic widget; and qua researchers, to insist on further resources to meet our individual needs. In my mind, the model is dysmorphic and very possibly unsustainable–certainly undesireable. I suggest that for education practice to right itself, to flourish and evolve, and for students and academics to get back to the work of learning we need to shed the technology carapace and develop a new education inflected archtecture.”
To sum up, we have to stop deciding what we’re trying to accomplish based on what our tools make easy (or hard) to do and start deciding what our tools need to look like in order to help us with what we’re trying to accomplish. That’s…well…a lot harder than it sounds. Because computers are essentially stupid, they force us to explicitly map out even the very basics of what we’re trying to do. It’s easy to make these maps incompletely or even inaccurately, in part because some of what we’re trying to articulate explicitly is inherently tacit knowledge.
So what to do? I think we need to fundamentally change our software development practices. Agile development, a family of development techniques that seeks to tighten the feedback loop for developers so they don’t drift too far into theory land, certainly gets us part of the way there. My experience with software development teams creating applications for which they themselves are not the primary users is that they are best not left unsupervised for long periods of time. But I think we need more, too. Barbara is right: we need an education inflected architecture. Or, to put it another way, we need an architecture that can be inflected (or influenced, or evolved) by educators.
In a recent four–part interview, JotSpot CEO Joe Kraus gives us some hints as to what that might mean.As Kraus points out, one critical strategy for increasing user-driven and user-centered innovation is to lower the wall that separates users from developers. He makes the analogy to Microsoft Excel as a breakthrough financial application authoring environment.
Before Excel existed, if you wanted to build a financial app, it was just like web-based programming today: You had to find an expert. Obviously, spreadsheets existed before VisiCalc, but they were on chalkboards or whiteboards, and it was a bitch. You erased and penciled in, and if you wanted to make an electronic version, you had to get a Cobol programmer, wait six months, and then get back something that usually wasn’t quite right.
As a result, you didn’t do many electronic spreadsheets: They were silver bullets that you fired infrequently. But when Excel came along, it enabled end-users to do what had previously been the realm of high priests. And it enabled another class of programmer-a less technically skilled programmer-to do even more interesting things. End-users could do basic stuff-put things in rows and columns or cells and maybe do some formulas-while another level of programmer (for example, a financial analyst) could do macros and crazy stuff. When this happened, a thousand million billion spreadsheets bloomed. So Excel lowered the barriers to creating financial applications.
I believe that this strategy is one of the secrets to Moodle’s success. Their architectural philosophy can basically be summed up as the KISS principle. As a result, many teachers are able to become active participants in development, resulting in the rapid proliferation and refinement of high-quality teaching tools.
Now, there are trade-offs to this approach. Moodle’s strength when it comes to teaching tool development is precisely its weakness when it comes to enterprise (or academic) systems integration, scalability, and so on. Moodle is optimized to be run and maintained as a guerilla installation by a single non-technically-inclined faculty member on a simple web server. While it wouldn’t be fair to say that the Moodle community hasn’t put significant thought into scalability and integration issues, I would say that the design requirement for ease of tinkering throughout the entire Moodle architecture imposes pretty significant limitations on the software’s ability to scale in various ways. So I think it’s important for an education inflected architecture to distinguish between the user-facing layer, which should be optimized for easy “tinkering”, as Kraus puts it, and the develoepr-facing layer, which should be optimized for ease of integration and scalability. As far as I can tell, this is precisely what Jotspot does with their application.
Another important point that Kraus makes is about the need for a focus on integration:
It’s pretty clear to me that web-based programming is actually becoming more and more about integration and less and less about building anything. What’s interesting about the open-data trend is that it reinforces this notion that it’s going to be faster and faster to build things. But the real heat of web services will happen in the consumer space. In fact, you can already see it happening in the number of businesses built on top of Flicker and the ecosystems built around Amazon and eBay: This is the new model.
The trend in web-based programming is integration, and it’s enabled by open data-that’s the feedback loop. The more people who want to do web-based programming, the more they’re going to want to integrate. This in turn will force companies to open up their data, which will enable even more web-based programming. That’s how the engine gets started.
If we really want an “education inflected architecture” then we need to relax our core notion of “architecture” somewhat. Software developers “architect” programs. Users grow them. I add formulas to my spreadsheet as I need them. One way to do this, beyond optimizing the user-facing software layer for “tinkerability”, is to optimize it for integration. If somebody built a tool that I wasn’t thinking about when I built my system, I don’t want to be forced into the suboptimal choice between using that tool as a stand-alone and re-inventing the wheel within my closed, architected system. I want to be able to pull that tool in, play around with it, and either keep it or throw it away, as is appropriate.
