Monday, November 24, 2008

Architecture, Alliteration, and Anti-freeze

As we approach the end of the calendar year, we enter a time of festive activities emanating from a plethora of social, cultural, and religious traditions. The once vivid memories of over-crowded parking lots, picked-over store shelves, tired, underweight, uninterested and uninteresting Santa's have faded from a mere twelve months (i.e. 15 production releases) ago. We are left with the thought of mustering up the better angels of our nature to prepare for the end-of-year freeze, where simultaneously work must slow down because production changes are persona non Grata, and yet history reminds us that the 35 days of Christmas beginning mid December and ending mid-January seem to be the busiest of the year. I keep waiting for this end-of-year lull I've heard so much about.

Ah yes, the End-Of-Year Freeze. A magical time in the life of IT professionals the world over. Where Santa has only 24 hours to accomplish miracles, we are given a month to plan, to think, to investigate, problem solve, diagnose, organize, reorganize, refactor, import, export, format, reformat, do, undo, collaborate, isolate, communicate, vacate, rest, test, invest, speed up, slow down, stop, start, restart, code, decode, encode, encrypt, decrypt, analyze, synthesize, scrutinize, sanitise, realize, open eyes, open hearts, open minds, and close the books. Clearly, Santa has the better deal.

The purpose for the end-of-year freeze is to maintain a known, predictable environment where the routine business of processing transactions can occur without the uncertainty and trepidation that comes with surprises; the kind of surprises that come with change. Change to logic, change to configurations, to work flow, appearance, authentication, authorization, or automation. Change must be managed, monitored, measured, minimized, manufactured, and matriculated through a defined process that purports to ensure limited disruption, down time, degradations, and undiscovered devilish details. And the best way to manage change while eliminating surprises is to freeze every single solitary system, application, OS, device driver, utility, suite, protocol, and user interface. Except of course, for that which we don't, won't or can't. Ah the EOYF, as we'd SMS to our BFF.

In a perfect world the end-of-year freeze would naturally be followed by the begin-of-year thaw. This would be a time where new features and function would slowly begin to emerge; first with cautious, careful steps, followed by more predictable replications which would be allowed to mature in a nurturing environment for many months before being exposed to the harsh realities of the real world (a.k.a. users).

Information Technology Architects long for the day when we can retire from sev #1 tickets, problem determination, change control, and anomalous application aberrations (i.e. non-reproducible errors). We would love to have the 35 days of Christmas (or Hanuka, or Kwanzaa, or December-and-a-couple) to ponder loose coupling, high cohesion, abstraction, encapsulation, or even (I can't hardly even imagine the day) polymorphism! It's not likely to happen this year. I suspect that I'll be able to republish this blog (and that last sentence) next year. Of course next year, the previous sentences will be referring to that year's freeze and the year that follows, so I've now started an infinite loop in the freeze-time continuum. Maybe this will show up as a bug some November and require an emergency code push during the freeze. My head hurts.

Architects rarely get to just architect; we tend to be entrenched in high level business requirements down through to implementation-level details. As such, the end-of-year freeze promises to exercise our context switching capabilities like an octopus on ice-skates. We'll be thinking about next year's features, functions, and fortifications, while pondering problematic production problems, anticipating technical training, and explaining emergency exceptions to the gods and goddesses of governance. To be sure the end-of-year freeze should indicate, as the word freeze does in every other context, motionlessness. For us, and our IT brothers and sisters it has not.

Friends, the word freeze is in trouble and it needs our help. It calls to us from the distant past, it calls from the data center, it calls from the confined cubicles of our competent coders, and it calls from our memories. I recall freeze tag as a child; the 'it' person touched you and you had to freeze, stop, lay still, cease to move, or be expelled. Freeze meant the absence of movement. Once touched nary a neuron would navigate, unless you were called by mom. We have the power, the right, and the responsibility to re-establish the meaning and value of the word freeze. Freeze should not simply mean that a change, which during any other part of the year would be considered normal, is merely, simply, and inexcusably tagged as an emergency. Indicating that a normal change request is now suddenly an emergency both misrepresents the importance of the change in question and dilutes the value of real emergencies - it desensitizes the change management system to the critical, highly visible, and truly emergent modifications.

Productions pushes will need to occur during the end-of-year this year ("Danger Will Robinson - the time loop continues!") in support of our businesses. But that is not an excuse for not thinking, not explaining, or not maintaining the most stable, predictable, unchanging production environment possible. Only promote those changes which cannot wait until the begin-of-year thaw of mid January. Fix what you must, test and test again, prepare for the changes you need to implement in the new year, but most of all - let us end the year with the most predictable production processing environment possible.

Follow by Email