On Fri, 27 Feb 2015, berg...@merctech.com wrote:
In the message dated: Thu, 26 Feb 2015 18:34:43 -0800,
The pithy ruminations from David Lang on
<Re: [lopsa-discuss] What is a System Administrator> were:
=> On Thu, 26 Feb 2015, Chris Manly wrote:
=>
=>
=> A System Administrator is not building products that customers use. They put
I've disagreed with many statements in this thread, but this may be the
one where I take the strongest exception.
Within your environment, and your range of experience, your statement
may be accurate, but that doesn't make it correct.
The definition of "customer" varies as widely as the definition of
"product" or "system administrator" -- and we clearly can't agree on
any of those definitions.
As a single counter example, in my current $WORK, the 'customers'
are interal technical users of our HPC cluster, and the 'products'
they use include things like the HPC scheduler (open source, with the
kind of 'minor customizing' that you'd accept) to locally written tools
('products' designed, written, and maintained by sysadmins) to manage
computation jobs, manage internal documentation, manage software build
systems, manage storage, etc., etc..
creating tools for internal users is a core part of System Administration.
Redefining "customer" from "someone not part of yoru organization who gives you
money in exchange for a product" to "whoever is using what your team produces"
breaks this definition. But if you stick with the external definition of
customers (and with the exception of explicitly selling System Administration
services), I think that if you are producing products that are being sold, you
are probably not doing System Administration, you are doing Product Development.
In previous $WORK, the products our company sold to external customers
were things like: professional system administration services, change
managment systems, account management systems, configuration management
systems, performance and security monitoring systems, etc. Those were
largely written by -- GASP! -- system administrators.
Well, if you are selling System Administration to your customers, of course the
System Administration work is sold externally.
Any definition that anyone can come up with will have exception.
=> together the systems to support the product, and may do things like build
mail
=> servers that the customers login to, but they aren't writing the code for
things
=> that are sold to customers (barring minor exceptions in customizing
opensource
=> code to work better as a part of what is being sold)
=>
=> In tiny companies, a person may wear many hats and be the Sales team and the
=> SysAdmin team and the Finance team (or the entire C*O team), but wearing the
=> SysAdmin hat, the job all revolves around making things work and keeping them
=> working. If you are implementing new features that the users are going to see
=> directly, it's probably not SysAdmin work.
I think what you're saying now is much closer to the way I see the scope
of SysAdmin work....a different proposition to me than the earlier statement.
In my experience, a huge portion of 'system administration' falls under the HR
category of "other duties as assigned". In many environments, those duties
include creating customer-facing software products or systems.
Personally, I'd find a statement like "when building products for customer
use, the system administrator may take on the role of [product architect|UI
designer|software developer|etc.]" to be a better phrase. However, that
temporary assumption of a role that is a facet within the scope of System
Administration doesn't mean someone ceases to be a sysadmin. When I work on
the specifications of a contract for a new storage system, that doesn't make
me a purchasing agent. When I work on the language used in our software
distribution agreement, that doesn't make me a lawyer. When I build products
for our customers to use, I'm still a systems administrator.
I'd say that with the exception of directly selling System Administration
services, most of the tasks that you just described are not System
Administration. Many of them are Management tasks or other tasks where you
really are putting on another hat for the duration of the task.
On the subject of hats. I believe that most people do end up wearing many hats
in one job, and I think that it's important to recognize that this is the case
and figure out where the line is between the different jobs you are doing. One
reason for this is that if you know where the lines are, it's much easier to
pass a job off to someone else who is hired as a specialist in that field. In
many cases, the different types of hats/roles have different priorities, and
it's best to be able to state advantages and disadvanges explicitly for the
different roles. For example, a couple days ago I said something very similar
to: "with my Security hat on, I think this is a great idea, but with my Sysadmin
hat on, I'm cringing at the impact on workload and processes and think it's a
bad idea".
touching on some of your examples.
If you are working on specifications of a contract, you are acting as a
sysadmin, but if you are negotiating the price of that contract, you are acting
as a purchasing agent.
When you are working on the language of a licensing agreement, you are doing the
legal department's work (note that there may not be a legal department as such,
and due to things like the Bar association I am not saying that you are acting
as a lawyer :-)
Senior System Administrators do tend to be good at architecture issues, and
consulting with the developers on this is part of being a System Administrator
(educating and assiting your users). UI designer, software developer, etc for
external products are not System Administrator tasks. But someone with the job
title of System Administrator may end up wearing one of these other hats as
well, especially in small companies.
David Lang
_______________________________________________
Discuss mailing list
Discuss@lists.lopsa.org
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
