How does one transform an analytics practice to take advantage of radically new tools, practices, and techniques, such as machine learning (ML) and artificial intelligence (AI) engineering?
This was the challenge that confronted Priya Sarathy, a senior director with credit-reporting agency Equifax. Sarathy and her team rationalized Equifax’s distinct software development, analytic development, and data governance practices into a logically (if loosely) integrated practice: what she calls analytic operations, or “AnalyticOps.” She discussed her experience in a recent episode of Inside Analysis, a weekly data management-oriented program that is hosted by analyst Eric Kavanagh. In a wide-ranging interview, Sarathy explored what did and didn’t work, as well as elaborated on the relationship between AnalyticOps and the more familiar practice of data operations, or DataOps.
Along the way, Sarathy spoke to the importance of a soft skill – empathy – that is often overlooked.
There’s an ops for that
Equifax had taken important steps on the way to AnalyticOps, Sarathy says, including formalizing distinct DevOps and MLOps practices. But these groups operated as functionally separate entities, with suboptimal coordination between them. On top of this, neither group meaningfully coordinated with Equifax’s data governance group. “The whole concept of MLOps … had evolved because these new sophisticated analytical topics are not simple … to understand, [they’re] not simple to apply. [But] … on the other side, [we] had a technology team that had been so focused on meeting the data challenges … trying to make sure [big data is] monitored and governed properly,” she told Kavanagh.
It wasn’t just that each group was acting disjointedly; it was, rather, that each group tended to focus on what it knew best. The shift to DevOps and MLOps had reconfigured the scope, values, and responsibilities of software development and operations, along with analytic development and data management, respectively, but this didn’t mean that the new groups which were the products of these shifts – that is, DevOps and MLOps – knew how to communicate and collaborate with one another.
That’s where Sarathy and her team enter the picture.
As she sees it, the role of AnalyticOps is to knit together an analytic production line. This role is sometimes assigned to DataOps, which focuses less on automating the production, deployment, and maintenance of analytic products than on doing the same thing with data: i.e., making sure data is not only available, but used appropriately – and that the processes by which it is engineered (along with its provenance and lineage) are known and transparent. In this case, AnalyticOps as Sarathy describes it incorporates DataOps – although (outside of Equifax) this is not recognized as a common pattern.
“What my team does is it bridges that gap for the data scientist who knows enough to work with the data, engineer the data, but doesn’t know what is the best way to apply it into production process,” she told Kavanagh, explaining that her AnalyticOps team likewise liaises with Equifax’s product and technology teams. “Our role is to understand what is available, what is designed, and what needs to be done in bringing it all together in a more streamlined manner,” Sarathy continued, explaining that “the developer mind is really fascinating … because you have to think in terms of [specific programming] languages and in terms of the technology stack, and it’s very dense. And I think that’s why you really do need a liaison to really understand what is our technology stack, what have we built, what are the tools that are available to us. Because … you have lots of sensitivities that you have to deal with.”
Got empathy?
In effect, Sarathy is talking about empathy – especially as it is conceptualized and practiced in the context of information technology. In their provocative new book, Data: A Guide to Humans, co-authors Phil Harvey and Dr. Noelia Jiménez Martínez explore the importance of empathy in thinking about, designing, and using data, ML, and AI. They describe a problem that they say is characteristic of human-designed systems as such: a tendency to reduce a system to its bare set of constitutive parts – and to exclude parts that are determined to be non-germane, external, etc. to the system.
Harvey’s and Jiménez Martínez’s book explores how the skill of empathy helps address this problem.
Take, for example, DevOps. It’s usually understood as the domain of software developers and operations people. DevOps practitioners use domain-specific tools and have codified their own domain-specific concepts. Many DevOps practitioners likewise identify a set of responsibilities, values, or ideals that they recognize as integral to DevOps as a discipline. The thing is, DevOps Isn’t alone: MLOps does the same, as do DataOps, AIOps, and (let’s face it) any other conceivable enterprise Ops.
This is fine, so far as it goes, but the danger is that the DevOps team will function as not only separate from but – in a special sense – indifferent to the priorities of MLOps, DataOps, or any other “Ops” group in the enterprise. Again, this is a feature, not a bug, of the way humans design and optimize systems. “[W]hen a problem is recognised within a system (even implicitly), [in order] to solve this problem the negative aspects are pushed into the environment outside of the system,” Harvey and Jiménez Martínez write. In IT lingo, this is tantamount to “throwing something over the wall:” i.e., a group disclaims responsibility for (or ownership of) a problem and makes it in effect, another group’s problem.
The practical effect of this is to poison relations between the group and other groups. It is likewise to encourage other groups to do the same thing. As a by-default posture, this harms the organization.
An essential aspect of empathy as Harvey and Jiménez Martínez see it has to do with recognizing the inevitability of perspective: namely, the fact that each and every person, to say nothing of the (smaller or larger) organizations into which people tend to congregate, has a perspective; that each and every person and (smaller or larger) organizational unit has its own values, priorities, and responsibilities.
This isn’t the (pro forma) diversity training to which almost all employees are now subject; it is, instead, a function of encouraging people and groups to accept and affirm the fact that other people and other groups are going to have different (perhaps contradictory) perspectives.
To us, these perspectives might seem trifling, inane, wrongheaded, blockheaded, pigheaded, chowderheaded, muddleheaded, knuckleheaded, thickheaded, lumpheaded, boneheaded, etc., but they’re nonetheless valid as perspectives: i.e., as points of view that are shared by other people or groups. For this reason, it behooves us to take them seriously, rather than dismissing or ignoring them.
To practice empathy on these terms is not to cede agency, self-determination, or initiative; to be empathetic is not to deprecate one’s own freedoms, priorities, values, etc. in order uncritically to valorize those of another person or group. It is to recognize the difference between throwing something over the wall, on the one hand, and working responsibly and collaboratively, on the other.
To put it another way, to be empathetic is to have the capacity to disagree empathetically; to try to be empathetic is to try to understand where other people are coming from, even if you don’t agree with them. “[D]iversity breeds empathy, sameness squashes it … with assumption and unconscious bias,” Harvey and Jiménez Martínez argue. “The wider and more diverse your experience, the more you become trained in considering the experience, and therefore the needs and feelings of other people. You drop the assumption of understanding that sameness encourages and understand that your perspective is only one of many. Your experience, while valuable, is part of a much bigger puzzle.”
Empathy in practice
This is an issue that Sarathy herself touched on in assessing the reasons for the success she’s had with Equifax. “It [has] a lot to do with … the culture of the company that wants to pick up the change and take it through and realize it,” she told Kavanagh, stressing that, in spite of formal separation or isolation between teams, she had a core substrate of recognition and respect – the building blocks of empathy – with which to work. She stressed, however, that more restrictive practices such as security and compliance, along with data governance, almost always alienate other (dependent) groups.
One of the biggest challenges of digital transformation is to convince these and other traditionally restrictive groups to reimagine how they interact with the groups they are nominally supposed to serve.
“You also need to break down the barriers to the data assets themselves and the rest of the infrastructure, which means you have to float from a policy where by default [people] don’t have access until it is explicitly given to [one in which] preferentially access is provided – but with … guardrails,” Sarathy said. “You need to think about establishing more open systems but with default policies for data privacy, data security, so the right people get access to the right data assets in the right format at the right time, and [that] happen[s] in a more automated way.”
Unfortunately, transformation at this scale is not something that can be accomplished by fiat, fatwa, or ukase. “I think [it] requires patience, [it] requires understanding and listening, because many of those [security and compliance] policies and rules have been put into place for safeguarding the enterprise, for safeguarding the customer,” she allowed. “But the bottom line is [that] when the culture is accepting of seeing facts and showing them what it is that your customers want and how that translates to what you can provide for them I think making the connection happen lets you open up a path for conversation … [even if] that may take a couple of months, or it could take a couple of years.”
The upshot, Sarathy told Kavanagh, is that, yes, talent, tools, techniques, and collaborative design matter, but that (backstopping these) is something more basic: not just empathy for other people and their own pressures, priorities, and responsibilities – but an empathic sense of working together.
“If you want to be good in analytics, you need to be good [not only] in your understanding of the technology [but in] your understanding of the people who are using the technology,” she stressed.
About Stephen Swoyer
Stephen Swoyer is a technology writer with more than 25 years of experience. His writing has focused on data engineering, data warehousing, and analytics for almost two decades. He also enjoys writing about software development and software architecture – or about technology architecture of any kind, for that matter. He remains fascinated by the people and process issues that combine to confound the best-of-all-possible-worlds expectations of product designers, marketing people, and even many technologists. Swoyer is a recovering philosopher, with an abiding focus on ethics, philosophy of science, and the history of ideas. He venerates Miles Davis’ Agharta as one of the twentieth century’s greatest masterworks, believes that the first Return to Forever album belongs on every turntable platter everywhere, and insists that Sweetheart of the Rodeo is the best damn record the Byrds ever cut.