Skip to main content

Overview

Practice Shaper​

The Practice Shaper is the main and most impactful Witboost setting that models Witboost entities (domains, systems, components, templates) as nodes of a fully-configurable property graph.

This enables data-oriented organizations to shape Witboost based on their unique use cases, structure, and needs: the Witboost installation in Organization A could be completely different from the Witboost instance running in Organization B.

Thanks to the Practice Shaper, a company can approach any project scenario in data (Data Landscape), such as Data Mesh, Data Lake, Machine Learning Sandbox and others, by defining which practices are enabled and regulated, with the possibility to define technological and methodological guardrails.

Data Landscapes​

A Data Landscape refers to the overall environment and ecosystem in which data exists, is managed, and is utilized within an organization.

For a better understanding, let's try to analyze the needs of an organization that wants to shape its operations on the Data Mesh model.

tip

If you want to delve deeper into the Data Mesh, check the AgileLab blog

First, it needs a structure to represent Data Products. Each data product could be composed of internal components such as storage areas (e.g., an S3 bucket) and workloads (e.g., an ETL Spark job) based on its specific needs. It will also expose one or more output ports to enable the external world to consume its data in a format such as a relational table, a file or an events stream.

The Platform Team, to make Witboost support the Data Mesh model described above, will:

  • register the Data Mesh data landscape. Users can seamlessly switch between all the registered data landscapes through a visual selector available on most Witboost pages
  • create a new system type named Data Product and link it to the Data Mesh data landscape: this enables users in creating and accessing Data Product instances (e.g., a Data Product exposing cash flow data of a company) when working in the Data Mesh context
  • create a component type named Storage Area and define a partOf relation with the Data Product system type: this enables users in defining Storage Area instances (e.g., an S3 bucket) within a registered data product instance
  • create a component type named Workload and define a partOf relation with the Data Product system type
  • create a component type named Output Port and define a partOf relation with the Data Product system type
  • define a readsFrom relation between the Workload component type and the Output Port one: thanks to this, users, when instantiating a Workload, will be able to specify if it reads from the output port of a published data product (e.g., a Databricks job reading from a Dremio table)

Thus, the Platform Team possesses all the necessary tools to define highly customizable Data Landscapes, comprising system and component types, their attributes, constraints, and relations.

End users operate within one or more of these defined Data Landscapes without needing to worry about the underlying specifications. Their interaction with the platform is primarily guided by templates and utilities that ensure compliance with the relations, constraints, and structures defined in the Practice Shaper.

info

Glossary:

  • System: a logical collection of interconnected and interdependent components or elements collaborating together to achieve a common goal or purpose
  • Component: a self-contained and modular part or element within a system, possessing specific functionalities or capabilities
warning

The Practice Shaper has been introduced with Witboost v2. Prior to this, Witboost was purely Data Mesh oriented. As the documentation is currently being refactored, you may find some sections still referring only to Data Mesh and Data Products. However, the same principles apply to systems in other data landscapes.