Skip to main content
Solved

Modeling (SAP) BW in LeanIX

  • July 23, 2026
  • 2 replies
  • 46 views
M

Hello LeanIX Community,

We're currently designing our LeanIX model for an SAP BW landscape and would love to hear how others have approached this.

Our LeanIX meta model distinguishes between two Application subtypes:

  • Business Applications

  • Platform Applications

Business Applications run on Platform Applications.

Our current thinking is to model SAP BW as a Platform Application, while the user-facing BI/reporting solutions would be modeled as Business Applications running on top of SAP BW.

However, we're unsure about the right level of abstraction and how to represent the different SAP BW artifacts.

Some of the elements we're considering are:

  • SAP BW

  • InfoAreas

  • InfoProviders (e.g., ADSOs, CompositeProviders)

  • InfoObjects

  • BW Queries

  • Workbooks / Dashboards

  • BI frontends such as SAP Analysis for Office, SAP Analytics Cloud, or SAP BusinessObjects

  • Underlying technologies such as SAP HANA or NetWeaver

Our goal is to create a model that supports transparency, ownership, and impact analysis while remaining practical to maintain.

We're particularly interested in your experience with the following questions:

  1. How would you model SAP BW in LeanIX?

  2. Which BW artifacts (e.g., InfoAreas, Queries) would you model in LeanIX, and which would you intentionally leave out?

  3. How would you model BW artifacts in LeanIX?

If you've modeled SAP BW or BW/4HANA in LeanIX, we'd really appreciate hearing about your approach, lessons learned, and any best practices you've established.

Thanks in advance for your insights!

Best answer by Thomas Schreiner

Hi ​@MarkusHafner, I like to set up things in a simple way and add complexity later if it cannot be avoided. My BW approach is:

  • The BW System as a parent application (your „Platform Application“)
  • The individual end-user facing reporting solutions as child applications (your „Business Application“).
  • Interfaces to source systems on Child level to allow data flow transparency, aggregated on parent level.
  • Further properties: Only a relation to the Data Object fact sheet. I didn’t need anything else so far, and I do not want to add any other attributes without a clear use case, i.e. a consumer to whom the data provides value, or a process that breaks if the data is not available.

 Hope this helps!

    2 replies

    Thomas Schreiner
    Forum|alt.badge.img+4

    Hi ​@MarkusHafner, I like to set up things in a simple way and add complexity later if it cannot be avoided. My BW approach is:

    • The BW System as a parent application (your „Platform Application“)
    • The individual end-user facing reporting solutions as child applications (your „Business Application“).
    • Interfaces to source systems on Child level to allow data flow transparency, aggregated on parent level.
    • Further properties: Only a relation to the Data Object fact sheet. I didn’t need anything else so far, and I do not want to add any other attributes without a clear use case, i.e. a consumer to whom the data provides value, or a process that breaks if the data is not available.

     Hope this helps!

    M
    • MarkusHafner
    • Author
    • Rookie
    • July 27, 2026

    Hey ​@Thomas Schreiner,

    thanks a lot for your response. Happy to hear that our initial thoughts got backed up by your opinion. This definitely helps.

     

    All the best!

      Terms & ConditionsAccessibility statement