Today’s IT is moving fast. We don’t have time to coddle our servers by tending to them in the time-consuming way that we used to or dig out a dozen floppy disks to re-image a system. And in this new environment, monitoring IT infrastructures has become even more challenging. We need to do our job as quickly as possible and with fewer resources. This not only applies to us but to everyone inside an organization.
This necessity to do more with less causes individuals to act on their own when the systems that they rely upon aren’t up to the task. We’ve come to call this phenomenon Shadow IT. It’s a simple case of “cause and effect” but can become a great threat, both legally and with regards to security, to your organization.
But Shadow IT isn’t the only problem. Another issue is that organizations today are stuck with legacy systems. Most of these systems are simply not compatible with the workflows demanded by the fast-paced environment of today’s IT. This in turn creates a bottleneck that makes your technical debt larger and the problem of Shadow IT even bigger, making monitoring a logistical nightmare.
What many don't realize is that you can’t just continue doing what you’ve always done. The dynamics of today’s IT require a new set of routines, not necessarily because the old ones were bad, but because they just don’t meet the demands of a new, more modern environment.
This leads us to one of the most common mistakes that many organizations make today: trying to make modern IT fit a legacy routine, which only creates a dark chain of incompatibility.
What you need to strive towards is moving beyond your old routines. Use the lessons and wisdom learned from them and create new routines that can fit in with your remaining legacy systems while also meeting the demands of a new, faster IT environment.
We can’t talk about routines without mentioning the teams that handle the everyday operations and development of them. As human beings, we naturally have a tendency to carry on with what we’re used to in all aspects of life, and this routine can be problematic when it extends to continuing with a legacy mindset when modernizing IT. Transitioning to something new is no easy task, and each team member plays a huge role.
Remember, modernization isn’t a one-off event. Adapting to a new environment is a long-term and continuous process. So teams need to be in it for the long haul and get used to change as the new norm.
All these changes in routines, mindset, and infrastructure will also cause changes to other areas in your organization. This is especially true when it comes to roles and responsibilities, so it’s critical to think about how you will support a team during and after any change is made.
Some old roles will disappear, and new ones will take their place. Responsibilities will switch between roles, be replaced, or be removed. Such changes demand that you have the right monitoring, logging, and general tooling in place to give you the upper hand and not lose control.
We all have technical debt in several areas, and where it isn’t today, it will be next week, or next month. Today’s fast-moving and ever-developing tech causes teams to build up technical debt or not fully optimize workflows for their new infrastructure. When you are not able to properly develop or optimize workflows, you’ll in turn build up even more technical debt.
Proper tooling will be an enormous resource here, but it won’t be of any use if you don’t have the right workflows and routines to support it.
Another factor to consider is the massive differences in methodologies being used, as well as the problems this creates. People who aren’t able to transition properly between different tasks due to varied methodologies can become mentally exhausted, possibly worsening the effects of Task Switching and Attention Residue. This will then affect your team’s performance as well.
All of these small obstacles can slow your team down and ruin their focus. Some of their “Eureka” moments might not even occur. It’s a sure way of building technical debt, especially when it comes to all the missed great ideas that tooling demands.
Speed is essential when it comes to adapting to today’s fast-moving tech. And it’s not just important for countering technical debt, it also plays a big part in counteracting Shadow IT. You need to ensure that your users get what they need before they develop into a version themselves that’s incompatible with your organization.
The “metaworkflow” is unique to every organization, but should strive to be a workflow that is mainly orientated towards identifying and gathering information about what you need, what you have, and how to combine these two into workflows that are as streamlined as possible.
Some questions you may want to ask are:
This is yet another part that makes monitoring a modern infrastructure so hard–the diversity between different technologies. It’s not just about shipping syslog and writing regex to monitor infrastructure anymore. A metaworkflow will identify the new ways of interaction and make them fit in with what you already have.
We shouldn’t forget that IT isn’t the only arena struggling with legacy. Organizations have departments that are decades older than IT and have routines, a culture, and workflows that are even more deeply rooted. But they do have one thing in common with their tech colleagues: One way or another, they are all now dependent on IT when they want to change something.
The hard part here is that many organizations as a whole have inadequate, slow, or even no routines when it comes to onboarding new technologies or a new infrastructure. The emphasis here is on the organization, not the IT department. Companies need to be able to cooperate and develop routines together, with the speed and transparency required to do so.
One common mistake that organizations make before or during onboarding is that they don’t map the technology against what they already have. Why? Because it’s hard. That’s why having a window into your environment that’s easy to consume for the average user is one of the first steps to take.
Having this window of insight for your users can save you from numerous ordeals, especially when it comes to SaaS-systems where the recurring theme seems to be related to services like Dropbox and OneDrive. And it almost always begins with a user needing to send a file that’s too large for email.
Creating a service catalog is a great way of creating this window and can save you from Shadow IT or other unnecessary implementations. Just make sure that it’s easily discoverable and accessible to all users.
These two methodologies tend to collide due to the sheer incompatibility between them. The fail faster methodology demands dynamic infrastructure and tooling with great monitoring capabilities where we can spin up multiple dev/QA environments at once. We can’t achieve that kind of environment with legacy infrastructures or with the routines that came from them. We need to either adapt the legacy systems, tooling, and routines to fit the modern infrastructure or adapt the modern infrastructure to fit the legacy systems in combination with new routines and tooling. Both have their pros and cons.
The largest challenge with modern infrastructure isn’t what tool we should use. It’s developing a new set of routines that can work side by side with the old ones. We should instead take the wisdom and lessons learned from our old routines and use this knowledge to identify tooling that’s compatible both with our legacy, and our aspirations of modernization. You may still apply the old here and there when it seems reasonable, but legacy systems and mindset should never dictate to the new.
On the subject of tooling, there are a number of things that you need to think about that will impact what sort of tooling works for you:
You can read more about how to work in a way facilitated by tools, rather than defined by them, in the “Beginning DevOps” article found here.
In Part 2 of this article, we’ll focus more on the technology and tooling behind monitoring modern IT infrastructures, and less on the people and organizational aspects.