December 18, 2019
Are the IT Disciplines of the Past Still Relevant Today?
Recently I have been asked a set of similar questions by people inside and outside of OST, college students and professors, VPs of IT and CIOs, and DevOps engineers and developers.
The questions boil down to one idea: are the IT disciplines of the past still relevant today?
The answer is yes, but with a qualifying statement: the tools of tomorrow are not the tools of the past.
Growing Up Before the Cloud
Adolescents tend to devalue the wisdom of their parents because they don’t seem to have a shared experience. When their parents were teenagers smart phones, social media, the Internet, etc. weren’t invented, around, or a thing.
In a similar way, cloud-native technologists can be dismissive of legacy IT teams. But think about the world those teams grew up in.
Most of what we call “modern IT” evolved as enterprises consolidated from the custom software developed in the 1960s to 1990s to packaged applications in the 1990s coupled with Y2K remediation. Enterprise software products built upon on-premise equipment and relational databases became the foundation of environments designed to support the transactional and reporting needs of global organizations. The World Wide Web (as it was called in the 1990s) extended that model as companies sought to buy platforms and products that would secure and support their operation in new digital spaces. The public face of web applications added to the historic “-ilities” (reliability, availability, and scalability, for example) but did not fundamentally disrupt them—at least not yet.
In this context, architects built applications and services that combined enterprise purchased applications with customizations. The application or business owner would get a set of hardware specifications from the software vendor. Those would be adjusted by the architect with a safety factor, which would then be adjusted by each domain architect, reconciled, and then presented to a reseller or OEM for configuration assistance with a three- to five-year support contract. Customizations were not that onerous because generational changes in hardware were relatively infrequent. However, these practices often resulted in a great deal of unused capacity.
Some of the “ilities” important to this type of IT (Mode 1 in the Gartner parlance) include:
- Conformity to Standards (which decreased perceived risk)
- Ease of administration and use (from a technical audience point of view)
Discussions around value to the business and financial flexibility were usually a subject for presales and procurement conversations, but not an ongoing part of the OEM, reseller, and customer conversations.
Moving Cloud Native
Our belief at OST is that the disciplines of IT absolutely have value for cloud-native development in IoT, products, digital services, and more. We cannot take a cavalier approach to reliability, performance, ease of administration, documentation, or the other value-driving “-ilities” enumerated above. But we also cannot stay locked in the methods and tooling of the past.
We have to decouple the wisdom and disciplines from the tooling and the methods. The wisdom of good parenting around engagement, communication, setting boundaries, and all the things parents do has not changed. The places where that wisdom is applied has changed drastically as society and technology have evolved. And the same applies to IT.
Yes, the tech is different than what it was when we were “growing up,” but the approach and goals and disciplines can still inform our approach. For example, if I see another enterprise IT team try to manage their Agile teams through traditional change control, I will yell at them. I will also yell if I see someone trying to extend their legacy IT management platform into the cloud to try and monitor PaaS IoT architectures. But I will also get visibly agitated when I see a cloud team rolling something into production without documentation, or a discussion of data protection (“well Azure takes care of that”), availability, and cost/performance compromises. I will get even more confrontational if those concerns are dismissed because “the business didn’t ask for those things”. Well of course not! Decades of traditional IT has trained the business that those things are just taken care of.
Don’t Trivialize the Past. And Don’t Impose on the New.
Cloud developers and DevOps engineers need to appreciate the values and outcomes that the legacy IT team is managing. Legacy IT teams need to invest in new skills, tooling, management practices, and vocabulary, and they need to appreciate the values and outcomes that Agile development teams, cloud architects, and DevOps engineers are managing.
And everyone needs to align and find ways of ensuring that risks are managed in a way that meets business needs without compromising value, velocity, and efficiency in driving differentiation in the market.
Accomplishing this requires a mindset of respect, humility, learning, and willingness to embrace the strengths of both sides while not being overly committed to a tech stack, method, or tool set.
And if you’re struggling to realize this ideal balance, OST is here to help.
OST: Solving for the Whole
With over 20 years of success behind us, we have uniquely deep and broad expertise in holistic technology solutions. And if you’re facing challenges associated with moving to a hybrid IT environment, our team is ready to help you with everything from planning and alignment workshops to complex cloud migrations to managed services.
We continually evaluate and advance our tools, methods, and approach by leveraging the wisdom we’ve gained across IT disciplines. And we’re ready to apply that expertise to help you drive new value in ever-evolving digital spaces. All you need to do is get the conversation started.
Are the data center disciplines of the past still relevant in the era of the cloud? Yes, if we acknowledge that the tools of yesterday are not the tools of tomorrow.