another area that DAs are doing more and more are "DS-lite" roles where they also manage experimentation and perhaps analyses using ML methods (e.g. clustering/regression) but not productionizing the solution. DS unicorns + DA unicorns?
One thing I would add is that the barrier for an analyst to go down the Data Engineering rabbit hole has also lowered, causing Analysts to explore that area and, sometimes, remain there or even find comfort in the technical aspects of it.
Afterall it is much easier to explain to your stakeholder that the insight they want requires a lot of technical work to be completed than to simply say "I didn't have enough time or tenacity to get to an insight on why this business problem is happening". Not that this is the rule, but definitely causes some analysts to solve the wrong problems (making the ETL work vs solving he business problem).
Today one can make simple ETL processes with no-code or even, hire some Saas service that does it for you for 20 bucks a month. 5/10 years back, you as analyst had to go fetch those exel reports by hand because there were no such tools.
But it is indeed a great point: should analysts go down that path or should they focus on the business? And I guess each company has it's balance of where that repsonsibility lies. Plus, the way to keep them focused on what matters depends on stronger leaders to guide them in this journey (which is also getting harder and harder to find)
another area that DAs are doing more and more are "DS-lite" roles where they also manage experimentation and perhaps analyses using ML methods (e.g. clustering/regression) but not productionizing the solution. DS unicorns + DA unicorns?
Grea point!
One thing I would add is that the barrier for an analyst to go down the Data Engineering rabbit hole has also lowered, causing Analysts to explore that area and, sometimes, remain there or even find comfort in the technical aspects of it.
Afterall it is much easier to explain to your stakeholder that the insight they want requires a lot of technical work to be completed than to simply say "I didn't have enough time or tenacity to get to an insight on why this business problem is happening". Not that this is the rule, but definitely causes some analysts to solve the wrong problems (making the ETL work vs solving he business problem).
Today one can make simple ETL processes with no-code or even, hire some Saas service that does it for you for 20 bucks a month. 5/10 years back, you as analyst had to go fetch those exel reports by hand because there were no such tools.
But it is indeed a great point: should analysts go down that path or should they focus on the business? And I guess each company has it's balance of where that repsonsibility lies. Plus, the way to keep them focused on what matters depends on stronger leaders to guide them in this journey (which is also getting harder and harder to find)