The Silo Mentality, as defined in the Business Dictionary, is not new nor confined to business. Silos are prevalent in all aspects of Academia, and having them around is generally considered a Bad Thing. Take a certain University in Cambridge, for example. It’s a big place. A huge place. With many different Schools, consisting of many different administrative and academic departments, each consisting of many different groups. Not to mention libraries and museums and other centers of learning. It’s a cornucopia of conflicting visions, motivations, and group mentalities, all of which are somehow supposed to work together toward a common mission of education and research (which, in themselves, are at sometimes at odds with each other). Having each entity operating by itself, looking inward rather than outward, seems a recipe for disaster.
A disaster it can certainly can be, and there is often great expenditures in time, money, and people to break down silo barriers. For those of us in Educational Technology, the proposed wrecking balls are often getting everyone onto the same Learning Management System (LMS), the same calendar, the same email, the same network, the same software and hardware and computers and . . . the list goes on and on. For administrative functions, such as calendaring and email, this approach makes sense. It’s incredibly difficult to operate with different calendaring and email systems. Even using different version of office software or operating systems can make a mess of things (I’m looking at you Microsoft Office for Mac and Windows!).
So I can understand why academic organizations such as University IT may want to centralize, well, everything they possibly can, including environments for software development. I’ve heard many of my co-workers and leadership say things like, “We should all be using Java” or “We should all be using Git” or “We all need to be using Agile Software Development.” At the surface level, such decisions make sense. If everyone uses the same tools and possesses a similar skill set, then you have an excellent pool of resources that can look out for each other. If one person gets sick or gets hit by that proverbial bus, someone else can jump in. You can shift people on and off projects more efficiently. Getting up to speed is faster. Yes, there’s lots of good stuff there.
Such a centralized approach may be good for a small business or even a small school, administratively. But in Higher Education, even at small schools, the breaking of barriers argument quickly implodes when it comes to academic needs. This is because Higher Education is, by definition, about academic freedom, and it’s this freedom, as ironic as it may seem, that builds the silos in the first place. The building of silos, in fact, is inevitable and necessary.
As an example, take software development for pedagogical tools, an area my group is intimately familiar with. Unlike many of the software development groups within our parent organization, we do not focus on the development of enterprise-wide applications that cater to a common need across multiple organizations; we develop software on a much smaller scale over a much more diverse range of needs and, hence, technologies. Additionally, we are responsible for helping faculty and students stand up their own software, which usually involves a different technology stack than our own. So unlike some of our counterparts, we cannot be confined to a single language such as Java or Python. We cannot be confined to single deployment infrastructure. Such confinement inhibits the academic freedom of students and staff. We are, by necessity, different from other groups. Separated. A silo.
This is not a Bad Thing. Our educational technology group needs to operate differently from enterprise groups–such as, say, the Registrar–just as the enterprise groups need to operate differently from us. Maintaining these silos is a Good Thing. It’s isolating the silos from each other that causes problems. Since our group is building course ware, we are often interested in accessing student data. It would make zero sense for us to have our own set of student data when we should be utilizing the information managed by the Registrar. If we did our Own Thing, that would be isolation.
It’s isolation of silos that causes people to start waving around those wrecking balls of centralization, but removing the silos all together is missing the point of academic freedom. Rather, bridges need to be built between the silos, conduits of communication and best practices that allow the silos to act as a cohesive team. So how does one go about doing this? We’ll explore some possibilities in an upcoming post. Maybe. Assuming I write it.
