It’s been a little while since my last post – 2008 was a crazy busy year for me, and it culminated in a change in my job responsibilities.  The change started in September after a couple members of my team were laid off and I was asked to take up handling Novell’s practicum exam registrations.

In November, I was asked to take over our testing programs, so I’ve been working on learning an entirely new aspect of the training business.

I’m still in the process of assimilating information about testing processes, almost entirely around our registration process and partner management processes.

As nearly everyone knows (or should know), testing is an integral part of the learning experience.  From the standpoint of understanding how effective any training is, testing is used to understand the change in knowledge.  Done properly, a student should be assessed prior to taking a course and then tested after the course in order to determine what change in knowledge took place as a result of that training.

In my role in working with Novell’s instructor community, I got heavily involved in learning evaluation and metrics.  Novell uses Knowledge Advisors’ “Metrics that Matter” tool for learning evaluation in the training courses, both direct from Novell and through our training partner channel.  The guys who started Knowledge Advisors even wrote a book about their methodology, entitled Human Capital Analytics (written by Kent Barnett & Jeffrey Berk – a must read for anyone interested in measuring and improving learning – and I didn’t just take that from the cover, though it is on the cover).

Part of the MTM methodology can utilize assessments to pre- and post- test students in order to work into the calculations, which include a return on investment calculation.  The system can work things out without the testing data, but it seems to me that testing helps validate the information (at the very least) produced by the ROI report.

So while I have changed roles, my aim still is very similar to what it has been for the past three years:  To demonstrate the value of Novell’s training programs.  This is going to be an interesting shift for me, and I know I’ll be writing more as I learn more in the world of testing.

In reading Steven J. Vaughan-Nichols’ recent article based on my last posting, it occurred to me that I had left one fairly important thing out regarding the Certified Linux Administrator: The Novell CLA is a stepping-stone to the Novell Certified Linux Professional 10 (CLP10) certification.

The Novell CLA is based on the content from two of the courses in the CLP10 track; courses 3071 and 3072 (SLES 10 Fundamentals and SLES 10 Administration); the third course (course 3073, SLES 10 Advanced Administration) is not part of the CLA certification. Think of the CLA as a “checkpoint” on your way to the CLP10. The CLP10 exam (as well as the more advanced Certified Linux Engineer 10) is a practical examination, and as such, it focuses on proving your skills.

Many candidates have a degree of apprehension when being asked to prove that they can do something; being able to do is dependent on knowledge, so if a candidate is uncertain about their knowledge, there is an increased fear of failing at the practical examination. The creation of the CLA was done in part to help remove some of that fear. As I said in my previous post, Linux isn’t hard, just different. I would add to that statement that because it’s different, candidates need to have some comfort in their knowledge. A knowledge-based examination and certification gives candidates increased confidence when going in to take the CLP10 practical examination.

My thanks to Mr. Vaughan-Nichols for the article and the chance to clarify my thinking on this certification.

It’s hard to believe it’s been almost a month since BrainShare 2008 – and yet, here we are, in the middle of April.

At BrainShare, we offered exams for a total of four new certifications – the CLA,, the CLDA, the NCA, and the NCE-ES. In this post, I want to give you my (unofficial) perspective on these four certifications.

The first certification – the Certified Linux Administrator (CLA) – is an entry-level Linux certification based on Novell courses 3071 and 3072. The exam is what we call a “traditional” or “forms-based” exam.

(As an aside: Forms-based exams are useful for determining what a cert candidate knows, but not necessarily what they can do. The way I see it, there is a distinction between knowing and doing (and I think most would agree with that), but there is value in testing both capabilities when it comes to certifications. If you can do something but it takes a while for you to figure out what it is you need to do, or if you need to reference a book in order to do a task properly, that shows a lack of knowledge. Yes, you eventually will get there, but if you know the information you can perform the task more quickly. Testing for knowledge is an extremely valuable tool.

At the same time, knowledge alone isn’t sufficient in the real world – if you know the command-line parameters for the find command in Linux but can’t effectively use the tool to accomplish a task, you’ve demonstrated that you can successfully memorize facts, but there’s no test for applying the knowledge to the real world.)

