Simplified guidelines for selecting a bi platform in an enterprise

Simplified Guidelines For Selecting A BI Platform
In An Enterprise
“an Architectural Approach”
Alaa Karam – Senior Project Manager and Business Architect

Title: Version Number of Pages:
Simplified Guidelines For Selecting A BI Tool 1.2 2 (43)
CONTENTS:
1 Glossary and References.............................................................................................................................. 3
2 Summary....................................................................................................................................................... 4
3 Introduction.................................................................................................................................................... 5
3.1 Motivation Viewpoint............................................................................................................................... 6
3.2 Target Audience ..................................................................................................................................... 7
3.3 Background............................................................................................................................................. 8
3.4 The aim and the goals of the guidelines................................................................................................. 8
3.5 The BI Requirements Aspect.................................................................................................................. 8
3.5.1 Providing Requirements...................................................................................................................... 9
3.5.2 Information Requirements................................................................................................................. 13
3.5.3 Quality Attributes ............................................................................................................................... 20
3.5.3.1 Security Requirements ............................................................................................................... 20
3.5.4 Scenario For Selecting A BI Platform According to Information Aspect ........................................... 23
3.5.4.1 Scenario 1 – Single Data Report ................................................................................................ 23
3.5.4.2 Scenario 2 – Mixed Data Sources .............................................................................................. 23
3.5.4.3 Scenario 3 – BI Capability .......................................................................................................... 24
3.5.5 Decision For Selecting BI Platform According To Information And Security Requirements............. 24
4 BI Platforms................................................................................................................................................. 25
4.1 BI Platforms – Baseline Systems And Target Architecture .................................................................. 26
4.1.1 BI Platforms – Baseline Systems ...................................................................................................... 26
4.1.1.1 QlikView...................................................................................................................................... 26
4.1.1.2 SAP BW ...................................................................................................................................... 28
4.1.1.3 Power BI ..................................................................................................................................... 29
4.1.2 BI Platforms – Target/Transition Architecture ................................................................................... 30
4.2 BI Platforms – Target Systems............................................................................................................. 30
4.2.1 BI Platforms – Information Content ................................................................................................... 31
4.2.2 Decision For Selecting BI Platform According To Information And Security Requirements And The
Type Of BI Platform........................................................................................................................................ 32
5 Appendices ................................................................................................................................................. 33
5.1 The Project’s Aspect............................................................................................................................. 33
5.2 The Infrastructure And Integration Aspects.......................................................................................... 36
5.3 The BI Capabilities Aspect ................................................................................................................... 36
5.3.1 BI Capabilities According To Gartner................................................................................................ 37
5.3.1.1 BI Capabilities represented in Different BI Platforms ................................................................. 39
5.3.2 BI Capabilities Requirements............................................................................................................ 40
5.3.3 Decision For Selecting BI Platform According BI Capabilities .......................................................... 42

1 Glossary and References
Concept or
Abbreviation
Explanation
DBMS A database-management system (DBMS) is a computer-software application that
interacts with end-users, other applications, and the database itself to capture and
analyse data. A general-purpose DBMS allows the definition, creation, querying,
update, and administration of databases. [From Wikipedia]
LOB Line Of Business
KPI A Key Performance Indicator is a measurable value that demonstrates how
effectively a company is achieving the decided key business objectives
Table number 1: Glossary
# Reference
Document
The Link to the Reference Document
1 http://support.sas.com/resources/papers/proceedings12/021-2012.pdf
2 https://en.wikipedia.org/wiki/User_story
3 http://www.osisoft.com/corporate/connected-services/pisystem.html
4 https://www.greentechmedia.com/articles/read/how-will-smart-grid-transformer-
technologies-provide-stability-to-the-aging
5 https://en.wikipedia.org/wiki/Business_intelligence
6 Gartner BI
report (2017)
7 ArchiMate®
3.0
Specification
http://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc451758138
8 https://practicalanalytics.co/2011/05/02/bianalytics-center-of-excellence-coe-bi-shared-
services-or-bi-competency-center/
9 http://www.watchwise.net/business-intelligence.htm
10 http://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc451758136
11 https://digitalguardian.com/blog/data-protection-data-in-transit-vs-data-at-rest
12 https://en.wikipedia.org/wiki/ISO/IEC_27001:2013
13 https://bi-survey.com/business-intelligence-software-comparison
14 http://wikis.corp.vattenfall.com/vitwiki/index.php/IT_Architecture
15 http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_29
16 http://www.datamodel.com/index.php/articles/what-are-conceptual-logical-and-
physical-data-models/
17 http://www.qlikfix.com/2011/02/04/hands-on-with-qlikview-script-generator/
18 https://dataonwheels.wordpress.com/2017/04/10/power-bi-and-data-security-
compliance-and-encryption/
19 http://www.thedigitalprojectmanager.com/project-management-methodologies-made-
simple/
20 http://wikis.corp.vattenfall.com/vpmm_online/index.php/Agile_Project:Agile_Project_Fra
mework
21 https://en.wikipedia.org/wiki/Data_in_use

22 http://help.qlik.com/en-
US/qlikview/12.1/Subsystems/Server/Content/QlikView%20Server/QVSRM_FunctionalAr
chitechture.htm
23 https://chamonix.com.au/power-bi-and-microsoft-azure-whats-all-the-fuss-about
24 https://help.sap.com/saphelp_nw73/helpdata/en/47/5fa4468d0268b4e10000000a42189
b/frameset.htm
25 http://radacad.com/hybrid-end-to-end-power-bi-azure-sql-database-data-factory
Table number 2: References
2 Summary

In this document we presuppose that the Enterprise has already different available BI Platforms and there are
some difficulties and no direction in selecting the right BI Platform.
There are many aspects that need to be considered when we evaluating and selecting a BI Platform. In this
document we suggest that the main aspects are, please see the following figure in this page:
1. Defining the business requirements is always a good starting point. The user stories and or the use
cases will provide a high-level understanding for the required business needs regarding the involved
information/data in these requirements.
2. One of the fundamental aspects in selecting a BI Platform, among some existing BI Platforms in an
Enterprise, is the information aspect and the different scenarios for the required data that will be used
in the business reports/dashboards. This aspect will decide if the data is located in a single system or
in different systems. By the this aspect we mean:
a. The definition of the conceptual, logical and physical models and down to the requirements
on different data that will be the source for the business reports/dashboards.
b. The required BI data could be located in a single system or the data need to be collected and
received from different systems.
c. The existence of the required data in one or several BI Platforms. If the required data is
already exists in the BI Platforms, then it is easy to build new reports/dashboards based on
that.
3. The security aspect or the IT security requirements is one of the most important aspects that need to
be considered when the BI Platform will be selected. The IT security requirements should be gathered
and analysed as any other important requirements.
4. If the information is classified as NSI (National Security Information) data or if there are other
regulatory requirements that do not allow to have the data in the Cloud, then the project that is
aiming to select the BI Platform, must use an on premise based BI platform, if the Cloud based BI
platform is not according to the IT security requirements. If the required information in the BI
reports/dashboards is not classified as NSI data or if there are no other regulatory requirements to
have the data in the Cloud, then the project has the permission to select a Cloud-based platform,
please see the following figure:.
3 Introduction

