The School and the Software Developer

JMSS have much of their eServices in the cloud, or running locally but created and maintained by an external provider. Basically, most things are commodity systems.

Department Systems

The Department tries to provide all systems that a school would need. Unfortunately, being a large bureaucracy, it doesn't do a particularly good job fitting to any one school's needs. Nonetheless, there are certain mandated IT systems in place, which we have to use, or at least interface with. Smaller school tend to rely on these systems due to financial reasons.

Commodity systems

Things not covered by the department, or not done well are often outsourced. This might be a service in the cloud, a service hosted locally but maintained remotely, or hosted locally with support provided. Some of these may fill the exact niche required. They tend to be written by organisations specialising in that type of software or service, so have plenty of experience of multiple clients to go off. Some may fit well enough, or provide some flexibility in their implementation. Others fit well enough at the time of commissioning, but can't adapt to the school's changing circumstances or requirements.

Home-grown systems

Where an outsourced system isn't available, is too expensive, doesn't fit, or isn't agile enough, schools can implement home-grown systems. This obviously requires a developer (or team thereof). While a home grown system can be tailored exactly to the school's requirements (even moving targets), the big down-side is maintainability. Programmers don't come cheap, and sysadmins who try their hand at programming may not be sufficiently skilled in software liffecycle management - documentation, maintenance, scaling. When the person who wrote the software leaves - what happens then?

This leads us to the role of the programmer in the school. There are three options:

1. Settle for a less-than-ideal solution by using a department or commodity system.

2. Work closely with a company to create/modify and maintain a custom system

3. Employ a developer (or team thereof).

While option 1 might be the only way for some schools, I shall not seriously consider it here. Option 2 is a viable possibility, but most software development organisations work for business (there being all the money). They don't necessarily have an understanding of the needs of an education environment. Further, this options requires someone at the school to create a watertight specification of the service required. In doing that, you're half-way to option 3. Before embarking on a school driven software project, however, a spec is certainly needed, and processes need to be in place. Source code management, a documentation system and convention, and succession plan. My preference is for small components that work with other systems (be they home-grown, commodity, or department). Modularity leads to flexibility, and agility.