Bob Apthorpe wrote:
> 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...?)
>
>
Boilermakers are 'tradespeople'. Do you suggest that sysadmins be
'tradespeople' (boilermakers) or 'professionals' (engineers)?
> 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.
>
Engineers didn't fix most of those errors, boilermakers did!
> 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.)
>
The Sarbanes-Oxley act contains NOT ONE WORD about IT. Standards like
HIPPA do actually cover the handling of information, S-Ox does not. (Go
read it. I have. It's truly depressing that the very 'profession'
(auditors) go to ride roughshod over IT staff when they were the very
people who caused the ruckus in the first place!)
> 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.
>
ITIL is not about certifying professions like sysadmins. ITIL is about
service management. I am certified in ITIL 'Foundations' (v2 and v3).
ITIL is about about IT Service Management and having a common taxonomy
and phraseology with which to communicate, and while their training and
certifications are certainly pertinent and useful to IT operations, they
have just about zero to offer to the profession of systems
administration (other than a defined way to communicate with IT colleagues).
> 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?
>
Exactly!
I still believe that it is too soon to cast this profession in stone.
It would be like casting Electrical Engineering into stone before Ohm
came up with his law - and if you've seen what preceded it (with
logarithms and other mathematical complications caused because no one
understood that electrical sources had internal impedances), you might
get the parallel.
We have not yet got to the point where systems administration is a
science as well as an art. It's still only an art. Even hybrid
professions like Computer Engineering are really only there because they
are an extension of Electrical/Electronic Engineering. Systems
Administration is either too much of stretch or belongs a rung or two
below (as of yet) in the 'technician/technologist realm', at least the
way that most of us practice it.
- Richard
> 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/
>
_______________________________________________
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/