This document is a result of cooperation from different architects and BI experts in the Enterprise. This
document was written to try to give a direction for the ongoing, planned and future projects that have
difficulties in selecting the right BI Platform.
3.1 Motivation Viewpoint
We start with a motivation viewpoint diagram that will help us to define and describe some benefits that will
deliver value to our stakeholders.
According to [7], the motivation viewpoint allows the designer or analyst to model the motivation aspect,
without focusing on certain elements within this aspect. For example, a viewpoint can be used to present a
complete or partial overview of the motivation aspect by relating stakeholders, their primary goals, the
principles that are applied, and the main requirements on services, processes, applications, and objects.
A simplified motivation viewpoint is shown in the following figure, figure 1. The actual motivation viewpoint is
represented by different elements such as goals, principles and stakeholders.
The goals represents some desired results and in our case they are about:
1. Cost reduction.
2. Performance Improvement.
These goals could be achieved by applying some high-level principles:
1. Standardization
2. Control of technical diversity
3. Reuse before buy
These goals will ensure and provide some values to our main stakeholders:
• Users
• Project Sponsors and Project Steering Groups
• Line Of Business Managers
• Project Managers
• Architects (Enterprise, Business and Solution Architects)
• Solution Experts and developers
Motivations are considered to describe one or more viewpoints. The below diagram is considering the
financial viewpoint, architecture simplicity viewpoint and the project/business viewpoint.
The presented principles and the existing constraints in the enterprise should not compromise the fulfilment
of the business requirements. And at the same time there should be a balance between the goals, business
requirements, existing constraints and avoiding creation/development of complex applications.
The principles that are stated in the diagram are used by the whole Enterprise. Some other principles that are
more BI specific should be introduced here. An example of such principle could be based on “separation of
duties” between the different platforms.
For example, in our enterprise, we use IBM’s Cognos as the Financial BI system. And we are using SAP BW
based system for reports that are based on customer data. The separation of duties between the different

platforms could make the choice of the right platform easier for the BI project. And this principle could be one
of the main constraints in the enterprise.
Other constraints that can impact the architecture could look like:
• Compliance with:
o Existing regulations in Sweden (e.g. PUL - personuppgiftslagen) and future regulations (e.g.
GDPR - The General Data Protection Regulation)
o The existing IT security policies in the Enterprise
• Use of third-party software or a particular technology
• The IT landscape/the IT environment (server configurations, firewall, DMZs,…)
Figure 1: A simplified motivation viewpoint for the guidelines
For the reader’s information, the figure above does not show all elements, the content of these elements and
the relationships in the Motivation Aspect.
In this document we decided to not follow the fulfilment of the goals that are described in the above diagram,
because this is one of the main purposes of the BI projects and the KPIs (Key Performance Indicator) that are
agreed in the project.
3.2 Target Audience
The introduced document is presented to help projects with BI business needs in order to select an existing
standard BI Platform that are suitable and according to the business requirements.
The main audience for this document are:
• Project managers (Business and IT)
• Project sponsors (owners), steering groups and decision makers

• Enterprise, Business and Solution Architects
• Business analyst
• BI experts and BI Developers
3.3 Background
The Enterprise, as many other companies, have many challenges in the BI area. Some of these challenges are:
1. The existence of the old BI Platforms and data warehouses that are very hard to update, develop and
maintain.
2. Trying to use the principle “on-size-fits-all” in the area of BI and directing all projects with their BI
requirements to the same heavy (old) BI Platform. And often this way of thinking did not solve many
projects’ needs and requirements.
3. The investments for approaching and maintaining the BI area is very high comparing to the value that
the business get from that.
4. The absent of common and agreed strategy and accepted standard BI Platforms, created a situation
that many organisations in the company decided to acquire and even develop and maintain own
applications/BI Platforms.
3.4 The aim and the goals of the guidelines
These guidelines will try to answer the following questions:
1. How to help the business in different organisations/projects to select the right BI Platform(s) without
adding a new Platform to the already complicated IT environment?
2. What a business project needs to know and to do in order to select a suitable BI Platform ?
3.5 The BI Requirements Aspect
In the project methodology, the requirements management could be initiated from the day one of the
project’s life cycle and may continue until the project have the solution in the production environment.
The business requirements will be used to design a suitable solution that will probably aims to satisfy the
business.
There are many challenges in providing the business requirements, especially when we have many involved
stakeholders and users. And of course there are other challenges in the interpretation of the business
requirements from the designers and the developers especially when the requirements are not specified in a
way that is understandable for these designers and developers.
Detailing and breaking down the requirements, especially the ones that are complicated, is a suitable way to
avoid misunderstandings and misinterpretation in the solution side of the project and even between the
stakeholders that are involved in requiring these needs.
The following figure describes an easy lifecycle for business requirements adapted to BI requirements:
1. User stories and use cases are an excellent starting point for gathering needs and requirements from
the involved stakeholders/users and also gives a standard way to document these requirements.
2. The information requirements are a critical part of any BI project. The non-functional requirements
(the quality attributes) will dictate how well the solution will perform the required functions.
3. As we mentioned, detailing the requirements, especially the information requirements is a prerequisite
for designing and developing a suitable solution.

4. The BI solution must provide the right reports/dashboards based on the correct and the required
information.
Figure 2: Simplified requirements lifecycle adapted to BI requirements
The list of requirements need to be gathered, analyzed, prioritized and then used to evaluate the fulfilment of
these requirements in the BI solution, please see page 12.
3.5.1 Providing Requirements
Often the BI Platforms are related to different types of users (e.g. Enterprise and Business Area executives,
Business Unit managers, LOB managers, Business Controllers, end customers and others). These users for
example the Executives and Managers, want to get deep insight in the business and making better decisions
supported by the BI information.
The project (in this case the business analyst) needs to ask the business users about what kind of decisions
they need to take and what information they need in order to make these decisions (e.g. analytical
information, KPIs,…).
Then the project starts to transform these needs into requirements or more correctly into business
requirements.
We start with explaining how to provide the business requirements. An important concept that need to be
defined here is the user story.
According to [2], in software development and product management, a user story is a description consisting
of one or more sentences in the everyday or business language of the end user or user of a system that
captures what a user does or needs to do as part of his or her job function.
User stories are used with agile software development methodologies as the basis for defining the functions a
business system must provide, and to facilitate requirements management. It captures the "who", "what" and
"why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small
paper notecard. A user story encapsulates the action of one function making it possible for software
developers to create a vertical slice of their work [2].
The following figure illustrates an conceptual example of a user story based on a possible need from a
Maintenance responsible.

