Every project is like a sailboat; it needs a Captain, bosun, and deck hand, each knowing what they need to do to ensure the boat reaches its intended destination. Likewise, every key component of your organization needs to be owned and anchored by someone to ensure it is managed and monitored properly.
This can be easy in smaller environments, with one CTO or IT Manager and sometimes a small support team to assist, but even so, it is important to define who is responsible for what, from top to bottom.
In larger environments this becomes even more complex, with several departments in various locations, regions, countries and/or time zones. They often end up sharing responsibilities, and if ownership is not defined, assigned, and acknowledged from the beginning, problems are around the corner when the first grain of sand gets into that supposedly well-oiled machine.
The following examples are based on true incidences, with identifying names and locations changed for discretion.
The IT group for ACME in France wanted to test a new MDM solution for a small group of pilot users, however they needed the green light from the corporate IT department in London first. Not willing to wait forever, they decided to deploy the solution on their own, under the table. It's not that big of a deal, right? This is just one new server, used by a limited group of people and for a limited time. What damage can it do? As usual, at the French office more and more people asked the IT department to hook them to the new server so they could experience all the new features first, without having to wait. One little problem, though – from an infrastructure perspective, this is a rogue server with no monitoring or documentation, and only a handful of people have permission to connect to it. In so many words, this server is off the grid. However, it has been servicing production users, most importantly VIP users, so any service disruption would be critical, highly visible and could provoke business losses.
Yes, that server set up under the table, quick and dirty, just for a couple of weeks for a little testing suddenly became mission critical without the proper tools and procedures in place.
This example illustrates the importance of delegating ownership in a large organization, to avoid situations where all processes in place are ignored just because control is too centralized. Additionally, when an issue occurs and proper actions are not taken, it will be highly visible and likely result in business impact and later internal escalations.
Another example is one of the largest cloud providers with several locations all around the globe, a state of the art monitoring system, skilled and experienced IT personnel, follow-the-sun 24/7 support with team all around the globe, proper procedures for every managed component, remote access, etc. In other words, everything is in place to be ready for any possible situation. One weekend evening, an issue was detected on one of their Mission Critical messaging servers. As expected, an alert was triggered and sent to the defined contact (via email, SMS, or push notification). In a normal situation, that person or team would receive the notification, determine its criticality and potential impact, and then follow established procedures, like connecting to the component, troubleshooting, fixing the issue and sending communication via the proper channels. If unable to fix the issue on time (as defined per SLA), then it would escalate to the next person (ex: on-duty engineer) or team (Level 2, Level 3, Server Owner). In this example, the first person to respond decided to call the on-duty engineer, using an internal tool that references all components and who is responsible for them.
The only problem was that person was sitting in a different time zone and happened to be sleeping at the time! As a result, no solution could be provided before that person was online again.
How could this happen? Well, in a large environment, with dozens of locations, regions, departments, and new components added every other day to the hundreds or thousands the infrastructure is composed of, it is easy to have incorrect or outdated information for one component. In this previous case, nobody was “owning” that server for a period of time, so no proper action could be taken to remedy the issue in a timely manner.
This example further illustrates why having ownership in place is so important, particularly having ownership at the local/regional level so that issues can be resolved without being sent up the chain.
Ownership of enterprise mobility and security is a hot potato – no one really wants to own it. Yet, everyone really needs to own their part. Some organizations place the responsibility in the IT department, others in the risk and compliance department or security. If jointly owned, roles should be clarified.
Ownership is mandatory in any organization to ensure proper response is given to any issue or problem that may occur. Like sailing a large ship, running a large organization needs to be structured, with everyone knowing their scope of responsibility and action. This not only makes things easier on your users, but ultimately makes things easier on the team since roles are clearly defined. With everyone in place knowing their roles, it should be smooth sailing towards your destination.
(C) Rémi Frédéric Keusseyan, Mobility Expert/Master Trainer