Hi,
> Stephen Potter wrote:
>> (Since this is a discussion of what LOPSA should do regarding
>> professional standards/certification, I will invoke the standard
>> board member disclaimer that I'm speaking for myself and my
>> opinions, not for the Board or the organization)
>>
>> This has always been more of my idea of what we should do for
>> certification. Most professional certifications ("Board Certified")
>> require four parts, not all of which are under the direct
>> control/supervision of the certifying organization:
>>
>> 1) Completion of a recognized degree or other core subject
>> educational curriculum (technical certification)
>>
>> 2) Demonstration of professional experience, such as an intern
>> program or apprenticeship
>>
>> 3) Professionalism or ethical training and certification
>>
>> 4) Registration, fee
[Following Stephen's lead, as a member of the LOPSA board consider these
my personal opinions, not that of the Board or the organization.]
In the engineering world there are a few levels of what I'll loosely
refer to as certification:
1) Obtaining an engineering degree from an ABET-accredited program
2) Passing the FE (Fundamentals of Engineering) exam
3) Passing the Professional Engineering (PE) licensure exam
System administration as a profession or field of study is not yet at
(1); while there are a few institutions teaching system administration,
there's no agreement or standard as to what should be part of a sysadmin
curriculum. I mentioned ABET - the Accreditation Board for Engineering
and Technology - their role in this process is to set curriculum
standards, evaluates educational programs (departments) to ensure
they're covering the standard curriculum, and to maintain the list of
accredited programs.
In the past few years, the engineering community has started looking
beyond their traditional insular cloister of brick & mortar programs
(mechanical, civil, chemical, electrical) toward computing programs and
to that end, ABET actually does accredit IT programs (see page 9 of
their proposed 2009-20010 Criteria for Accrediting Computing Programs
<http://www.abet.org/Linked%20Documents-UPDATE/Criteria%20and%20PP/C001%2009-10%20CAC%20Criteria%2012-01-08.pdf>)
Currently accredited IT programs include:
Brigham Young University
University of Cincinnati, OMI College of Applied Science
East Tennessee State University
Georgia Southern University
University of Missouri-Kansas City
Purdue University at West Lafayette
Rochester Institute of Technology
University of South Alabama
United States Naval Academy
A necessary first step is to develop a standard sysadmin curriculum,
probably by surveying existing programs and considering the needs of
employers as well as practitioners.
A few years ago at LISA (Atlanta?), Mark Burgess held an accreditation
BoF and tried to explain the process of developing a curriculum. It
boiled down to writing the canonical tome of all things sysadmin, very
much akin to "The Computer Science Handbook"
<http://books.google.com/books?id=9IFMCsQJyscC>, a monstrous 2700+ page
tome of all things computer science. It's one of those awful unreadable
semi-reference books put out by rat bastard bloodsucking academic
publishers like Pearson or Elsevier or CRC Press. The book retails for
$150 or so; I got my copy at Half-Price for $20. And while the book does
not cover the cutting edge, it covers damn near everything relevant in
computer science well enough that one could pull a curriculum out of it
without much effort.
There was a lot of pushback at Mark's BoF. Some people didn't see the
need to produce an expensive and immediately out-of-date reference book
that no normal person could afford and that no normal person would read.
My impression of Mark's position was that even though the book would be
time-consuming to produce and would in most cases rot on a shelf, it was
absolutely necessary for it to *exist* if only to be used as a
bibliographic reference as a first step toward creating a standard
system administration curriculum, the curriculum being necessary for
departmental accreditation and achieving step 1) above.
My jaundiced view is that there was a lot of willful ignorance and mild
anti-academic sentiment in the room, but that's generally to be expected
when you bring up hot topics like certification and licensing.
Regardless - one way to set some quality control standards on sysadmins
is to graduate people with an accredited degree in the field. It should
cover basic technology, common issues, and skills necessary to be an
entry-level sysadmin.
----
Back to the original comparison with engineering: one can comfortably
practice engineering with no more than a BS in the appropriate
specialty; the degree is essentially certification. Further, there is
some work you cannot do without an engineering degree from an accredited
program, specifically 2) & 3) above (i.e. obtain professional
licensure.) I'll lump both 2) & 3) together because 2) only exists as a
prerequisite to 3) and 3) is really what matters.
There are certain classes of work that can only be performed by a
licensed professional engineer, generally those relating to the health,
safety, and well-being of the public. The software industry has been
lucky thus far that so few people have died because of bad coding but as
software & firmware works its way into areas formerly dominated by
mechanical and analog controls, there will be greater emphasis placed on
quality assurance, compliance, and liability; it may not happen in my
lifetime but I firmly believe UCITA's days are numbered. History is on
my side.
Professional licensure and engineering standards were driven by the
insurance industry back when any ol' jackass could sell a steam boiler
or install petroleum piping. I won't bore you with the details of
history suffice to say that insurers were tired of paying out for
exploding buildings and boats and the resulting widows and orphans. They
basically ratcheted Congress into regulating who could do what after
decades of industrial whining and hand-wringing about the cost and
"stifling innovation" (where have I heard that before...?)
And yes, that meant that a bunch of people who called themselves
engineers were driven out of the marketplace; on the other hand, the
number of exploding boilers dropped, and the death and morbidity toll
went way down.
At present the legal situation isn't such that there's a requirement for
professional licensure of sysadmins. SOX is probably the closest we have
to such regulation and even then, it's not clear that SOX even does what
it was intended to do. It only considers the societal ill of gaming the
financial system and as we've seen, you can be completely SOX-compliant
and still screw the pooch. HIPPA and FERPA only deal with privacy, and
safety-related software packages are probably regulated under the
auspices of the field they're used in (I'm in the middle of at least
three code qualification efforts at work.)
This leaves us with the problem of ensuring the quality of systems, be
they software, networking, database, whatever. These systems are only as
good as the people putting them together, and even then (see "The Limits
of Software" <http://books.google.com/books?id=8a1QAAAAMAAJ>)
Industry responded with commercial technology certification though it's
of uneven cost, utility and quality. ITIL
<http://www.itil-officialsite.com/> and others have tried their hand at
certifying IT management, process, etc. but I'm not sure who actually
uses ITIL.
Those take care of certifying low-level technical skills and high-level
managerial skill but don't address the middle-tier of system analysis &
designing or the skills you need to evaluate a technology. Those are
skills that I believe would come out of an accredited degree program,
and I don't see a sysadmin curriculum becoming pervasive and
standardized anytime soon. Further, such a program does nothing for the
people currently working in the field.
So what to do?
Richard Chycoski wrote:
[...]
> If we're to get the industry to buy in to a certification, we need to
> show that this is a truly professional certification - not based on a
> particular product or technology, but based on principles of systems
> administration that apply across platforms. Individuals might still
> specialise in a particular platform (just as engineers, doctors, and
> lawyers specialise in particular areas of their profession), but the
> basic principles are really common to all technologies, and these need
> to be learned by all types of systems administrators. If you put me in
> front of a *nix/Windows/Mac/zOS/VMS/... system, there are underlying
> philosophies that are common and these should be the basis for the
> profession.
>
> If you want to do a CCIE, you need to show proficiency with X.25, SNA,
> and AppleTalk (or at least you did recently) even if you will never
> encounter those protocols in your IP-only environment - and this is for
> a technology cert. For a sysadmin-cert, a candidate should be able to
> show proficiency and understanding of the underlying requirements for
> backup, security, authentication, authorisation, data integrity, etc. -
> not just how to implement these in Linux or Windows. OSes come and go -
> I've worked with at least a dozen or two already in my career, and
> expect to hit a dozen more before I'm done. You train to a product for a
> fleeting certification in that product. You train to a general standard
> for long term professional certifications. Professionals are expected to
> keep learning new areas after their initial certification, but that
> certification itself does not become void or useless because of time -
> because it is a certification of the understanding of underlying
> principles, not specific implementations.
In the short term, we need to serve our community; in the long term we
need to guide sysadmin education in a way that serves the public, our
community, and the academy.
Here's a strawman:
1) Answer the question: "What are accredited schools teaching?" Put
together a working group to review the state of the art in sysadmin
education, specifically the ABET-accredited programs and the
accreditation process. My guess: between 5 and 12 LOPSA members with a
variety of backgrounds (or whatever has worked for others that have
served on working groups before.) Set a 3-6 month charter with the goal
of describing a general sysadmin curriculum. It may be that ABET already
has such a document and all we have to do is pony up the cash to get a
copy. Or ask nicely.
If we create this as original work, summarize it in a white paper and
issue a press release and offer the full report for $$$ a la Gartner.
2) Of the subjects taught, determine:
2.1) which are specific enough that they are covered by vendor certification
2.2) which are general enough that they are covered under a bachelors or
an associates degree program
2.3) which subjects or skill are suitable for decomposition into
day-tracks for a "Sysadmin Days"-style educational conference
3) Develop and teach a number of "training tracks" based on the skills
identified in 2.3.
3.1) Develop LOPSA-standard curriculum, perhaps with join IP agreements
with people who may already teach similar courses at conferences.
3.2) LOPSA offers these standardized training tracks at conferences
("Sysadmin Days", SCALE, OLF?, etc.) & companies
3.3) Revise the curricula based on participant and instructor feedback
This most probably would benefit from corporate or university
sponsorship and a major promotion effort.
4) Long-term: work with ABET, universities, and other related
organizations to formalize a standard curriculum.
4.1) Use experience gained in 3.3 to guide curriculum formation
4.2) Work to publish and maintain the Weighty Tome of Sysadminnery to
guide the development of additional accredited programs.
----
This leaves us at the "Step 2. ???, Step 3. PROFIT!" phase - who the
fsck is going to implement this? A quick answer: not the LOPSA board.
And I don't mean to be flip - the Board is still working diligently to
resolve The Issue Which Is Not To Be Named, but most importantly, the
Board doesn't have the time & skills to execute any but a fraction of it
(#2.) And I don't want to follow the time-honored tradition of tagging
the one who brought it up as the one to make it happen.
My take: focus on #1, the curriculum survey. Find LOPSA members who've
done something like this before, give them a clear objective, and let
them loose. The Board gets the report, makes a few phone calls and
emails, and organizes a group to do #2 and #3.1. Those people need to
have the time and skills to do the job and they need a clear deliverable
and time frame from the Board. Once that's done, the Board and LOPSA's
management company bust ass to make #3.2 happen and make sure it's done
well.
I don't know that we'll be able to do #2.1 without cooperation and
probably an NDA from the appropriate certification orgs or vendors. The
goal is to be able to avoid teaching stuff that's already covered in the
vendor courses and to 'bless off' a certification as having covered
essential vendor-independent material. This doesn't strike me as
super-important since it's likely we can (or do) teach the essentials
and it won't kill anyone to teach or learn an extraneous fundamentals
class. We just have to make sure it gets done by someone.
I don't believe #4 is worth worrying about until #3 happens though
writing it down may help us forge relationships now that will benefit us
later.
Anyway, that's my strawman. Pick it apart, punch at it - whatever - I
only ask that the focus be on creating an achievable, useful outcome.
The whole "to certify or not to certify" debate has been going on for
probably as long as I've been associated with LOPSA/SAGE/USENIX; it'd be
nice to actually have something to show for all the angst for a change.
-- Bob
_______________________________________________
Discuss mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
