[Ab]used Leashes

Tina Darmohray, editor of SAGE News & Features, is a consultant in the area of Internet firewalls and network connections, and frequently gives tutorials on those subjects. She was a founding member of SAGE.

I've had several interesting conversations lately that, surprisingly, revolved around pager technology. The first one took place at my investment club meeting between the members and our guest speaker, an investment fund manager. She pointed out that the cell phone market had scared investors away from pager companies, resulting in a deflated price of their stocks. We talked about whether we thought paging technology was dead. Several members of the club are also system administrators. They interjected that pagers are a different technology from cell phones and have their unique strengths. First, pagers allow you to screen your messages; you can return a page if you choose to. But once you've answered a cell phone, you're stuck. Also, pagers can send you time-critical information, whether or not you answer. For example, computers can page people when something is happening: "temperature has reached 92 degrees in machine room E." A wife can tell her husband that plans have changed: "meet us at Italianos'; the kids refused to step foot in the Indian place." Neither of these messages requires a person to answer the phone, but the information still reached the recipient in realtime.

I remember when pagers first came on the scene at my office. Some folks wore them as a kind of "badge of courage"; others made the comment, "I don't do pagers." Both these groups were addressing the concern that wearing a pager often brings: it can turn your day job into a 7x24 operation, with you covering all of those hours! Of course, no one wants that kind of scenario. I know, as a manager, I sought out information from other system administration managers on how they compensated an employee who was "on call" via a pager. I found many interesting approaches. The most common went something like this: "you will be compensated [overtime pay] for scheduled hours that you are on call. On call means that you are within an hour traveling time of the site and provide 30 minute telephone response time." Note that everything is spelled out, including what hours you're on call, which makes everyone a lot happier about wearing pagers. This kind of use of pagers helps groups provide off-hours coverage in an organized and predictable way; it can benefit both the sysadmins and their users.

Another way that my group used pagers to increase our overall sysadmin "coverage" was to enlist them in our plight to justify hiring new system administrators. Hiring justification usually involved the system administrator manager (me) putting together some report on how many tasks are getting done vs. how many tasks are being left undone and how the latter queue was increasing over time. I used to prepare the report and then, inevitably, was asked to present it to the powers that be. During those meetings, my fellow sysadmins would take turns paging the daylights out of me so that the meeting attendees would see, firsthand, that the system administrators were so busy that our pagers were getting hit every four minutes. I suppose the danger in this approach is that unsympathetic managers could choose to stock up on pager batteries, rather than employees.

Of course, I've experienced paging technology at a personal level as well. My husband is tied to a pager. When it was upgraded to an alpha-numeric variety and tied to his email, I found it to be a tremendous benefit. This way I can keep a running conversation going with him while he works (and he can't really fight back). I sometimes take devious pleasure in letting him know the goings-on back on the home front. Recently, I paged him with the news that the children had found a dead rat under the house and that it would be waiting for him upon his return. "Can't wait for you to get home, dear." Before you all side with my poor husband, I'll point out that his pager, set to vibrate, deftly switches to audible tones to warn of a low battery; it's been my experience that that happens around 2:00 am.

It's those "inopportune" pages that cause all of us to question who really benefits from pagers, the person wearing one, or the person dialing one. We often hear the analogy of being put on a leash by getting a pager. My husband contends that a pager, used correctly, can work to the benefit of the wearer. He points out that, as a manager, he can be available for questions without having to be onsite all the time, especially during times his group is working around the clock to get a product out. Sure, he's tied to a pager, but the alternative is to be tied to the office. I guess that makes sense, but it's harder to swallow when he has to leave in the middle of the school play.

Yesterday I called an old school buddy of mine, now an attorney. We had been playing telephone tag for over a week. He finally left me instructions to have his secretary page him if he was not at his desk when I called, which I did. I started the conversation by apologizing for having him paged, because the call was certainly not urgent. He responded that it really was the way he preferred to do business because it made sense. He said, "Hey look, when I get a page, if I'm busy, I don't pick up the phone. I use my pager that way. I think people who don't use their pagers as a leash aren't using the technology to their benefit. So I wasn't busy, and I'm glad you had me paged so we can finally talk."