The CLA is a test designed to let the candidate demonstrate knowledge, not skills. The primary focus is to let people know that Linux isn’t hard – that’s a myth. It’s just different than what they may be used to (NetWare, Windows, Mac, etc).

The Novell Certified LInux Desktop Administrator (CLDA) is based on a single course – course 3086 – and is intended to be taken by candidates looking to learn how to administer Linux desktops. It focuses on the sorts of things that users find important – software management, printer configuration, desktop configuration, and usage. The exam for the CLDA is also a traditional forms-based exam.

The Novell Certified Administrator (NCA) is an introduction to Novell services. Some who have looked at this want to equate it to the Certified Novell Administrator (or Certified NetWare Administrator, for those who have been around Novell long enough), but the goals of the NCA are quite different than the goals of the CNA. The CNA focused on administration tasks around the NetWare operating system – use of the management tools for NetWare to manage the platform.

The NCA is quite a bit broader, as Novell’s product portfolio has expanded since the CNA was developed. The NCA thus focuses on a wider range of products, but with fairly shallow knowledge in each (after all, it is a 5-day course; how much depth can get for 4 or 5 complex products in that time period?). The idea of course 2000 (and the NCA) is to give candidates a taste for what Novell’s product line consists of and the sorts of things the products can do. As with the other’s we have discussed so far, this is also a forms-based exam.

Lastly, we have the Novell Certified Engineer – Enterprise Services (NCE-ES). This is the first of the NCE certifications, and is based around Novell Open Enterprise Server 2, with a particular focus on the Linux version of the product. This certification focuses on doing rather than on knowing, so the exam is a practical examination delivered using Novell’s practicum technology.

NCE-ES is a logical progression for traditional CNE candidates coming from a CNE6 or CNE-OES background, Stay tuned for information about other NCE tracks that are being developed.

Over the last few days, I’ve been playing around again with LinkedIn and also joined Facebook. I’ve been a LinkedIn member for some time now, and also have had people invite me to Plaxo, Spock, and even got an invitation to participate in a beta for something called “NotchUp”.

In talking with some of my friends and business contacts about the benefits of social networking, particularly as relates to business, I’ve heard opinions on both ends of the spectrum – that it’s good because you get a chance to find out what’s available out there, or just to reconnect with former coworkers and friends from the past; or that it’s bad because it’s essentially one more untrusted organization with your e-mail address and the ability to spam you. Some of my friends even consider the invitations themselves to be nothing but spam.

My own experience with LinkedIn has been that it seems to be a good thing; while I’m not looking for a new job, I have received a couple of interesting contacts with proposals for job offers – a director of developer training and support at one company, and a general “let’s see if there’s a match” from another.

At the same time, I’ve also managed to reconnect with past employers – most notably a boss whom I (regrettably) feel I burned some bridges with when I left the company. We exchanged a few e-mails, but nothing much more happened with that.

Perhaps of more interest is seeing who the people I know know – I found a former VP of mine who knew someone I attended university with (not someone I knew at all from classes, but to find someone who knows two people who attended the same small university in Daytona was a bit of a surprise). I’ve also managed to find long-lost business acquaintances, partners, and co-workers whom I thought I would not be likely to hear from again.

Most people, it seems, form fairly strong but temporary relationships with the people they work with. At my last company, I was very good friends with my boss (who was first my team lead and a coworker); we used to get together regularly for parties, have lunch together, and just chat about the state of the world while he was out on a smoke break (I’d go out even though I’m a non-smoker myself – it often was the only time I could catch him to ask for his opinion on work-related matters). Once I left the company – an amicable parting by all accounts – we never really chatted again.

I have to admit that I miss that when I think about it, but at the same time, that has been replaced by similar working relationships with my current coworkers.

So, is this newest trend in social and business networking a good thing, and if so, where should the trends go?

