Knowledge Hub

In simple terms, when we talk about an Embargo, we're usually talking about a rule or limit, especially when it comes to trading or sharing information. Now, if we use "data embargo," it means there are rules or limits on using, sharing, or spreading certain information. This mostly happens for legal reasons, to keep things safe, to protect privacy, or because there are rules to follow.

Let's delve into the concept of an "embargo," especially in the context of data, using simpler language:

1. Embargo Basics: An "embargo" is like a rule that says you can't do certain things. It often happens in trade or when sharing information.
2. Data Embargo: Now, if we add "data" to the word "embargo," it means there's a rule or limit on how we can use, share, or spread specific information. Imagine it's like having a set of rules for how you can talk about or share certain details.

These rules could be there for different reasons:

Accessibility and Visibility are often used interchangeably, especially in simple terms. However, in the world of data solutions, it's crucial to distinguish between them.

Let’s decide it…..

Accessibility pertains to your ability to connect to and utilize data for decision-making purposes.

On the other hand, Visibility involves having a comprehensive understanding of what's happening behind the scenes with your data.

For instance, if you request your Data Warehousing or Data Lakehouse datastore owners to extract data from source systems and transform it into the desired format for decision-making, two key concepts come into play:

Accessibility: This is achieved when your database administrator or datastore owner grants you privileges within the database, allowing you to read, write, or update your data.

Visibility: This extends beyond mere access. It encompasses a deep understanding of various aspects of your data, such as what was sourced, the business rules used for transformations, the presence of business, technical, or operational metadata, the formula for golden records, data quality assurance methods, data loading approaches (e.g., CDC, batch, real-time), SLAs, and lineage information, among other things. All of these elements collectively provide you with comprehensive Visibility into your data.

In the context of the data world, "BASEL" likely refers to the Basel Committee on Banking Supervision. The Basel Committee is not directly related to data management but plays a significant role in shaping international banking regulations, including requirements related to risk management and data reporting.

Basel Committee on Banking Supervision (BCBS) is an international committee of banking supervisory authorities. It was established by the Bank for International Settlements (BIS) to strengthen the regulation, supervision, and practices of banks worldwide. The committee is known for developing and maintaining global regulatory frameworks, commonly known as the Basel Accords, which set standards for bank capital adequacy, risk management, and prudential supervision.

Basel Accords/ Standards:

• Basel I: Introduced in 1988, Basel I established minimum capital requirements based on credit risk.
• Basel II: Developed in 2004, Basel II expanded the framework to address credit, operational, and market risks. It introduced more risk-sensitive capital requirements.
• Basel III: Implemented in response to the 2008 financial crisis, Basel III further strengthened capital requirements, introduced new liquidity standards, and enhanced risk management practices.

FinOps is a term derived from "financial operations." It represents a set of practices and principles aimed at optimizing the financial aspects of cloud computing especially in an era where Cloud is the to-go approach for everyone.

• Management Practice: FinOps is not just a set of guidelines; it's a management practice, indicating that it involves a structured and ongoing approach to managing financial aspects within the context of cloud operations.
• Shared Responsibility: One of the central tenets of FinOps is the promotion of shared responsibility. This means that financial considerations are not solely the concern of the finance department; instead, there is a collective responsibility across different organizational functions.
• Cloud Computing Infrastructure: FinOps is specifically tailored to address the financial aspects related to cloud computing infrastructure. This includes services, resources, and functionalities provided by cloud service providers such as AWS, Azure, or Google Cloud.
• Cost Management: The primary focus of FinOps is on effectively managing the costs associated with cloud usage. This involves understanding, optimizing, and controlling expenditures to ensure they align with business goals.
• Organizational Involvement: FinOps encourages participation and collaboration across various teams within an organization. It brings together stakeholders from finance, operations, and IT/engineering to collectively manage and optimize cloud costs.
• Efficiency and Optimization: The ultimate goal of FinOps is to enhance efficiency and optimize cloud spending. This may involve identifying cost-saving opportunities, optimizing resource usage, and making informed decisions to achieve a balance between cost, performance, and reliability.
• Continuous Improvement: FinOps is not a one-time initiative but a continuous improvement process. Teams regularly assess, analyze, and refine their practices to adapt to changing business needs and technological advancements.
• Educational Component: The statement doesn't explicitly mention it, but part of FinOps often includes educational initiatives. Teams are educated about cloud financial management practices to enhance their understanding of how their decisions impact costs.