Of course, I didn't call to talk about pagers, but once he made that comment, I had to ask him what he meant by it. He came back with a story about an unhappy colleague of his who had just spent the entire weekend working on a crunch project for a client who was still furious with her, even though she completed the project by Monday. My friend asserted that her mistake was she had failed to take advantage of pager technology. Apparently, her schedule required that she travel over the weekend, but she had taken her laptop computer so she could work on the plane, etc. However, she didn't know that while she was diligently working, her client was leaving increasingly frantic voice mail messages back at the office. My friend suggested that if she had just had a pager, she could have easily known that her top-priority client was trying to reach her and given him a quick "warm fuzzy" call. That way she could have delivered the goods and kept the client happy at the same time. The analogy that my friend used for pagers was that they are like a leash for a dog. "Without a leash, the dog stays at the office; with one, the dog still gets the work done, but now gets to go out for a walk."

We've all seen the commercials of the employee making the business call from the golf course. I think my friend is right.The first thing we need to get straight is that I am not, in fact, a professional system administrator. You might be confused on this point; I was, until some time last month. After all, I'm clearly not an amateur system administrator ­ I don't think I've ever administered a system for the sheer joy of it. I also believe that my work as a system administrator is of high quality and displays those semitangible qualities known collectively as "professionalism" (as in, "Well, painting the tail-light red with nail polish does meet the legal requirements, but it's hardly the professional way to repair it.")

But over the years in working with SAGE, it's been clear that there's a big comprehension gulf between me and many of my colleagues, often despite mutual respect that verges on hero-worship. Early on in SAGE prehistory, it became clear that you could divide the board very neatly into people who were interested in professional issues and people who wanted to do random things to make life better for system administrators. On one side, for instance, we had the people arguing for a code of ethics and certification; on the other, we had the people arguing for local groups and Web sites with FAQs on them. Each side thought the other side's most important issues were kind of cute, but not really important. We made progress mostly because we found occasional areas of overlap and because the two agendas are parallel. If you have enough people, you can pursue them both without major problems.

However, we occasionally end up in actual conflict. The code of ethics, for instance, is an obvious benefit for some people, whereas I find it at best a harmless idiosyncrasy and at worst an intolerable attempt to control matters of conscience. That's not actually what I want to debate right now, but it is the deciding issue that pushed me back into discussing these matters with people.

And it was in the middle of that discussion that somebody made a key observation. It's these issues, he said, that divide professional system administrators from people who're just in it for the money ­ not that he'd accuse me of just being in it for the money. I hate to shatter anybody's illusions, but I'm in it for the money. I didn't know there was anything wrong with that. As I said, I've never in my life administered a system for the sheer joy of it, and I am roughly as likely to start as I am likely to start playing football for amusement. (Although I must admit my motivations are slightly mixed, I am clearly not in it for the money as much as some people, having reduced a recruiter to a state of near-speechlessness in which he could only gasp, "You're not willing to be snowed on for a quarter million dollars a year?" Apparently, I was supposed to salivate at the sound of the cash register bell.)

Now, I think it's unethical to be a minister just for the money, or even a doctor. I also think it's unethical to do a bad job at something in order to make a fast buck. I think it's unhealthy to care more about money than anything else about your job. But I see nothing wrong with picking any branch of working with computers as an honest way of making a living, doing a good job of it, and going home at night with no particular further commitment.

Partly this is because I grew up in the academic world, where jobs you might admit to having are divided roughly into three camps. There is real work, which involves adding to the world's supply of knowledge. There is honest work, which is, well, most of the other ways of making enough money to keep body and soul together. And then there are a few callings, like ministries and the arts, which you do out of sheer love for it. Being a system administrator, like being a lawyer, secretary, accountant, truck driver, engineer, or waitress, is honest work. The distinctions between these jobs have to do with things like how much they pay, how pleasant they are, and what core competencies they demand. You can lump them together in lots of ways; for instance, you can make a distinction between blue-collar and white-collar jobs, jobs that require uniforms and ones that don't, and sedentary and active jobs.

Apparently, many other people can divide these things into professions and jobs, and most of these people who are system administrators believe that system administration really is a profession and it is important to convince everybody else of it. I am deeply unclear on this concept. It is clear to me that "profession" is a cultural construct, which is high status. Something that is "unprofessional" is bad. Being a professional is good. My grandmother thinks I am a professional because the TV ads for trade schools talk about "highly paid computer professionals." Besides, I have a college degree. My mother-in-law doesn't think I'm a professional, because I have only a bachelor's degree and because in her mind any job you can wear shorts and sandals to is not a profession.

