Date Published May 20, 2020 - Last Updated December 10, 2020
“Chance favors the prepared mind.”—Louis Pasteur
With the exception of taking my car around the block once or twice to make sure the tires don’t wear unevenly I haven’t left my house in three weeks. My son hasn’t gone to school for over a month (and won’t go back for the rest of the year). My employer, like many others, has issued travel restrictions and work-from-home requirements. Such is life in the precarious times we find ourselves in trying to deal with the onset of COVID-19.
Some argue that this is a “new normal” or perhaps even post that, “next normal.“ On some level, it’s too soon to tell what the true consequences will be. Regardless, something is abundantly clear: when disruption of this magnitude happens, the speed at which you can make adjustments is paramount for near and mid-term resiliency.
When disruption happens, the speed at which you can make adjustments is paramount for near and mid-term resiliency.
Specifically, within the ITSM space, I’d like to share some observations I have noticed from people that got it right, as well as areas of opportunity for those who got it wrong. I intend this to be a two-part series. Part one will focus on enabling these adjustments in two key areas: technology and management. The second part will reflect on lessons learned and, where appropriate, how to more permanently foster this business model for sustained support in prolonged use-cases.
Moving from a centralized to a decentralized model is never easy. I chose to reflect on two specific areas—technology and management—but it’s obvious there are areas I am leaving out: internal budgets, HR, and other logistics, just to name a few. Your people are your people (and your most important asset), your budgets are your budgets (you can’t make up money out of thin air, much less be frivolous with it in times of economic uncertainty), and your logistical infrastructure (products development and delivery, as well as internal pipelines to facilitate such ends) are all beyond the scope of this article. These are important areas and will directly affect resources and effort. Tradeoffs will need to be weighed, but I believe keeping in mind the areas I outline below are what is minimally needed to be successful, regardless of these tradeoffs.
Technology
On the technological side there are four areas to focus on: networks, remote access, security, and deployment/collaboration tools. Each of these areas will be put to the test when making a switch from a centralized to a decentralized model.
Networking
If your remote users can’t access your internal systems, they can’t work. If many of your systems are running in a public cloud or as-a-service model, this may be alleviated as much of the heavy lifting is shifted to the service provider. Still, there will probably be certain things only accessible via your internal network. To account for this, you need to check the following areas:
-
VPN (and remote certificate deployment). Obviously needed for internal access
-
Bandwidth/Throughput. With increased out-of-network traffic hitting your infrastructure, you need to consider increased bandwidth and throughput on your pipe and entry points
-
Ports, Firewalls, and Reverse Proxies. Somewhat negated by VPN, but depending on how your internal systems are orchestrated (e.g., perhaps one of your web-apps need not use the VPN due to bandwidth consumption, but does need to be exposed via reverse proxy), this is still an area to consider
Remote Access
While remote access could fall under networking (since a proper network would enable remote access), I broke it out specifically to emphasize that you need to take inventory of your key systems so that you know which ones can natively support a work-from-home structure, and which ones need to be augmented (or deemed non-essential). For example, it may be the case that your networking solutions (VPNs, reverse proxies, etc.) suffice for 80% of your work-from-home networking needs. But if one of your core applications is cloud-based, and your app team has set an IP range to limit that access, then your VPN might not alleviate this problem. Taking stock of your core systems and understanding what in fact needs remote access capabilities will be paramount to your success.
Security
What security model will you deploy to protect your internal systems? Will you make your user’s download corporate anti-virus? Run a scan on their personal machines to ensure they’re up to snuff? Implement increased web application firewalls (WAFs)? What about remote patch management? You almost certainly won’t be able to manage everything like you would on internal nodes, so what security trade-offs are you willing to make? Inventorying this list will outline what other areas you need to consider to ensure proper mitigation.
Deployment/Collaboration Tools
With your users dispersed from your internal network and each other, you’ll need to think about how to deploy physical and digital assets to them, as well as allow them to collaborate effectively. Consider the following:
-
Hardware deployment models. If you’re required to stay-in-place, that means support may be as well. That also means that they won’t have access to internal inventory to image laptops from within the network. Do you have a golden image you can transition to a VAR or distributor so they can image laptops that meet your needs should your internal inventory not be accessible? What about deploying public-cloud virtual workstations instead?
-
Application Deployment Models. If you will operate a BYOD model, how will your users access the necessary applications (the ones that aren’t cloud-based)? Accessible networked drives? MDM for mobile? Something else?
-
Limited Admin Accounts. You never want to give out your admin password, but there may be situations where it makes sense to enable a limited admin account to perform specific actions (I’m looking at your locally cached password resets).
-
Collaboration Tools. How will you enable collaboration now that users aren’t in front of each other? Web meetings? Cloud collaboration tools (e.g., online or SaaS provided project tracking or Kanban boards)? Do you have a messaging client? Is it accessible remotely? Are your core office applications local-file-based or cloud based? How will you enable and track version updates and editing?
While not exhaustive, I think these are the minimal areas that need to be considered technically to help make a quick transition. However, all of this will only be effective if managed correctly. For that, let’s turn to the next area of consideration, how to properly manage these changes, starting with your most important asset, your people.
Management
Technically considering all the above is necessary, but not sufficient to enable quick transitions. In order for that to happen, you need appropriate processes, executive sponsorship, and people-alignment. Without proper management, moving from a centralized to a decentralized model may not only be unsuccessful, but a huge resource drain in multiple areas, one which some businesses are finding it hard to return from. Consider some of the following areas when thinking about how to manage these quick transitions.
People
Your people are your most important asset—not your products, not your financial clout, your people. Period. While this is a good mindset to have strictly for altruistic purposes, it also makes business sense. Replacing employees is expensive (16% annual salary, on the low end), not to mention lost intellectual, process, and project knowledge. Also, from a security perspective, the vast majority of breaches happen via people, not systems. So, having employees mentally acute, cared for, and still dedicated while working in a decentralized model is paramount.
So how to care for them? Be empathetic. Children are now around, sleep and work schedules are disrupted, and perhaps finding a quiet place to work 9 to 5 is not possible. Adjust accordingly, and provide your employees outlets to interact, decompress, and, if possible, have access to resources (e.g., Employee Assistance Programs) to enable continued well-being. Studies have shown that monetary amplification, while appreciated, is not always the driver of cohesion and agreeability in compromising times. Sometimes a heartfelt “How are you doing,” “I understand,” “I appreciate,” or “I’m sorry,” will go much further to keeping a cohesive unit.
Processes
Who will make the decisions to enable such decentralized measures? What inventory needs to be taken before, during, and after? When/if it’s time to migrate back to a centralized model, what processes need to happen to ensure inventory is recouped, access is removed, and cap-ex-based systems are turned off? Will your support processes change? Will you move from a 24x7 model to a follow-the-sun model since your teams are now dispersed? As you learn from new issues that arise along the way, how do you adjust your processes? Perhaps above-all, how will you communicate these changes out? Almost certainly these changes will happen over a series of steps, and each step needs to be communicated effectively. Similar to having Recovery Time Objective and Recovery Point Objective (RTO/RPO) processes for disaster-recovery, in this “new normal” period of decentralized support, you should outline various checklists, priorities, and processes so you have a playbook to follow.
Executive Sponsorship
Any transition of this magnitude will incur costs and need executive buy in. Identify who can approve what, at what level, and, if possible, how much it will cost (to transition to and back). Given the multitude of changes needed for this to be successful, it is all the more important to have executives buy in and avoid having the wrong person make inappropriate decisions (even if correct).
Build Resilience
As we all adjust to this temporary new normal, you and your organizations have probably already attempted many of the steps above. Hopefully you were able to capture a few new ones as well. Just because something wasn’t done and has yet to be an issue doesn’t mean the gap doesn’t exist. Use the above items to take stock of your situation, maybe ask questions that weren’t outlined before, and plan accordingly. Resilience isn’t built out of complacency.
Adam Rauh has been working in IT since 2005. Currently in the business intelligence and analytics space at Tableau, he spent over a decade working in IT operations focusing on ITSM, leadership, and infrastructure support. He is passionate about data analytics, security, and process frameworks and methodologies. He has spoken at, contributed to, or authored articles for a number of conferences, seminars, and user-groups across the US on a variety of subjects related to IT, data analytics, and public policy. He currently lives in Georgia. Connect with Adam on LinkedIn.