Planning scalability

I received a message a few days ago from our student information system vendor. They let me know that the system would be down from 4:00 in the afternoon until 6:00 the next morning so that they could install new servers to handle increased utilization.

I received a message a few days ago from our student information system vendor. They let me know that the system would be down from 4:00 in the afternoon until 6:00 the next morning so that they could install new servers to handle increased utilization. As it turns out, other school districts have figured out they have a really outstanding product and, not surprisingly, are migrating to their servers. Similarly, it is far more cost-effective to have them host the applications than to host them internally, so again, more migrations.

As a result, all of their customers were experiencing some performance issues. The switch to new servers would have been welcome had it not been occurring the day before school started. This left us wondering just how functional the system would be when we walked through the door, ready to take attendance and field a deluge of scheduling changes.

As it turns out, not very functional. An unexpected hardware issue with the new servers brought performance to a slow crawl for most of the first day, much to the horror of my front office secretary, the guidance counselors, and the queues of students waiting to fix scheduling problems.

The story has a happy ending, since by the afternoon performance was better than ever and all seemed well with the migrated data. However, it didn't make for many happy users; talking with the tech support folks later in the afternoon, the sound of their voices suggested that they didn't have a very fun day either.

If the story has a happy ending, what's the moral? The moral is twofold. First, every IT project takes twice as long as you expect. Don't let any IT guys tell you otherwise and, if you're the IT guy, plan accordingly. Second, plan for growth before you outgrow your systems. I learned this the hard way as my two labs of thin clients went down last spring because I ran out of disk space. I badly miscalculated the requirements of Windows user accounts. Same goes for a computer lab into which we squeezed 5 extra machines. Every time that last computer turned on, half the wing went dark. It took an electrician and a thousand dollars to fix that one. Live and learn, right?