Looking back now, it’s impressive how deeply IT has specialised as a professional field. A generation or two ago, ‘IT’ barely existed as a career option; today, not only is it one of the world’s major fields of employment, but workers within it are called to take on incredibly specific roles and skills in order to meet industry demand. For any technology which, from the outside, looks like a part of a part of something else, there are whole teams for whom it is their whole focus and world.

It’s hardly surprising, then, that words and ideas take on a different, specific flavour in different areas of the profession. Usability means something different to a support desk worker or a data engineer; speed has different metrics for a systems administrator in an office block or in a high-performance computing centre; and security has different implications for a networking specialist or a cryptographer; and yet, these are all requirements which come down from a business strategy perspective as though they are identical and interchangeable.

When thinking about resilience, the result is palpable. When attacks happen, an IT manager’s first reaction is not how it impacts the business, but how it relates to their own definition of security. Following the thread of a problem through different IT towers with different internal metrics takes time – and taking more time means suffering greater reputational and financial damage. As IT professionals have specialised over the decades, so has the way in which we sell, buy, and connect IT infrastructure: this comes at the expense of a cohesive view of the business impact of failures.

All of which is not to say that we should – or even could – roll back the clock on IT specialisation. We do, however, need to rethink what preparing for and measuring resilience looks like within these disciplines. SLAs are attractive because they are native to the technology they measure, but they do not necessarily correspond to real-world consequences. Instead, we need to start thinking back from minimum viable business function requirements and asking how the whole IT estate, together, can work to support them.