Personally, I think it is a good thing – not just because it’s interesting to see that in my 2nd tier of connections on LinkedIn, there are people who work for companies like Tippett Studios, DreamWorks Animation, LucasFilm, and other such notable companies (though that admittedly is pretty cool), but because in todays job marketplace, it is valuable to keep your options open – and in order to do that, you’ve got to know what’s out there.

Not long before he passed away, my father told me that if there was one thing he’d learned in his nearly 90 years on this planet, it was that giving loyalty to a company is not something that is generally going to be rewarded. He worked for the same company for around 40 years; the retirees ended up having to sue the company’s successor in order to get the benefits that they were guaranteed under the pension plan. As rapidly as companies are born and die in the modern workplace, nothing is really guaranteed these days.

In nearly 20 years of being in the workforce myself now and having worked for 8 different companies (some as the result of a merger or acquisition, but different management, policies, and processes constitutes a change in employer in my book), I’ve observed some of the things my dad talked about. The bottom line was that only you are going to look out for your best interests, and having a contingency plan in place is something everyone in the workplace should have.

Having a good list of contacts helps with that contingency – if you can go to your network and say “hey, I’m available to be hired, and I have this skill set now”, you’ll have a leg up in trying to keep that unemployment period as short as possible.

Now, with that said, there are some trends that I’m seeing in the social networking sites that need to change. First and foremost, there are far, far too many of them now. Pick one, folks, and stick with it. Personally, I’m a huge fan of LinkedIn, probably because it’s the first one I joined. It’s where I update my information; as an identity management specialist, it seems very awkward to me to maintain the same set of information in multiple places, so I picked one place to keep up-to-date.

If I were to make a prediction about these sites, it’s that there will be some consolidation over the next couple of years. Some of them may integrate services (similar to the way Facebook can integrate your network on LinkedIn now). But I think some integration and consolidation is inevitable – and not at all a bad thing.

Happy new year!

It’s been far too long since I wrote anything up here – the training business at Novell has gotten very busy, and it’s been all I can do to keep up with the things going on at work, not to mention the things happening in my home life (including a much-needed vacation last month).

For 2008, I will be writing more on the topic of IT careers, certification, training, and the things I’m working on at work.

One of the things I see as a lost art is identifying the root cause of a problem in an IT infrastructure. In fact, this is becoming a lost art in more than just IT – the medical field (in my limited experience) also suffers from this.

A few years back, I decided I needed to do something about what appeared to me to be an allergy problem. So, we went to our local medical center, and the answer I was given by the doctor was “here, try these pills, if they don’t work, try these pills, and if they don’t work, try these pills and this nasal spray together. Good luck!” I didn’t even get a referral to someone more qualified to perform a root cause analysis to determine why I felt so miserable.

A lot of IT troubleshooting is handled in this way as well. Some of it is a necessity, but I’m of the opinion that trying different solutions is the last thing you should do, not the first thing. To be successful in IT, you have to understand the systems well enough to fix the problems that happen so they don’t happen again.

It seems that many people coming into IT are not taking the time or making the effort to understand the systems they implement. This is something that should be taught as part of a certification program, but many cert programs don’t go into this.

When I first started teaching for Novell back in 2003, I was hired to teach the eDirectory Advanced Technical Training course. Before I taught that class, though, I had to learn a new course that had just been released, course 3007: eDirectory Tools & Diagnostics.

This course, I think, is one of the best certification courses that I’ve ever seen. I might be slightly biased, because it was the first course I taught – and was a course that taught something that I’d been doing for many, many years at that point: How to find the root cause of a problem and diagnose it.

So, just like the doctor I saw years ago, many IT professionals learn how to try several things until one of them works. In many cases, the “magic bullet” is to reboot the system and wait for the problem to happen again.

“Troubleshooting” in this way requires very little thought, but ultimately defeats the purpose of why one is hired as a professional in this field. Being professional, in my mind, means having a brain and knowing how to use it.

Now, why do I refer to troubleshooting as a “lost art”? Certainly, there is a fair amount of science (or application of scientific methods) involved in troubleshooting. Narrowing the problem down to a specific cause is a very methodical process, and done right, the same process can be used consistently and return good results.

