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

Data & Analytics