Exploring Data and Analytics Services

Analogy: A well-organized library: Books (data) are carefully categorized, cataloged, and placed on specific shelves (tables/schemas) so you can easily find exactly what you need for a research paper (a business report).

Definition:This is one of the first terms in the list and has been used for many decades. Data warehouses have been around for many years and businesses utilize them for reporting, analysis and decision making by taking advantage of its repository features. Data warehouses integrate and store structured data (i.e., database tables, spreadsheets and the like) which typically comes from all corners of the organization and from many different source systems. Whereas data warehouses typically represent a repository for the organization as a whole, data marts are typically smaller and represent the needs of a specific business department or function such as finance or marketing. Otherwise the two are the same.

Primary Use Case: Business Intelligence, corporate reporting, and performance dashboards.

Analogy: A large, natural reservoir of water: Water (data) flows in from many rivers (sources) in its raw form. You can later take this water and filter it for drinking (reporting), use it for farming (machine learning), or analyze its composition (data science).

Definition: A newer term data lakes compliment data warehouses by being a repository for not only structured data but also semi-structured and unstructured data. By "semi-structured" and "unstructured" we mean data sources such as social media, mobile apps, intelligent sensors and even websites.

Primary Use Case: Big data analytics, machine learning model training, and data science exploration.

It is important to understand that data warehouses and data lakes are complimentary and organizations do not have to choose between them. Both are an important part of a comprehensive data and analytics strategy. A few interesting technical differences between them include:

• Data is typically stored in a data warehouses via an "Extract, Transformation and Loading (ETL)" approach. The relevant data is "extracted" from a source system, "transformed" (i.e., cleaned and converted) and then "loaded" into the data warehouse. With data lakes the raw data is typically stored as files or some sort of object storage with a unique key enabling it to be "found" when queried.
• To access data from a data warehouse typically specialized tools optimized for that data warehouse are used. For example when using SAP Datasphere (covered later in this lesson) is used as a data warehouse SAP Analytics Cloud (also covered later in this lesson) can be used for analytical reporting. While the same specialized tools could exist for a data lake there are several open source frameworks such as Apache Hadoop and Apache Spark that are available for usage.