Figure 3: An example of a user story
Of course you cannot gather the requirements without knowing who are your stakeholders. Make a list of the
of the involved stakeholders that will act as users or the receivers of the outcome of BI solution. Usually this
list is provided by the project.
Providing requirements could be a complex issue, especially when projects working in the BI area. In many
cases the business users need to get the data visualised and analysed before deciding about requirements.
In order to extract knowledge or insights from data, the business users need to visualize the data and then
applying methods and formulas to the data. This requires some BI Platforms that can extract, read, aggregates
and apply the methods and formulas to the data in a sandbox. An example of a BI Platform that could be used
to visualize and extract data in an easy and fast way is QlikView from QlikTech.
In other cases the business users do not have the capability and the required competence to find the right
methods and formulas, then they need to seek and find the right expertise in that specific area.
The following table and figure describes the flow when the business users or the projects have difficulties in
providing requirements.
# Activity Input Output Responsibility
1 Identify the project’s BI needs Project scope Described BI needs Project/Users
2 Describe the requirements Described BI
needs
BI requirements Project/Users
3 If the project needs help from a BI Platform
in order to develop the requirements
Described BI
needs
4 If the project needs help from experts
(inside or outside the company) to extract
knowledge or insights from data
Described BI
needs
5 Provide requirements BI requirements Described/Detailed
BI requirements
Project/Users
Table 3: The steps in the providing requirements flow

Figure number 4: Providing requirement
In many cases, step 4 is about creating very complex algorithms. The people who create these algorithms are
called “data scientists” and they have deep experience in math, statistics, data mining, and computer science.
In order to develop the requirements by using own experts/data scientists and or external experts/data
scientists, the project will need a Sandbox/Lab environment where the project can extract and load the
required information.
The following steps describes how to provide a Sandbox environment where the project can experiment on
the data that is extracted in the environment:
1. A Requirement Manager with the involvement of the Business User(s) gathers and documents the
draft requirements (user stories) and communicates the first requirements to the designer and to the
developers that are working in the BI platform.
2. The designer and the developers in the BI platform analyze the draft requirements and check if the
required information/data is already existing in the BI platform. If the information/data is already
loaded to the BI platform then the designer, the developers with the involvement of the Requirement
Manager develops and presents views to the business User(s). Otherwise the designer in the BI
platform could request more information/data from the suggested data sources, if needed.
3. The designer and the developers in the suggested data sources can extract and load the required
information/data from the suggested source systems into the target BI platform.
4. The Business User(s) analyzes the views from extracted/loaded data in order to specify their
requirements. The Requirements Manager gathers and documents requirements especially the
information requirements. The views will be corrected according to the business requirements. When
the implementation is complete (it may take a few iteration), the acceptance tests starts.

Figure 5: The steps in the providing Sandbox environment
The following table describes an example of a provided requirement. As we mentioned previously, the
requirements need to be analysed, specified, prioritised and approved.
It is also very important to use the right and the available templates when documenting the requirements. The
used template(s) should be recognised and accepted by the involved parts.
# Requiremen
t
(User
Stories)
Effect Origin Priori
ty
(H-M-
L)
Verification
Method
Affected
area
Comments
1 As a Business
Analyst, I
would like to
analyse the
age of and
the number
of events in
certain
overhead
power line so
that I can
suggest
underground
power cables
instead of
1. Less manual
efforts in
providing
these reports.
2. Correctness in
these reports
Network
Operation
(Tommy
X.)
H Test case(s) Network
Operation
organisation,
Procurement
organisation
The analysis
will lead to
select the
right
solution for
transporting
electricity to
the
customers

overhead
power lines
2
Table 4: The list of the requirements (User Stories)
Some explanations for the columns in the above table.
#: Requirement Sequence number.
Requirement: Description of a requirement placed on the deliverable of the project. Requirements can
deal with functionality, operability, user friendliness, etc.
Effect: Description of the intended effect of meeting the requirement on the receiver of the
deliverable or on the company as a whole.
Origin: Organisational unit or individual who has stated the requirement.
Priority: Priority as perceived by the originator of the requirement, e.g.: High – Medium – Low.
Verification Method: Approach to verifying if the requirement has been met by the project.
Affected area: Organisational units affected (positively or negatively) by implementing the requirement.
Comments: Any additional clarification, e.g. interrelationship between requirements, background to
the requirement, etc.
3.5.2 Information Requirements
The cornerstone of any BI project is the information that need to be analysed in order to make better
decisions as an example.
Information requirements have a wide scope and here we will concentrate on the main parts of information
requirements.
As we mentioned previously, the user stories or/and the use cases will describe a view over the requirements
and if there are any processes and flows that are involved in the project’s business requirements then the
project needs to describe and agree about these processes and flows too.
From the user stories, processes and flows we could create different views over the required information,
namely, the conceptual, logical and physical domains or models of the information/data, please see the
following figure.

Figure 6: The conceptual, logical and physical domains
According to [16], a conceptual data model is a summary-level data model that is most often used on strategic
data projects. It typically describes an entire enterprise. Due to its highly abstract nature, it may be referred to
as a conceptual model. Common characteristics of a conceptual data model:
• Enterprise-wide coverage of the business concepts. Think Customer, Product, Store, Location,
Asset.
• Designed and developed primarily for a business audience.
• Contains around 20-50 entities (or concepts) with no or extremely limited number of attributes
described. Sometimes architects try to limit it to printing on one page.
• Contains relationships between entities, but may or may not include cardinality and nullability.
• Entities will have definitions.
• Designed and developed to be independent of DBMS, data storage locations or
technologies. In fact, it would address digital and non-digital concepts. This means it would
model paper records and artifacts as well as database artifacts.
If we agree that an information model is a simplified abstract view of a more or less complex reality, then we
may need to try to draw the reality that we will transform to an information model.

The following figure represents a schematic view over some of the main objects that are related to the
distribution and metering flows. The figure shows the separation between the physical and the administrative
objects:
Figure 7: Schematic view over some of the physical and administrative objects that are related to the distribution
and metering flows
The following figure represents an example of a high-level conceptual data model. The figure represents a
view over some of the main information objects that are related to the distribution and metering flows.
Figure 8: An example of a high-level conceptual data model
In our projects in the enterprise we create the conceptual data models if they are really needed and we use
the conceptual data model for:
1. Understanding the business from an information point of view.
2. Listing and mapping the main conceptual information objects.
3. Getting agreement and consensus over the semantic (the meaning) of different information objects.

