When there’s only one server-side person in an organization, their role is usually called “systems administrator.” Anything that involves the server becomes their job: buying server racks and server room equipment, ordering and installing server hardware, installing and managing operating systems, installing and managing databases, managing storage, installing and managing applications, and sometimes even the management of users and access within the applications.
And that’s great. But then you need two systems administrators, then three systems administrators, and all of the sudden your systems administrators don’t have time to spec out the new HVAC system because they’re ordering SAN hardware and adding users to Sakai. At a certain point, it’s helpful to refine what a systems administrator (proper) does vs. other server-focused roles.
I’ve found the below roles to be helpful in that the zones of control (balanced authorities, accountabilities, and responsibilities) are relatively easy to define and separate.
Server room/data center manager: responsible for the physical server room. Often interfaces with Facilities. May be responsible for capital requests to improve/maintain the data center. Ideally (to me), has authority over all physical assets in the server room. They take stuff from the loading dock and put it in the server room. They may rack servers, plug them in, and provide information to the…
Systems administrators: responsible for the physical and logical servers. (Potentially a “virtualization administrator” may be responsible for the physical servers of the virtualization environment, e.g. they may own the VMware ESX server boxes as well as provision of the logical servers created within the virtual environment.) Systems administrators manage the operating systems and all that comes with that: system security, troubleshooting, and core OS tools such as syslog, to name a few. Ideally systems administrators also build the server configuration environment and have syslog servers, monitoring tools, and other things that make the provisioning and maintenance of operating systems easier.
Storage administrators: responsible for networked storage and generally any ≥$100k storage systems. They run the storage area network. If they make a mistake, you lose all your data. These people usually need networking skills as well as systems and storage skills, so they can write zoning rules, debug fiberchannel driver issues, and configure fiber switches.
Database administrators: typically the first role created after systems administrators, database administrators install, maintain, and upgrade databases. They also configure and tune the databases, e.g. making sure tablespaces don’t fill up, being EXPLAIN experts, etc. I’ve never been a database administrator. There’s a big set of skills potentially needed, depending on the types of databases and demand for database resources.
Application administrators: responsible for installing, maintaining, and upgrading server-side applications. Think Sakai: a Sakai application administrator would install Sakai, mess with any server-side configuration files, and then open it up. They may be responsible for integrating Sakai with other applications, e.g. setting up LDAP authentication. With forethought, the permissions needed for this role can be separated relatively cleanly so they do not need full superuser access on the operating system.
Application operators: full access within the application only. Often this role doesn’t sit in IT, but instead sits with functional users. With Sakai, this is a Sakai admin who has full access within the Sakai interface to create courses, users, etc., but does not necessarily log in to the server itself. Or with Remedy (speaking from my experience), this is someone with access to the Developer Console but not necessarily any access to the server.
You can see this distinction in SFIA: “Application support (ASUP)” seems to map well to application administrators, and “System software (SYSP)” seems to map well to systems administrators.