Who Gets the Call When Your Analytics Process Crashes?

I recently had a meeting with one of the largest companies in the world, where we discussed concerns about ongoing maintenance and, more importantly, ongoing repair required for analytics processes. The conversation helped solidify in my mind a major disconnect that often occurs when organizations deploy an analytics process into a production setting. Let’s walk through that disconnect here.

I recently had a meeting with one of the largest companies in the world, where we discussed concerns about ongoing maintenance and, more importantly, ongoing repair required for analytics processes. The conversation helped solidify in my mind a major disconnect that often occurs when organizations deploy an analytics process into a production setting. Let’s walk through that disconnect here.

The Background

In this case, I was speaking with the IT leadership team that was responsible for the systems used for production analytics. As is the case with many companies, demand for analytics had been increasing and the IT team wanted to figure out how to best handle the anticipated influx of additional analytics processes that would be coming their way. As our discussion turned to the policies that should guide a process from the discovery phase to the production phase, an interesting issue was raised.

At this client, once a process is turned over to production, it is considered fully IT’s responsibility. This includes even the accuracy and maintenance of the analytic logic within the processes. The IT team is understandably quite concerned about taking ownership and responsibility for the logic of increasingly complex analytics processes. They just don’t have people with the analytical knowledge to effectively take that ownership. The only spots in the company with the requisite skills are the analytic teams creating the processes.

IT feels it has been burned too many times in the past when analytics processes were thrown over the wall to them and then they had to scramble to deal with issues that arose. They were hesitant to continue to add more processes without a better way to handle maintenance. I believe that my client’s real problem is with the contract that IT has with the analytics teams when it comes to placing something into production.

Who Gets The Call?

In this case, I see a serious issue in the precedents that have been set for production processes that must be addressed. Namely, it makes no sense to me that IT should have full responsibility for complex analytics processes built by an analytics team. IT should ensure that the systems are up, the data is accessible, and the necessary system resources are available so that the processes run smoothly. The logic of those processes, however, should remain under ownership of those who built them even when it is in production.

When logic is simple, such as standard reporting, it is reasonable to hand over all responsibility to IT. It does not make sense for complex analytics that may include predictive modeling, machine learning, or other advanced techniques in addition to all the requisite data preparation logic for those techniques. Analytics teams have to step up to the job of maintaining ownership of the processes they build in the long term. That means getting the phone call that something has broken at an inconvenient time. In the end, an organization needs problems with an analytics process solved as swiftly, completely, and accurately as possible. Only those with the knowledge to build such a process have the ability to meet this requirement. The responsibility rests squarely on analytics teams.

In the old days when a new analytics process had to be built on different systems and with different toolsets than the production environment, it was hard to avoid this disconnect. For example, IT often re-coded a process written in SAS to run directly within a mainframe or other operational system. While the analytics team built the initial logic, they weren’t familiar with the deployment environment or the language used to code the production process. Therefore, IT was stuck owning it all. This scenario was never a good one but was a necessary evil. With today’s technology, it is entirely possible for an analytics team to both develop and deploy an analytics process at scale using the same toolsets and to take full advantage of the power of the production system.

I don’t believe that most analytics professionals will balk at maintaining ownership of what they build. I know I wouldn’t. It is just a matter of asking them to maintain ownership and updating the “contract” with IT so that the split of who owns what pieces of the production process is changed. Unfortunately, in many organizations IT has not asked for this change nor has the analytics team suggested it. As a result, the deployment of analytics is much more stressful and carries much more risk than it needs to. Take a few moments to assess if your organization needs to update its deployment policies.