4. Defining the relationships between these involved objects in order to understand the business and the
business requirements from an information/data point of view.
According to [16], a logical data model is a fully-attributed data model that is independent of DBMS,
technology, data storage or organizational constraints. It typically describes data requirements from the
business point of view. While common data modeling techniques use a relational model notation, there is no
requirement that resulting data implementations must be created using relational technologies.
Common characteristics of a logical data model:
• Typically describes data requirements for a single project or major subject area.
• May be integrated with other logical data models via a repository of shared entities.
• Typically contains 100-1000 entities, although these numbers are highly variable depending on
the scope of the data model.
• Contains relationships between entities that address cardinality and nullability (optionality) of
the relationships.
• Designed and developed to be independent of DBMS, data storage locations or
technologies. In fact, it may address digital and non-digital concepts.
• Data attributes will typically have datatypes with precisions and lengths assigned.
• Data attributes will have nullability (optionality) assigned.
• Entities and attributes will have definitions.
• All kinds of other meta data may be included (retention rules, privacy indicators, volumetrics,
data lineage, etc.) In fact, the diagram of a logical data model may show only a tiny percentage of
the meta data contained within the model.
A logical data model will normally be derived from and or linked back to objects in a conceptual data model.
In our projects in the enterprise we often start with creating the logical data models because they are
necessary for understanding and developing the physical data models. If there are difficulties in defining and
understanding the logical data models then the project need to consider putting efforts in developing the
conceptual data model. We use the logical data model for:
1. Listing and mapping the main logical information objects.
2. Getting agreement and consensus over the semantic (the meaning) of different information objects.
3. Defining the cardinality and the relationships between these involved objects in order to understand
the business and the business requirements from an information/data point of view.
4. Create a basis for understanding and developing the physical data models.
The following figure represents an example of a logical data model:

Figure number 9: An example of a logical data model
According to [16], a physical data model is a fully-attributed data model that is dependent upon a specific
version of a data persistence technology. The target implementation technology may be a relational DBMS,
an XML document, a NoSQL data storage component, a spreadsheet or any other data implementation
option. Common characteristics of a physical data model:
• Typically describes data requirements for a single project or application. Sometimes even a
portion of an application.
• May be integrated with other physical data models via a repository of shared entities
• Typically contains 10-1000 tables, although these numbers are highly variable depending on
the scope of the data model.
• Contains relationships between tables that address cardinality and nullability (optionality) of the
relationships.
• Designed and developed to be dependent on a specific version of a DBMS, data storage
location or technology.
• Columns will have datatypes with precisions and lengths assigned.
• Columns will have nullability (optionality) assigned.
• Tables and columns will have definitions.
• Will also include other physical objects such as views, primary key constraints, foreign key
constraints, indexes, security roles, store procedures, XML extensions, file stores, etc.
• The diagram of a physical data model may show only a tiny percentage of the meta data
contained within the model.
The following figure represents an example of a high-level representation of a physical data model (in
Swedish):

Figure 10: An example of a physical data model (in Swedish)
Another example of a physical data model is presented in following figure [17]:

Figure 11: An example of a physical data model
A representation of a work request message format according to IEC 61968-6:

Figure 12: An example of a physical data model
An XML representation of a work request message format according to IEC 61968-6 is shown in the following
figure:
Figure 13: An example of XML representation of a physical data model
Often these physical data models are provided by the vendor of the products. The physical data models need
to be mapped to the logical data models. The mapping of the logical data models and physical data models
will lead to better understanding of the required data from the involved systems in e.g. a BI project.
3.5.3 Quality Attributes
3.5.3.1 Security Requirements

Security requirements as a subject, is very big to cover in this document. Here we will introduce some of the
main concepts and definitions that we will use later in this document.
The following figure presents the data in transit and data at rest in a multitier (n-tier) architecture. The
architecture that is shown in the figure is simply divided between a client, an application server and database
server/storage.
The red marked areas present the parts that need to be protected, especially if they contain data that is
considered as sensitive data (e.g. NSI “National Security Information”, special categories of personal data, etc).
Information that is considered important for the maintenance of vital societal functionalities of the nation-
state's critical infrastructure and the military defense, and which needs to be protected from, e.g. disclosure to
unauthorized individuals, entities or processes, is called National Security Information (NSI).
The schematic figure describes even the communication between different systems that need to be protected.
1. Data in transit
According to [11], data in transit, or data in motion, is data actively moving from one location to
another such as across the internet or through a private network. Data protection in transit is the
protection of this data while it’s traveling from network to network or being transferred from a local
storage device to a cloud storage device – wherever data is moving, effective data protection
measures for in transit data are critical as data is often considered less secure while in motion.
2. Data at rest
According to [11], data at rest is data that is not actively moving from device to device or network to
network such as data stored on a hard drive, laptop, flash drive, or archived/stored in some other way.
Data protection at rest aims to secure inactive data stored on any device or network. While data at
rest is sometimes considered to be less vulnerable than data in transit, attackers often find data at rest
a more valuable target than data in motion. The risk profile for data in transit or data at rest depends
on the security measures that are in place to secure data in either state.
3. Data in use
According to [21], data in use is an information technology term referring to active data which is
stored in a non-persistent digital state typically in computer random access memory (RAM), CPU
caches, or CPU registers. Data in use is used as a complement to the terms data in transit and data at
rest which together define the three states of digital data.

Figure 14: Data in transit and data at rest in a multitier (n-tier) architecture
Systems and applications that are using NSI data must consider a number of security requirements that need
to be fulfilled.
It is very important that the project should consider the ability of the evaluated BI platform to protect the data
in transit, in use and data at rest according to the security requirements. The BI platform should in a simple
way apply the protection capabilities.
The project should also consider the maturity, the required security competence (e.g. awareness about how to
handle NSI data) and the existing security routines in the maintenance organisation of the BI platform.
There are many aspects that need to be considered when we evaluating and selecting a BI Platform. The
security aspect or the security requirements is one of the most important aspects that need to be considered
when the BI Platform will be selected.
As we mentioned previously, the security requirements is a part of the non-functional requirements/quality
attributes.
In our Enterprise, the Information Asset Classification routine that is provided by the security office in our
enterprise is a good way to define the security classification of the required information. The routine for
information classification in our Enterprise is based four information security categories:
• Confidentiality
• Integrity
• Availability
• Traceability
The main outcomes of an Information Asset Classification routine are:
• The decision about the confidentiality of the required data (C4, C3, C2, C1)
• If the data is NSI data or not

The information asset classification will decide the target environment for the data, please see paragraph 4.5.5
- Decision For Selecting BI Platform According To Information And Security Requirements.
3.5.4 Scenario For Selecting A BI Platform According to Information Aspect
The required information/data that will be used in the reports/dashboard is an important element in selecting
a BI Platform.
The scenarios that are presented below are based on the location of data. The following paragraphs will
describe these scenarios.
3.5.4.1 Scenario 1 – Single Data Report
If the business user or the end customer needs a report or reports that require information that is located in a
single application, e.g. in an Asset Management system and the application could provide the report easily,
then the best choice here is to build the report in that single application.
Figure 15: The application specific data scenario
3.5.4.2 Scenario 2 – Mixed Data Sources
If the business user or the end customer needs a report or reports/dashboards that require data/information
from different data sources, e.g. in an Asset Management system, SCADA system, Meter Data Meter system
etc) then the best choice here is to use an available standard BI Platform that is recommended by the
Enterprise.