Analogy: A smart universal adapter or a city's electrical grid: You don't care which power plant generated the electricity; you just plug your device into the wall outlet (the fabric's access point) and get standardized power. The grid intelligently manages and routes the electricity for you.

Definition: A Data Fabric is an architectural approach that acts as an intelligent, integrated layer over disparate data sources. It doesn't necessarily move the data but provides a unified way to access, manage, and govern it, no matter where it resides (in a data warehouse, data lake, or operational database).

Primary Use Case: Providing a unified, real-time view of all enterprise data to data consumers, breaking down data silos without creating another massive repository.

A data fabric architecture links, manages, and controls data across systems and applications, providing a centralized and uniform view of the data. This applies to both the teams and the systems - at every point in your organization. The most important layers of a data fabric architecture include:

• Data Connection Layer: You can think of data connectors as bridges that connect different systems where the data is stored (for example, databases, applications, sensors) at a central point. In this way, all data sets can be analyzed from a central point.

• Data Management Layer: The aim here is to ensure that the data is structured, secure, and of high quality. This includes tasks such as data integration (merging data from different sources), data governance (defining rules for the use and management of data), and data security (protecting sensitive data from unauthorized access).

• Data Modeling & Semantic Layer: This step helps you to understand the data by creating a common language for the data from the different systems. This involves creating a model and a semantic layer. While the model describes the data, the semantic layer represents the agreed language for the "story" of the data.

• Data Processing & Analytics Layer: This is where the data is processed and analyzed to gain important insights. This includes tasks such as data warehousing (storage of large amounts of data), data streaming (continuous processing during creation), and data visualization (easy-to-understand presentation of the data).

• Automated Data Management Layer: While data analysis is at the center of automation in various business areas, in the architecture context it is more about the efficient and consistent management of data. This includes the automation of tasks such as data integration, data governance, and data security. Through automation, companies can reduce errors, save time, and improve data quality.

Analogy: A GPS for your business data: A regular map (Data Fabric) shows you all the roads. A GPS (Business Data Fabric) understands your goal (e.g., "get to the nearest coffee shop"), overlays points of interest (business context), and gives you turn-by-turn directions (actionable insights).

A Business Data Fabric is an evolution of the Data Fabric concept that is specifically designed around business context and meaning. It goes beyond technical connectivity to weave a semantic layer over the data, making it understandable and usable for business users, not just technical staff.

Primary Use Case: Enabling true self-service analytics for business departments, ensuring that data is not just accessible but also meaningful and trustworthy from a business perspective.

Analogy: A marketplace of data products: Instead of one giant supermarket (central data team), you have a market with different stalls (business domains like "Marketing," "Sales," "Logistics"). Each stall owner is an expert in their goods (their data) and is responsible for packaging them as high-quality, ready-to-use products for others to consume.

Definition: A data mesh is similar to a data fabric in some ways. The main difference is that whereas a data fabric tends to be centralized for the entire organization bringing together data across the entire organization, the focus for data meshes is relatively speaking more decentralized and either more department or more functional specific (similar as to data marts discussed earlier in the lesson). Data meshes promote the concept of "data autonomy" where different teams can claim and manage their own data and services making decisions independently based on that data and their needs.

Primary Use Case: Scaling data management in large, complex organizations to avoid the bottlenecks of a centralized data team and increase data agility and quality.

Challenges sometimes exist with having access to data for reporting and decision making purposes:

• Complexity: Database table models are sometimes highly normalized with non intuitive table names. Business context can sometimes be buried in application logic.
• Silos: Data can be locked within separate areas (i.e., SD, MM, FI, CO). This can create challenges when trying to achieve an end-to-end view (e.g., "Order-to-Cash").
• Dependency on Experts: Business users often cannot access data directly. They must file a request with IT or a specialized team, sometimes leading to long delays which can impact fast decision making.
• Inconsistent Extracts: Different teams sometimes extract the same data (e.g., customer data) in slightly different ways, which can lead to multiple "versions of the truth".

Think of a physical product you buy. It’s not raw materials; it's a finished good that is reliable, documented (user manual), and easy to use. A data product is the same. It is a self-contained, reusable, and trustworthy data asset designed for a specific business purpose.

A Data Product is not just a database table or a raw data extract. It is a composite of:

• Data: The core information itself (e.g., sales order details).
• Code: The logic to ingest, clean, transform, and serve the data.
• Infrastructure: The underlying platform to store and compute the data.
• Metadata & Governance: The "labeling" that makes it understandable, trustworthy, and secure. This includes lineage, ownership, quality metrics, and access policies.

Applying the data product concept directly addresses these pain points. It's a move fromextracting data from SAP products to serving curated data products from the entire SAP ecosystem.

Note the differences in the table below where on the left are traditional aspects and on the right are data product advantages.

The SAP Master Data Integration service helps business applications to arrive at a consistent view on master data. All SAP applications produce and/or consume master data. Since business processes are typically not local to a single application, master data needs to be replicated between these applications.

Customer landscapes not utilizing master data integration, are currently characterized by many point-to-point integrations between multiple different applications. These point-to-point integrations lead to an inherently complex landscape that is hard to maintain as well as to extend with new applications. As a natural consequence this also leads to data inconsistencies between applications.

SAP Master Data Integration provides a solution to reduce this complexity by migrating from point-to-point integrations towards a centralized, hub & spoke based approach. Instead of creating multiple custom integrations per application, applications connect to SAP Master Data Integration centrally for any kind of master data replication. These integrations are based on the SAP One Domain Model, which is the common model for business objects across different SAP applications. SAP One Domain Model enables applications to "speak the same language" during data exchange, while keeping their local representation untouched. This removes the complexity from mapping models between various applications, towards a situation in which each application just has a native single mapping towards the SAP One Domain Model effectively eliminating manual data mapping and enabling the delivery of ready-to-deploy integrations. This allows for easier extensibility and reduces overall complexity and maintenance efforts. If desired, organizations can build custom applications on top of SAP Master Data Integration as its data is persisted in SAP HANA Cloud.

Since SAP Master Data Integration persists the data, it is possible to add a new application to a customer landscape without any large analysis of available master data in the landscape. Initial loads towards these solutions are supported and the application will eventually arrive at a consistent state according to the customers filter settings for this application. These filters allow the customer to specify exactly which master data objects and which fields of these objects are supposed to be replicated to an individual downstream application.

Many SAP SaaS products integrate with SAP Master Data Integration out of the box. For example SAP Cloud ERP uses the master data objects "Bank" and "Business Partner" while SAP SuccessFactors uses "Job Classification" and "Workforce Person". When out of the box integration is not available, organizations are recommended to use SAP Integration Suite to integrate applications with SAP Master Data Integration.

As just mentioned applications can be built on top of SAP Master Data Integration. SAP Master Data Governance, cloud edition (MDG) is an SAP BTP service which offers the maintenance of high level master data quality, specifically offering capabilities to manage core attributes of business partners and to evaluate their quality. Its capabilities are organized around three pillars:

• Central Governance - The creation and maintenance of business partners incl. contact persons and relationships in a workflow-driven process including the ability to process multiple BPs simultaneously, and to use reference data from external data providers.
• Consolidation - The creation of a single view for accurate analytics and operational insight continuously or on request. Business partners can be loaded from files or received via APIs. Duplicates can be detected and merged into a best record.
• Data Quality Management - The definition, enforcement, monitoring, and improvement of the quality of business partner master data. As part of this capability validation rules can be managed collaboratively and used in data quality evaluations, consolidations, and central governance.

A story is a presentation-style document that uses charts, visualizations, text, and images to describe data.

With SAP Analytics Cloud, analytics designer, you can create analytic applications for data analysis and data planning. In analytic applications, you can configure the behavior of the UI elements with a set of specific script API events and specify which actions must take place when events are triggered.

• Build a data-driven analytic application. You can visualize your data, pick a model, add widgets, and add custom logic to your analytic application.
• Create and use planning applications that support both manual and automated data entry and changes to data.