As far as I can tell, that about sums up the state of things when it comes to defining a profession. For most people in the world, system administration already is one: you have to learn a lot of stuff, and you get paid (relatively speaking) lots of money. For the rest of the world, the key indicator for whether or not something is a profession is how much you have to suffer to enter the field, and anything that doesn't involve a long and expensive degree process is just not worth considering. The difficulty of convincing people that what you do is a profession varies according to the social status of what they do, along with its mystique. Try convincing an engineer ­ not a Certified Netware Engineer but a genuine we-build-dams-that-don't-fall-down (often) civil engineer, for instance ­ that system administration is a profession in the same sense that engineering is. It isn't going to work, but when you get depressed trying, you can always amuse yourself by trying the same argument only using any nonmathematical profession (dentistry, say, or being a professor of Romance languages). Or you could try to convince a doctor that civil engineering is a profession in the same sense that medicine is. As a party game, this is kind of amusing, but I have better things to do in real life.

So, it turns out, I am not a professional system administrator. I am still trying to decide what I am ­ a practical system administrator, perhaps.

This opens up the question of what I am doing involved with SAGE, which is "dedicated to the advancement and recognition of system administration as a profession." (It seemed to me that I had seen USENIX describe itself as an association for advanced computing professionals, but we appear to currently settle for "USENIX is the advanced computing association," without specifying who or what associates.) It certainly seems to call into question how I managed to get an award for advancing the profession.

And the answer here may be a certain amount of confusion on both sides. What I consider to be nice, straightforward ways of making system administrators' lives better often strike other people as somehow involving "system administration as a profession." For instance, I'm known to believe that system administration makes a perfectly reasonable career, not just somewhere you go while you're waiting to grow up to be a programmer. I publish about "professional" (i.e., nontechnical) issues. (The idea that a squeaky octopus is more of a professional issue than a sendmail.cf file strikes me as a trifle bizarre, but if you divide the world into "technical" and "professional," that's what you get. This may help explain some of my confusion about the entire question.)

I am interested in advancing system administration. I consider the question of whether or not it's a profession somewhat lower in interest than the question of how many angels can dance on the head of a pin, which has a long and honorable history. I think it's naive to believe that it would reduce the political battles, or make people more willing to hire the system administrators that they need, if system administration were widely considered a profession. (Health maintenance organizations seem to have no problem treating doctors with disrespect and understaffing.) I think it's downright offensive to believe that it's necessary to be a professional to deserve respect.

I am therefore going to wander off in my unprofessional way, doing what seems to be the right thing; I invite everybody else to do the same, even if that's making system administration a profession, as long as they promise not to assume that being a professional is an inherent good that should be obvious to everyone.

This article presents my understanding of the state of, and my proposed direction for, SAGE education and certification efforts. It may be the basis for communitywide discussion and implementation of these programs. Questions and comments may be submitted to this forum or directly to me <[email protected]>.

One of the charter goals of SAGE has been to address the educational requirements of its membership and of system administrators as a group. The details of our profession have been thus far learned almost exclusively on the job, generally in a rather haphazard manner. There is no widely accepted method of determining what an individual knows. We as a guild are united (as strongly as we are ever united) behind the idea of promoting a consistent education program to ensure a minimum level of qualification.

A second, less clearly defined goal, has been to create an industrywide recognition program that provides employers an indicator of the training levels achieved by current or prospective employees. What that recognition ought to be and how it might be effected have been a murky swamp, with no consensus or agreement.

Both these goals have inspired conversation and debate, sometimes intense. Neither has resulted in implementable plans or programs to date, partly because they are "tough problems" that take a lot of work to solve and partly because the organization has been busy with formation issues.

SAGE is now in a position to address these goals. Given the apparent industry demand, and the number of vendor-specific education and certification programs now available, this has become time-critical and requires immediate application of SAGE organizational and individual resources.

I define two types of education for the purposes of this article: formal and on-the-job. I also define two types of certification: topic and comprehensive.

Formal education is generally carried out in the classroom or by correspondence. It follows an "accepted" or "standard" curriculum or course of study and employs qualified instructors who present information and monitor progress. It covers theory, background material, and methods of application to practice. On-the-job training (OJT), or informal education is usually carried out in the workplace, either managed by the student directly or mentored by a more seasoned professional. It emphasizes the practical. OJT might be accomplished in an apprenticeship program, correspondence course, or nonstructured individual training.