Figure 16: The BI Mixed Data Sources scenario
3.5.4.3 Scenario 3 – BI Capability
If the business user or the end customer needs a report or reports/dashboards that require BI capabilities (e.g.
analytical capabilities) then the best choice here is to use an available standard BI Platform that is
recommended by The Enterprise.
Figure 17: BI Capabilities scenario
3.5.5 Decision For Selecting BI Platform According To Information And Security
Requirements
There are many aspects that need to be considered when we evaluating and selecting a BI Platform. In this
document we suggest that the main aspects are, please see figure in the next page:

1. Defining the business requirements is always a good starting point. The user stories and or the use
cases will provide some understanding for required information/data.
2. One of the fundamental aspects is the information aspect and the scenarios for the required data that
will be used in the reports/dashboards. This aspect will decide if the data is located in single system or
in different systems. By the this aspect we mean:
a. The definition of the conceptual, logical and physical models and down to the requirements
on different data that will be the source for the business reports/dashboards.
b. The required BI data could be located in a single system or the data need to be collected and
received from different systems.
c. The existence of the required data in one or in several BI Platforms. If the required data is
already exists in the BI Platforms, then it is easy to build new reports/dashboards based on
that.
3. The security aspect or the IT security requirements is another important aspects that need to be
considered when the BI Platform will be selected. The IT security requirements should be gathered
and analysed as other important requirements.
4. If the information is classified as NSI data or if there are other regulatory requirements that do not
allow to have the data in the Cloud, then the project must use an on premise based BI platform, if the
Cloud based BI platform is not according to the IT security requirements. If the required information
in the BI reports/dashboards is not classified as NSI data or if there are no other regulatory
requirements to have the data in the Cloud, then the project has the permission to select a Cloud-
based platform.
Figure 18: Decision For Selecting a BI Platform According To Information And Security Requirements
4 BI Platforms
According to [5], Business Intelligence (BI) are the set of strategies, processes, applications, data,
technologies and technical architectures which are used to support the collection, data analysis, presentation
and dissemination of business information.
The scope of the guidelines is mainly the BI Platforms (applications/technologies) that are used in our
enterprise.

4.1 BI Platforms – Baseline Systems And Target Architecture
The activity for gathering and analysing the Baseline of the BI Platforms that are used in the enterprise, should
be performed by the responsible organisation for the BI area or the Solution Architect in the BI area. The result
of describing the baseline is often used as a starting point for the agreement about the Target Architecture of
the this area.
4.1.1 BI Platforms – Baseline Systems
The following figure lists the main existing BI Platforms in the company.
Figure 19: The Baseline for the current status of the BI Platforms
4.1.1.1 QlikView
The overall architecture of a QlikView installation reflects the separation of roles. The figure below shows a
QlikView deployment with Publisher containing the location of the QlikView components [22].

Figure 20: The QlikView components [22]
The following figure shows in a high level the QlikView BI platform’s configuration in the Enterprise. The
QlikView BI platform is used for mixing data from different data sources in order to provide the right reports
and dashboards for the right users.
Figure 21: The QlikView Configuration in the Enterprise

4.1.1.2 SAP BW
The graphic below shows a simplified view of the architecture of a complete BI solution with SAP NetWeaver
BW [24].
SAP NetWeaver BW can connect data sources using various interfaces that are aligned with the origin and
format of the data. Data transfer of non-SAP data in particular is supported by SAP BusinessObjects Data
Services.
The data is loaded to the entry layer in the Persistent Staging Area. Here the data is formatted (using one or
more layers of the data warehousing architecture) so it can be used for a specific purpose and then stored in
InfoProviders. During this process, master data enriches the data models by delivering information such as
texts, attributes, and hierarchies.
Besides replicating data from the source to the SAP NetWeaver BW system, it is also possible to access the
source data directly from the SAP NetWeaver BW system using VirtualProviders.
The analytic manager provides methods and services for analysis and planning as well as generic services such
as caching and security.
You can use the planning modeler to define models that allow data to be entered and changed in the scope
of business planning.
You can use BEx Query Designer to generate views of the InfoProvider data that are optimized for analysis or
planning purposes. These views are called queries and form the basis for analysis, planning and reporting.
Metadata and documents help to document data and objects in SAP NetWeaver BW.
You can define how the BW data is displayed using the tools in SAP Business Explorers (SAP BEx). The tools
support the creation of Web-based and Microsoft Excel-based applications for analysis, planning, and
reporting. The BEx applications created with the BEx tools can be integrated into the SAP NetWeaver Portal.
Integration with SAP BusinessObjects tools offers further options for analysis and reporting in addition to the
standard SAP BEx functions. You can access BI information (like reports, analyses and dashboards) with the
SAP BusinessObjects BI Portal InfoView.
SAP NetWeaver BW has an open architecture. This allows integration of external, non-SAP sources,
broadcasting of BW data to downstream systems and moving data to near-line storages to reduce the volume
of data in InfoProviders. Third-party tools for analysis and reporting can also be connected using the open
analysis interfaces (ODBO, XMLA).
The SAP NetWeaver BW Accelerator improves the performance of queries when reading BW data. It can be
delivered as a preconfigured appliance for partner hardware. If you use the SAP HANA database to persist BW
data, you do not need a SAP NetWeaver BW Accelerator to improve performance [24].

Figure 22: A simplified view of the architecture of a complete BI solution with SAP NetWeaver BW
4.1.1.3 Power BI
Our Enterprise is using Power BI as an Analytic Platform. Our Power BI Platform is a group-wide data platform
to suit Business Intelligence and Data Analytics use cases across the Enterprise in areas for example of
streaming, big data storage, machine learning and traditional warehousing. The target groups for the platform
varies, with the ambition of fulfilling as many use cases as possible across the Enterprise with the various
offerings.
Power BI is a business analytics service provided by Microsoft. It provides interactive visualizations with self-
service business intelligence capabilities, where end users can create reports and dashboards by themselves,
without having to depend on any information technology staff or database administrator.
The following figure describes the main components of the Power BI’s architecture:
1. Power BI has the ability to connect and integrate to different data sources and fetch data from
different formats including On-Premises databases, cloud and web sources.
2. The extracted and loaded data can be transformed with different transformation options provided by
Power BI platform. This component is a part of the Azure Data Factory or SSIS with Azure Pack for
Data extraction and transformation.
3. Usually data is loaded to Azure SQL Database or Azure SQL Data Warehouse as the database / data
warehouse engine in cloud. But Microsoft recently released the a version of the Power BI (Power BI
Premium) that has the capability to publish reports to on premises Power BI Report Server.

