Decoding the IT Infrastructure Quagmire
I don’t think the tech stack is in a good place—not at all. Our industry is a disorganized and Balkanized wreck—and doubly so for multinational corporations (MNCs). The issues start with not even having a common language—a lingua franca—for how to talk about what I see as a 500B dollar problem.
If you want to have a conversation about a better way forward, what language should you use? What do you even call what we’re talking about?
Traditionally the industry has used the amorphous phrase “infrastructure operations.” Look where that got us.
Using the current terminology doesn’t make sense. It represents the way things are now, and it's hard to imagine things getting any more screwed up. I’m not sharing state secrets when I say IT infrastructure organizations are constructed incorrectly down to their foundations.
From where I stand, companies spend too much time focused on their technical debt when they should be focused on their systems debt. What is often lost in the shuffle is how important the atoms side of this industry truly is. Without a well-functioning infrastructure topography, there is nothing for your bits and bytes colleagues to build on, market, or sell. Spending time thinking about hardware, its consumption models, supply chain, and deployment methodologies is both extremely valuable and powerful.
It’s my belief that it’s far more difficult to “pay down” your technical debt without first attacking your systems debt. If you want to become better at supporting your developers, getting smart with cloud, leveraging AI projects, and attracting and retaining great talent so that you can best service your clients, you’ve got to bite the bullet here. If companies don’t invest in rethinking the base of their technology pyramid, then they and the industry as a whole will continue to be trapped in negative feedback loops.
I’ve been lucky enough to work with a wide array of technical organizations, and the foundational problems I’ve described above are systemic. While some find this disheartening, I’m here to tell you that this is great news, because what I’m about to share with you isn’t unique to some corner of the industry. It also means that there is a solution in the offing: companies that are willing to do the heavy lifting of establishing better systems, processes, and protocols will emerge with a competitive advantage.
But if you’re ever going to start meaningfully exploring and solving the problems you face in the ITosphere, there needs to be some stage-setting first to settle on the right way to talk about the issues. In other words, you need a framework.
InfraOps Emerges: Pioneering a Strategic Shift
It became obvious to me long ago that we needed a term to represent a business philosophy and systems approach for the “infra/atoms” side of the corporate ITosphere. I started using the term InfraOps to represent a different way forward.
The term InfraOps obviously combines Infrastructure and Operations. But what it represents and symbolizes is NOT synonymous with the present infrastructure operations you find in businesses today.
InfraOps (as I use the term) refers to a framework designed to guide technical infrastructure stakeholders as they work to get out of what has become a balkanized, redundant, and ineffective set of asynchronous administrative tasks resulting in bad outcomes. It represents easy mode vs. hard mode, because effort does not equal outcomes in today’s infrastructure operations.
I’ve been a logistician and business person for over 20 years. For the last decade I have focused most of my energy on InfraOps. I work with some of the biggest companies in many of the most challenging environments imaginable. Procurement to power-on full rack deployments into a 3rd-floor data center in Egypt that doesn’t have a freight elevator? Check. Setting up business and commercialization protocols in India to book assets in such a way that allows for leveraging tax and nexus strategies? Check. Standing up a Just-In-Time Forward Stocking Location (JITFSL) to support a new data center build in Hong Kong that gave inventory visibility to local engineers and the client’s stakeholders in real time? Done that too.
The one consistent through-line in the examples above and countless others is that solid InfraOps tactics and protocols open up strategic InfraOps opportunities that are near-impossible to surface otherwise. Simplifying and better controlling this part of an IT organization produces a domino effect that unlocks all sorts of efficiencies and new options.
Where InfraOps gets really interesting is when you look at the broader outcomes of implementing such an approach. What if you didn’t need to primarily make and communicate about our InfraOps work through asynchronous systems like email or Slack? Seeing the before and after metrics for asynch communication mediums is impressive once you take an InfraOps approach.
But even massive improvements to metrics like these are not what is most important about an InfraOps approach. What matters is that the reduced communication load means our engineers and InfraOps professionals are freed up to make more progress on valuable projects that really matter.
The Anatomy of InfraOps: A Framework for the Future
I use the term InfraOps as an “idea coat hanger” for the lessons I’ve learned while working on the atoms side of the ITosphere. The lessons are many, but I’ve organized the space into this single non-comprehensive graphic for us for illustration purposes.
Above is a visualization of the surface areas I consider inextricably linked with InfraOps that desperately need active management and systematic codification (please note that each firm, including your firm, will have a unique topography).
As the buying organization, you can see that there are two major internal ecosystems that require effort: Logistics & Material Handling and Business & Systems. At the outset I want to say that the order in which these areas are reworked matters: you can attack the former before fixing the latter, or rework both at the same time, but focusing on Business & Systems before recalibrating Logistics & Material Handling simply does not work. You must first gain proficiency and higher levels of control over the commodities you consume. If you do not do this, it will be nearly impossible to redesign your business and systems to enjoy the benefits that the InfraOps framework delivers.
At the bottom of the diagram you can see our InfraOps functions plug into “The Channel,” which is just to say the sell side of this market. Whether you are buying hardware, managed services, outsourced engineering services, cloud products, etc., it’s all coming from this multitiered technical distribution market.
Most importantly, I’ve included your stakeholders in the center. This is the team that conducts our IT business orchestration. Over time you should aim to tighten your connection to and between these colleagues so that the team can become better together.
The Road Ahead: Implementing InfraOps for Success
While I’ll get into the weeds in subsequent articles, at the 30k foot level there are three key insights that require immediate attention if you are going to make forward progress:
· The first is that you need to integrate the tenets of InfraOps into our broader business strategy.
· The second is that you need to help your stakeholders turn low-quality inputs into high-quality outputs.
· The third is you must purposefully design your InfraOps system to deliver outcomes in such a way that allows us to aim at maximum optionality and sovereignty in the future.
In my next three articles I will unpack for you the core elements of the InfraOps approach: the tenets you will leverage to guide your stakeholders in delivering the best outcomes possible.