We IT folks are pretty fearless. Because it is newer technology, and change in IT is easier than in areas like heavy manufacturing, we are regularly thrown new tools, products and methodologies and expected to be able to master them. And we do. And it works. If your career is more than a couple of years old, you are not doing what you started out doing. DevOps and Agile have made this process more pronounced because they increased the rate of change, but this phenomenon has been going on since the PC became readily available. Someone somewhere is currently developing your next toolset. And when they do and it gets thrown at you, you’ll figure it out and run with it.
The problem is that our architectures are never black and white, and we should fear the unknown more. The unknown residual cruft that is all over our networks. Doesn’t matter if “networks” means data center, cloud or both, there’s residual cruft on it. Some organizations even have a full-time position finding cloud instances and services no longer in use and eliminating them. But it is much more broad than cloud instances; there is garbage all over your network and it is time to try to clean it up.
Most of us believe that we can’t possibly get a handle on everything that is out there. Oh, zombie containers and VMs are relatively easy, but the modules and libraries we loaded up and then, through the natural evolution of the software, stopped using, or whatever was bundled in with the OS chosen for that particular project, but was never used—it’s all over, it’s hidden and lots of it isn’t easy to find. That doesn’t even touch on the software that one employee from accounting absolutely had to have—but that employee is long goneand no one in accounting is willing to remove the software, either because they’re unaware of its existence or because they are unaware of what purpose it might be serving.
There are tools to help with some of this, like SBOM generators for excess software on instances, and application maps that work much like network maps to help you understand what is interrelated. But they’re not perfect. They can’t be. You’ve been building this spaghetti application infrastructure for years; it’s going to be tough to work out. Get a list of what’s deployed, tag a person as responsible for it–that app in marketing? The person who requested it is responsible for it (or their manager is, if the original person is gone). IT is responsible for cataloging and, in some orgs, managing the app, but the business unit can explain why it is in use, and if it is still necessary.
It’s a ton of work and, as a former enterprise architect, I can confidently say that it won’t be easy getting names attached to apps. Some apps you might have to turn off to see if they are still in use … and the work will likely never be complete because the infrastructure is changing non-stop as you work.
But it’s worth it. It saves the org money; it reduces IT footprint and it reduces security exposure. It may even save IT staff time, which is one of the most precious commodities your organization currently has. So, start wrangling. Start with one business unit and ask them to help you–after all, they are almost guaranteed to have running apps or SaaS that IT is unaware of. The goal is not to take control of those apps and relationships, but to inventory them so that when they’re no longer needed they can be cleaned up. A side benefit is that if four business units are using similar software outside of IT’s purview, it may be possible to merge those solutions for a corporate approach … But that’s a blog for another time.
Meanwhile, keep rocking it! Just remember there is more on the cloud and in your data center than are dreamt of in your architecture plans (many apologies to Shakespeare). And keep solving the business’ problems.