4. Reports and dashboard could be visualized in multi-device platforms. Power BI reports are delivered
to across PC, mobile, tablet and other devices.
Figure 23: A simplified view of the architecture of a Power BI solution [25]
4.1.2 BI Platforms – Target/Transition Architecture
The following sections describe how to define the Target Architecture for the BI area.
4.2 BI Platforms – Target Systems
The business requirements regarding BI platforms have changed during the last years. The decision makers are
requiring to gain more insights from the Enterprise’s data in order to make well-informed decisions.
The systems that were used during the last 15 years in the enterprise were based on providing predefined and
static reports that visualized the main KPIs or score cards.
An example of the new needs from the business is the request for applying predictive maintenance instead of
preventive maintenance.
The new generations of the BI platforms in the Enterprise were installed in 2007 and now the Enterprise has BI
analytical Platforms that are used by experienced users.
The next big event that will occur and will impact the BI area in our enterprise is the outsourcing of the on
premise based billing and CRM systems. The new vendor will provide reports that are based on the new CRM
and the new billing system.
The following figure shows the new billing and CRM systems and the decommissioning of the old BI platforms
(the red marked applications).

Figure 24: The Target of the BI Platforms
4.2.1 BI Platforms – Information Content
Different platforms can be specialised in having different domains of information. Some of these domains
could be:
• Customer and Customer Relationships Domain
• Financial Domain
• Asset including the Metering Domain
• Service Management Domain
It is very important to know what kind of information is located in different systems/data sources and what
kind of information is extracted and loaded to different BI Platforms.
The enterprise could invest into creating different BI Platforms. For example a BI Platform for critical/NSI data
(e.g. an asset-based BI platform).
Another BI platform could include the required information about customers and their consumptions, invoices
etc. These BI Platforms will be some kind of “single version of truth” for the data that they contain.
The criteria for selecting the right BI Platform could be impacted by the availability of the required information
in the BI Platforms. So by the information content we mean:
1. The BI Platform already contain the required information from the business or the BI Platform is
specialised in managing the required information domain(s).
2. The roadmap is pointing that the required information/data(s) will be extracted to a BI Platform due to
the implementation of a certain project(s).

It is the responsibility of the maintenance organisations of different BI Platforms to inform about and describe
the availability of the different information and information domains in the available BI Platforms.
There are many ways to visualise the existence of different critical and required data and information objects
in different BI Platforms/systems. This is very important to know when the projects want to fetch or extract and
load the right data to the selected BI Platform.
The following list shows the assessment of the master data in different systems in the company. The list
contains some main information objects mapped to the existing (as-is) and target systems. The circles define
the operations the systems could perform on the data (e.g. create, read, update, delete “CRUD”).
Table 5: A high-level visualization of some of main information objects in the Enterprise’s systems
The list above is a high-level visualization of some of main information objects in the Enterprise’s systems. Of
course the project will need to have another level of details and granularity in the required information/data.
This level of granularity is not presented here.
4.2.2 Decision For Selecting BI Platform According To Information And Security
Requirements And The Type Of BI Platform
The figure 15 is updated with adding the Target BI platforms. As we mentioned previously, if the information is
classified as NSI data or if there are other regulatory requirements that do not allow to have the data in the
Cloud, the project must use an on premise based BI platform (if the Cloud based BI platform is not according
to the IT security requirements). The main available BI platforms in the on premise side are:
1. Power BI “on premise”

2. SAP BW (plans to be decommissioned in the future)
3. QlikView
The above BI platforms could have different types of information/data domains. And the above BI platforms
could have different types of capabilities and different maturities of the existing capabilities in these platforms.
The appendix part of this document is about the BI capabilities. The appendix is also describes the
implementation of these capabilities in different available BI platforms in the company.
If the required information in the BI reports/dashboards is not classified as NSI data or if there are no other
regulatory requirements to have the data in the Cloud, then the project has the permission to select the Power
BI Cloud-based platform. As Cloud based BI platform the company offers the following BI platforms:
4. Power BI – Cloud-based platform
5. The new CRM and the new billing system – the system has own reporting BI platform based on
QlikView.
Figure 25: The Decision For Selecting BI Platform According To Information And Security Requirements And The
Type Of BI Platform
5 Appendices
5.1 The Project’s Aspect
The project’s aspect is about the main constraints in a project and how they could impact the delivery or the
outcome of the project, in e.g. a BI project.
The classic triangle in project management shows the main three constraints in projects (time, cost and scope)
and how these constraints impacts the quality of the project’s outcome.
It is very important for a project manager to have control over these constraints and mitigate the risks for
scope creep, budget changes and the time to deliver the project.

Figure 26: The classic triangle in project management
The selected methodology and way of working need to be synchronized with the BI platform provider’s
organization.
An overview of the Project management methodology is presented in the reference [19]:
• Agile – collaborating to iteratively deliver whatever works
• Scrum – enabling a small, cross-functional, self-managing team to deliver fast
• Kanban – improving speed and quality of delivery by increasing visibility of work in progress, and
limiting multi-tasking
• Scrumban – limiting work in progress like Kanban with a daily stand up like Scrum
• Lean – streamlining and eliminating waste to deliver more with less
• XP – Extreme Programming methodology– doing development robustly to ensure quality
• Waterfall – planning projects fully, then executing through phases
• PRINCE2 – controlled project management that leaves nothing to chance
• PMI’s PMBOK – applying universal standards to waterfall project management
In our enterprise we are using the following Waterfall methodology:
Figure 27: VPMM as a Waterfall methodology

VPMM has an Agile variant - Vattenfall Agile Project Framework, . The purpose of the Vattenfall Agile
Project Framework is to support consistent, efficient and effective management and governance of
Agile Projects and to improve project performance by:
• Supporting a common understanding of what has to be delivered for informed decision making
in each of the project phases
• Clarifying generic project governance and management roles, responsibilities and mandate
levels
• Defining Agile Project Assurance methodologies [20]
Figure 28: Vattenfall Agile Project Framework
The BI project should suggest and decide the methodology that will be used and then agree about the
suggested/decided methodology with the involved parts.
The following table is a suggestion for how a BI Reporting Project can be implemented in fast track way. From
a request for new flexible reports/dashboard to an implemented and maintained reports.
The outcomes, approximate budget requirements and the corresponding VPMM phase of every step is
described in the following table:
# Activity Desired Outcome Budget % In TG
1 Business seeks For Information about their
KPIs/reports/dashboards
Top 5-10
KPIs/reports/dashboards list
with definitions
5% TG0-TG1
2 IT helps with defining the related data and
making the data available for the business
Appointed list of data
sources
5% TG0-TG1
3 The business starts prototyping (e.g. using a BI
platform as QlikView)
Preparing for a demo based
on the prototype
20% TG1-TG2
4 The business and IT Documents/specifies the
requirements
Requirements specification
(KPIs/reports/dashboards
details, information/data,..)
20% TG1-TG2