Following the medical analogy I started with, though, there’s a bit of science involved in a diagnosis, but there’s also the application of knowledge that sometimes happens in a nonintuitive way (at least to the untrained observer) to identify what the actual root cause is. A few weeks ago, I was watching an episode of some crime program, and the beginning was a guy walking into a veterinarian’s office with what seemed to be some sort of fatal wound. The veterinarian walked over and started by saying “I don’t treat people! I treat animals!”, but he tried to do what he could. When the police showed up, they asked him questions, and he gave very detailed answers about what was wrong with the guy – dislocated shoulder, ruptured spleen, and a few other things; all this information given even though the patient couldn’t talk to him. The cops looked at him funny, and he said “what can I say? I’m used to dealing with patients who can’t tell me what’s wrong – I have x-ray hands, I guess.”

That’s the kind of art I’m talking about: Being able to diagnose issues in a system when there’s no evidence of a problem other than, say, a complete failure of something. Using an example from my own IT career, I got a call one day from the help desk saying “users can’t log into a particular server”. I was connected to the server, so I looked at a drive mapped to the server and said “well, the server’s up, send someone out to look at the workstation.” After a while, the number of calls escalated, and started coming in from other parts of the company: Clearly something was wrong, even though all these servers were up. It turned out that the authentication system on the system had deadlocked, and that didn’t prevent access for those already logged in, but for those who were just getting started, it meant they couldn’t do anything.

3 days of troubleshooting ensued, and it turned out to be a bug in the code for an update we’d just applied – a one in a billion chance of it happening, and we just got lucky – the right amount of load on the servers, the right number of users logging in, and the right distribution of services across the servers in the environment.

For those familiar with Novell’s NDS product and with my writings on Novell’s Cool Solutions and in the support forums, you’ll know that my least favourite way of troubleshooting a directory problem is to start running repairs. Troubleshooting requires finesse, not brute force. This is true for any technology, not just directory technologies (though I might argue that for directory technologies, it’s more important to not use brute force to fix problems one doesn’t understand because of the distributed nature of the technology). Take some time to understand the problem, particularly if it’s a serious problem. While your users will likely not thank you for not getting the system running immediately after a failure, if you can isolate the problem and fix it for good, they will appreciate that the system isn’t going down again.

This isn’t to say that a band-aid solution is never appropriate: Sometimes, you’ve just got to get the thing back up and running as quickly as possible. The financials server has crashed, and the quarterly sales figures are due today. Not much you can do about that, if rebooting the system is going to get the system running so the finance people can get their work done (which might be work that is required by, say, the Securities and Exchange Commission in the US).

Just don’t leave the band-aid on. If you’ve ever left a bandage over a wound for longer than you should have, you’ll understand what I’m saying here.

As someone now involved in Novell’s certification programs, this troubleshooting aspect is something that I’m happy to say there’s some traction for in the certification paths. Troubleshooting and optimization – the latter of which I may write about in a later post – are two key points of discussion as we design the new paths. It simply isn’t enough to just be able to install and manage the system, you’ve got to be able to fix it when it’s broken.

That’s one of the things they pay you the “big bucks” for.

Just like in the doctor’s office – a GP might tell you to try a handful of different drugs in order to treat the symptoms, but a specialist (such as the very good allergist I saw about a month ago) is going to actually do some diagnostic work and determine the actual root cause before prescribing a treatment – and that treatment is going to be targeted at that root cause rather than the symptoms.  The specialist may not be able to give you good news all the time (as in my case – a course of 3-5 years of allergy shots was the resulting prescription), but the chances of the problem being solved for good are much better.

Over the last few months, I’ve had an ongoing discussion with an acquaintance  about his  job and where he wants to go.  For purposes of this post, I’m going to call him “John”, though that’s not his real name.  He is based somewhere in the UK, currently working for a small company as their sole IT resource.

John is a fairly quiet guy; he’s got a degree in computer science, and interests in math and music.  Like a lot of people starting in IT, he’s not sure exactly where he wants to go or how to sell his skills to potential employers.  Part of the reason for this is that he doesn’t believe he knows anything special that would merit him getting a new job.

