Over a million developers have joined DZone.

What is IT? A brief guide for non-IT people


I’ve an interesting challenge at the moment with one of my clients. I have a group of people who don’t come from an IT background who need to get up to speed pretty quickly with what IT in organisations is all about. And there doesn’t seem to be much out there in the way of “IT Management for Non-IT managers” in the way that such material is common for, say, Finance. So here’s my take…

It’s easy to get sidetracked with the “stuff” – the shiny (or not so shiny) kit. The software. The data centres. But in fact IT within organisations is very much more about the people, the structures, the processes and procedures and the way that all of those resources along with the actual technology are provided within the constraints of finite budget and external regulations.

It’s always good to, as Simon Sinek puts it, start with why? Why do we have IT departments in most organisations? To some extent I guess it’s because everyone else does, but the drivers that saw the rise of IT as a business function in the 1990s were partly about having to build up technical expertise to support the delivery on technology into an organisation, and secondly that increasingly services needed to be provided across an organisation for them to make any sense: each business unit having its own network didn’t work very well; economies of scale could be found as services could be shared across groups (well, that was the idea, anyway).

The technology that an IT group delivers splits into software that is crucial for the business to be able to operate (often known as Line of Business software), software that is important but not unique to the particular organisation (word processing, email and so on), the devices that people use to access all of that software (PCs, and then mobiles, tablets and so on in recent years), and the infrastructure to make all of that work (networks, servers, backups, security and so on).

The way in which an IT department is organised generally will reflect in terms of three functions that it must perform: project delivery, service delivery and governance. Project delivery is about making changes to any of the technology in place, or to introduce new technology. Service delivery is about making what is available today work, and fix it when it doesn’t. There is an inherent tension between these two disciplines, because service delivery folk fear change because it might have unpredictable effects on the operation of what is available today. Project delivery folk often see service delivery folk as obstructive because they seem to say “no” a lot.

This entire tension has been codified into a discipline known as “Change Management” which shouldn’t be confused with the sort of change management that people in HR and Internal communications talk about. The former is about processes and checklists to make sure that someone doesn’t press the wrong button. The latter is about helping people within an organisation to actually do things differently. That people-centred model of change is one that, in my opinion, is still woefully overlooked by IT people and is ultimately the cause of most IT project failures.

Alongside the Project and the Service people, you will find some other governance functions.

Architecture (particularly Enterprise Architecture) tries to make sense of how the technology within the organisations fits together, both in itself, and also how it in turn supports the business. Whilst the term architecture conjures up aspirations of planning for the future, Enterprise Architects can find themselves spending quite a bit of their time just trying to unpick the past. Enterprise Surveyor might be as apt a term.

Information Security try to provide assurance that services will be secure from threats. In good cases, they are a function that allows for business folk to understand potential risks and make informed decision in that context. In many cases they are a bunch of worry-worts who say “no” to just about anything and everything.

Procurement may or may not be a function within IT, but the purchasing of stuff is a crucial part of the IT function. That “stuff” includes physical items, outsourcing agreements, professional services, software licenses (a world of intellectual property law that defies many laws of physics) and other things beside. The biggest cost for many IT departments traditionally, though, has been it’s staff. Not so much people are our greatest asset as people are our most expensive asset.

And cost has been a big thing for IT over the years. In particular, managing cost. Up until the late 1990s, the big investments in technology had come in supporting functions of a business (notably finance). It seems that if you are running a P&L, investment and cost in technology is harder to stomach than if you are a cost centre. And then along came the World Wide Web.

There are two existential threats that IT faces in the modern world. The first is that whilst IT was traditionally about cost management and broader cost reduction (through efficiency), the Internet and our era of digital have meant that technology now can be used to drive revenues rather than just save cost. The mindset across much of traditional IT doesn’t really extent to that concept very well, because the structures and processes are optimised to save money not make money.

The second is that much of traditional IT management was designed for a world where the IT department was the monopoly supplier of technology into a business. If you wanted something, IT had to sanction it. But in a world where you can access powerful business software with nothing but a web browser, and where the smartphones in our pockets are as powerful and connected as the PCs on our desktops (the phone sitting next to the laptop I’m writing this on is actually more powerful)- in this world individuals and business units have choice of supply like they never had before. Again, IT departments aren’t well equipped to work in a competitive marketplace.

So what happens next? Well, it appears that after two decades of centralising technology management into the IT Department, we are inevitably seeing a period where the purchasing and consumption of technology gets decentralised out across departments, with particular focus on marketing teams (although I think that this will happen much more broadly). IT departments have a few choices – put themselves out of existence, hold on to the increasingly diminishing field of influence that they have (it’ll eventually boil down to providing networks and a few old legacy business systems), or reinvent themselves as something else. That last option is tricky because, ultimately, IT departments are the people who work there, not the technology, and reinventing your department as a digital, customer-focused Dev-Ops* powerhouse might not be that feasible when you are staffed by people with very different skills and personalities.

So there you go. A starting point.

If you want to explore things in more depth, try looking at ITIL for an understanding of one of the most common frameworks for traditional IT management. Although you might want to have a bit of a lie down and a cup of tea before embarking on that one.

*Dev-Ops is a modern idea that rather than having a separation of projects (development) from service delivery (operations), you bung it all into the same pot. This can work, or it can result in total chaos.


The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}