This is the way to scale ELMS Learning Network to support the needs of institutions of any size. The method to do so, is to align deployment architecture with organizational structure. This simple change while radically different then how educational technology deployments happen, is how things happen every day in nature and other human hierarchies.
Drupal Doesn’t Scale
First, let’s dispel a FUD (Fear, Uncertainty, Doubt) based notion: Drupal doesn’t scale. Let’s look at this statement. Thing doesn’t scale. This is simply false. In technology deployments, your desire to scale is aligned with the finances and team you are willing to put at it. Anything can be scaled, it’s if you know how. So please, don’t tell me what we’re doing doesn’t scale or can’t scale, your flatly, politely, wrong. I share your concern of scale and as a result I think you need to contact The Whitehouse, The Grammies, Weather.com, PSU.EDU and others and tell them “Hey million hits per day website owner; did you know this doesn’t scale?”
Crushing the Committee Deployment Paradigm
Now let’s look at our approach to scale for when I tell you that we can easily scale to meet the needs of not just this university, but any organization of any size. We do this by attacking the empowerment paradigm of institutions. As we know (but have previously never spoken out of FUD), institutions purchase things incorrectly. So let’s reshape this notion of scale by crushing the committee paradigm.
You have 23 colleges represented in a room. They all say “We need a video management solution”. So you come out (historically) after many months, with a solution: “If we just buy vendor X product, it will do what most of you are talking about”. It takes a year or two to select this product, another 6 months to pilot, only to find it either doesn’t work or won’t meet the needs of all (but hey, 70% is better then 0).
An alternate reality: “Land Grant” 2020
Let’s rework this using the structure of the institution and aligning the deployment methodology against it shall we?
You have 23 colleges represented in a room. They agree upon 50% of what a video management solution needs to do. You create 3 options:
- Central – No control over what it is, you take what you get
- Decentralized – Local deployment, some influence but also lack of control of some areas
- Developer – Total control, no outside update or influence
The groups that agree to pay X dollars into the pot, get their own localized, modifiable copy of the Video management solution. Jenkins (an open source automation robot) sets up their replicated copy of the original “product” that central helps manage. In the future, there is no central management, there is the person that manages Jenkins; central management has been largely automated. Central gets the control of security and quality required via the robot, but the local units that can afford adoption, have their own local copy to run.
Because of how this works, developers in a distributed manner can now contribute back to the Video platform by working completely disconnected from working production instances. These contributions at the local level, give the colleges control over the system (what they needed) while allowing for contributions to bubble back up from the college to the central level. Through iteration, actual on the ground use-cases and collaboration, you form consensus around the next 45% of the system. This leaves you with a decreasing percentage of centralized product that doesn’t meet needs, while allowing the entire university community to have engaged in the process. Don’t engage? Well then you get what’s made by those that do (Open Source is a do-ocrasy).
Effectively, the colleges of the university form distributed innovation nodes which allow them to run ahead of what a central authority could have done; while still benefiting it over time. This already happens places right now but is typically referred to as bad apples and chaos. Our empowerment and control structure built on automation forms Structured Anarchy — The distributed nature of everything with just enough structure to maintain order and prevent devolving into chaos.
Mirroring the form of the institution over time
Four years from now, trends shift. Two colleges merge, two others are formed to address new trends, two others collapse and are eliminated. These are different button pushes in an automation system. Use case one merges ELMSLN deployments (weird, I thought this was a video example; oh, we’ve got that too).Use case two is click a button to build out their new deployments, Use case three sees their course snowflakes merged back into the main central version while their localized copies are killed off.
In this model, we always have a central copy, but is naturally (because of diminishing variability as a supported base increases) is less flexible / feature robust then the innovation nodes found in our colleges, departments, and yes, individual faculty members running their own learning networks. How do we maintain consistency? Automation. How do we maintain “control” while democratizing deployment methodology? Automation.
This model will resolve conflicts, increase faculty / staff satisfaction with solutions which will in turn lead to better, more timely solutions across the organization which will increase student satisfaction with college experiences.
How do I know? Where’s my evidence? Come see us doing it daily where I work. It’s incredible working here, maybe you should think about joining us in the transformation of education. See you in 2020.