SLA stands for "Service Level Agreement" A Service Level Agreement is a contractual agreement or commitment between a service provider and a customer that outlines the level of service expected, including the quality, availability, and responsibilities related to the service. SLAs are commonly used in various industries, including the data and technology sectors.

Here's a breakdown of key aspects of SLAs in the data world:

• Quality of Service: Specifies the expected quality, accuracy, and reliability of the data service. For example, a data storage service may have an SLA stating that data will be stored securely, with minimal risk of loss or corruption.
• Availability: Defines the agreed-upon level of uptime or availability for a data service. For example, an SLA for a cloud-based data storage service might guarantee 99.9% uptime, ensuring that the service is accessible to users for the vast majority of the time.
• Response Time: Outlines the expected time frame within which the service provider commits to respond to queries, issues, or requests. For example, an SLA for a data analytics platform may specify that support tickets will be addressed within 24 hours.
• Data Security and Privacy: Addresses the security measures in place to protect data and the adherence to privacy regulations. For example, an SLA for a data processing service may include provisions for encryption, access controls, and compliance with data protection laws.
• Scalability: Defines how the service will scale to accommodate increased data volumes or user demands. For example, an SLA for a cloud-based database service might specify the procedures for scaling resources based on increased data loads.
• Data Backup and Recovery: Outlines procedures for regular data backups and the expected timeframe for data recovery in case of a failure. For example, an SLA for a data storage service might include provisions for daily backups and a commitment to restoring data within 48 hours in case of a system failure.
• Compliance: Addresses adherence to relevant industry standards, regulations, and legal requirements. For example, an SLA for a healthcare data management system might specify compliance with healthcare data privacy regulations such as HIPAA.
• Termination and Penalties: Outlines conditions under which either party can terminate the agreement and may include penalties for non-compliance. For example, an SLA might specify the process for termination if the service provider consistently fails to meet agreed-upon service levels.

GDPR, or the General Data Protection Regulation, is a significant law in the European Union focused on data protection and privacy. In very simple terms, it's a set of rules about how companies and organizations should handle personal information of individuals. It gives people more control over their personal details like their names, addresses, and photos, ensuring that this information is handled in a secure and lawful manner.

The main principles of the GDPR center around responsible data management.

• Transparency is key, requiring clear communication about how personal data is used.
• Purpose limitation means data can only be used for specific, clearly stated reasons.
• Data minimization insists on collecting only the data that is absolutely necessary.
• The principle of accuracy ensures that personal information is kept up-to-date and correct.
• Storage limitation mandates that data should not be kept longer than necessary.
• Integrity and confidentiality require that the data is kept safe and secure, protected from unauthorized access or breaches.
• Accountability places the responsibility on organizations to ensure all these principles are adhered to, making sure personal data is managed in a compliant and ethical way.

During the years of industrialization and first process automations, there was the first batch of international standards which has become the core of ISO “framework”. When data stormed through various industries, ISO/IEC 27001 was necessary to be defined. It is an international standard specifying the requirements for establishing, implementing, maintaining, and continually improving an information security management system (ISMS). From a data perspective, this standard is core, essentially pivotal to ensure the confidentiality, integrity, and availability (CIA) of data. It consists of 3 main sections, which encompasses policies, processes, and technical measures to manage information security risks.

There are 6 Key Components when dealing with data and data management.

