Click to learn more about author Rob Chapman.

If you’re part of an IT team supporting a lot of retail locations, you’ve likely felt the burden of technology sprawl. Businesses that once had just a few servers and a small IT shop are suddenly dealing with dozens, hundreds, or maybe even thousands of systems. Unfortunately, the size of your IT team probably hasn’t grown at the same rate. Sound familiar?

During my first experience in the retail world, I was involved in managing several hundred sites. After a sudden company transition, I found myself owning the IT security, networking, and computing responsibilities for all those locations. And guess what — they all had a significant PCI compliance burden as well.

The Sprawl Won’t Wrangle Itself

The biggest issue was simply the immense amount of work involved. The stores had been around for years, over which time the IT systems had spread like weeds. Only a few systems had been pruned or documented along the way. And each store was as singularly unique as a snowflake — in the worst possible way.

My first task was to regain control and document the current state before I could even start envisioning what the end goal should be. Even with the help of great colleagues, there was absolutely no way I could hand-crank all the technology at each site. Old-school “cowboy-style” IT was out. To survive and remain PCI-compliant, we had to adopt a new mentality.

DevOps Rides to the Rescue

If there’s one term that has truly defined the IT transformation of the last decade, it’s “DevOps.” While there’s no exact definition of DevOps, it generally describes a cultural shift in which IT becomes increasingly nimble, collaborative, and iterative.

Embracing a DevOps mentality means breaking down old silos between operating groups and changing attitudes about the IT systems we manage. We often describe it as the need to shift from treating our systems like pets to treating them like cattle.

Here’s the rough analogy: We name our pets and tend to treat them as prized family members. Cattle, on the other hand, don’t have names. We don’t get sentimental about them. They’re just part of a large nameless herd. If one isn’t working, we simply replace it with another and move on.

Automation Is the Hero

One of the core benefits of DevOps is turning automation into the superpower of the modern IT and engineering shop. Whether you’re just starting your career or deep into it, building your automation skills is one of the best career investments you can make for today and the future.

To be honest, you don’t actually need to hold a special DevOps job title or use the latest container technology to be a DevOps shop. I know tons of network engineers who have been using Perl and Expect scripts to automate deployment and management for years. The main point is to create more of a DevOps culture throughout your IT shop.

To get a better feel for where you are today, ask yourself a few questions. For some of you, this might be easy by virtue of your company size. For larger IT shops, finding the answers might be considerably harder:

• How many servers or workstations do you have?
• What versions are your applications and operating systems using?
• Do you have firewalls turned on and configured for each?
• If someone made a change, would you even know it?
• If you’re a PCI shop, what systems make up your card data environment?
• When was the last time you patched — and how difficult was it?
• If you lost a server, how quickly could you recover it?
• If a team member suddenly left the company, what skills would you be lacking?

You’re Not Alone

Honest answers to questions like these reveal the state of your inventory and situational awareness of your environment. If you can easily answer these questions, you’ve probably managed your technical debt well. You’ve deployed meaningful automation, and you’re vigilant in tracking your environment.

If those questions give you heartburn, you’re probably not alone. Any IT shop that has lots of “pets,” “cowboy or cowgirl” IT admins, and no change control process is bound to have far too much overhead and technical debt.

Those red flags could signal any number of issues queued up to bite you when you least expect it. Worst of all, if nothing’s documented, you’re extremely exposed if you lose a key team member — and all their institutional knowledge.

The Culture Shift Begins with You

So how do you begin the cultural shift to instilling a DevOps mentality in your IT shop? Step 1 is to create a vision for what “better” looks like. There are many good resources for learning about DevOps, but I highly recommend the book The Phoenix Project.

In fact, I wish I had read it 15 years ago because it would have saved me a ton of headaches. The book is a fictional story of a technology company transitioning from old IT practices to DevOps practices. Most importantly, the book focuses on the people, not the technology.

After you define your own DevOps vision, Step 2 is to start making the necessary technology changes. Automation is worth focusing on right away because it typically delivers fast ROI. If you’re a Windows-heavy environment, this means learning about PowerShell. If you’re a Linux-heavy environment, start learning about Python and Bash. You’ll soon discover the next step involves time-saving orchestration platforms such as Ansible, Salt, Chef, or Puppet.

The key is to remember that everything you do should drive toward cultural change. Invest in the necessary time, resources, and training for your team. And always demonstrate strong leadership by example. Doing so will help you wrangle technology sprawl while creating a PCI-compliant environment that helps modernize your entire business.