Devs Rool, IT Roolz

Jonathan Frappier Virtxpert

Boy, social media is proving tough to have some discussions for me lately – here is the first of two three blog posts to set my position straight. Yesterday a conversation got started on Twitter based on a tweet shared by John Troyer “Devs Rool, IT Droolz” – in fact here is another point of view on the conversation from Rynardt Spies. Now as an “infrastructure” person you may think my take here is about saving my job, or staying relevant or some such thing but it is nothing at all about that – its about working together. In fact, those who know me well know that I am trying to push the “infrastructure people” into a more application focus, not necessarily development, but stop being infrastructure focused and work on being able to deliver applications and value to the business. I’ve never had a CFO walk into my office and say a virtual machine was down or a VLAN was misconfigured, but they know when their application is down.

I was fortunate enough in my first IT job to work for a manager who “got it,” as well as several other thought leaders in the technology management space such as Gary Beach. I came out of that job thinking that all IT shops must run like this, I mean after all, it only makes sense that IT’s role is to enable technology for the the business and the people in it. My job as an infrastructure person is to understand the business needs, take the business needs and translate those into functional technology requirements and make sure they are working. In some cases it might be working with sales to ensure an SFA/CRM fits the business model, or that developers have access to the tools and systems to do their jobs, as well as to work with them to ensure access and security requirements are met.

Where I got into trouble in both cases recently (and another blog post is to follow) are “general” statements that some people are taking as “blanket” statements. When I say devs shouldn’t work on infrastructure, I’m not saying they can’t, or don’t have the skills; I’m saying that as a business – I don’t want them to. Now yes, advances in technology allow some level of orchestration at the network layer which allows people to instantiate networks on the fly, things like NSX or Neutron (I’m still pissed at you Neutron by the way) but those technologies still need a strong hardware foundation to be built upon to function and perform properly in support of the business requirements – not just software requirements. A well built network allows orchestration at the software layer to enable the needs of the business.

As I have said many times, there is no silver bullet or magical piece of technology that supports all businesses, and all workloads. “Generally” there will need to be several things, working together to provide everything a business needs. The same holds true for people; if IT is not talking to the business – Finance, Sales, Executives, Legal, Marketing, and engineering teams (development, QA, security) etc… then IT droolz. But the same holds true for developers; if devs are not taking to the business, not talking with IT, not talking with security then those bad devs drool just as much as the bad IT people do.

I have worked at enough software companies to see first hand what can be accomplished when people work together – its not about devs vs IT, its about devs AND IT working together in support of the business. Can developers setup a switch, VLAN, or ACL on a firewall – sure but it’s “generally” not their primary skill set, just as my primarily skill set is not coding or automation. However, working together each person can learn something from the other. Our skills, our experience, our roles provide us with a unique view of that no other person can have. So when you work together you may find that the way you interpreted a requirement needs to be adjusted, either because of technology or business; say for example a business security requirement could be met by coding the application a certain way, but there may be other requirements on the business that require additional layers of security. Again, it’s all about working together. If you are a CIO who isn’t talking to the business and CTO everyday then shame on you. If you are a CTO who isn’t talking to the business and CIO everyday then shame on you as well.

Some of the smartest people I have ever had the privilege to work with and for were developers (Chris, Michael, Igor, Sebby, Cayla, Sarah) . Those people have helped me grow professionally, in way I am so grateful for – they probably don’t even realize the impact they had on me; still don’t think I’d want them setting up my switches, servers, and domain controllers though :)

Devs Rool, IT Roolz