Comprehensive certification is what most people think of when they hear the term "certification." It is common in many professions and demonstrated by examples such as a license to practice medicine, dentistry, or law, a P.E., or a journeyman's certificate for electricians. These are widely accepted, and they cover large numbers of topics. Topic certification is limited in scope to one or two topics and is acceptable only to those organizations for which the specific topics are applicable. Examples of topic certifications are those given to automobile mechanics for brakes, emission control, or air conditioning service.

Vendor-specific system administration recognition methods, such as the Certified Network Engineer from Novell, or the new Sun Microsystems certificates, are a new and relatively limited form of "certification." They are not truly "topic," because they cover multiple topics. They are not "comprehensive," because they cover things from only one viewpoint and include only topics relevant to that vendor's hardware or software. This is a trend that could result in large numbers of similar programs, each limited to a given vendor, none of which would be really applicable in the standard heterogeneous site, but would be sufficient to convince some companies to require one or more from their sysadmin candidates.

A number of building blocks must be engineered and constructed in the development of education and certification programs for system administrators. There is a natural pyramid resulting, built of a series of interdependent project areas, each of which has its own reason to exist (see Figure 1). Blocks of the higher levels require those of the lower levels as prerequisites. At the base of this pyramid is the description of our job. Next comes a definition of ethical considerations that shows something about who we are. With these, we can develop an acceptable definition of a system administrator. We then tackle the training for the job as de-scribed, for both on-the-job and classroom education. Once we have all these blocks, we are ready to debate the merits of certification, then, if we are going to proceed, to define programs for certifying sysadmins, first, on a topic-by-topic basis, then in the comprehensive arena.

We already have the foundation block in the jobs descriptions booklet. This has proven immensely successful in its own right; plus it gives us the starting point for this pyramid.

There is now a code of ethics document. Debate on what it means has not subsided, nor will it stop for some time to come. We do, though, have a base from which to proceed.

Many attempts have been made to capture in a sentence or two the definition of a system administrator. One of those attempts may eventually fit our need, but thus far the "real" definition has eluded us. Our daily jobs encompass many disparate areas.

The best available definition of a system administrator, so far, is one who, as a significant part of his or her job function, manages the operational and data integrity of networked computing systems for use by others.

We "know," as a community, what sort of OJT is required to train a working sysadmin. Documenting this and drafting a program to standardize, publish, and monitor OJT are currently under way. A Short Topics booklet will be out soon that will also define a core formal curriculum. A number of universities are already teaching a course or series of courses, all of which are acting as proving groups (as well as supplying new sysadmins).

The Executive Committee is looking at a proposal by Pat Wilson (using the working title of "merit badges") that provides guidelines for teaching/learning pieces of the job independently of other pieces. Such a proposed system now gives us a few task area descriptions/checklists, and others will trickle in as they become available. These tasks both stand on their own to teach individual subjects, and begin to aggregate to form a larger education program. The system allows us to field-test and apply the lessons learned. This proposal lends itself well to the "topic certification" role, providing the framework for a recognition program without the attendant legal and political baggage. This recognition/certification by-product allows us to develop and field-test ideas that may eventually make their way into a "real" comprehensive certification process.

With a formal curriculum established, the OJT commonplace (thus covering both parts of the education dichotomy), and clarity with regard to the job definition, the time is right to begin the review of what certification means, what it doesn't mean, and implementation options. We will soon have practical experience, and the benefit of working programs of education and "minicertification."

System administration is not a statutorily regulated profession, as are the medical and legal fields. Those require certification in order to practice. They require adherence (including "word of honor") to a code of ethics. What we are building is different. No sysadmin will be required to do these things in order to perform the duties, use the title, or even become a member of SAGE. The purpose of these programs is to advance ourselves as individuals and as a group, not to regulate the membership.

We are at this point pursuing further clarification of the code of ethics and the codification of the merit badge proposal into a workable program. The next step is to lay out certification definitions, the pro and con arguments, and options. One of those options appears to be to set up a comprehensive plan based on various combinations of topic certifications. Results of that definition exercise will find their way to the membership soon.

We are dangerously close to being "too late" as the number of other bodies and vendors offering both education and certification increases. We must not sit idly by, but continue to press forward.