Keeping Up With Data #104
Automation is a great way to improve efficiency of operations. Why keep performing a repetitive task when we can have a code taking care of it?
Typically, the candidates for automation come from situations that take too long, occur too often, or are simply too frustrating. But frequently, the idea behind the automation is way too complicated (and sometimes completely delusional).
As with any decision, the benefits must outweigh the costs. And we need to be realistic about what will be required to create the automated solution, let alone to maintain and improve it in time.
It is often a way more complicated picture than the thought of the frustrating process simply disappearing. Not dissimilar to the xkcd image above.
The notion of automation taking a life of its own is the golden thread of the articles below. In some cases the automation creates a behemoth to fight, often it needs to be managed going forward, and sometimes it’s not needed at all.
This week’s reading list looks at IT and business, data-product managers, and MLOps.
- The great divorce — IT and business: The disconnection between IT and business is omnipresent. Bill Inmon shares his view on the causes and factors of this divorce. It very much speaks my mind. I’m often baffled by the gigantic size of IT budgets unjustified by any ROI. I find it immoral to consider it being costs of running business. Sometimes I fear the data industry is heading towards the same destiny. Especially when the data initiatives are driven not by the business needs, but by the vendors’ goals and ambitions. (Bill Inmon)
- Why Your Company Needs Data-Product Managers: Data and analytics are becoming products in their own rights. And products often benefit from having dedicated product managers. Without them, the product can stagnate because individual contributors don’t know (or don’t want to know) who should take action to drive product’s adoption, support, or improvements. I’ve seen some of our clients looking for data-product managers in the last few month. The role is new, it’s hard to specify the job description, and even harder to find the matching candidates. Often because you also need to navigate the dynamics of adding a new role among teams that have been coexisting for a while. (HBR)
- No, you don’t need MLOps: The boom of MLOps solutions suggests that operationalising ML is impossible without them. The 2015 paper by D. Sculley and others concluded that maintaining ML systems in time is difficult and expensive. Many MLOps vendors adopted the image showing that only a tiny fraction of ML systems is actually ML (the rest being feature extraction, data processing, infrastructure serving etc.) and started building solutions to automate these other components. Lak suggests that the ML frameworks and tools have gone a long way since 2015 and some of the solutions are automating something already automatic. Or are over-engineering a solution, where a simple one exists. (Lak Lakshmanan @ Medium)
Enjoy the weekend!