Data Object

📘

These modeling guidelines are for the Meta Model v4. For Meta Model v3 guidelines, see Modeling: Data Object.

Definition

Data Objects provide an overview of general data processed and exchanged by specific applications.

Description

Data Objects are used in LeanIX to analyze which data is processed by specific Applications and exchanged via specific Interfaces.

Overview of all relations to/from Data Object:

In LeanIX, we capture data in the Data Object Fact Sheet. Data can be classified into personally identifiable data (e.g., to cater to GDPR use cases) or according to security needs. Also, the definition of CRUD operations on specific Data Objects and their related Applications is a vital use case for preparing migration initiatives. Data Object exchanges between Applications can be captured using the Interface Fact Sheet. Then you will be able to show the data flow between your applications.

Data Objects also reflect information about important business items. This could be account, employee, or organization data. Data Object Fact Sheets can be linked to Applications and Interfaces and store additional information about data sensitivity. Data Object will benefit you when you want to manage data sensitivity or the consistency of business information. Then, you can answer the question such as: “Where do you use data of a special sensitivity level?”

Data Objects Examples: Contract, Order, Material, Customer

Guidelines and Best Practices

• We recommend modeling the Data Object in a lean hierarchy, for example, Production as level 1 and Bill of Material as level 2. Another example would be Employee / Contract.
• Avoid creating redundancies. Well-defined Data Obiects do not overlap. They are mutually exclusive. A good test is to check whether you can assign Level 2 Data Objects without any ambiguity.
• Rely on Business Capabilities. It is very easy to find which Data Objects exist once you have mapped your Busines Capabilities. This is why we recommend creating a Business Capability map first.
• Long-term stability. Properly defined Data Objects are fairly stable over time, persisting throughout any organizational changes. Only major business changes should affect them.
• Cross-organizational. Stay specific. Data objects should remain the same, independent of any changes that might happen to the organizational structure.
• Use existing data models. Many applications (e.g., SAP) will already have an existing Data Object model. Orient yourself with these when creating your own list.
• Breadth rather than depth. While more levels can help to get a better structure, it comes at the cost of increased complexity. We recommend keeping it at two levels.
• Involve relevant parties. Leverage insights from representatives throughout the business. Those responsible for different parts of the business are likely to have the best overviews of Data Objects. Consider using surveys to collect information.

In the poster below, you can also find tips, examples, and the aforementioned best practices on what is important for using Data Objects.

How to model Data Objects for data classification

As mentioned above, Data Object can help you capture the information for the GDPR initiative. In this context, we must identify applications dealing with public, sensitive, restrictive, and confidential information.

In LeanIX, you can capture this information in the Data Object Fact Sheet (Public, Sensitive, Restrictive, and Confidential). Then, you can link the Data Objects with the respective Applications.

When you have this model, you can then leverage the Data Flow Diagram to visualize how your data flow from one application to another. This overview is useful to identify which application is using particular information and has the potential to mitigate information leaks.

You can also get a report on the Data Classification, as shown below. The report lets you easily identify which data classification is applied in your applications.

How to model Data Objects for CRUD on the Application Landscape

Similar to the previous example, you can use Data Object Fact Sheet to capture how the data access between your applications. You can create a Data Object Fact Sheet for Create, Read, Update, and Delete, also known as CRUD. When CRUD Data Objects are added and linked to the Application, you can use this information by leveraging the Application Landscape Report to visualize the application usage based on those Data Objects directly on the Applications.

Antipatterns

This section addresses antipatterns involving ineffective or counterproductive ways of modeling Data Object in LeanIX.

• Data Objects in LeanIX aim to capture information that is relevant for business and the application layer. LeanIX is not a Master Data Management (MDM) or data lineage tool to create in-depth data architectures. You can leverage tools like Collibra, which is integrated with LeanIX.

Applicable Use Cases

• Deepening your Application Portfolio Assessment with insights on data security and compliance that are relevant to GDPR or other regulations.

Insights from Data Object Fact Sheet

• Data classification of Applications can be shown in a Matrix View (Aggregated View).
• Visualization of data flow.
• Application usage on CRUD can be shown in the Data Object Landscape Report leveraging the Application Landscape Report.

Further Resources

• How does Collibra Integration play a role in the modeling of Data Objects?