What is DevOps?
The IT department had a problem. They had two different groups of very smart engineers, working on delivering the same service, but with very different cultures. On the one side was the Operations team. Their mandate was sustainability. They developed culture of care, moving slowly to avoid disruption.
On the other side was the Development team. Their mandate was innovation. They operated in short sprints, iterating quickly over prototypes towards new features. In their view, bugs were a natural byproduct of creation.
These two teams, with vastly different cultures, found themselves siloed off from each other. Sparks flew at every meeting. Hand-offs became impossible. The Devs saw Ops as guardians designed to prevent change; Ops team saw Devs as children who didn’t have to get up in the middle of the night when the system crashed.
DevOps as a field has grown up exactly to solve this issue of siloed cultures. At its heart, DevOps engineers see ourselves as translators for warring tribes. We think that this problem is basically a problem of language. We build tools to help these siloed groups speak their own language, write in a way that is native to them, and then translate it for various other constituent parties.
The key to DevOps is recognizing that there are multiple groups, each with their own concerns. Developers want to write good code, and get it approved for production quickly. So we write tests to surface problems; we write pipelines to get code to the ops side. Operators want to manage risk. So we build audit tools that act on the pipelines to catch problems before the occur. We build roll back tools to automate disaster recovery. We build error visualization platforms so that Operators and Developers can collaborate on exceptions.
Fundamentally, DevOps teams are focused on eliminating this friction by allowing each side to focus on what they do best, and handling the translation by listening to the concerns of the respective teams. We engineer solutions that let Developers innovate, and help Operations teams sustain, while keeping both in sync.
So what does this mean for marketing?
Marketing has a similar problem. As marketing has moved into the digital space, it has accelerated and the tools that marketing teams use have multiplied. It is common for marketing teams to need access to siloed data across dozens of different platforms. Sometimes that data is owned by multiple groups, with different sets of concerns for how the data is used, managed, and accessed. Often that data uses different access technologies, and cannot be visualized in the same place.
To DevOps engineers this problem is similar to the problems we solve every day. Groups of talented people have worked hard in their domain to produce what they need, but they don’t have the time, resources, or technology to make that data available outside of their domain. We can come alongside these groups and use the techniques, the translation skills we’ve already developed, to help these groups connect, while staying focused on their core job.
Reportiv: lets talk about a specific example
At Convertiv, our development and DevOps teams have worked together to build Reportiv. Reportiv is a web application designed to connect to all of the different data sources your marketing team works with, and wire them together into powerful, flexible dashboards
Under the hood, our DevOps team has used cutting edge tools to build data pipelines that can harvest data from silos, normalize the data into standard pattern, and store these records in our AWS Redshift lake.
These data pipelines are the real innovation of our DevOps team, because they can be customized to take care of the concerns of the various owners of the data. So your Sales team owns the CRM database, and IT owns the web analytics data. Your legal department wants to make sure that you don’t leak sensitive customer data. But your marketing team really needs to be able to connect inbound leads and ongoing web traffic and visualize what marketing is effective.
This is what we can do for you. We can build pipes that can normalize that data, while respecting governance and compliance rules, centralizing that data for the marketing team without disrupting or demanding resources from the teams that own the data.