One of the things to keep in mind when looking for a job in IT is that all companies need IT infrastructure people these days.  Because of this, you don’t want to limit your options to just, for example, software companies (because that’s where you think of the technology being) or even companies that are in the high-tech industry.  Your local grocery store has some IT infrastructure, and they need someone to manage it, design it, and maintain it.

One thing that surprised me a little during the discussion with John about some of the larger employers in his area was that one of them – a large consulting firm – is something he ruled out because he doesn’t see himself as a good fit for doing consulting work; he doesn’t like working with people, and doesn’t want to be caught between unreasonable customer expectations and sales promises.  Those of us with some experience in the field will have seen the cases where sales says a product can do anything you want, and the consultant coming in and providing a much more limited – and realistic – picture of what it is that a product can do.  John doesn’t want to be the one stuck having to explain that sales oversold the product, and for some people, that’s a reasonable thing to want.

But ruling out any job at the company because they were a consulting company struck me as a little odd.  It turns out that John had learned that one of the things they do is provide outsourced systems management to large clients, so he assumed that they would use those same people to manage their own systems.  He was very surprised to learn that this is likely not the case, as a few of us pointed out to him.

Billable resources (which is what consultants are) are the product that a consulting company sells.  A consultant being billed out at, say, $100/hour to do systems management for a Fortune 50 company is going to be more valuable to the company as a billable resource (that is, a resource that is essentially a consumable product – ie, the consultant’s time) than managing the infrastructure used to run the business.  To run the business, the company might hire a $30-$40 per hour worker.  The revenue generated from the billable resources in the field (ie, the consultants) is going to be what pays both for the consultant and for the non-billable resources that run the company.

Taking a $100/hour resource and dedicating them to several hours a week of managing the systems for the consultancy results in a loss of income that would be used to both pay the consultant and to pay for the IT worker – it’s a double hit for the company to use the resource in that way.

The bottom line is this:  Never assume what a prospective employer’s needs are – that’s up to them to decide.  If your skills are “programming in any number of languages, but not C” (as John’s are), don’t assume that as a programmer you’re worthless to them because “any real software shop is going to require coding in C”.  Fill out the job application, send in a resume/CV, and see what sticks.  Part of the process of getting a job is to put feelers out in as many places as possible and see who bites – it’s kind of like fishing:  Some days you’ll get a nibble, and some days you won’t.  But if you don’t even cast a line into the water, you’re guaranteed never to catch a fish.

A second certification we announced at BrainShare is the Certified Linux Desktop Administrator, or CLDA.

The certification itself is still being developed, so I don’t want to pre-announce anything beyond the announcement at BrainShare, but rather to use this as a framework for some comments regarding my thoughts around certification “levels”.

Certification, as I see it, plays two separate and identifiable roles in the IT world (this may apply beyond IT, I just have little experience in those other arenas):  Firstly, for the vendor, in that a large certified audience helps drive product sales; in effect, it’s a marketing tool for a vendor when the certification is a mass-market certification.

Secondly, it’s a measure of expertise for the individual.  It’s a marketing tool for an individual certification candidate to demonstrate competency in a particular area or technology.

From a career path view, in IT there are really four “levels” of expertise:

1. Help Desk/User
2. Administrator
3. Engineer/Implementor
4. Architect

There is some overlap in the requirements for each level – for example, in order to implement an IT solution effectively, it helps a lot if the person working on the implementation understands the user experience or how a help desk is expected to support the solution, as well as how an administrator would do their job with it.

From my point of view, these levels build on each other – an architect would have to know some details at the lower levels.  For example, to understand what is and isn’t possible with a particular product set from an implementation standpoint – the best architected solution is useless if it can’t be implemented.

In terms of Novell’s Linux certifications,  right now there are two (The Certified Linux Professional (CLP) and the Certified Linux Engineer (CLE)).  Both of these certifications, in my mind, cover different pieces of the engineer/implementor level, and specifically around server implementations.  The CLP covers a lot more fundamental Linux knowledge, so might overlap between the administrator and engineer levels, and even people in the Help Desk/User level would benefit from it.

