As for that matter, I ask myself: how much time did I waste as a junior sysadmin in charge of the systems so many years ago, technically proficient but naïve in the reality of business, because I didn't know what needed to be done and I couldn't structure my day? Procrastination through reading net comics didn't help the business and it certainly didn't help my self-esteem. What should I have done?
Here is the executive summary of my answer for the impatient:
- Write down a list of what you are responsible for ("service portfolio")
- Using the portfolio as a guide, write down out what, if you mess them up, could break the things you are responsible for ("change management system")
- Set up your email
- Get training / read a book for the most critical service you are responsible for if you don't have it already.
This winter, my company was kind enough to send me on an Information Technology Infrastructure Library (ITIL) course. ITIL, a trademark from OGC, is a compilation of best practices in IT management, researched over three decades. I believe this is the framework through which I will grow my company's IT without making Athena over into a Hydra. Yes, ITIL has its critics, but for someone who has no framework at all, it can inspire. The ITIL books are expensive, however, and the literature is hard, hard, hard!
Before taking the course, I had already started going through the second book in the series, "Service Design." English is not the native language of the researchers and, although the information it gives on structuring an IT department is infinitely valuable, the book itself suffers from structure problems. It is a reference maze with traps. This sad fact, along with its CAD$700 price-tag for the series, can make it inaccessible to the junior or intermediate sysadmin.
The publication did mention quite clearly that one of the toughest things to do is actually get ITIL started. It asserts that existing pre-ITIL services such as email or shared filesystems are already doomed to be en eternal headache for their admins (I disagree). The continual service improvement (CSI) of these services is, by its very nature, circular: no entry point, no exit. The solution that comes to mind quickest -- redesign a IT service in order to design and fire up the ITIL processes -- won't work: those ITIL processes need already to be started and their tools implemented to tie in the service. Holy catch-22, Batman!
On top of this, my experience with small and medium companies is that the bosses don't have the time or inclination to play ball.
I needed that course.
A Good System is Grown, not Imposed
So where would one start? How does a simple accountant-turned-sysadmin set up what looks like a complicated ITIL framework for a simple office? Does she really need to?
Unfortunately, since the course was a simple overview, no more than a quick two-day survey, the devil in the details weren't identified although there was some in-depth work on running a help desk. The consultant/instructor, an excellent and experienced lecturer, did say that out of the almost 30 ITIL v3 processes, the one he would start first is "Change Management" (CM), followed by "Financial Management." Change Management is the process by which a business is assured that the components of a system are altered only if the business needs it, everyone who matters is cool with it, and nobody who uses the system gets a nasty surprise.
How complete should the CM process be made? Not very, to begin with: a company needs to grow in its ITIL maturity. A completed ITIL process, not tied to any other processes, is just bureaucracy without benefit. The ITIL books gave a hint by displaying a diagram of company ITIL maturity levels. Level one is no ITIL set at all. The second is the recognition that ITIL exists at all. The third is basic lip-service to each process, no more.
So why shouldn't we set up CM completely from the get-go? I state again that the biggest problem for the small- or medium-sized business is that the senior management who need to approve such a complicated project won't have the time or patience to learn about a complicated framework, no matter how much it will smooth the works of their company. Add to that the sysadmin's habitual lack of time for projects and, of course, the lack of funding. A fully created CM processes, with all the tools present, requires more time for interviews, role assignment, tool testing and installation -- to say nothing of training -- than one can reasonably afford.
So does the new sysadmin want to implement this stuff? The instructor was quite clear: a company needs all the processes to smooth the way for the sysadmin and the people he serves. However, the starting sysadmin wants to start from level zero.
I disagree with the instructor on what process to start at level zero: setting up CM (other than writing a big black "Don't Touch Anything" sign) won't help if the poor accountant I mentioned above doesn't know what she has inherited.
How to Break into ITIL
As the instructor said, set up the processes, but with only the basics in place. The lovely thing about basics is that basics really do not need to have senior management approval or funding (thank you Open Source developers!). They can be grown by the sysadmin in his spare time, and the benefits will be realized almost at once. Once the basics are set, they can be grown further at leisure.
So how basic is basic? Where is the line that says "too basic to be useful?" Where is the line that shows "too complicated; you are wasting your time?"
The First Steps for the New Sysadmin
Before we start the practical stuff, look to the abstract. Stephen Covey, the famous author of Seven Habits of Effective People, says "start with the end in mind." Develop a mission statement for your job. Of course, the new sysadmin might be too wrapped up in the newness of everything to come up with a credible mission statement (mine is"grow my IT into a reliable service that is predictable, simple, flexible and unnoticed"), but at least some sort of goal might be established in her mind.
Next, go from the abstract to the concrete: I say that before tackling the processes of system administration, one must set up some basic tools as defined in the books "Service Strategy," "Service Transition" and "Service Operation:"
- A service portfolio, just the bare essentials. This doubles as a sysadmin's job description and it is a good one, believe you me. As the service portfolio expands over the years, one can track how one's job has altered without feeling like a mote in the ocean. In the smallest networks, a spreadsheet might suffice.
- A configuration management system (CMS), based upon the service portfolio, once again with just the basics. One can use a spreadsheet for a small system.
- A service desk application to control the inevitable requests, configuring it based on what one has learned in establishing the service portfolio and the CMS. This may be as simple as setting up folders in one's personal Outlook or Lotus Notes.
- Get training. Choose the most critical service, look at its component list (in the service portfolio) and its configuration items (in the CMS). Learn it and experiment with it on an old discarded laptop, even if you have only the budget for books.
À bientôt !
