By Stephanie Baskerville on December 20, 2016

Your BI Implementation Roadmap – Select and Architect!

 

To maximize your business intelligence (BI) investment, your project needs efficient BI implementation. When implementing your BI project, we recommend utilizing an implementation roadmap (see the map below). Leveraging an implementation framework can streamline your implementation activities.

As the roadmap below presents, you can divide the implementation activities into six groups: Environment Selection, System Architecture, Data Architecture, Development, Production, and On-Going Test. In this blog post, we will focus on the first three groups of activities – Environment Selection, System Architecture, and Data Architecture – and the next blog post (scheduled to be posted on Thursday, Dec. 22 – stay tuned!) will discuss the rest.

BI Implementation Roadmap

 

Throughout our BI blog series, we have recommended the 5-step approach to your BI project: Structure, Identity, Choose, Implement, and Measure. Building your BI roadmap is the fourth step of your BI journey. Feel free to review our previous blog posts to get the helpful tips for the first, second and third steps:

 

Activity 1. Environment Selection: Select the right environment for the BI platform

The first group of activities is dedicated to selecting the right environment for the BI platform. You can decide whether you want On-Premise, Cloud, or Hybrid environment.

 

On-Premise

  • Deploy the BI platform on internal physical server(s)
  • Keep data internal
  • Total control on the platform
  • Organizations with a lot of sensitive data
  • Starter with only a single server

Cloud

  • The BI platform is deployed on a public or a private cloud
  • Managed services
  • Focus effort and resources on strategic initiatives
  • BI starter with a small and busy IT department
  • Departmental BI

Hybrid

  • Some components of the BI platform are deployed internally and some are deployed on the cloud
  • Used to optimize storage cost and level of control
  • Large enterprises looking to find a balance between storage cost and control

Bottom line:

Your environment selection may change. Check with the BI vendor about the flexibility to move from one option to another option in the future.

 

Activity 2. System Architecture: Plan availability

BI has to be available for users to get data that they want and to make decisions. Work with the business and plan availability collaboratively. Strike a balance between availability and resources. High availability requires effort and resources while lack of investment in availability may hurt decision-making capability.

 

Bottom line

BI and the underlying data is like water and pipes. You need both to provide BI capabilities. Plan for availability in your data warehouse, datamarts, and ODSs while you plan for BI availability.

At the end of the day, BI is an internal application, rather than a customer-facing one (unless you extend BI to your customers). A reasonable availability may be fine for your information needs.

 

Let’s architect your BI platform!

  1. Configuration
  • Use the application parameters to optimize the BI platform.
  • Configure data connections: data warehouse, ERP, CRM, etc.
  • Connect to the web server, exchange, and mobile server.
  • Configure the connectivity among your instances: PROD, DEV, TEST, etc.
  • Define the content database of the BI platform. Content database is an application database that stores the artifact, user, and permission definitions for the BI platform.
  1. Version, Patches, and Feature Management
  • Certain BI platforms require an exact combination of operating system patches and BI application versions to work properly.
  • Some technical support also requires the exact patch combinations to be built.
  • BI partners are doing a very good job in releasing new versions to introduce new features and fix bugs. The BI team needs to pay attention to the releases and make sure the BI platform is upgraded to the latest releases.
  1. Security

You can use a combination of these two security models to protect your BI platform against intrusions.

Security Model 1: Application Security

Your BI platform comes with native security features. Make sure you leverage them fully:

  • Authentication: making sure the users are in fact who they say they are.
  • Authorization: giving the right permission to the authenticated users.
  • Role-based security: a matrix structure that determines what permission a user has based on the role.
  • Content-based security: content-level security that allows content to be accessed by specific personnel.

Security Model 2: Enterprise Security

  • BI security is only a component in the overall enterprise security model. Make sure the BI platform fits into the overall server security, infrastructure security, and environment security.
  • Consideration: Collaborate with your corporate security team to ensure BI security aligns with the corporate security measures.

 

Activity 3. Data Architecture: Build your BI Building Blocks

BI building blocks, such as dimensions, metrics, hierarchy, and relationships, need to be built before they can be used to develop BI content such as reports, dashboards, and self-service datasets. The building blocks also help BI developers and BI users clarify by reorganizing the data in a meaningful way.

 

Dimensions

Dimensions are usually your business entities. Customers, products, regions, suppliers, employees, time, etc. are your dimensions. Dimensions will be used later in artifact creation in which the developers will simply drag and drop dimensions in the creation area.

Metrics

Metrics are also called measures. They are the numerical elements that you can report on. Absolute numbers, monetary values, ratios, percentages, etc. are metrics. Once metrics are created, you can create calculated metrics to calculate values that you already have.

Hierarchy

Hierarchy organizes parents and children. Hierarchies allow you to analyze by level and you can aggregate data according to the levels. Drill down function is based on hierarchy. Examples of hierarchy are geographic hierarchy, product groupings, time, and customer groups.

Relationships

Dimensions are related to each other by relationships. Relationships can be one-to-one, one-to-many, and many-to-many. Relationships can also be mandatory or optional. Defining relationships helps the BI platform to create the right query, aggregate data correctly, and fetch data optimally.

The later three groups of activities – Development, Production, and On-Going Test are discussed in our next blog post: Your BI Implementation Roadmap – Develop, Productize & Test!

 

Let’s map your BI journey together!

Business Intelligence is no longer a luxury or niche. Organizations of every size and across all industries are taking advantage of the benefits of BI. Having an appetite for BI does not mean that the initiative will be an automatic success. It is imperative that organizations take the time to select and implement a BI suite that aligns with business goals and fosters end-user adoption.

Our team of BI experts will be happy to help you start your BI journey. Contact us today. We will be happy to discuss how we can help you!

Published by Stephanie Baskerville December 20, 2016