Data Flow diagrams in combination with Processes

Dear ​@mvanrooijen,

thank you for this question!

As mentioned as per the pre-defined Meta Model there is no direct relation between process and data object. As per SAP LeanIX best-pratice data objects are created, read, updated & deleted by Applications (see here for detailed relations), based on that the data-flow logic within SAP LeanIX applies to the respective applications fact sheets and shows the connection between these via the interface fact sheet by which the data objects are transferred.

To model relations beyond application to application via interface fact sheet, you can use the free draw diagram and expand by a “show dependencies” filter. 

As you mention Signavio here, are you currently using Signavio? If so where do you maintain the relations for processes, in LeanIX or in Signavio?

KR,

Luca

​@acaetano it is worthwhile to consider the “indirect” relationship to business architecture that the OOTB data model provides before extending the data model. E.g. Data is used by an Application that in turn provides or enables a Business Capability.

If that doesn’t suit, or getting to the insights is too difficult, then you could consider extending to “direct” relationships but be aware of the increased effort required to create/maintain those relationships.

​@acaetano I fully agree!

There generally is a direct relationship between business objects (that are sadly not included in the LeanIX metamodel) and business contexts.

From an Enterprise Architect perspective that is a no go. Data or business objects are transformed through a process, not an application. Especially if you want to showcase the organization that they are wasting time and money on an application when a small change in a previous process can deliver the desired transformation WITHOUT adding additional applications to your landscape.

From my perspective yours is the only right answer.

LeanIX needs to evolve to include the full business layer, not just the ones pertaining to applications.

In mainstream Enterprise Architecture frameworks, the common direct relationships are (1) Business Process uses Data Object, (2) Data Object realizes/supports Business Capability, (3) Application realizes/supports Business Process, and (4) Application uses (CRUD) Data Object.

The OOTB LeanIX v4 metamodel forces an application-centric approach where Data must be defined from the perspective of the Applications that use it. But he relationships between data and the business should never be indirect/transitive but direct.

(Business) Data Objects (such as Customer, Sales Order, Purchase Order) are actually more stable than Applications and its definition is fully independent from Applications. That is why Data is usually defined from a Capability and/or Process perspective and not from an Application perspective, unless the focus is describing the design of the applications, which is often not in scope of EA management.

Actually, if processes are defined, then the data used by applications can be defined indirectly/transitively. But this is not possible in OOTB LeanIX due to the lack of relationships. Also note that LeanIX has "official" integrations with Signavio and Collibra, which makes it even more surprising that the relationships (1) and (2) are not readily available OOTB.

Of course, extra relationships do increase maintenance effort. However, no one is forced to use all of the available OOTB relationships. A decision on which relationships to use depends on maturity and the scope of the EA practice. Moreover, we already have today several OOTB relationships that mostly exist to address edge cases - so it makes little sense to leave out core relationships between data and business. 

IMO it would be preferable having OOTB the existing data/application relationships plus the data/business relationships. This would also allow pre-defining reports/dashboards to view and assess the alignment between business, data, and applications. But since this is not available, each LeanIX customer is forced to devise its own solution to support these custom data relationships :-( Hopefully this will be available in v5.