For T-SQL Tuesday #91 the topic is databases and devops. Grant Fritchey asks us:
How do we approach DevOps as developers, DBAs, report writers, analysts and database developers? How do we deal with data persistence, process, source control and all the rest of the tools and mechanisms, and most importantly, culture, that would enable us to get better, higher functioning teams put together? Please, tell me your DevOps stories.
Tons of folks out there in the data world, whether Business Intelligence people or Data Scientists are not even using source control, let alone thinking about this thing called DevOps.
Because we’ve spent decades being told that we should be democratising data analysis, that anyone should be able to do it, and that you don’t need to be technical do it.
I agree with everything but that last part. It’s tantamount to saying you shouldn’t be technical. “Technical” is not a perjorative and it’s not something difficult – it’s a problem-solving mindset and people are technical when they can use tools to solve problems.
This “non-technical” messaging has caused a ginormous divide between “developers” and “data people” because data people are “non-technical”. If they’re not technical, why should they bother listening to those dtechnical developers over there? What could they possibly learn that applies to their non-technical jobs?
So partly, this is a branding problem — I’m trying to solve it by calling it DataOps around data people. We need to make it seem like this isn’t something being imposed on data people, but something they should want to do for themselves. DataOps is great — it means you can move faster and with greater certainty that you’re getting it right. This is awesome but it needs to be coming from data people in terms data people are used to hearing.
The second part is changing the message about coding. Being able to code is incredibly liberating. GUIs allow you to basically do what you’re told you should be able to do, the way someone else thinks you should do it. We’re not enabling people to own their own outputs when they are constrained by what we tell them they can output. We need to equip with them with knowledge and skills to code. Yes they could do terrible things with code, but isn’t that worth the risk if they could do brilliant things with code? If they stick with the GUI, then they’re only ever going to be able to do mediocre things.
I don’t think we can change the great Developer vs IT Pro / Analyst divide overnight. We need to use terms and approaches that fit into the IT Pro/ Analyst’s world view and change them from the inside out. We need to equip everyone with the ability to script their jobs which is mainly about giving people the permission and confidence that they can indeed do these things. Once they’re doing it, then the gap betweeen Devs and Data people will go away.
By doing DataOps, we can get data people doing DevOps!