• The foundational aspect for ISO/IEC 27001 is the systematic assessment of information security risks in your own data. Risk assessment includes identifying potential threats to data, assessing vulnerabilities, and risk impacts’ evaluation. The outcome guides the prioritization of security processes, monitoring and controls.
• Managing risk effectively, data must be classified according to its sensitivity and importance to the organization and its departments. Such classification influences how data is handled, stored, and transmitted, ensuring that more sensitive data receives higher levels of protection. The processing phase is called data classification.
• ISO/IEC 27001 highlights massive importance for limiting access to data based on the principle of least privilege. Access control lineage and its measures ensure that only authorized individuals can access or modify data, reducing the risk of unauthorized disclosure, alteration, partial loss, or total destruction.
• Encrypting data (both at rest and in transit], is a very common control in data protection process for keeping confidentiality and integrity. Encryption makes data unreadable to unauthorized parties, safeguarding it against spying or undesired interfering.
• Next component the ISO standard 27001 requires for all organizations to have procedures for managing information security incidents. Incident Management includes detecting, reporting, and investigating each incident to mitigate their impact on data and prevent recurrence.
• Last but not least ISO/IEC 27001 brought into place Business Continuity Management to keep development of any business continuity plan which includes data recovery procedures. “Continuity” ensures that critical data remains available or can be restored in the event of a disruption. Under “event” you can imagine a typical cyber-attack or natural disaster.

Let’s start by breaking down each part of this acronym based on the context of its usage.

• Information – In this case the Information is related to the usage of the related data stored in a database or a data platform.
• Lifecycle – The standard definition for life cycle is the different stages of life for a living thing. In this case the living thing is the Data. The Lifecycle for data is classified based on its usage as: - ‘HOT’, ‘WARM’, ‘COLD’ and that also could be extended to ‘DEAD’ for deleted.
• Management – The process to facilitate the movement of the data related to the information over its Lifecycle.

So, using the context above, Information Lifecycle Management (ILM) is the process to optimize data storage by automatically tiering data to different locations based on its age, access frequency, and required read/write speeds. This approach minimizes storage costs by placing frequently accessed data in high-performance tiers and infrequently accessed or archived data in lower-cost tiers. ILM can also simplify data archiving and deletion according to data retention policies.

Before we explore what constitutes a Data Product (DP), it is important to establish the foundational context within which these products exist. Most enterprise data environments comprise two distinct but interconnected types of systems:

• OLTP (Online Transaction Processing) systems, which are responsible for generating operational data through transactional processes.
• OLAP (Online Analytical Processing) systems, which are designed to serve data for analytical and decision-support purposes.

We will not dive into the technical specifics of OLTP and OLAP here, as those are covered in dedicated sections elsewhere in this book. However, it is essential to understand this distinction because Data Products are primarily built and operated within the OLAP ecosystem.

In essence, OLTP generates data. OLAP serves it.

Data products are almost always born, shaped, and consumed in the OLAP layer, where raw data is transformed into meaningful, trustworthy outputs for business consumption.

In the modern data landscape, few topics spark more debate than the question: “What is a Data Product?”

Across conferences, boardrooms, and industry discussions, the term has taken on a life of its own. Many practitioners argue over definitions, frameworks, and taxonomies, yet the underlying truth is simpler: most of us already know what a data product is.

The real challenge isn’t defining it. It’s understanding its quality.

At its core, a data product is any output, a curated dataset, analytical model, dashboard, that delivers tangible business value, offsets the cost of inaction (COI), and can be reused by multiple stakeholders. By that definition, its importance is undeniable.

But the real question is: Is the data product Good, Bad, or Ugly?

The Juice Analogy

To make this concept tangible, think about juice as an analogy.

When someone makes juice for you at home, is it a product? No. Even if it has the same ingredients, taste, and nutrition as a bottled juice, it’s not a product because: