You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

The Silo Mentality: It Can Be A Good Thing If You Don’t Do Your Own Thing

Silos: What Are They Good For?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.

Posted in Uncategorized. Comments Off on The Silo Mentality: It Can Be A Good Thing If You Don’t Do Your Own Thing »

Topics in Version Control

versioncontrol-allthethingsThis last month I put together a presentation on version control. As far as I’m aware, everyone I work with uses some form of version control. My purpose with the presentation was many fold. I and a lot of thins that had been prrcelating that I wanted to think about and express. This as an excellent opportunity for that.

Git vs SVN

One thing I know is a sore point for some developers is the idea that git is taking over. There are a lot of people espousing the idea that git is better than svn in every way. This has created a conflict culture because there are a lot of developers making good use of svn and most have heard the primary arguments in favor of git and found the arguments are not compelling enough to motivate a switch.

This is okay.

There is no war on centralized version control, and if there is, the only people pushing it are dumbasses. (This coming from someone who was one such dumbass a couple years ago.)

It’s anti-agile to prescribe something like that. Each team works differently and needs to determine for themselves if the benefits outweigh the costs.

Continuous Delivery

Recently I read a book called continuous delivery. It is a comprehensive blowhard description of how devops “needs” to be. It covers testing strategies, and branching strategies. While a lopsided view of the world, it offered potential solutions that I have found fascinating.

Trunk Based Development vs Feature Branching

This offers not just a workflow that allows for potentially faster delivery, but also a realistic way to use SVN. An alternative to the branching hoopla around distributed systems.


It also gave me an opportunity to talk about DevOps in a reasonably safe environment. It’s a political word at the moment and while I don’t want to get involved in that, I do want to talk about the DevOps movement.

This movement is about working together. Communicating on a level that hasn’t classically been done. It’s there because a lot of the problems we face are due to the fact that in our workflow, we develop a product and throw it over a virtual wall to operations to “handle”. They don’t understand what we need done and we don’t understand what they need done. It’s a matter of sharing knowledge and searching for a deeper understanding of what we’re doing. It’s hard because we don’t want to spread ourselves thin, but in order to deliver a quality product, you have to be more than just a cog in the machine. You don’t have to know exactly “how” to do everything, but you have to have a basic understanding of “what” is happening.

But I digress, I was able to tie this in to version control by talking about how DevOps is also concerned with automation. Creating scripts to do all parts of the deployments. These scripts, this automation needs to be in version control as well. They “can” be in the same repository, or they can be in a separate repository. But managing dependencies, flipping all the right switches, needs to be maintained in much the same way code is controlled. Because it is code.

Database Version Control

And of course, you can’t talk about Version Control without talking about database version control… but this one requires its own article.

Posted in Uncategorized. Tags: , , , . Comments Off on Topics in Version Control »