Updated on December 1, 2015 by Alan Sharp-Paul
I have a confession to make. My first job in IT wasn't as a rails developer in a hot startup. It wasn't managing cloud infrastructure. It didn't involve cool open source projects or cutting edge technology. Quite the opposite in fact. My first job was a graduate trainee analyst programmer at an Australian Funds Manager. What was I trained on? ADABAS NATURAL. Yep, I was a mainframe developer. This editor was my entire world:
Sure, I sometimes got to bust out some batch processing using JCL. Such fun was reserved for special occasions though. Things weren't much rosier for my cofounder Mike. He was busy manually rotating backup tapes during the same period. Good times!
Did you know?
The 80 character line limit for JCL was in place due to the fact it based on punch card technology!
The technical environment I, and my predominantly older mainframe developer colleagues, worked in would be considered by many these days to be egregiously restrictive. 20x80 line IDEs. No plugins. No extensions. Text only forms. No open source alternatives. No alternatives period.
Even in the Enterprise today these type of restrictions would not be suffered lightly. It wouldn't matter if you were talking about developers used to ruby, node or even .Net; or sysadmins comfortable with Puppet, Nagios and Logstash. The technical freedom they enjoy and the creativity it permits them is not something they would give up lightly.
So that's a good thing, right? We've evolved. Things have gotten better. Well, perhaps it depends on whose point of view you take. You see, it was a conversation with Mike Kavis on this topic that reminded me of one key characteristic of my old mainframe team that seems to be lacking in modern DevOps environments:
They knew the business. Better than anyone.
The funds manager I worked for had billions under management. It was serious stuff and business knowledge was gold. What I realized early on was that no one understood the core business processes better than the members of the mainframe development team. Time and time again people from the business were made to look like fools by the softly spoken men and women of our team.
Why was this? Well, when you take away technology decisions; when you provide an environment with very little room for technical creativity; then the focus of your technical team comes back to that which is most important: the business.
New tools are fun to use. Cutting edge practices can yield significant gains. The evolution of these things though - in many ways accelerated by the DevOps movement - has come at the cost of an increasing disconnect between the business and IT. An engineer who is proficient in 5 languages, can use 3 automation tools and is a regular contributor to a slew of open source projects is a valuable resource, no doubt. How much bandwidth do they have left for understanding your business though?
The team leads, managers and executives responsible for DevOps in their Enterprises need to be aware of this. DevOps initiatives are predisposed to focus on technical goals and improvements. In and of themselves they add value. If they are being undertaken in a vacuum - and in particular one isolated from real business challenges - it is a problem.
As technologists we often need to remind ourselves that tech for tech’s sake just adds unnecessary complexity
The advances in technology over the past 15 years - and the resultant proliferation of languages/ frameworks/IDEs - has allowed old businesses to improve, and new ones that were hardly imaginable back then to be born. As technologists we often need to remind ourselves though that tech for tech's sake just adds unnecessary complexity. It can also push us further and further away from the business. We never want to stop learning or improving. We should take the time to understand our business though. If the bells and whistles we entertain ourselves with do not permit this then perhaps it is time we look back to the lessons of simpler times. I've spoken previously of the need for visibility; nothing is more critical than visibility into, and an understanding of, your company's business goals.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.