5 IT specifies the right target system for the
business information and the right solution
Solution Selection (Solution
Approach)
10% TG2-TG3
6 The business and the IT provider agree about
the solution, budget (costs) and time plan
Project Specification/status
report
5% TG2-TG3
7 The IT provider implements the solution Implemented reports/KPIs 20% TG3-TG4
8 The business test the solution Approved test cases 10% TG4-TG5
9 The IT provider Deploys and maintains the
solution
Final Report 5% TG5
Table 6: An example of how a BI Reporting Project can be implemented in fast track way
5.2 The Infrastructure And Integration Aspects
The infrastructure and the integration aspects are very important parts in any BI project. Regardless if the BI
project will select a Cloud-based solution or an on premise-based solution, some integration flows will be
needed in order to feed the BI platform with the right/required data. And this of course will impact the
infrastructure solution, especially if the connectivity between the source systems and the BI platform is not
established yet.
Involvement of infrastructure and integration experts/solution architects in an early stage of the project is
essential to define the scope of the integrations and the integration requirements.
The interoperability capability of the BI platforms is another significant function that need to be considered.
The infrastructure and the integration aspects are parts of the solution selection process that will be reviewed
as other parts of the project.
5.3 The BI Capabilities Aspect
According to TOGAF [15], a capability is: An ability that an organization, person, or system possesses.
Capabilities are typically expressed in general and high-level terms and typically require a combination of
organization, people, processes, and technology to achieve. For example, marketing, customer contact, or
outbound telemarketing.
In our Enterprise we defiened our Business Capability Map (BCM). The figure number 19 represents the level 1
of the BCM for the Enterprise. The BI capability is defined as Business Support Capability, see the same figure.

Figure 29: The Business Capability Map (BCM) for the Enterprise (Level 0)
In our guidelines we distinguish between the capabilities in:
1. Reporting Platforms that are not based on using BI Platforms (e.g. reporting Platforms that are
included in different systems in an asset maintenance Platform or in meter reading Platform). These
Platforms are often not based on BI softwares.
2. BI Platforms that are based on BI softwares (e.g. QlikView, Power BI, Cognos Analytics) that are used
for analysing information in order to getting a deep insight in the business and improve the business
decision-making process by putting the right information into the hands of those who need it most.
5.3.1 BI Capabilities According To Gartner
A way to break down the capabilities in figure 19, is to define the next levels of capabilities. For identifying the
next level in BI/Reporting capability we will use the definitions provided by Gartner. The 15 capabilities that
are presented in table 6, are divided into 5 categories:
• Infrastructure
• Data Management
• Analysis and Content Creation

• Sharing of Findings
• Overall platform capabilities
Many of these capabilities are more or less IT Related. This level of capabilities will be used to select the right
BI system.
Infrastructure
BI Platform
Administration, Security
and Architecture
Capabilities that enable platform security, administering users, auditing platform
access and utilization, optimizing performance and ensuring high availability and
disaster recovery
Cloud BI Platform-as-a-service and analytic-application-as-a-service capabilities for
building, deploying and managing analytics and analytic applications in the
cloud, based on data both in the cloud and on-premises.
Data Source
Connectivity and
Ingestion
Capabilities that allow users to connect to structured and unstructured data
contained within various types of storage platforms, both on-premises and in the
cloud
Data Management
Metadata Management Platforms for enabling users to leverage a common SOR (System Of record)
semantic model and metadata. These should provide a robust and centralized
way for administrators to search, capture, store, reuse and publish metadata
objects such as dimensions, hierarchies, measures, performance metrics/key
performance indicators (KPIs), and report layout objects, parameters and so on.
Administrators should have the ability to promote a business-user-defined data
mashup and metadata to the SOR metadata
Self-Contained
Extraction,
Transformation and
Loading (ETL) and Data
Storage
Platform capabilities for accessing, integrating, transforming and loading data
into a self-contained performance engine, with the ability to index data and
manage data loads and refresh scheduling.
Self-Service Data
Preparation
"Drag and drop" user-driven data combination of different sources, and the
creation of analytic models such as user-defined measures, sets, groups and
hierarchies. Advanced capabilities include machine-learning-enabled semantic
auto discovery, intelligent joins, intelligent profiling, hierarchy generation, data
lineage and data blending on varied data sources, including multistructured data.
Analysis and Content
Creation
Embedded Advanced
Analytics
Enables users to easily access advanced analytics capabilities that are self-
contained within the platform itself or through the import and integration of
externally developed models
Analytic Dashboards The ability to create highly interactive dashboards and content with visual
exploration and embedded advanced and geospatial analytics to be consumed
by others
Interactive Visual
Exploration
Enables the exploration of data via an array of visualization options that go
beyond those of basic pie, bar and line charts to include heat and tree maps,
geographic maps, scatter plots and other special-purpose visuals. These
Platforms enable users to analyse and manipulate the data by interacting directly
with a visual representation of it to display as percentages, bins and groups.

Smart Data Discovery Automatically finds, visualizes and narrates important findings such as
correlations, exceptions, clusters, links and predictions in data that are relevant to
users without requiring them to build models or write algorithms. Users explore
data via visualizations, natural-language-generated narration, search and NLQ
technologies.
Mobile Exploration and
Authoring
Enables organizations to develop and deliver content to mobile devices in a
publishing and/or interactive mode, and takes advantage of mobile devices'
native capabilities, such as touchscreen, camera and location awareness.
Sharing of Findings
Embedding Analytic
Content
Capabilities including a software developer's kit with APIs and support for open
standards for creating and modifying analytic content, visualizations and
applications, embedding them into a business process and/or an application or
portal. These capabilities can reside outside the application, reusing the analytic
infrastructure, but must be easily and seamlessly accessible from inside the
application without forcing users to switch between systems. The capabilities for
integrating BI and analytics with the application architecture will enable users to
choose where in the business process the analytics should be embedded.
Publish, Share and
Collaborate on Analytic
Content
Capabilities that allow users to publish, deploy and operationalize analytic
content through various output types and distribution methods, with support for
content search, scheduling and alerts. Enables users to share, discuss and track
information, analysis, analytic content and decisions via discussion threads, chat
and annotations.
Overall platform
capabilities
Platform Capabilities
and Workflow
This capability considers the degree to which capabilities are offered in a single,
seamless product or across multiple products with little integration.
Ease of Use and Visual
Appeal
Ease of use to administer and deploy the platform, create content, consume and
interact with content, as well as the visual appeal.
Table number 7: The 15 BI capabilities according to Gartner
5.3.1.1 BI Capabilities represented in Different BI Platforms
Depending on the implementation strategy and the configuration, development of the available BI platforms
in the enterprise, the availability of the BI capabilities could be different from a BI platform to another. And the
different BI platforms could provide and offer their BI capabilities to their customers in variable degrees of
satisfaction.
Gartner’s own evaluation is presented in the list below. Scores in following figure represent analyst opinion
only and specifically exclude customer opinions that can sometimes inflate as well as suppress product
capability scores as customers work with different definitions and expectations, [6].