The CLDA certification will fill a gap with regards to the deployment and management of Linux desktops (specifically, the SUSE Linux Enterprise Desktop product) .  Desktop administration overlaps somewhat with server administration, but there are many unique aspects to desktop administration that indicate a potentially separate career path for those interested in the desktop.  Some people will make the shift to the server side of things, but others seem to prefer being closer to the users and working with the desktop environments.

The question in my mind is where, from the standpoint of a desktop administrator certification falls in general, does that certification belong in the first category of certifications (the mass market) or in the latter (high value for the certified individual).

What do the readers here think?

Last September, prior to the conclusion of his Novell NetWare Tips newsletter, my friend Dave Kearns concluded an article on the CNE6 certification with:

So, yes, go for that upgrade to CNE 6. Training is never a bad thing, but training on a system that is still an excellent server operating system, still has a good sized installed base and appears to have a shortage of trained managers sounds like a good career move.

Dave couldn’t have gotten it more right, partly in terms of training being a good thing, but also in ways he wasn’t aware of at the time. Ultimately one question on many people’s minds at BrainShare this year was whether or not there was a future path forward for those holding a CNE6.

The answer to that was revealed at BrainShare during one of the keynotes: Yes!

The certifications team at Novell has been working hard for the past several months on defining what that path is, and what it should be. Our approach has been to ask those who do the job what the job entails. Through a series of Job Task Analyses (JTAs), we’ve been doing research for where the path should go.

We reached a couple of conclusions as a result of our questions and study: Upgrading the CNE to cover NetWare 6.5 would be a good thing (especially since the courses were nearly completed), and we should extend our certification path to cover where the product is going – to Linux.

One of the most frequent comments during the JTA process was that Linux is interesting, but the people looking to move from the NetWare kernel to the Linux kernel needed to understand how the traditional NetWare services (which is what they provide to their end users) work in a Linux environment. We had had a couple of courses that hit this at a high level (both 3059 – Deploying Novell Open Enterprise Server and 3077 – Integrating Novell Open Enterprise Server for Linux), but there wasn’t enough in those classes to take someone with NetWare experience into a comfort zone where they could manage those traditional NetWare services running on OES on Linux. The Novell Certified Linux Professional and Novell Certified Linux Engineer certifications are all about Linux, but don’t talk at all about traditional Novell services running on Linux, so those certifications don’t get you to where you need to be if you’re integrating OES on Linux into your existing environment.

Based on that feedback, we’ve put together a path forward – the Novell Certified Engineer, or NCE.

I can already hear you asking: Why does it have a new name?

Let me give you my personal thoughts on this – thoughts I expressed during the decision making process. Over the years, Novell has used the same acronyms for a number of different things – those of you who know Novell products well, tell me what the following acronyms mean: NTS, NLS, and CNE.

Here’s what I recall:

• NTS: Novell Technical Services, Novell Technical Support, Novell Training Services
• NLS: National Language Support, Novell Licensing Services
• CNE: Certified NeWare Engineer, Certified Novell Engineer

I’m sure you can see a pattern – and I know there are more definitions than the ones given for these acronyms. I believe at one point, there were 5 concurrent meanings for NLS alone within Novell, and which one was being used was dependent on the context in which it was used.

The last one in particular is significant, though: CNE was the Certified NetWare Engineer abbreviation, and even today, when most people think CNE they think NetWare, not Novell. And why shouldn’t they? The certification has been a NetWare-centric certification forever.

This new certification builds on the existing NetWare knowledge (CNE6 is a prerequisite), but by changing the letters up a little bit, we accomplish a couple of things:

