IT: Standard Discipline Areas Within IT
scottalanmiller last edited by scottalanmiller
Information Technology and Business Infrastructure are an enormous field filled with numerous and extremely varied career opportunities not just in the industries in which work is done, but also in the type of work that is done. Only rarely are any two IT jobs truly alike. The variety is incredible. However, certain standard career foci do exist and should be understood and known to everyone in the field as they provide important terminology for mutual understanding.
It is very important to note that, like in any field, it is most common that a single person will do more than one role throughout their careers and even at the same time. Just as someone may be half time burger cook and half time cashier, someone may have their time split between different IT roles. But we need to know what those roles are and what they mean to be able to convey value, experience and expectation to others.
These are what we refer to as "IT Specializations" and are areas of specific focus and opportunity for deep skill within IT. These often do not just represent job roles within IT, but in large businesses generally are representative of entire departments of career peers who work together. None of these areas of focus is more or less senior to any other, these are different areas, not levels. There is no natural or organic progression from one IT discipline area to another, however all IT experience is valuable and it would be expected that experience in one discipline would prepare someone to more quickly learn and adapt to another area.
The terms "Administration" and "Engineering" are often applied today, these, again, are not levels, nor are they discipline areas. These refer to a role being focused on operations (the running of production systems) or on designing systems for deployment. These two share discipline areas. So, for example, the Systems discipline would have need for both administration and engineering workloads within it.
Systems. Shortened from "operating systems." Systems roles are focused on the operating systems, normally of servers (but not necessarily in all cases.) This is the most broadly needed specialized IT role. Within systems, specializations tend to be such as Windows, RHEL, Suse, Ubuntu, AIX, HP-UX, Solaris, FreeBSD, Mac OSX and so forth. High level specializations such as UNIX are common with a single person or department servicing any system that falls under that umbrella, or larger organizations might split AIX, Solaris, RHEL and FreeBSD into four discrete teams to allow for a tight focus on skills, tools and knowledge. Systems specialists provide the application platform on which computer programs (which would also include databases) will run. Desktop support is generally seen as being a sub-discipline of systems, and one that often intersects pragmatically with end user and helpdesk roles.
Platforms. Also known as virtualization or cloud teams (depending on exact role), the platform discipline focues on the abstraction and management (hypervisor) layer that sits, or can sit, between physical hardware and the operating system(s). This team tends to focus on capacity planning, resource management and reliability. Foci within platform specialization would commonly include VMware ESXi, vCloud, Xen, XenServer, KVM, OpenStack, CloudStack, Eucalyptus, Hyper-V and so forth. With the advent of massively hosted platforms, there has also arisen a need for foci on specific hosted implementations of platforms such as Amazon AWS, Microsoft Azure, Rackspace, Softlayer and so on.
Storage. Storage of data is so critical to IT that it has filtered out as its own, highly focused discipline. Storage specialist generally focus on SAN, NAS and object store systems. Focus areas might include block storage in general, or might drill down to specific product or product lines, such as EMC VMAX or HPE 3PAR. With recent growth in scale out storage technologies, the storage arena is growing both in total size as well as in depth of skill expectation.
Databases. Similar to storage, databases provide critical "backing" of information to be consumed by other departments. While conceptually databases and storage overlap, in practicality the two are separated dramatically in how they are treated. We think of storage as "dumb", "unstructured" or "bulk" storage and database as "smart", "focused" or "highly structured" storage. At their fundamental level, the two are actually quite hard to distinguish. In practice, they are extremely different. Database specialists work specifically on database services, but rarely create databases and certainly do not code database connected applications. Like their systems counterparts, database specialists (often called DBAs) manage the database platform for other teams to consume. Database foci could be high level such as relational databases or non-relational (NoSQL) databases. Or, more commonly, a DBA would focus on one or more very specific database applications such as Informix, MS SQL Server, DBase, Firebird, PostgreSQL, MariaDB, MySQL, MongoDB, Redis, CouchDB, and many more.
Applications. Applications are the final product that consumes all other platform components from physical systems, platforms, systems, storage, databases and more. Applications are the ultimate component of the computational stack and can take a massive variety of forms. Application specialists would never use that term but would be referred to as a specialist on a specific application or set of applications. Some application families, such as CRM and ERP, as so large that an entire career might be spent learning and supporting a single one (such as an SAP ERP system.) While in many other cases one might manage and oversee hundreds of small applications over a career span. Common application areas include CRM, ERP, email, web portals, billing systems, inventory tracking, time tracking, productivity and so much more. Applications could include just about anything and while some are high provide, such as an Exchange email system; others might be very trivial such as a small desktop utility for calculating mortgage rates quickly.
Networking. Networks tie computers together and require much design and management on their own making them often the second largest discipline within IT. Network specialists work on buses, hubs, switches, routers, gateways, firewalls, unified thread management devices, VPNs, network proxies, load balancers and other aspects of allowing computers to speak to each other. Networking specialists typically focus on a vendor, such as Cisco or Juniper, rather than product types such as switches or routers. Networking is, with systems, the best well known or most commonly mentioned, role in IT even if the two are often confused. This role also supports the SAN (the actual network itself) for storage teams.
Security. Not truly an IT discipline itself, but rather an aspect that applies to every other role, IT Security specialists tend to either specialize by other discipline (network security, application security) or act as a cross discipline role with a focus on the security aspects as they cross those domains. Security specialists and teams might focus on proactive security, security testing and even social engineering.
Call Center, NOC or Helpdesk. The front line role for monitoring systems across other domains, taking incoming calls and emails and assisting in triage and sometimes direct support for an organization which may or may not include end users. This role varies heavily depending on who the direct "customer" of the service is, if tasks are interrupt (monitoring) based or if they are queue (ticket) based. Often the focus of this role is high level triage but can cross dramatically into end user support. This discipline is often seen as a "helper" group to other teams.
End User Support. Whether working sitting beside an end user in person (aka "deskside support) or remotely (aka helpdesk), end user support roles work directly with individual end users to resolve individual issues, communicate with other support teams, train and educate, and so forth. This is the only IT role that would commonly have any interaction with non-IT teams (unless reporting "up" in the organization to management.)
Hardware Technical Support. This role has no well known name and is often known only by the fact that it works with hardware. This role or family of roles includes the physical support and management of desktop or laptop devices, the support and management of physical servers, storage systems, or networking devices or the physical management of a datacenter or similar. This is the portion of IT that rubs shoulders with the "bench" field (considered to be outside of IT) and consists of much grey area overlapping with it. Hardware Support will often plug in and organize cables and generally works supporting other teams, predominately platforms or systems. Separating IT Hardware Support from Bench work is often nothing more than an "operational mindset" and most roles could potentially go in either direction. Placing desktops on desks is often seen as falling to bench, whereas racking, stacking and monitoring server hardware is generally seen as IT Hardware.
Part of a series on IT Basics
scottalanmiller last edited by scottalanmiller
It is often practical to define what IT is not, rather than what it is. Many things are often assumed to be IT roles, but are not, and are so commonly connected with the field that it is worth expressly pointing out that they are not IT roles, but rather something else.
Project Management. PM is its own discipline that is far more a part of management than any other field and has no direct ties to IT whatsoever. IT often utilizes PM roles and PMs often oversee IT projects and IT companies or departments generally have PMs tasked to them; but the PM career itself is quite separate from IT. The same as any management role.
No Cabling. IT is most certainly not an electrician's trade and the running off, termination of and certification of building cables is not even remotely within the scope of IT. Most IT departments will plug in computers to their network ports; but this no more makes IT the electrical maintenance department than plugging in a lamp at home makes you the electrician. The physical cabling plant of a company remains part of the electrical and maintenance roles clearly outside of IT.
No Programming. There is no programming role within IT. Software Engineering is a closely associated industry, but is not itself part of IT proper. The head of IT is seen as the CIO, the head of SE is see as the CTO. CIO is about business infrastructure - the "plumbing" of the organization. The CTO is about the engineering and creation of new tooling - often which would then be used by the IT organization. The expectation is that IT would request tools from SE. That is not to say that IT roles never write code, they often do, but coding is not the product of IT, it's a tool in the toolset. An SE's job is to deliver code as the end product.
No DevOps. DevOps is not a role. DevOps is a modern terminology for a specific style of working in other roles. One can be a DevOps System Admin or a DevOps Network Admin or a DevOps DBA, for example, but you can't be just "DevOps" as it does not mean anything on its own. DevOps is a way of working, not a specific task. So we do not see DevOps on the list, even though DevOps is an important concept in IT in general.
Carnival Boy last edited by
I have no idea what my role is or even if I work in IT.
But one thing I'm not sure about is the difference between programming and scripting? And if a Windows Administrator spends a significant proportion of his days writing Powershell scripts, is that not an IT guy programming (or similar with Linux)? I'm not sure what you mean when you say both "There is no programming role within IT" and "that is not to say that IT roles never write code" - why is that not a contradiction?
But one thing I'm not sure about is the difference between programming and scripting?
Simple answer: none. Scripting is just one of two main types of programming.
And if a Windows Administrator spends a significant proportion of his days writing Powershell scripts, is that not an IT guy programming (or similar with Linux)? I'm not sure what you mean when you say both "There is no programming role within IT" and "that is not to say that IT roles never write code" - why is that not a contradiction?
This, to me, is purely defined around deliverables.
Windows System Admin who does every bit of his job through writing scripts: his deliverable is systems administration, not scripts. The scripts are an "under the hood" aspect of his job. He's resulting deliverable, his role, is IT.
Programmer who writes code all day: his deliverable is software. The code that he writes is itself what he delivers for his job. Code is not under the hood.
Programming (not just scripting, but all programming) can be not just an important too, but in some cases more or less the only tool, used by an IT professional. But if the goal is to use that code to manage systems, rather than to create products, it's IT. It's not that programming isn't something that IT pros can or will do, it's that it's not itself a role within the IT field.
Dashrender last edited by
and "Engineering" are often applies today, these, again,
This doesn't make sense. fourth paragraph
Fixed that as well, thanks.