Working with Information Technology

by | Jan 26, 2017

How do you resolve distrust existing between Information Technology (IT) and Business Intelligence (BI) teams?  This discussion often rears it’s head in my BI mentoring and coaching sessions.
If you are starting in your first business intelligence management role, or wanting to become a top business intelligence professional, this blog may be relevant for you.
On face value these two teams should have a strong and supportive relationship.  But, there was that one time a junior BI analyst ran a cartesian join bringing down the system.  And there was that other time, an IT dBA forgot a data backup causing the loss of a considerable amount of irretrievable data.  These “mistakes” are hard to forget and often cast long shadows.
First up, the BI team should take every opportunity to improve their technical skills.  See my earlier blogs on Computer Science and Statistical technical skills to identify opportunities for development.  If a BI team has strong technical skills they will have credibility with their IT counterparts.
When starting out to build a relationship of 100+ people, start with these 5 or 6 people:

  1. Your IT relationship manager who has oversight of all IT, they are your guide through processes, people and problem resolution.   Their insight is invaluable.

    Source: Pixabay

  2. Architects, whether domain, solution, enterprise or data, these people balance capability, technology options, function, requirements and service delivery to design and deliver credible and performing technology environments.  From a BI perspective it is important to form a strong relationship with the domain and data architect.  Domain architects oversee a particular technology suite, find the architect who oversees yours.  Data architects oversee data models, policies, rules and standards.  If these architects don’t know what is happening in BI they cannot assist in planning BI evolution, so meet, discuss and plan.
  3. Help desk managers sit at the forefront of resolution management.  If they are aware of your constraints and dependencies they can make informed decisions.
  4. Database administrators (dBA’s) oversee use and deployment of data and databases.  For context this involves database management, data models and database design, metadata management, database schema management, capacity planning and storage management (including archiving), programming development, code review and testing, performance tuning, managing availability, data movement, data backups and recovery, data integrity, process skills, database auditing and security, managing data types (hopefully with consistent naming), systems management, maintaining business knowledge and related web-technologies. Phew!  This list alone shows the fundamental importance of a good dBA.  It is difficult to understand how any BI team could exist without a good dBA, so meet, discuss and include your dBA(s) in environment related communications.
  5. Problem managers are responsible for resolving high priority and recurring issues or faults.  In an ideal world you won’t have much to do with these people, but like all risk management processes it is good to know who they are and how to quickly get on their radar.

When you’re up and developing business intelligence following a system development lifecycle (SDLC) process you will also need to build relationships with the release and testing managers.  These guys manage the release of your development into a production environment, which enables more of your business users to access and use your good work.  This is a stressful and intense process, good relationships with all concerned will make the process more enjoyable and productive.
Release managers oversee system changes in the production environment.  Each organisation operates their own SDLC and it is well worth familiarising yourself with it well in advance.  The lead in time will quickly disappear, and it gives you time to meet with the Testing manager to agree release protocols.
Most testing by an IT testing team focuses on online transaction processing (OLTP) systems, which facilitate and manage transaction based applications.  BI teams work on online analytical processing (OLAP) systems. The systems are different and IT testing teams seldom have resources available to adequately test BI releases.  In my experience BI teams apply the IT testing procedures to BI releases with the IT testing manager having final approval.
IT process and protocols exist to reduce the risk to production systems, by working with IT and collaborating to prove your credibility any distrust which may have initially existed will be overcome.
Have fun – Mel.
[cartoon-headset]. [Cartoon] WordPress. Retrieved from the Infotech webpage (
It would be great to hear any feedback you have regarding this blog in the comments below.
Mel blogs about analytics, analytical tools and managing better business intelligence.  Want to read more? Try ‘Statistics within Business Intelligence’ or more from Mel.
We run regular business intelligence courses in both Wellington and Auckland.

Submit a Comment

Your email address will not be published. Required fields are marked *