1. We remove the ambiguity about it meaning NetWare by virtue of the fact that NCE has never been a NetWare certification – because it never existed before.
2. We fall in line with a fairly common practice in the industry: MCT is “Microsoft Certified Trainer”, CCNA is “Cisco Certified Network Associate” – ie, the vendor name is first in the certification name. I don’t know that anyone has stated this is the way it has to be, but it is a fairly common practice, and when it comes to branding, the vendor name should be part of the certification name (it is, in fact, with the CLP and CLE – officially, those are the “Novell CLP” and “Novell CLE” with the version number afterwards)

The courses for the NCE are soon to be developed – we expect to have them later in the year; rather than build this new certification to the current release of Open Enterprise Server, we’re building it to Open Enterprise Server 2, which is due to ship in the near future – it doesn’t make sense to develop a new certification to a product that’s going to be replaced fairly soon. We’ll develop to released code, which we always do (things change from beta to release, and we want to make sure the final product reflects the shipping product rather than a pre-release product).

Information on the NCE is available on the NCE Certification Page. You’ll note that the NCE is largely a framework – the page talks about “Enterprise Services” and includes a link to the NCE – Enterprise Services certification roadmap, but you may also notice that we’ve put a couple of teasers about where we’re going on the page as well.

The intention with NCE is that this is a framework under which we can build other related certifications; this is the reason it’s taken us a while to reach the point we’re currently at – we decided that it was necessary to revamp how we frame certifications and to build a more consistent model in which we can fit other needed certifications as well.

There’s much more to come. As I stated in the opening of this post, Dave got it right, but he had no idea when he wrote what he did in September how right he was.

In my next post, I’ll touch on another certification we announced at BrainShare – the Novell Certified Linux Desktop Administrator.

I wrote in an my previous post about an article written by monster.com’s Allan Hoffman. Allan’s article is a great piece, but I wanted to include his questions and my answers in a post here as well. With Allan’s permission, I’m reproducing the Q&A here.

Q1. You note that you’ve been skeptical about certifications. Given that, where do you see their real value?

A1. A lot of my skepticism has to do with the simple economics of certification programs. While I don’t claim to be an economist or an expert in the dynamics of supply and demand in the free market, it occurred to me back in the early 90’s that tests based solely on book answers that contradict how things work in the real world did not provide real proof of anything beyond the ability to memorize facts. For example, I had to take an engineering physics class during my first year in the Computer Science program when I was at University; I had a debate with my professor about the value of memorizing formulae when, as a CS student, my objective was to learn how to write code that would evaluate complex equations in order to model/simulate situations in the physical world. The focus of that physics class as well as others was on memorization of facts rather than application of knowledge to solve problems. This is the underlying root of my skepticism about “traditional” certification based only on the candidate’s results from written exams.

The value of certification increases when you move to a practical testing environment – demonstration of skills learned. At Novell, we use a practical examination (the “Novell Practicum Exam”) using online technologies to deliver a real-world (not simulated) scenario with a set of tasks to complete in a specified time. Being able to demonstrate the skills necessary to complete a task or series of tasks increases the value of certification because the test provides those real-world scenarios and also applies the pressure of a time constraint – something that is all too real in the world of IT, especially when troubleshooting.

From the standpoint of a certification candidate, the real value of certification comes in scarcity (this is where I have to restate that I’m not an expert in economics or supply/demand dynamics) – in my mind, the more people who achieve a certification, the lower the value of the certification to the holder because the certification becomes much more commoditized. Being one of a million is a way of getting your foot in the door; being one *in* a million is a way to actually get the job. In other words, if a certification sets a high bar, then it helps you stand out from the pack. Most certifications these days turn knowledge into a commodity, and I personally believe that’s why research like the Foot Partners report shows a decline in value of certifications when applied to pay scales. When I see statistics showing, for example, many millions of MCSEs in the world and then look at discussions about CISSP where people who hold the certification number in the tens of thousands worldwide and the candidates are concerned that the certification might lose its meaning, I see that as supporting my personal point of view on certification.

