Once upon a time in a prior century I taught classes called "Strategic Business Analysis" and a modeling class on a combination of ERD, Function Hierarchy Diagram and CRUD matrices using Oracle Designer. I taught these as "requirements and understanding the business gathering", not designing a database. This worked so well that Oracle Designer could generate 95+ of a finished application, i.e. all of the grunt work.
ERD in particular was taught as a "thought discipline", with heavy focus on meaningful working of entities, attributes and particularly relationships.
A part of the offerings, I would hold an afternoon or evening session with the business and stakeholders using a group reading of their ERDs with heavy emphasis on speaking aloud the MAY BE, MUST BE of the relationships (ala Barker et alia).
That was what we called as "Business Analyst"; they may or may not have been database experts.
I got in hot water when working for Oracle on a very early clinical study application. I trained the nurses to read the, who the provide feedback to the Oracle consultants, who were not happy to have their work questioned.
I don't think such a position is very common these days.
I have been wondering about this post for awhile now, and I still don't know how I'd like to chew on it.
There are a few sub-components that are probably worth addressing:
1) "We were at our best when we weren't just building dashboards and mechanically tracking metrics; we were at our best when we were given vague problems, well-sourced data, and the time and tools to go exploring."
If you asked me at heart whether I believed this, I'd still lean "YES!!". Part of the challenge is that "analytics" is emergent out of multiple cultural streams, but one of the dominant starting points of "analytics" IS consulting. McKinsey was originally a managerial accounting firm promising unique insights from balance-sheets. Even Frederick Taylor, the inventor of Industrial Engineering, was originally a consultant hawking an idea.
The investment in data analytics should (ideally) be used to bridge the strategy gap. (Now, it might not actually do so, but that still seems odd if true. As in, data is a strategic investment)
2) "And the panelists' point—that data projects are prone to failure, and don’t often deliver meaningful insights—wasn’t some bold new take"
This is also fairly interesting. Having been through a number of scenarios, I find that data projects inherit a lot of the problems of business projects & technology projects. Everything from every domain has to coordinate relatively well together.
That being said, and this is where I do have some wonder -- is FP&A supposed to go into the "analytics" category, or "accounting" category? FP&A (in my understanding) is a function dependent upon accounting, but with the analytical drive for strategic insights. It is NOT technically innovative, but it's not boring accounting.
If you told me that the future of analytics was FP&A, and that the future of data was accounting, then I don't see a huge concern. However, data as accounting without an FP&A dimension feels... odd to me?
3) "First, there may not actually be gold in a lot of those thar hills. Most of us may just have “moderately valuable datasets that can inspire moderate business improvements.” Second, finding meaning in data is very hard, as suggested by our continued insistence that most job candidates who are trained to do it actually can’t. Third, even if we do find something interesting, it’s hard and expensive to make it useful"
I'm definitely still curious on this bit. If you told me that everything could be solved without an analyst, then I could definitely believe that. The analogy in my head is a process redesign project; arguably "this project doesn't work right" doesn't require a data ecosystem, nor does "we should fix this manufacturing line as it is causing all of the problems", etc.
However, it's still true that you need to have people who can solve the people problems, and reason effectively, even if you work without a database. The tools aren't actually central, and 6 Sigma professionals and/or Industrial Engineers are still paid well even though they aren't in the "Data analytics" revolution.
-----------------
And just to get my head on straight, is this a disillusionment that "data is a magical & transformative force" or actually a statement that data SMEs are less helpful than Industrial Engineers & FP&A professionals?
I think an interesting component of this conversation is that companies want to be different even in areas there is no reason to be. Market differentiation = necessary it’s the reason your still in business. Data differentiation - it can definitely be a differentiator for your business - no question. But just doing things differently for the sake of it - not helpful. As has been said by several authors in posts this week - when in doubt be boring.
Accounting has been around for 7,000 years. Double entry book keeping is a relatively recent discovery in the last 500+ years. Hopefully data teams will not take as long to coalesce on commonly observed patterns that work across domains and institute them as gospel to make subsequent generations of data teams boring.
Accounting/finance folk are often surprised when I tell them that w/ a bit of programming, sql, and tech training they could do most of my job. If only they knew....
I'd love a GAAP for DS, but I've been/am on projects to "standardize metrics" across a bunch of RELEATED product lines within the same megacorp and the lowest common denominator metric list is still very sad... Revenue/accounting stuff, basic 'success of flow/funnel" stuff, and some variation of customer acquisition/retention ... maybe that's already enough to get by, but past that it gets very hard to ignore the nuance *for product dev work*. Nuance in financials, which are probably as messy as DS metrics, can get footnoted away pretty regularly, but line managers aren't using those same metrics to make decisions either
The end of our purple era
"Most of us may just have 'moderately valuable datasets that can inspire moderate business improvements.'"
<<nodding head>>
Once upon a time in a prior century I taught classes called "Strategic Business Analysis" and a modeling class on a combination of ERD, Function Hierarchy Diagram and CRUD matrices using Oracle Designer. I taught these as "requirements and understanding the business gathering", not designing a database. This worked so well that Oracle Designer could generate 95+ of a finished application, i.e. all of the grunt work.
ERD in particular was taught as a "thought discipline", with heavy focus on meaningful working of entities, attributes and particularly relationships.
A part of the offerings, I would hold an afternoon or evening session with the business and stakeholders using a group reading of their ERDs with heavy emphasis on speaking aloud the MAY BE, MUST BE of the relationships (ala Barker et alia).
That was what we called as "Business Analyst"; they may or may not have been database experts.
I got in hot water when working for Oracle on a very early clinical study application. I trained the nurses to read the, who the provide feedback to the Oracle consultants, who were not happy to have their work questioned.
I don't think such a position is very common these days.
I have been wondering about this post for awhile now, and I still don't know how I'd like to chew on it.
There are a few sub-components that are probably worth addressing:
1) "We were at our best when we weren't just building dashboards and mechanically tracking metrics; we were at our best when we were given vague problems, well-sourced data, and the time and tools to go exploring."
If you asked me at heart whether I believed this, I'd still lean "YES!!". Part of the challenge is that "analytics" is emergent out of multiple cultural streams, but one of the dominant starting points of "analytics" IS consulting. McKinsey was originally a managerial accounting firm promising unique insights from balance-sheets. Even Frederick Taylor, the inventor of Industrial Engineering, was originally a consultant hawking an idea.
The investment in data analytics should (ideally) be used to bridge the strategy gap. (Now, it might not actually do so, but that still seems odd if true. As in, data is a strategic investment)
2) "And the panelists' point—that data projects are prone to failure, and don’t often deliver meaningful insights—wasn’t some bold new take"
This is also fairly interesting. Having been through a number of scenarios, I find that data projects inherit a lot of the problems of business projects & technology projects. Everything from every domain has to coordinate relatively well together.
That being said, and this is where I do have some wonder -- is FP&A supposed to go into the "analytics" category, or "accounting" category? FP&A (in my understanding) is a function dependent upon accounting, but with the analytical drive for strategic insights. It is NOT technically innovative, but it's not boring accounting.
If you told me that the future of analytics was FP&A, and that the future of data was accounting, then I don't see a huge concern. However, data as accounting without an FP&A dimension feels... odd to me?
3) "First, there may not actually be gold in a lot of those thar hills. Most of us may just have “moderately valuable datasets that can inspire moderate business improvements.” Second, finding meaning in data is very hard, as suggested by our continued insistence that most job candidates who are trained to do it actually can’t. Third, even if we do find something interesting, it’s hard and expensive to make it useful"
I'm definitely still curious on this bit. If you told me that everything could be solved without an analyst, then I could definitely believe that. The analogy in my head is a process redesign project; arguably "this project doesn't work right" doesn't require a data ecosystem, nor does "we should fix this manufacturing line as it is causing all of the problems", etc.
However, it's still true that you need to have people who can solve the people problems, and reason effectively, even if you work without a database. The tools aren't actually central, and 6 Sigma professionals and/or Industrial Engineers are still paid well even though they aren't in the "Data analytics" revolution.
-----------------
And just to get my head on straight, is this a disillusionment that "data is a magical & transformative force" or actually a statement that data SMEs are less helpful than Industrial Engineers & FP&A professionals?
Why didn't you link the Alcaraz-Zverev point referenced? :-)
I think an interesting component of this conversation is that companies want to be different even in areas there is no reason to be. Market differentiation = necessary it’s the reason your still in business. Data differentiation - it can definitely be a differentiator for your business - no question. But just doing things differently for the sake of it - not helpful. As has been said by several authors in posts this week - when in doubt be boring.
Accounting has been around for 7,000 years. Double entry book keeping is a relatively recent discovery in the last 500+ years. Hopefully data teams will not take as long to coalesce on commonly observed patterns that work across domains and institute them as gospel to make subsequent generations of data teams boring.
Accounting/finance folk are often surprised when I tell them that w/ a bit of programming, sql, and tech training they could do most of my job. If only they knew....
I'd love a GAAP for DS, but I've been/am on projects to "standardize metrics" across a bunch of RELEATED product lines within the same megacorp and the lowest common denominator metric list is still very sad... Revenue/accounting stuff, basic 'success of flow/funnel" stuff, and some variation of customer acquisition/retention ... maybe that's already enough to get by, but past that it gets very hard to ignore the nuance *for product dev work*. Nuance in financials, which are probably as messy as DS metrics, can get footnoted away pretty regularly, but line managers aren't using those same metrics to make decisions either