PRAGUE UNIVERSITY OF ECONOMICS AND BUSINESS
Faculty of International Relations
INTEGRATION OF CREDIT DATA INTO THE ENTERPRISE DATA ARCHITECTURE
MASTER THESIS
Study programme: International Economic Relations Field of study: International Trade
Author: Bc. Denis Zelenin Supervisor: doc. Ing. Jan Pour, CSc.
Prague, December 2020
2
Declaration
I declare that this thesis entitled Integration of Credit Data into the Enterprise Data Architecture is a result of my own research except as cited in the references. All used literature and materials are mentioned in the attached list of bibliography.
In Prague 6th of December 2020 ……...………..
Signature
3
Acknowledgement
First of all, I’d like to thank the supervisor of this thesis, doc. Ing. Jan Pour, CSc., Who, despite the challenges, did not gave up on me and provided me with valuable feedback. Not to mention his contribution to my decision to study business IT in the first place. I’d also want to thank doc. Ing.
Martina Jiránková, Ph.D. for her support and coaching in the process of writing this thesis.
Last but not least, I’d like to thank Stewart Oldroyd for spending his time helping me editing and improving this thesis.
4
Abstract
This thesis deals with the growing importance of data architecture in today’s business environment.
The thesis analyses how in order to achieve its data analytical goals, enterprises need to take ownership of the concept of data architecture, on the other hand, today’s definition of data architecture does not reflect sufficiently the business’s role in designing and implementing it, focusing rather on the technical aspects. This thesis tries to bridge between the IT and the business world, showing how business driven initiatives, and smart utilization of available technologies, can change the way data analytics is performed, how BI solutions are designed, and how it impacts real business processes and results. This is done through a focus on a real-world use case of a Credit department within a major oil corporation that moves away from stand-alone BI solutions and integrate its data into the corporate data architecture.
Keywords
Alteryx, business intelligence, data architecture, data analytics, SAP HANA
5
Abstrakt
Tato práce se zabývá rostoucím významem datové architektury v dnešním business prostředí.
Analyzuje, jak business pro dosažení svých analytických cílů v oblasti dat musí převzít vlastnictví nad konceptem datové architektury, jejíž definice v současnosti dostatečně neodráží roli businessu při jejím navrhování a implementaci, spíše se zaměřuje na technické aspekty. Tato práce se pokouší propojit IT a business svět a ukazuje, jak iniciativa vedena businessem a chytré využití dostupných technologií mohou změnit způsob, jakým se provádí datová analýza, jak se navrhují řešení BI a jak to ovlivňuje skutečné procesy a výsledky businessu. Propojení daných dvou sfér je prezentováno na skutečném případu kreditního oddělení v rámci velké ropné společnosti, která se vzdaluje jednorázovým BI řešením a integruje svá data do podnikové datové architektury.
Klíčová slova
Alteryx, business Intelligence, datová analýza, datová architektura, SAP HANA
6
Glossary/Abriviations
ABI- Analytics and Business Intelligence
DAS- Data, Analytics and Systems (Business IT team supporting data capabilities of the enterprise) DIM- Master data based foundational data model (Dimension)
DMSA- Data Management Solutions for Analytics EDH- Enterprise Data Hub
MSR- Transactional data based foundational data model (Measure) OPDBMS- Operational Database Management Systems
7
Content
Glossary/Abriviations ... 6
Figures and Tables ... 9
Figures ... 9
TABLES ... 10
INTRODUCTION ... 11
Topic Definition ... 11
Reasons for Choosing the Topic ... 11
Scope and Goals of the Diploma Thesis... 11
Structure of the Diploma Thesis ... 12
Approach to the Solution ... 12
Assumptions and Limitations ... 12
1. Literature Review ... 13
1.1 Technical Literature ... 13
1.2 Online resources ... 13
1.3 Internal documentation and author creation ... 14
2. The Theory of Data Architecture ... 15
2.1 Definition ... 15
2.2 Types of Data Architecture ... 18
2.3 Business Intelligence as Part of the Data Architecture ... 24
2.4 Conclusion of Chapter 2 ... 26
3. Business Overview and Business Objectives ... 28
3.1 Corporate Structure ... 28
3.2 Data Management ... 29
3.3 Conclusion of Chapter 3 ... 30
4. Technological Landscape ... 31
4.1 Database Technology ... 31
4.1.1 SAP HANA ... 33
4.2 Data Visualization Tools ... 34
4.2.1 Tableau ... 36
4.2.2 Power BI ... 36
4.3 Data Preparation Tools ... 37
4.3.1 Alteryx ... 38
8
4.3.2 Power Query ... 40
4.4 Integrating the tools to support the data infrastructure ... 41
4.5 Conclusion of Chapter 4 ... 43
5. Data Modules Implementation and Output ... 44
5.1 Credit Risk vs. Reward Module ... 45
5.1.1 Module Overview ... 46
5.1.2 Reporting Use Case ... 46
5.1.3 Business Benefit Case ... 47
5.1.4 Integrating the Solution into the Enterprise Data Architecture ... 50
5.1.5 Data Scope ... 52
5.1.6 System as it is ... 53
5.1.7 System to be ... 54
5.1.8 Key Dimensions and Calculations ... 58
5.2 Credit Receivables Module ... 61
5.2.1 Module Overview ... 61
5.2.2 Reporting Use Case ... 61
5.2.3 Business Benefit Case ... 62
5.2.4 Integrating the Solution into the Enterprise Data Architecture ... 65
5.2.5 Data Scope ... 66
5.2.6 System as it is ... 68
5.2.7 System to be ... 68
5.2.8 Key Dimensions and Calculations ... 72
5.3 Conclusion of Chapter 5 ... 75
Conclusion ... 77
Bibliography/Sources ... 79
9
Figures and Tables
Figures
Figure 1: The DAMA-DMBOK2 Data Management Framework ... 16
Figure 2: TOGAF Enterprise Architecture Framework ... 17
Figure 3: Sample Enterprise Data Warehouse architecture ... 20
Figure 4: Sample Operational data store architecture ... 21
Figure 5: Sample data vault architecture ... 22
Figure 6: A sample of Hub and Spoke Data Marts architecture ... 23
Figure 7: McKinsey best-practice reference-data architecture ... 26
Figure 8: High level corporate structure ... 28
Figure 9: Magic Quadrant for Operational Database Management Systems ... 32
Figure 10: Magic Quadrant for Analytics and Business Intelligence Platforms ... 35
Figure 11: Data analytics process and time saving by data preparation tools ... 38
Figure 12: Alteryx menu of drag and drop tools... 39
Figure 13: Translation of Alteryx model into SAP HANA model ... 40
Figure 14: Technological landscape for Credit data analytics ... 41
Figure 15: Enterprise data hub architecture, the hub of hubs concept ... 44
Figure 16: Enterprise Data Hub environment Architecture ... 45
Figure 17: Customer overview dashboard ... 48
Figure 18: Risk vs. Reward bubble chart ... 48
Figure 19: Portfolio benchmark bubble chart ... 49
Figure 20: Security measures removal impact ... 50
Figure 21: Integration of Credit Risk vs. Reward solution into the enterprise data architecture ... 51
Figure 22: Risk vs. Reward process prior to the EDH module implementation ... 54
Figure 23: Credit Risk vs. Reward project full data flow diagram ... 55
Figure 24: Credit risk vs. reward analytics flow ... 57
Figure 25: Integration of Credit Receivables solution into the enterprise data architecture ... 65
Figure 26: Split design of the BSEG&BKPF tables into new foundational models ... 67
Figure 27: Credit Receivables project full data flow diagram ... 68
Figure 28: Input parameter interaction in Tableau ... 70
Figure 29: Visual representation of the Trend view split components ... 70
Figure 30: Credit receivables analytics flow ... 71
10
TABLES
Table 1: Key dimensions and measures in the Risk vs Reward module... 59
Table 2: Key calculations in the Risk vs Reward module ... 60
Table 3: Key dimensions and measures in the Credit Receivables module... 72
Table 4: Key calculations in the Credit Receivables module ... 74
11
INTRODUCTION
Topic Definition
The importance of data and business intelligence for a corporation is no longer a topic for debate but rather a necessity to compete, stay relevant in the market, and also to meet various legal and accounting standards and regulations. Cost optimization, margin optimization and hidden market opportunities are some of the benefits that drive companies to invest billions of dollars into its data infrastructure and BI solutions.
The thesis looks into the benefits of shifting from stand-alone BI solutions to broader data architecture solutions on the corporate, division or department level. This is done through analysing data architecture’s place in the overall enterprise architecture, business data needs and the changing interaction between the business and IT.
To put theory into practice, I provide a solution of integration of treasurer’s Credit data into the enterprise data architecture, in line with the broader data architectural approach, using today’s available tools and collaboration between IT and business departments.
Reasons for Choosing the Topic
The reason for choosing the topic is that I see a gap between what I studied during my studies of Informatics in Business, which usually prepares students to be, among others, BI consultants; and on the other hand what I see in my work, which revolves around providing the corporation with data to support its operations and to find new opportunities hidden within our ERP and external systems.
The demand for data and the frequency of required changes is so massive, that a specific BI solution, designed to meet a certain goal or answer certain questions, might become irrelevant or insufficient before the design phase is even finalized. For that reason, I started working with a broader concept that would meet not only the current business requirements, but also those that will come in the future, in some cases without the business realizing that those solution will be needed (for example to meet future predictive analytics and machine learning requirements). I later learned that this approach falls under the term of data architecture, and while I got to it through my own experience and common sense, there is a whole theory and philosophy behind it.
Scope and Goals of the Diploma Thesis
The goal of the thesis is to properly define, and to provide the business perspective on Data Architecture, aiming to demonstrate how companies can benefit from switching from standalone Business Intelligence solutions to a broader architectural approach and finally to demonstrate such a solution in practice.
The scope of the thesis covers the theoretical overview of the topic, description of the environment in which the theory is applied in practice, and finally to cover the real solution that was designed and implemented by the author.
12
Structure of the Diploma Thesis
The thesis can be divided into three sections-
Theoretical part- in this section I start with the definition of the term Data Architecture and its place in the overall enterprise architecture. With terminology in place, I cover the different types of architecture. Finally, I put Business Intelligence into the context of data architecture. Throughout the theoretical part I provide personal observations and remarks from practice.
Environment description- in this section I provide an overview of the environment in which that practical development was developed. This section is divided into two chapters, the first describes the enterprise structure, and the second covers the technologies used and available for the solution.
Practical part- the final section covers the actual solution that was delivered by the author:
integration of Credit into the enterprise data architecture. The section covers both the technical and the business aspects of the solution.
Within this thesis, citations are referenced continuously within the text, a methodology that is in line with the Faculty of International Relations requirements, to which the author belongs. This process was agreed with the thesis supervisor.
Approach to the Solution
To meet the goals of the thesis, I started with a theoretical research of the topic in order to define it with the proper terms (Business intelligence and data infrastructure were considered). After identifying the proper terminology, I provide a theoretical analysis of the place of the data architecture within the enterprise architecture, combined with personal experience and remarks from the business perspective. With the theoretical frame in place, I give an overview of the specific needs and requirements of the Treasurer’s Credit department in major oil corporation. This overview is based on the author’s experience, as the author himself is the main point of contact for data related questions within the department. In the practical part of the thesis, I use internal documentation of the projects that I designed and lead to provide a practical solution of meeting Credit department’s needs by integrating its data into the corporate data architecture.
Assumptions and Limitations
While the topic and the practical solution is of a technical nature, the author still represents the business side of the project (serving effectively as the Business Venture Manager), based on which this thesis is written. For that reason, the style and the language of the thesis might seem sometimes vague or not sophisticatedly technical to a purely IT oriented person. Also from choosing which part of the practical solution to cover, a bigger emphasis is placed on the practical use of the data rather than the technical documentation, this also reflects the author’s role in the project- to translate the business needs into an IT friendly and data friendly language, and to make sure that those needs are met, while the technical role itself is executed by a dedicated team of IT developers. No interviews with the management are covered in this thesis, as the business needs were collected unsystematically over the course of two years by the author.
13
1. Literature Review
In this chapter I will provide a description of the sources that were used in this thesis. This chapter is separated into 3 sections: Technical literature, online resources and internal documentation, which was used as part of the practical solution of the thesis. All of those sources are cited throughout the thesis, and the full list can be found in the Bibliography section.
1.1 Technical Literature
Technical literature that is listed below was mainly used for my research of the theoretical part of the thesis (chapter 2).
DAMA-DMBOK: data management body of knowledge- DAMA-DMBOK is a book that combines best practices and experience from well experienced contributors in the field of data management. It concentrates on developing practical practices for enterprise data management solutions. The book is published by the Data Management Association International, which provides well respected certificates for data management professionals.
The TOGAF® Standard, Version 9.2 – TOGAF is an Enterprise Architecture methodology and framework standard, its standard is a publication that covers all the areas of enterprise architecture, with data architecture being part of it. The publication is constantly updated with version 9.2 being the latest available version at the time of writing this thesis.
Applied Microsoft® Business Intelligence by Patrick LeBlanc, Jessica M. Moss Dejan Sarka and Dustin Ryan, 2015 – the publication concentrates on the business intelligence building blocks and how to integrate them together, despite the book’s concentration on Microsoft products, the book provides a useful technology-agnostic overview on certain practices, especially on the data architecture part, which was used in this thesis to describe the commonly used data architecture types.
Business Intelligence v podnikové praxi by Jan Pour, Milos Maryška and Ota Novotný, 2012- The book, written by experts on BI from Prague University of Economics and Business covers both theoretical and practical principles of Business Intelligence. I chose this book as I often referred to it during my studies and in my professional life, when it comes to BI solution design and implementation. In this thesis, I use its overview on the BI development lifecycle, demonstrating how it is impacted by integrating the BI solution into a corporate wide data architecture.
1.2 Online resources
Online resources listed below were used both in the theoretical part of the thesis as well as my coverage of the available tools and technologies.
14
Gartner reports and IT glossary- Gartner is a research and advisory company that provides a wide variety of reports and market studies for IT and business functions. In this thesis I used Gartner resources to analyse existing technologies that are integrated into the practical solution and its glossary to define some of the terminology. The following reports were used:
- Operational Database Management Systems (OPDBMS): What are Operational Database Management Systems (OPDBMS)?
- Data Management Solutions for Analytics: What are Data Management Solutions for Analytics (DMSA)?
- Magic Quadrant for Analytics and Business Intelligence Platforms: Analytics and Business Intelligence (ABI)
- Magic Quadrant for Operational Database Management Systems - Gartner Glossary: Data Preparation
- Gartner Glossary: Analytics and Business Intelligence (ABI)
MBI- MBI (Management Byznys Informatiky) is a portal that includes generalized solutions for business IT management. The portal purpose is to share knowledge and recommendations arising from practice. The portal can be used as a reference material for designing BI solutions. In this thesis it was used for the research of the definition of data architecture and its place in enterprise architecture.
McKinsey Digital. Why you need a digital data architecture to build a sustainable digital business by Sven Blumberg, Oliver Bossert, Hagen Grabenhorst and Henning Soller. 2017- McKinsey is a top management consulting company, consulting businesses on strategic decisions and transformations, including digital. In this thesis I used its article on the importance of data architecture in order to reinforce the conclusions of my theoretical analysis. The findings of the article are matching my observation on the benefits of a proper data architecture.
What is SAP HANA?- for the technical capabilities and specifications of SAP HANA, that this thesis is dealing with, I used the information available on the official SAP web in the SAP HANA product description
1.3 Internal documentation and author creation
This thesis heavily relies on internal documentation that was created as part of the implementation of the practical solution described in this thesis. While the official documents are not available for reference due to information sharing restrictions, I provided sufficient materials that mirror the original documents. As the lead of the project, I was responsible for creating the original documentation, therefore both the originals and the materials provided in this thesis reflect authors’
creation and contribution to the project.
15
2. The Theory of Data Architecture
The first time I encountered the term “Data Architecture” was during a BI project, when we had to comply with data governance and the established data architecture, in order to get the required approvals for the project. Being initially frustrated by the imposed limitations and the delays on the project that were caused by them, I quickly changed my mind and learned to embrace those practices as the benefits were obvious:
- Sustainable data models, aligned with the rest of the organization - Aligned naming conventions for dimensions and measures - Centralized data quality improvement effort
- Formal endorsement for the models to be used by other organizations and departments Working closely with experienced data architects taught me to appreciate their work and also to see the full potential of the investment in building a proper data architecture: advanced data analytical tools that can be deployed at a much lower cost and at a higher rate than stand-alone BI solutions, which can provide the corporation with a competitive edge.
One surprising aspect about data architecture was the fact that most of the data architecture and data governance initiatives came from the business side of the corporation and not the IT department, with the later serving as an enabler. Being from the business side myself, in this chapter I would like to analyse the theory behind data architecture and enrich it with the business perspective that is often missing from the technical literature on the topic.
2.1 Definition
What is data architecture? Being a very broad term, multiple definitions are available, covering various scopes of the term. Data Management Association (DAMA), in their Data Management Body of Knowledge edition (DAMA-DMBOK2) places Data Architecture as part of its Data management framework1:
1 EARLEY, Susan a Deborah HENDERSON. DAMA-DMBOK: data management body of knowledge. 2nd edition. Basking Ridge, New Jersey: Technics Publications, [2017]. ISBN 978-1634622349.
16
Figure 1: The DAMA-DMBOK2 Data Management Framework Source: DAMA-DMBOK2
In figure 1, DAMA puts data architecture as one of 11 components of its data management framework. As we will see, some of the other components directly overlap with the activities of a data architect and might be considered to be part of the data architecture solution, such as Data Warehousing & Business Intelligence and Data Integration. This point can be supported by looking at figure 2, where The Open Group Architecture Framework (TOGAF) places Data Architecture as part of its framework- one of the 4 main components of an enterprise architecture, together with Business Architecture, Application Architecture and Technological Architecture2.
2 The Open Group Standard. The TOGAF® Standard, Version 9.2 . 11th ed edition. Van Haren Publishing, 2018. ISBN 978-9401802833.
17
Figure 2: TOGAF Enterprise Architecture Framework Source: Author based on TOGAF Standard
MBI (Management of Business Informatics) defines Data Architecture in the following way3:
Data architecture is an arrangement of the data sources and information assets that an enterprise must have in order to meet its defined goals and needs.
Data architecture thus defines data sources of various types, their characteristics and links, both internal and external.
The definition above has a technical view on data architecture, concentrating on the data sources and their arrangement within the enterprise. While in the past that definition would be sufficient to describe the data architecture of an enterprise, I would argue that today a higher emphasis is placed on the final consumption of the data and its potential benefit to the company.
Another definition provided by the Data Management Association (DAMA) in their Dictionary of Data Management elaborates more on the business goals of the data architecture4:
In common usage, the physical technology infrastructure supporting data management, including database servers, data replication tools and middleware.
The method of design and construction of an integrated data resource that is business driven, based on real-world subjects as perceived by the organization, and implemented into appropriate operating environments. It consists of components that provide a consistent foundation across the organizational boundaries to provide easily identifiable, readily available, high quality data to support the current and future business information demand.
3 MBI. MBI [online]. Available on: http://mbi.vse.cz/
4 MOSLEY, Mark, Michael H. BRACKETT, Susan EARLEY a Deborah HENDERSON. The DAMA guide to the data management body of knowledge: (DAMA-DMBOK Guide). Bradley Beach, New Jersey:
Technics Publications, c2010. ISBN 978-1935504023.
18
The definition above appeals more to the business side of data architecture- a good data architecture must foresee current and future use of the data and the value it can generate for the company, which means it must come from the business. If we take the financial module for example, how can a data architecture be developed without understanding how financial reporting and financial KPIs are working or used? Same can be applied to any other aspect of the corporation: Margin analytics, material master data, HR and others. Therefore a data architect cannot come solely from a technical background.
2.2 Types of Data Architecture
Picking the right data architecture structure is an important decision for a company to take, however quite often this step is overlooked.
From my own practice and observation, I can name the following reasons for not investing the time and money in a proper data architecture:
Experience- If the company doesn’t have a proper data architecture in place, chances are that the IT department is not experienced enough to design and implement a proper solution using its own resources.
Short term solution does not require substantial investment- The first BI solution I designed was built in Excel using Power Query with no IT investment, yet it served its purpose. Before the business starts to grasp the full potential of data, its requirements are usually short term and can be achieved without allocation of substantial budgets. Those solutions of course tend to be unsustainable and unscalable.
Challenging quantification of the long term benefits- Quantifying the benefits of a specific BI project is relatively simple, those usually address a specific business need with a benefit case attached to it. The benefits of a proper data architecture are rather long term and impact future business cases- Improved data quality, reduced costs of future BI solutions, reusability of data models and others.
Absence of a centralized IT organization- In big organizations, data related tasks and projects can be implemented on regional, function/department level. Building a standardized data architecture on corporate level requires better coordination, and a single centralized organization and decision making process.
In the book “Applied Microsoft Business Intelligence”, which, among others, tackles data architecture regardless of the applied technology, the authors provide a good overview of the challenges of not having a proper data architecture solution in place, and the benefits associated with its implementation5:
Challenges:
5 LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence. Indianapolis, Indiana: John Wiley & Sons, 2015 [cit. 2020-04-10]. ISBN 978-1-118-96179-
19
Slow development and maintenance time- without a proper data architecture, each data related project would be forced to start from scratch: getting data from source systems, cleaning and processing, modeling, deploying. Without a centralized data architecture it’s impossible to get a full overview of the existing solutions that can be reused.
Wasted time due to redevelopment- anything but a proper data architecture solution would require constant band-aiding and adjustments to satisfy the growing data needs.
Loss of confidence in the solution- without a centralized data architecture, same types of data can be built and models can be built in different ways and provide different answers.
This lack of single source of truth can result in a mistrust in the models and solutions.
Lack of scalability- what works on small scale, might not work for a larger scale. With growing volumes of data, the architecture should accommodate current and future data demand. Lack of scalability would result in substantial future costs.
Benefits:
Fits neatly into the enterprise architecture and ties business and technology together- Creating a data architecture used by the entire organization ensures that all other architectures can take the same aligned data architecture into account. Aligning scopes, models, technologies, and functions across all these disciplines makes all areas of the business stronger than without such alignment.
Better describes exact cost, time, and efforts to implementation- By having a standardized data architecture solution in place, the process for future data projects becomes repeatable. The development process includes an implicit template for adding new data sources and providing reports. On top of that, with a standardized process, the organization can acquire valuable know-how that can lead to further improvements and efficiencies gain.
From the above mentioned challenges and benefits, the importance of a proper data architecture is clear, but what is a proper data architecture? There are multiple types of data architecture, each has its own pros and cons. The authors of the “Applied Microsoft Business Intelligence” book define four types of data architecture. In reality of course, a solution might not follow those blueprints to precision, and its form may vary. From experience, data architecture might be applied on a lower level than enterprise, such as on a division or a department level, therefore, an architecture type
“Enterprise Data Warehouse”, might not be applicable for a full enterprise. In such cases, an enterprise might end up with multiple data architectures.
The four data architecture types according to the literature are:
Enterprise Data Warehouse-
In this approach, data is collected from all the source systems
20
Figure 3: Sample Enterprise Data Warehouse architecture
Source: LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence
Figure 3 illustrates enterprise data warehouse architecture, where all the source systems are feeding the centralized enterprise data warehouse, which serves the various users. According to the literature, this architectural approach includes the following advantages6:
- Consolidation of disparate reporting systems: especially in large corporations with multiple ERP systems, bringing all the data together in one place is already a big step for BI sustainability.
- One version of truth: all projects are using the same data source, avoiding duplication of data and BI solutions.
- Historical change tracking: Enterprise data warehouse can create time stamp on data One concern of this solution that I observed in practice, which is not mentioned in the reviewed literature, is that data governance plays a key role in enabling scalability of the enterprise data warehouse. With increased volumes of data, the performance of the system might be undermined because all the data is stored in one location, this might have bigger consequences and undermine the trust of the business in the system.
6 LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence [online]. Indianapolis, Indiana: John Wiley & Sons, 2015 [cit. 2020-04-10]. ISBN 978-1- 118-96179-7.
21
As this precise solution is the one that the practical part of the thesis is based on, I would like to add the following benefits based on own observation:
Scalability- the data hub can be designed to handle all the source systems and all the transactional and master data, regardless of the initial business use cases, later, with new departments joining and adding their projects, containers can be added, however, as mentioned earlier, this can go wrong if data models are built inefficiently.
Transparency of existing projects and data model- as each spoke/container has its own business owner, it’s easy to inquire whether a model that can meet a certain business requirement already exists.
Operational Data Store
“An operational data store (ODS) is a data repository that combines data from different source systems with the intent of providing a real-time view of the data. Data load programs conform and cleanse the information as it enters the ODS. The source systems can then access the cleansed information for their use. In addition, a data warehouse can pull the information from the operational data store for historical tracking and reporting.”7
The Operational Data Store can provide live access to the source system data but without storage of historical data.
Figure 4: Sample Operational data store architecture
Source: LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence
7 LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence [online]. Indianapolis, Indiana: John Wiley & Sons, 2015 [cit. 2020-04-10]. ISBN 978-1- 118-96179-7.
22
Figure 4 provides a high level diagram of an operational data source architecture, showing the initial stage of the data entering the operational data store, which enables the access to live processed data from the sourced systems. While this solution can provide real time reporting of source system data, today’s technology, such as SAP HANA, enables dimensional modeling directly from live source system tables (or at least making refreshes so often that the need in live access is obsolete), which will be demonstrated in the practical section of the thesis.
Data Vault
“When compared to the enterprise data warehouse and operational data store, the data vault architecture is fairly new to the modeling scene. The model is a cross between a dimensional and third-normal form model.”8
Figure 5: Sample data vault architecture
Source: LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence
Figure 5 provides a sample of the data vault architecture, with multiple vaults dedicated to multiple function. This architecture is best used for rapidly changing environments.
During my work I did not have experience with this type of data architecture but this structure undermines one of the key benefits of having data architecture- promoting collaboration and integration across various departments when it comes to data usage.
Hub and Spoke Data Marts
8 LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence [online]. Indianapolis, Indiana: John Wiley & Sons, 2015 [cit. 2020-04-10]. ISBN 978-1- 118-96179-7.
23
“A hybrid approach between one enterprise data warehouse and many departmental reporting silos, the hub and spoke data marts architecture includes one central data hub for information, which feeds separate data marts for each department.”9
Figure 6: A sample of Hub and Spoke Data Marts architecture
Source: LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence
The literature mentions the following benefits of this architecture model10:
Information is stored in central location
Business users have access to their own departmental business logic
It’s easy to develop and maintain in parallel
A central data hub includes all the base models, transactional tables and master data and feeds separate data marts for each function/department.
During my work, I encountered three types of approaches to data architecture, each one represents a different stage of the organization’s maturity:
9,8 LEBLANC, Patrick, Jessica M. MOSS, Dejan SARKA a Dustin RYAN. Applied Microsoft® Business Intelligence [online]. Indianapolis, Indiana: John Wiley & Sons, 2015 [cit. 2020-04-10]. ISBN 978-1- 118-96179-7.
24
Standalone databases- not much of an architecture but rather separated islands of data.
Before any coordinated effort was applied to manage data on a corporate/division level, departments were tackling their own data needs by building their own databases, usually using semi self-service technologies, such as MS SQL or Oracle SQL databases. The drawbacks of such solution are many: lack of transparency of existing models and BI solutions, unstandardized handling of data, impossible to scale up, departments work in silos, duplication of data and efforts and lack of a single source of truth.
Organization data warehouse- the first coordinated effort to put data architecture in place was achieved on organization/division level. While it was a huge step forward, this solution still suffered from many drawbacks- due to lack of experience, no proper data governance was in place, creating broken models that eventually overwhelmed the system. As each organization had its own data warehouse, corporate/crossorganizational functions, such as Credit still had the data it needed scattered across multiple locations. As each data warehouse was built with one organization in mind, it was impossible to scale it up to enterprise level.
Enterprise data hub- The final stage of the evolution – a hub of hubs concept, close to the hub and spoke data marts architecture described above. This solution includes standardized data governance rules for the entire corporation, each department, regardless of its organization, gets its own spoke/container. One big advantage of this architecture, incurred even before the insight of the data models, was that it promoted cooperation between different departments that was not seen before.
2.3 Business Intelligence as Part of the Data Architecture
In the previous subchapters, I described the importance of proper data architecture in an organization and how it is more sustainable than standalone BI solutions. Does that mean that data architecture can fully replace the need in BI? Not exactly, Business Intelligence is an integrated part of the data architecture, but the process and life cycle of a BI project will change.
To demonstrate that, I would like to start by looking into the lifecycle phases of a BI project and analyze, how data architecture impact those phases (phase description based on literature)11:
Preparation of the initial study- the purpose of this phase is to map the environment in which the BI solution will be developed, and to formulate all the end user and business requirements for the solution. As we will see in the practical part of the thesis, with a proper data architecture in place, the environment in which the BI solution is to be developed would differ significantly. The first question I would ask- is there a proper data architecture and foundation already available for this project? Are there other departments or functions that are looking for a similar solution? If there are no foundations available, in which case that I will need to work with data governance to build those foundations (which is the case for the Receivables module described in chapter 5.2).
11 POUR, Jan, Miloš MARYŠKA a Ota NOVOTNÝ. Business intelligence v podnikové praxi. Praha:
Professional Publishing, 2012. ISBN 9788074310652.
25
Formulation of incremental additions to the solution- Based on the outcome of the initial study, the requirements for the BI solution are adjusted and new requirements are taken into account. Unlike a typical BI solution, using the wider data architectural approach, this phase would include the requirements for the data foundation and broader needs of the enterprise as whole on top of the requirements of the project sponsor.
Analysis of user requirements and data sources- this phase includes the analysis of the available data sources that are required in order to meet the user requirements (data availability, data quality, etc.), as we will see in the practical part of the thesis, this phase would look different when using data architecture- instead of using source systems (usually ERP), we are using foundational models built by the data architecture/data governance team.
This means that issues such as data quality ate already taken care of and the data is usually catalogued, which makes it easier to identify and analyze.
Modeling and design of the BI solution- The purpose of this phase is to create the dimensional data model for the solution based on the previous analysis. This phase is much easier and requires less expertise when using the foundational models built as part of the data architecture design.
ETL design- The purpose of this phase is to define the data transformation rules of the data elements within the BI data warehouse. Using data architecture foundational data objects reduces the transformation requirements of the data as a big portion of the work is already completed as part of the foundational models design.
Implementation of the BI solution- Based on the previous phases, the goal of this phase is to physically implement the BI solution. The impact of data architecture makes this step easier to implement considering that all the building blocks are standardized with predefined joining criteria.
From the description of the BI lifecycle phases, the implementation remains the same. The main impact is hidden in how complex each of those phases are. Having proper data architecture and centralized data governance helps to make BI projects cheaper and simpler, reducing the involvement of technically savvy personnel.
To conclude this chapter, I’d like to refer to a McKinsey article called “Why you need a digital data architecture to build a sustainable digital business”. In this article, McKinsey criticizes the approach of many companies to data analytics, stating that, based on its surveys, companies “either focus on the technologies alone or address immediate, distinct use cases without considering the mid- to long term creation of sustainable capabilities”12 more than that, according to them, their survey found
12BLUMBERG, Sven, Oliver BOSSERT, Hagen GRABENHORST a Henning SOLLER. Why you need a digital data architecture to build a sustainable digital business [online]. 2017, November 13, 2017 [cit.
2020-11-15]. Available from: https://www.mckinsey.com/business-functions/mckinsey-digital/our- insights/why-you-need-a-digital-data-architecture#
26
that eight out of ten companies made their IT departments responsible for the data transformation.
This approach contradicts the theory and findings in this chapter, where I make the case that data should be owned by the business. The article summarizes very well the distinction between addressing immediate and distinct use cases (which I describe here as a traditional BI solution) and developing a long term data strategy which involves investing in a proper data architecture.
McKinsey offers a high-level capability-oriented reconceptualization of data management activities that a company should consider before making costly technology decisions.
Figure 7: McKinsey best-practice reference-data architecture
Source: McKinsey Digital, “Why you need a digital data architecture to build a sustainable digital business”
Figure 7 represents a layered data architecture. The layers enable transparent data management flow, starting from the data infrastructure all the way to data consumption, which is done through traditional BI tools and reporting. Transparent data flow management prevents data silos and data inconsistencies. Data architecture involves traditional concepts such as data warehousing, the key aspects is that it is all managed centrally. As can be seen in the figure above, traditional BI is limited only to the end of the data flow cycle, as a small component of the broad data architectural approach.
2.4 Conclusion of Chapter 2
This chapter covered the theory behind data architecture and the business perspective on the subject, including its place in the enterprise architecture. I argued that provided definitions of data architecture by respectable sources such as Data Management Association (DMA) or Management of Business Informatics (MBI) are rather outdated, and do not fully capture the business aspects and the importance of data architecture to the operational results of the enterprise. Data architecture is a
27
key factor in the development of the data analytics capabilities of the business, and requires a broader approach than the traditional BI solutions, which concentrate on the immediate needs of the company. In order to achieve results, the design and implementation should be driven by the business, with the IT organization serving as an enabler. This requires a change of mindset from the business leaders, where subjects that traditionally were considered as “IT realm”, such as data warehousing, data quality and others aspects, need to be taken over by business data/digital organizations. We looked at the benefits of having a data architecture in place, among the most substantial of them are reduced costs of new BI development, sustainability, avoidance of duplication of work, and work in silos (by creating reusable data objects).
I covered the different types of data architectures that are available today, though in reality types may vary and new hybrid solutions can be introduced.
Finally, I analyzed what is the place of traditional BI development in a company that takes data architecture seriously. As we saw, BI becomes a much more straight forward activity that requires less expertise and investment. I argue (with providing the McKinsey study), that traditional BI becomes rather a side activity in the path to a digitalized, data driven organization.
28
3. Business Overview and Business Objectives
The environment in which I acquired my expertise and the projects described in the practical part of the thesis were developed in, is of one of the largest oil and gas corporations in the world. As a large company with hundreds of billions dollars’ worth of transactions, it generates massive amounts of data across numerous platforms and systems. Extracting the potential out of this data requires substantial investments in the IT infrastructure.
3.1 Corporate Structure
In order to understand the challenges involved in integrating all the data across the corporation, it is important to understand how the corporation is structured.
As it typical for an oil and gas giant, it operates in three main division, divided based on the products it works with:
Upstream- Research, exploration and extraction of oil & gas.
Downstream- Refining, supply and distribution of oil & gas products, such as crude, gas, diesel, lubricants and others.
Chemicals- Production and distribution of chemical products, such as polystyrene, additives and others.
Figure 8: High level corporate structure Source: Internal documentation
Figure 8 illustrates the split and interconnections between the three divisions: The lifecycle starts with the Upstream division that is responsible for oil and gas exploration and extraction, on top of
29
that, this division is also responsible for natural gas supply directly to the customers. From Upstream, crude oil and natural gas is supplied to the refineries and chemical plants that are operated under the Downstream and Chemicals divisions. Those divisions are responsible for manufacturing the end use products such as fuels, lubricants and plastic related products.
From a business perspective, it makes sense that the three divisions operate independently from each other- they have different portfolios, different markets and different end customers. On the other hand, this division creates challenges when it comes to building a single data architecture to support data analytics. Each division has its own ERP system and own support organizations.
The challenge came to light when cross-functional organizations, that cover all the divisions together, started to invest into data and looked to integrate into the corporate data architecture. One of the first functions to do so was the Treasurer’s organization that looked to analyze the financial aspects of the organization. Within this organization is the Credit department, which is where my Stewardship & Analysis team operates. The work of integrating Credit data into the corporate data architecture is the subject of this thesis.
3.2 Data Management
The company is going through the same evolutionary steps towards a single data architecture described in the previous chapter. When we started with the projects, we had to deal with 2 data governance teams operating in silos (Downstream and Chemicals, Upstream not having data governance to this date), since then, a single data governance board was created to cover the corporate data needs.
Despite the creation of a single data governance board, the data of each division is still owned and managed by the individual divisions, this creates obstacles to further aligning data sources and business processes to enjoy the full benefits of a single data architecture.
Data is managed by a set of organizations called DAS (Data, Analytics & Systems), as the name suggests, those organizations are split into three areas:
Data- Covers data enablement activities such as data foundation, master data management, data governance and data architecture.
Analytics- Analytics delivery activities, such as predictive analytics, tool design and implementation and data reporting.
Systems- Covers system support activities with collaboration with the IT organization.
30
The gap in this structure is that those DAS teams do not cover the corporate function, such as our Credit department. For that reason, there are smaller teams that support the data needs of the individual corporate functions, such as our Credit Stewardship and Analysis team.
The expectation is that in the future the individual DAS organizations (Chemicals and Downstream) as well as the smaller organizations, such as the Credit Stewardship and Analysis, will integrate into a single corporate DAS organization.
3.3 Conclusion of Chapter 3
The case of this company is similar to many other big corporations- multiple divisions that operate in silos but the modern data requirements force the company to integrate its data activities. This process takes time, effort and resources but most importantly, appropriate single data management strategy and support group.
Business needs cannot wait for the creation of a single data management organization, therefore in the absence of such organization, smaller organizations exist, such as the Credit Stewardship and Analysis team, which is where the projects in the practical part of the thesis were developed and implemented, in part. The main goal is to work within the framework of a corporate data architecture, and break down the silos, while meeting the immediate business needs of the Treasurer’s Credit department.
31
4. Technological Landscape
Working in a big corporation, the choice of tools is limited to the vendors with whom the company has an established relationship. The process of choosing a vendor is not always based on the technical capabilities of the technology but includes other aspects such as: legal requirements, reputation on the market, price negotiations and others. Despite that limitation, the offer of available technologies in a big corporation is wide and usually covers the top products available on the market.
In this chapter I will cover the available tools that are taken into consideration when integrating Credit data into the enterprise data architecture, starting from the database technologies, data processing and finally end user data consumption tools. It’s important to note that the assessment of the tools in this chapter is based mainly on personal experience and how I fitted them into a wide service offer for data analytics within the Credit department, which covers various use cases and different types of user groups.
4.1 Database Technology
Moving away from the traditional concept of database technologies as a data storage solution, databases today offer a wide variety of services and functionalities, such as cloud solutions, analytical hubs and even imbedded data visualization tools.
Gartner offers two categories for database management solutions for its famous magic quadrant ranking:
Magic Quadrant for Operational Database Management Systems (OPDBMS)- “The operational database management system (OPDBMS) market is defined by relational and nonrelational database management products suitable for the traditional transactions used to support business processes”13. In other words, database solutions that support transactional data flows that can be used for supporting applications and other source systems.
Magic Quadrant for Data Management Solutions for Analytics (DMSA)- “We define a data management solution for analytics (DMSA) as a complete software system that supports and manages data in one or more file management systems (usually databases).
DMSAs include specific optimizations to support analytical processing. This includes, but is not limited to, support for relational processing, nonrelational processing (such as graph processing), and machine learning and programming languages such as Python and
13 Operational Database Management Systems (OPDBMS): What are Operational Database Management Systems (OPDBMS)? [online]. [cit. 2020-11-2 available from:
https://www.gartner.com/reviews/market/operational-dbms
32
R.”14. In other words, those are database technologies that are supporting the data analytics processes in the company, with an emphasis on advanced analytics and BI solutions.
The distinctions between those two categories can be confusing, considering that both quadrants share many solutions and Gartner itself admits that “the OPDBMS market is moving toward a state in which analytics capabilities are also a requirement, in a development that blurs vendors’
traditional separation from data management solution for analytics (DMSA) uses”15. Considering that this the similarity between the two categories, I chose to use the OPDBMS category to provide commentary on the available technologies.
Figure 9: Magic Quadrant for Operational Database Management Systems Source: Magic Quadrant for Operational Database Management Systems. Gartner [online]
14 Data Management Solutions for Analytics: What are Data Management Solutions for Analytics (DMSA)?
[online]. [cit. 2020-11-20]. Available from: https://www.gartner.com/reviews/market/data-warehouse- solutions
15 Magic Quadrant for Operational Database Management Systems [online]. 25 November 2019, 2019 [cit.
2020-11-20]. Available from: https://www.gartner.com/doc/reprints?id=1-
4J1NAHG&ct=171023&st=sb?sc_channel=em&sc_campaign=GLBL_FY19_Analyst_Reports_Gated_AW S&sc_medium=em_211444&sc_content=ACQ_ln_acq&sc_geo=mult&sc_country=global&sc_outcome=ac q&trk=em_211444&mkt_tok=eyJpIjoiWkRneE5UYzVZakl3WmpkaiIsInQiOiJjQ3YrSFdlMm85UHdYQnF tYTRYNlREVjBxOGlUXC9OaTlpSDRoellabmlZQXJRVjBBYmI5S0x2dCtDaTdacXNGM0NaNXN2Y09 DU0o1NUFMXC9OZzFGM1JVYXk3dDRvck9zVzdodXlGM3JVOHh6dTV4MkpGYU5WQXJhYVNJZ0h oeXNjeENLYXgxMTBDK3JVSFZkQVwvMlM4NFE9PSJ9
33
Figure 9 provides Gartner’s famous magic quadrant for the OPDBMS. Traditional leaders in database technology are Microsoft and Oracle, with additional big players such as Amazon, SAP and Google offering competing products. What is common among those leaders is that they are all offering cloud based solutions, which Gartner sees as the future, claiming that by 2023, 75% of all databases will be cloud based16. From personal experience of working with products from SAP, Microsoft and Oracle, the key factor to successfully creating a corporate data architecture, is to make sure that those products communicate between each other, and each serves its purpose (in our case, HANA for big data analytics and Oracle and MS SQL serving as complementary databases).
4.1.1 SAP HANA
The main technology used in the solutions that will be described in the practical part is SAP HANA.
Using the information available on the SAP website, SAP HANA can be described as a column- oriented, in-memory relational database that combines OLAP and OLTP operations into a single system. Its column-based storage groups related information together in columns rather than in rows.
This drastically reduces the storage consumption and allows faster analysis compared to classic row storage databases (such as MS SQL). Its in-memory storage stores data in a computer’s main memory (RAM) instead of on disks or solid-state drives. Retrieval from memory is much faster than from a disk or SSD.17
Gartner in its report on OPDBMS provides a list of strengths and weaknesses to the SAP HANA technology18 to which I’d like to add my own perspective coming from experience of working with the technology for over 3 years:
Strengths
System stability- Gartner claims that overall customers are satisfied with the system stability of the system. From own experience, this depends on the implemented data architecture and data governance, loose data governance and poorly developed data models lead to frequent system crushes.
Corporate focus- SAP puts its long-term faith in SAP HANA technology, therefore the platform continues to evolve and improve. My own experience confirms this assessment as the system substantially matured in the past 3 years.
Performance and integration enhancement- SAP HANA’s speed and performance is its main selling point together with its ability to integrate OLAP and OLTP operations. This enables the business to change its business process to harness the benefits of HANA. As we will see in the practical solution part of this thesis, SAP HANA’s big data analytics unlocks new capabilities not available in the past to the business.
16 Magic Quadrant for Operational Database Management Systems. Gartner [online]
17 What is SAP HANA? [online]. [cit. 2020-11-20]. Available from:
https://www.sap.com/products/hana/what-is-sap-hana.database-design.html?btp=921bbed9-413c-4058-a31d- 0d24c7881dbb
18 Magic Quadrant for Operational Database Management Systems. Gartner [online]
34 Weaknesses
Perceived value for money- as with any SAP product, costs for system implementation, maintenance and data modeling are extremely high. From own experience, that puts more pressure on thorough planning before work in HANA can start, as any out-of-scope changes mid project can drive the project costs drastically up.
Ease of adding capacity and administration- Customers report complications with upgrading the system as well as complex administration of the system. Personal experience can confirm this concern, as system upgrades always caused technical issues, as much as at one point the system was not available for development for 3 months due to a failed system upgrade.
SAP HANA in the cloud- SAP entered the cloud market late and therefore its lagging behind cloud based technology pioneers such as Microsoft, Amazon and Google, especially when it comes to global infrastructure.
On top of what was mentioned above, I’d like to add another concerning characteristic of SAP HANA- its development application for data modeling. Working with the IT developers by providing them business prototypes that can be translated into an SAP HANA data model, simple data manipulation tasks required long time consuming development in HANA, this had a significant impact on project costs.
Overall, despite its shortcomings, SAP HANA offered unique capabilities to transform enormous amount of data into sophisticated models that offered business new capabilities that were not previously available. On top of that, SAP HANA was built with the purpose of offering corporations a platform that can enable corporate-wide data architecture.
4.2 Data Visualization Tools
By data visualization tools I’m referring to analytics and business intelligence tools, as they are often called. Gartner defines analytics and business intelligence as “an umbrella term that includes the applications, infrastructure and tools, and best practices that enable access to and analysis of information to improve and optimize decisions and performance”19. The reason why I prefer to refer to those tools as Data Visualization Tools is that when we look at the tools themselves that are being propagated as “Business Intelligence” tools, most of them can’t offer much beyond data visualization, or at least, they are not often used for anything else.
19 Gartner Glossary: Analytics and Business Intelligence (ABI). Gartner [online]. [cit. 2020-04-24].
Available from: https://www.gartner.com/en/information-technology/glossary/business-intelligence-bi
35
Figure 10: Magic Quadrant for Analytics and Business Intelligence Platforms
source: Magic Quadrant for Analytics and Business Intelligence Platforms: Analytics and Business Intelligence (ABI).
Gartner [online]
Gartner provides its famous magic quadrant that ranks and puts into quadrants analytics and business intelligence tools. As can be seen in figure 10, within the “Leaders” quadrant, four tools appear:
Microsoft Power BI, Tableau, Qlik and ThoughtSpot. Working personally with 3 of them (Microsoft Power BI, Tableau and Qlik) and being exposed to 3 other tools from other quadrants (SAP, SAS and IBM products), all the tools do not differ much- they all possess an arsenal of data connectors, a certain degree of data manipulation capabilities (though those are usually limited), data visualization capabilities, and recently more and more advanced capabilities, such as R and Python platforms.
Gartner’s report admits that the data visualization capabilities are becoming a commodity and the focus is shifting to the following differentiation20:
20 Magic Quadrant for Analytics and Business Intelligence Platforms: Analytics and Business Intelligence (ABI). Gartner [online]. 2020, 11 February 2020 [cit. 2020-04-24]. Available from:
36
Integrated support for enterprise reporting capabilities- organizations are looking to know how the tool’s visualization capabilities can transform corporate reporting needs.
Based on personal experience, the reason for that is that a lot of the corporate reporting is still done through outdated tools such as excel tables and pivot tables. Enabling the replacement of such tools require more than just data visualization.
Augmented analytics: Machine learning and artificial intelligence -assisted data preparation is becoming a more common requirement of the business, advancing those capabilities and making them more “user friendly” is becoming a key competitive differentiation.
4.2.1 Tableau
Tableau is one of the leaders in Gartner’s magic quadrant for ABI tools, it’s being praised for its customer enthusiasm, its visualization capabilities and data analytics options while being criticized for its data governance capabilities and its reaction to the changing market where data visualization functionality becomes a commodity, and to emerging competitors, especially Microsoft’s Power BI21. The last aspect was clear from my face-to-face conversations with Tableau representatives who admitted that their best practice visualization capabilities are easy to replicate by competitors such as Microsoft.
Within the environment where I operate, Tableau was chosen as the strategic tool for data reporting- dashboards. Regardless of other available technologies, it is useful that everyone uses the same technology for data reporting, it allows creation of a strong community and sharing expertise and solutions.
The use of Tableau in the service offer that I designed for my organization is limited to the creation of dashboards which are managed centrally by the Stewardship & Analysis organization, this despite the fact that Tableau has more functionality to offer. This decision is driven by two aspects-
Cost of license- based on the licensing agreement, each license has a substantial cost attached to it, which prevents the distribution of the tool to users without a benefit case attached to it.
User friendliness- while Tableau offers a wide variety of drag and drop tools, I find that familiarizing oneself with the tool takes time, and requires some formal guidance and training. This aspects makes the tool unsuitable for new power users in the making.
4.2.2 Power BI
Gartner report considers Power BI as the leader of the ABI market, it views it both as a visionary product and as a product able to execute. It is being praised for its product capabilities, including visualization and augmented analytics, with emphasis on machine learning and artificial intelligence
https://www.gartner.com/doc/reprints?id=1-
3TXXSLV&ct=170221&st=sb&ocid=mkto_eml_EM597235A1LA1
21 Magic Quadrant for Analytics and Business Intelligence Platforms: Analytics and Business Intelligence (ABI). Gartner [online]. 2020, 11 February 2020 [cit. 2020-04-24].
