Knowledge Hub

In typical SQL world (Structured Query Language), usually managing and manipulating data efficiently is very crucial for its performance, database lifecycle or DWH scalability. Temporary tables and materialized views are two powerful constructs (objects) that help in achieving both objectives simultaneously. Even though each serves a unique purpose within data operations and data streams. Let´s look at both little closer.

Temporary Tables

We can define them as typical tables which are created within a database session and are only available during the lifetime of that particular session. Lifetime during session is critical as they are designed to store intermediate results, results of window functions for complex calculations or data processing tasks and massive data manipulations.

Temporary tables are essentially useful in scenarios where data needs to be temporarily held and manipulated without affecting the main database tables. Here comes why it is called “temporary”. After your session ends, the temporary table is automatically discarded - same as you run command DROP TABLE, after query results are taken into another step. This way processing ensures no permanent database storage is consumed. You can imagine storing all 245 steps and their output tables consisting of 6 billion rows and 700 columns each day to have versions of each step.

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.

Reference Architecture is foundational to designing any complex system or solution. It provides a high-level diagram that represents the structural pattern of the solution, establishing a consistent framework that guides the design and implementation of similar projects across an organization. Unlike solution architecture, which is customized for each project, reference architecture offers a generalized template that aligns with established best practices, making it broadly applicable and easily understandable for both technical and non-technical stakeholders.

Purpose and Benefits

The main objective of a reference architecture is to set a standardized approach for designing solutions within an organization. This ensures consistency, reduces redundancy, and accelerates solution delivery by offering a clear blueprint. With this architecture, teams can quickly understand the fundamental elements of the solution, enabling efficient alignment with organizational goals. Additionally, reference architectures aid in risk management by promoting tried-and-tested design patterns and technologies, minimizing potential errors in execution.

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:

The transformation of data into a strategic asset has led to the evolution of modern data products into what is now recognized as Data-As-a-Product (DAaP). Unlike traditional data products that serve narrow, predefined use cases, DAaP represents curated, production-grade datasets or models designed for consumption by multiple downstream users, systems, or applications. The goal is not just to serve information but to enable further processing, analytics, and transformation, with guaranteed semantic clarity, contract enforcement, and lifecycle stability.

The DAaP Shift: Two Pathways to Maturity

A data product evolves into DAaP under two primary scenarios:

1. Organic Maturity
   • Occurs when the utility of a data product extends beyond its original intent, powering other systems, dashboards, or models.
   • Example: A sales insights dashboard originally built for a regional team becomes DAaP when its curated datasets feed into forecasting models, executive dashboards, or marketing analytics.
2. Purposeful Design
   • DAaP is built intentionally from day one to serve as a scalable, reusable, and governed data source across domains.
   • Example: A centralized operational dataset constructed with clear semantic models and data contracts to serve finance, supply chain, and HR platforms in parallel.

A Data Product Owner (DPO) is the person responsible for overseeing the development, maintenance, and evolution of a data product. This role is essential in ensuring the data product serves user needs, aligns with the business’s strategic goals, and leverages data effectively to provide value. But who should take on this role? Let’s explore what makes an effective Data Product Owner and which roles within an organization are best suited to it.

Who Can Be a Data Product Owner?

Selecting the right DPO is key to the success of a data product. While the role can technically be filled by individuals from various backgrounds, the most effective DPOs tend to have a unique blend of business, technical, and strategic skills.

Here’s a look at potential candidates:

• Business Leaders (CDO, CAO, or other Senior Business Leaders): Business leaders, such as the Chief Data Officer (CDO) or Chief Analytics Officer (CAO), are well-suited for the DPO role because they typically have a deep understanding of the organization’s strategic goals and data-driven needs. With a focus on aligning data products to support overall business objectives, these leaders ensure that the data product delivers high business value and actionable insights.
• Technical Leaders (CTO, CIO): A Chief Technology Officer (CTO) or Chief Information Officer (CIO) may also make a good DPO, especially in organizations where data products are highly technical or integrated with broader IT systems. Their expertise in the technical infrastructure allows them to understand the complexities of data architecture, security, and scalability, ensuring the DP is robust and reliable.
• Data Visionaries (Founders, CEOs, or Business Visionaries): For some companies, particularly startups or data-driven organizations, a visionary founder or CEO may step into the DPO role. These leaders often bring a strong vision for how data can shape the future of the business and can inspire teams to build innovative data products. However, for this to work effectively, the visionary leader should have a solid understanding of data and a clear vision of how it will add value.
• Cross-Functional Managers (Product Managers, Data Analysts): Product Managers with data knowledge, or senior Data Analysts who understand both the business and technical requirements, may also serve as excellent DPOs. They can connect the dots between data insights, business goals, and user needs, while ensuring a data product remains practical and user-friendly.
• Dedicated Data Product Owners: As organizations become more data-focused, some create roles specifically for Data Product Owners. This person focuses exclusively on managing data products, with a balance of business and technical skills, and may report to data, IT, or product leadership.

Data Product Ownership refers to the responsibility of managing and overseeing a data product from creation through to ongoing improvements. A data product owner (DPO) ensures the product aligns with user needs and business goals, making sure it’s useful, valuable, and reliable.

Key Responsibilities of Data Product Ownership

• Define Vision and Goals: The DPO sets a clear vision for the data product, focusing on how it will serve users and provide business value. For instance, if the product is a sales dashboard, the DPO would define what metrics and insights will help users make informed sales decisions.
• Prioritize Features and Improvements: Not all features or updates are equally important, so the DPO decides which functionalities to develop first based on their value to users and the organization. They balance short-term needs with long-term goals to create a roadmap that guides the development process.
• Understand User Needs: The DPO connects with end users to understand what they need and expect from the product. This means gathering feedback, studying user behaviour, and ensuring that the data product addresses actual problems or enhances the user experience.
• Ensure Data Quality and Compliance: Data accuracy, reliability, and security are crucial. The DPO collaborates with data engineers and analysts to ensure the data product meets high standards and complies with privacy regulations.
• Collaborate with Cross-Functional Teams: The DPO works closely with data scientists, engineers, designers, and business leaders to bring the product to life. This collaborative effort ensures that the product’s technical foundation is solid and that it serves business purposes.
• Monitor Product Performance: After launch, the DPO monitors key performance indicators (KPIs) to assess how well the product meets its goals and addresses user needs. This helps in deciding when to update features, fix issues, or adjust the product’s direction.

In today’s data-driven world, the creation, management, and delivery of data have evolved beyond pipelines and reports. At the heart of this transformation lies the concept of the data product, a curated, consumable asset designed to deliver value to internal and external consumers. But as enterprise data demands grow, so too does the need for a more governed, scalable model: Data-As-a-Product (DAaP).

To appreciate the full lifecycle, we must examine the zones, roles, and processes that underpin the ecosystem.

1. The Data Preparation Zone: Building the Foundation

The journey of every data product starts in the Data Preparation Zone, where raw, fragmented inputs are collected, validated, and modeled for reuse. This phase lays the architectural backbone needed for reliable analytics, machine learning, and productization.

Common modelling approaches in this zone include:

• 3NF Data Warehouse Modelling – Ideal for highly structured OLTP-aligned models with integrity constraints.
• Lakehouse Modelling (3NF in Data Lake) – Hybrid model allowing structured and unstructured data in open table formats with transactional consistency.
• Data Vault Modelling – Designed for agility, historization, and traceability in complex data landscapes.
• Ensemble Techniques (Focal Point, Anchor, etc.) – Used to unify fragmented entities across domains.
• Feature Store Design – Curated, versioned features for ML model consumption, supporting reuse across pipelines.