Q2. Foote Partners (see the first item at http://www.footepartners.com/ fp_html/pressreleases.htm) says its research shows that certifications are declining in value (in terms of pay). Should IT orkers be concerned?

A2. I think IT workers should be concerned if certification is something they consider as a goal unto itself. The problem I see with many certification candidates is that they see certification as an end rather than as a means. Ultimately, the goal of certification should be to expand one’s knowledge and build competencies and proficiencies that allow the candidate to apply what they’ve learned to solve business problems. A great many IT certifications in the market these days still seem to focus more on basic skills – installation, troubleshooting, and maintenance. IT workers need to become much more versed in the language of business and understand what their business’ goals are. The real value that a skilled IT worker brings to the table isn’t their ability to install, manage, and troubleshoot the platform, the web server, or the database, but rather their ability to look at an abstract business need and identify ways to streamline that business process by applying technological solutions in creative ways.

An example of this type of thinking comes when tying multiple systems together to provide a single means of authentication across multiple applications (ie, “Single Sign On” solutions). Sometimes an IT professional has to be creative in figuring out how to synchronize user ID and password information between systems, because many systems do not store the password using reversible encryption technologies; once the password is in the system, you can never get it out again without resorting to brute force techniques. Today, I see many different types of systems tied together through a common authentication credential set, allowing even your voice mail password to be a PIN that is used in other parts of the systems. While security experts debate the implications of using common authentication across systems, the end user experience is streamlined and the user can be more productive. Even 5 years ago, this was considered an emerging technology, and 10 years ago, most people never considered that maybe you could accomplish this without manually managing a dozen passwords.

A lot of the creativity that takes place in IT today centers around things like supply chain management – where understanding how the supply chain works is essential to successful design and deployment of a system that is truly going to capitalize on the efficiencies that technology can provide.

Q3. What’s a smart perspective for IT workers to bring to decisions regarding certification? I.e., is it a way to gain skills? Increase pay? Make themselves more attractive to employers? Or some mix of these factors (and others)?

A3. Ultimately, training is a way to gain skills – increased skills usually equates to increased pay. The smart way, in my personal opinion, to look at certification (especially mass-market certifications) is as a stepping stone. I’ve seen many candidates consider certification as the end of the road; in reality, it’s only the beginning. The programs that I see as good certification programs make it clear that learning doesn’t end with the certification – the certification is instead a measure of a certain level of competency, but the candidate must add to that a differentiating factor that helps them stand out from the crowd – even with certifications where scarcity of certificants means there is an increased value in the certification alone. Certificants need to understand that learning is an ongoing process, and that nobody can ever know it all.

I can speak to this point directly and personally: Prior to coming to Novell, I had co-authored a couple of books on Novell Directory Services (NDS) and eDirectory troubleshooting with my good friend Peter Kuo up in Canada. In addition to that, I had also contributed to a book on RedHat Linux (a section on connecting Linux machines to NetWare servers) and had performed technical reviews of a number of other books on topics pertaining to Novell technologies. From the standpoint of an outsider looking in, I knew more than 99% of the other NDS and eDirectory people out there. Novell was impressed enough with my knowledge that I was hired to both build and teach the eDirectory Advanced Technical Training course delivered around the world.

Once I started teaching the courses, I found students were challenging me with questions that I had never even considered, and decided I needed some training on the internals of the product in order to gain insight that allowed me to answer these questions. I received some in-depth training that’s offered internally to the best of the support engineers, and found that my knowledge barely scratched the surface of how the product actually works – I had made some very good guesses (and some not-so-good guesses) as to how things actually worked. I moved very quickly from thinking I “knew it all” to realizing that I knew a very small part of the whole, but that the part that I knew was the part that was mostly relevant to implementation, and consequently that knowledge was relevant to the majority of the people that I was teaching.

The bottom line is this: There is always more to learn, no matter what your level of expertise. Consequently, my advice is this: never stop learning. Whether it’s technology or business, IT professionals need to be conversant in both in order to be successful. Being able to combine knowledge in both of these areas in order to affect a company’s profitability by lowering operational expenses (which is the usual place IT investment is offset – it can generate revenue, but that’s normally a niche play for IT usually reserved for applications like online shopping) is what makes an IT worker successful. Certification and training help the IT worker achieve this goal.