I often am asked by clients to evaluate the configuration of a BI delivery team and point out any changes that seem prudent. Usually this is pretty straightforward, but over the years there’s some not-so-obvious roles I’ve come across that would make the cut on my dream team.
So, without duplicating the many, many “roles and responsibilities” posts out there to which your favorite search engine will gladly lead you, here’s my sleeper picks for a BI team:
Data Architect – Not a sleeper you say? Well, there’s a lot of teams out there that don’t have one. There is absolutely no way a team of any reasonable size should be without a data architect, the designated designer of databases. If you find yourself without a well documented, well understood, semantically consistent, adequately performing database as the foundation of your BI system, the buck stops here.
The Future of Big Data
With some guidance, you can craft a data platform that is right for your organization’s needs and gets the most return from your data capital.
Technical Administrator, a.k.a. the Glue Guy – In my opinion, the more parts of the development process you can automate, the better quality your results will be (how’s that for sweeping generalizations, eh?). However, automated testing, deploying from source control, automated documentation, pattern based model automation, quick-deploy environments, etc. all require some scripting magic to make it all work. Something that may not be in the average ETL or report developer’s tool belt. Enter, the glue guy (or gal). This team member can:
- Script anything using whatever tool you prefer (Perl, Python, VB Script, PowerShell, Korn shell, etc. etc.).
- Figure out how to “pull the levers” via the command line or APIs of all the tools in the stack (especially source control).
- Create and script a build of an entire environment from some common starting point, e.g. a VM with just the stock software installed.
- Handle administration tasks on the database, ETL tool, BI tool, metadata tool, and more, at least until the team’s big enough to offload these duties.
- Just make stuff work.
Technical Writer – Traditionally only justifiable on larger teams, I consistently fight for tech writers on my teams to take on the responsibility for effective communication to stakeholders. On my teams, this role is on the front lines every day ensuring that the team is communicating with stakeholders via well formed, complete documents and documentation including requirements, design artifacts like the data dictionary, status dashboards/wall boards/radiators, etc. For me, tech writer takes communication from adequate to one of the team’s primary strengths and does it in the most visible, customer facing aspects of the project.
QA Developer – For teams that follow test driven development (TDD) and/or automated testing practices, testing is every bit as technically demanding as the primary development. Maybe more. Traditional testing resources have an enormous, colossal, gigantic variability in skills they bring to the job. Some excel in process, some in system manipulation, some in information analysis using things like Excel, and some directly using programming. Since automated TDD demands that tests come first and are defined in working test code, the test analyst must be capable of:
- Directly interpreting design requirements without the benefit of a working system to gaze upon.
- Coding automated unit test fixtures (environments) and test cases.
- Creating, loading, and manipulating test data sets, possibly including test data generation and data masking.
I’d argue that these represent a set of skills more traditionally aligned with developers, and some recruit developers for this role. However, there’s all kinds of evidence that a good tester and a good developer share few of the same characteristics or motivations. So, I generally try and stick with proven test analysts that have the skills to meet the above requirements, and these are a valuable and unique group indeed. I deploy them alongside the “regular” developers and task them with testing the same deliverable as the “regular” developers. Thus, QA becomes an equal with “regular” development where it should have been all along in my opinion.
Functional Leaders – Not a role by itself, a functional leader leads a particular function or “competency” on the team with responsibility for setting best practices and standards for everything that happens in that function. Functional leaders are data architects, are ETL developers, are QA analysts, etc. and act as the thought leader for their peers. They are not managers per se, but rather mentors, reviewers, and visionaries. In other words, leaders.
I’m sure there’s more, but these are a good start. It is admittedly a tough sell to hire anyone but “coders” early (or even later!) in the life of a BI team, but there’s no doubt that these roles, properly deployed, can turn adequate into great for most BI projects.
