What is System Administration?
This blog contends that SysAdmin does not receive the attention that software development does; in research, debate and publication. But let’s first define our scope - what is SysAdmin? (Also, what is software development, and come to that, are there any other fields we’re excluding/including?)
Intuitively, software development is easy to describe - the process by which new software is created. In today’s integrated views of this process, development should not be separated from specification, design, testing or delivery, and it also includes the planning process for all these.
System administration is just about everything else. Simple! Well…
Creating a piece of software is clearly pointless if it doesn’t get run. And SysAdmin is entirely about providing the right environment for running software.
So can we define SysAdmin as everything that happens after software has been delivered? More or less. It covers the installation and customisation of the delivered software package, installation of the required underlying systems, support for users, and ancillary requirements such as resilience and backups.
Arguably, it should also include some earlier stuff – design of the overall environment, and specifications for how an individual product works with the others.
However, terminology and management structures will differ between organisations - some places will use “SysAdmin” to mean just about everything except Development, in others it’s just the folks who manage the core infrastructure. This blog will fearlessly address all areas in the widest definition - whether you consider your helpdesk to be part of your SysAdmin team or not, it’s all closely related (and hopefully not too far apart on the org chart).
Put differently, what are the parts of an IT department? You may have some or all of the following functions set up as different groups. Perhaps the first three are most likely to be considered non-SysAdmin, but your local setup will surely vary.
- Business analysis
- Development
- Management
- Architecture
- Problem resolution
- Application support
- Infrastructure support
- Product engineering
- System administration
- User support
- Maintenance
- Hardware support
These are the functional roles, but your teams may instead be grouped by technology/product area, or by alignment to business departments, with the above functions seen as roles within those groups. Most likely, a mixed combination of all possible arrangements, based on history, importance of different departments, or which managers are most successful at empire-building. On a smaller scale, you may have one team which does all the above, or one person who takes some time out of their main job to do the lot!
The following diagram shows a very simplified view of a software lifecycle. The initial evaluation should be based on a combination of the immediate business needs for the new product and the overall IT plan. The new system or function is either acquired by purchasing, or developed to spec (or a combination). It is then introduced with suitable testing, is used & supported, and is eventually removed.
Although the different shades show functions that may be differentiated, basically the green boxes are development tasks (particularly in Agile, where these are integrated); the yellowish ones are management and control; and the blue ones are aspects of SysAdmin. [Click to enlarge]
SysAdmin must also have some input to requirements before a piece of software is evaluated for purchase or development - although Business Analysis will specify the user functionality required, the admin should be able to specify the preferred constraints in order to fit with the company’s technology strategy, e.g. operating system, database used. Hopefully also the requirements for indirect functionality such as resilience, uptime, backups, etc will be specified by the analysts, leaving the administrators to choose exactly how these will be achieved.
For perversity’s sake, we should note a paradox: the systems that are used for software development (eg IDE, code repository) have to be administered themselves, and likewise apps that are being evaluated as potential components of the end product. Quite often this will be done by the devt team, but it’s really admin work that they are taking on, and some of the tasks look very familiar!
As a matter of interest, is there any IT work that doesn’t come under either Development or SysAdmin? Maybe you don’t count management of SysAdmin as part of SysAdmin itself (though hopefully your management is not too detached!). Outsourced and cloud resources are really just subcontracted forms of the same tasks - for the core company, the responsibility becomes more of a management and supervisory one, but the same work is happening in some place.
Imagine a company in which there are no developers and no development work, then virtually all the IT dept is SysAdmin except for business analysis and procurement, and the control functions (management, finance and planning).
I reckon that SysAdmin (at least for this blog) should cover everything except
- the price/contract negotiations of major procurements; this is clearly a management/legal/business area
- the user functionality part of system specification; this is business analysis (aligned to, or part of, development)
- core software development, including coding and code testing
…and I’ll include some of the aspects of management, because how could you detach them entirely?
Cool. So now I have licence to talk about anything I want.