A Violation of the Prime Directive...

With a nod to the Trekkies, I begin my first post after violating the prime directive of the professional - work hard, play hard. In the pursuit of doing everything that needed to be done, plus some that should be done, I neglected the necessary balance between working hard and purposefully relaxing to recharge and revitalize. That was a mistake, especially since this blog, though normally considered to be work - rightfully so - I consider to be a portion of play.

Bear with me on this one... there was so much to do and such a need for focus that my vision blurred and things that normally wouldn't elude me were evasive as ever. Why is it that the normally formidable combination of working smarter and working harder yielded diminishing results? What are the lessons to be learned here?

One interesting portion of this is that I put in a week of some of the hardest work when I attended IBM's IOD conference, yet that week was one where there was an unusual amount of clarity. I worked basically from sunup until late at night (some would call eating the occasional piece of cheesecake non-work, but it seemed there was always information to take in and try to apply, so I was always reading and connecting). Some of the work was networking, some was bouncing ideas off of others, some was meeting those individuals with whom I needed to forge a working relationship to try to benefit not only our service as a center for education but also the careers of our future and current students, some of it was even having the pleasure of meeting with a former colleague from my Master's program who is now a professional colleague. Whatever the task, though, the ideas and structures and problem solutions flowed as they hadn't in some time.

The answer to my questions, and really also to the conundrum where I had to fire Feng (pls. see the posts from September) lie in the style of the human versus the style of the machine. The human mind is made to form complex thoughts and solve multi-dimensional problems, not to perform routine functions that take time. That second type of activity is why we have computers in the first place. My official title is Lead ECM Architect, not Lead Access Configurator for an Old System, yet lately the limitations of an old system and architecture in use have cost me dearly in terms of the amount of time I have spent literally copying down account numbers that a person was given access to in one application for one of the many groups to which they are attached. It is important that we make sure that people have access to the things they need, and it is something I'm quite capable of doing, but it takes from my work time budget lately about the same percentage of time that my 1-year-old takes from my personal time.

The task I'm bemoaning is something that can be repaired by the proper security architecture, as driven by our unique needs and history, and that is enabled by the software tools we have on hand. There are many advances that have been made in the tools used to manager things like security, and especially in the areas where blended or more flexible security is needed. Careful design and deployment can either add years to your work, or years to your pursuit of higher-order goals; they inevitably lead to either violation of the prime directive, or enjoyment thereof.

My overall point is not to whine about my job - I have to say that now more than ever before it is one I feel satisfaction from , and which allows me the ability to play to my strengths and also encourage my weaker areas along nicely. My overall point is that, as IT professionals, we have a duty to not only push 'iron out the door', but also to do our work so that we enable our systems to play to their strengths and not shoot ourselves in the foot for later.

The return to my weekly pattern of blogging has more to do with the overall goals of my professional life than to my daily 'to-do' list, but it also goes to a final point that has been made on another blog about the continuous improvement that is needed in IT, and in Enterprise Content Management in general. The return to the more suitable problem-solving work and the delay of slowing of the velocity of the 'busy work' are indicative of the new way of work. When I tried to improve things I actually made the mistake of addressing the physical using feng shui, which is analogous to the traditional mistakes of just adding more disk (JBOD - Just a Bunch of Disks) or accepting substandard performance because of a change in platform (I once saw an application that took under two hours to run on the mainframe ported to run on a distributed server, and increase in time to an average of nearly 30 hours - true story! - and it was just accepted, probably because of FUD about using the mainframe and the driving myth that the mainframe was going away).

It isn't about the body, but about the mind. In refocusing the work, I'm actually doing professionally what I've been involved in doing architecturally, which is solving a problem of space and time by shortening space (virtualizing onto the mainframe so that all processing speeds are at bus speeds) and adding more available time, all done mentally (or at least with a different processor design). It is changing the work, changing the tempo and in the process changing the future, adding where there was nothing to add, and consolidating where before there was no time to consider it. First improve the architecture, then improve the physical. That sounds do-able.