Figure 30: Product/Service Rating on Critical Capabilities (Analyst Opinion Only)
5.3.2 BI Capabilities Requirements
A simple way to gather and provide the BI Capabilities Requirements is to make a list from the presented
Gartner BI Capabilities, please see table 7.
Define the levels of priority of each capability (e.g. high, medium and low), please see the following table.
The rating of the BI Capabilities could be done by interviewing the users that will use the BI platform. And it
should be wise to prepare a demo for explaining the different BI Capabilities in the available BI Platforms.
Infrastructure
Required
(H, M, L)
1
BI Platform
Administration, Security
and Architecture
Capabilities that enable platform security, administering users,
auditing platform access and utilization, optimizing
performance and ensuring high availability and disaster
recovery H
2
Cloud BI
Platform-as-a-service and analytic-application-as-a-service
capabilities for building, deploying and managing analytics
and analytic applications in the cloud, based on data both in
the cloud and on-premises.. H

3
Data Source Connectivity
and Ingestion
Capabilities that allow users to connect to structured and
unstructured data contained within various types of storage
platforms, both on-premises and in the cloud H
Data Management
4
Metadata Management
Tools for enabling users to leverage a common SOR semantic
model and metadata. These should provide a robust and
centralized way for administrators to search, capture, store,
reuse and publish metadata objects such as dimensions,
hierarchies, measures, performance metrics/key performance
indicators (KPIs), and report layout objects, parameters and so
on. Administrators should have the ability to promote a
business-user-defined data mashup and metadata to the SOR
metadata M
5
Self-Contained Extraction,
Transformation and
Loading (ETL) and Data
Storage
Platform capabilities for accessing, integrating, transforming
and loading data into a self-contained performance engine,
with the ability to index data and manage data loads and
refresh scheduling. H
6
Self-Service Data
Preparation
"Drag and drop" user-driven data combination of different
sources, and the creation of analytic models such as user-
defined measures, sets, groups and hierarchies. Advanced
capabilities include machine-learning-enabled semantic
autodiscovery, intelligent joins, intelligent profiling, hierarchy
generation, data lineage and data blending on varied data
sources, including multistructured data. L
Analysis and Content
Creation
7
Embedded Advanced
Analytics
Enables users to easily access advanced analytics capabilities
that are self-contained within the platform itself or through
the import and integration of externally developed models M
8
Analytic Dashboards
The ability to create highly interactive dashboards and
content with visual exploration and embedded advanced and
geospatial analytics to be consumed by others H
9
Interactive Visual
Exploration
Enables the exploration of data via an array of visualization
options that go beyond those of basic pie, bar and line charts
to include heat and tree maps, geographic maps, scatter plots
and other special-purpose visuals. These tools enable users to
analyze and manipulate the data by interacting directly with a
visual representation of it to display as percentages, bins and
groups. M
10
Smart Data Discovery
Automatically finds, visualizes and narrates important findings
such as correlations, exceptions, clusters, links and predictions
in data that are relevant to users without requiring them to
build models or write algorithms. Users explore data via
visualizations, natural-language-generated narration, search
and NLQ technologies. L

11
Mobile Exploration and
Authoring
Enables organizations to develop and deliver content to
mobile devices in a publishing and/or interactive mode, and
takes advantage of mobile devices' native capabilities, such as
touchscreen, camera and location awareness. L
Sharing of Findings
12
Embedding Analytic
Content
Capabilities including a software developer's kit with APIs and
support for open standards for creating and modifying
analytic content, visualizations and applications, embedding
them into a business process and/or an application or portal.
These capabilities can reside outside the application, reusing
the analytic infrastructure, but must be easily and seamlessly
accessible from inside the application without forcing users to
switch between systems. The capabilities for integrating BI
and analytics with the application architecture will enable
users to choose where in the business process the analytics
should be embedded. L
13
Publish, Share and
Collaborate on Analytic
Content
Capabilities that allow users to publish, deploy and
operationalize analytic content through various output types
and distribution methods, with support for content search,
scheduling and alerts. Enables users to share, discuss and
track information, analysis, analytic content and decisions via
discussion threads, chat and annotations. L
Overall platform
capabilities
14
Platform Capabilities and
Workflow
This capability considers the degree to which capabilities are
offered in a single, seamless product or across multiple
products with little integration. H
15
Ease of Use and Visual
Appeal
Ease of use to administer and deploy the platform, create
content, consume and interact with content, as well as the
visual appeal. H
Table 8: An example of priorities of each capability
Please note that the above priorities of each capability are just an example.
5.3.3 Decision For Selecting BI Platform According BI Capabilities
Another very important part of this journey is the mapping of the requirements to the available BI Platforms.
As we mentioned previously, the requirements includes the capabilities that the BI Platforms should provide
for the users.
In the paragraph 4.5.1 – providing requirements, we presented a way to gather and describe the requirements.
The following decision flow explains in a high-level, the way to map the requirements to the available BI
Platforms. The decision is based on figure 21.
1. By now, we assume that the list of the BI requirements is approved by the project’s stakeholders,
please see corresponding paragraphs and the required BI capabilities.

2. The second step will be executed in the design phase of the project. The best way to perform this step
is by using the solution selection process. The solution selection process with inputs from the BI
requirements including the BI capability requirements, and the inputs from evaluating the existing BI
platforms, will direct the project to select the right BI Platform. The solution selection process will also
assess different important aspects like the information aspect and other aspects that are prioritised by
the project’s stakeholders.
3. Cases where requirements regarding BI Platform cannot be fulfilled, must be reported as exceptions
and authorised by the e.g. a Business Architect or a project manager. If the project with the help of the
solution selection is missing an important requirement in the existing BI platforms or/and the project
is not satisfied with some BI capabilities in the existing BI platforms, then there should be a way to
escalate the problem to (e.g. the Business Architect, the steering group in the project or other parts in
the organisation that are responsible for the BI area). An exception report should be initiated and an
exception handling/flow should be started. The documented exceptions must include an explanation
as to why the exception is necessary and any compensating measures, or statement accepting risk.
Figure 31: Decision For Selecting BI Platform According BI Capabilities

Simplified guidelines for selecting a bi platform in an enterprise

Recommended

More Related Content

What's hot (20)

Similar to Simplified guidelines for selecting a bi platform in an enterprise (20)

Recently uploaded (20)

Simplified guidelines for selecting a bi platform in an enterprise