Business vs. IT — Who Should be Doing What?

With the advent of “self-service BI” and “visual data exploration” there has come a shift in the business intelligence world where organizations are struggling to determine who is supposed to be doing what when it comes to having an analytics practice. On the one hand, the IT side of the house is concerned (rightly so) with managing security and handling the mechanics of how data is ingested and disbursed within the corporation. The business, however, finds that the system is laden with controls and risk mitigation, and in pursuit of faster returns on where their money is being invested they clamor for faster and better response from their business intelligence technology stack.

I am asked quite often to help delineate from a feature perspective in MicroStrategy who should be doing what.  Here’s what I think the average organization has for resources, and my recommendation for what products each person should have access to.

Role Functional Rollup Access Level
BI Administrator IT EM, CM, OM, Admin Stuff (Job Monitor, etc.)
BI Developer – Dashboards, Documents IT or Business Desktop, Web
BI Developer – Reports IT or Business Desktop, Web
BI Developer – Schema IT Architect, Desktop, Web
BI QA Analyst IT or Business Desktop, Web
Business Analyst – Non-technical Business Web
Business Analyst – Technical Business Desktop, Web
Data Modeler / Architect IT Desktop, Web
Data QA Analyst IT Web
ETL Developer IT or Business Web
Graphic Designer IT or Business Web
Product Owner IT or Business Web
Program Manager Business Web
Project Manager IT or Business Web
Scrum Master IT Web
SDK Specialist – Java Programmer IT Desktop, Web, some Admin (as needed)
Director Engineering IT Web
Director (Marketing, Finance, etc.) Business Web
Network Engineer IT Web

I’ve highlighted the role of Technical Business Analyst because it is this role that really makes organizations tick.  I have had the pleasure to work with a few incredibly talented people who meet my criteria for this role, and they are often the unsung heroes of any BI implementation.  Here’s what I look for in a technical business analyst:

  1. They know the business cold.  They can tell you at an annoyingly discrete level what calculation definitions should be, spoken in coherent “if-then-else” phrasing.  They also know the people who implemented the business rules, and they know why the calculation has to be the way it is.  This kind of institutional knowledge is priceless.
  2. Technical Business Analysts write SQL because they think in SQL.  It might not be pretty, and they may use brute force tactics to get what they need, but they can explain what they need from a data model (yes, they know how to read a data model).  When they explain what they need from the data model, they inject SQL statements into their explanation.   For example, they might say something like “we need the calculation to be driven off of the main sales fact table, but we need to do a full outer join to the customer table, but only where the customer has had activity in the last six months…”
  3. They stay current.  Great business analysts stay on top of upcoming features and they are innately in tune with why those features are coming out.  “Data wrangling?  I can totally use that…”  Technical business people get the beauty of big data because they aren’t afraid to write their own scripts to get the data if need be.
  4. They are patient.  My favorite technical business analysts understand that some of this stuff can be really hard to figure out, and they run cover for the development team.

Enterprise software sales cycles often start (and end) with the technical business analyst — and if you have someone who meets the criteria I just laid out, make sure they are happy…because they tend to know the answers, and if they don’t they know how to get the answers.  I love working with people that have the technical and business acumen because they act like translators every day and keep the peace between the two sides of the house.