Herausforderungen kundeneigener Datenmodelle in SAP S/4HANA
ABAP CDS Views sind mittlerweile vielen ABAP-Entwicklern ein Begriff. Diese bilden die Grundlage des virtuellen Datenmodells, über das wir in diesem Blog schon geschrieben haben. Doch welche besonderen Punkte gilt es zu beachten, wenn ich als SAP-Kunde eigene Datenmodelle in SAP S/4HANA erstellen möchte?
Herausforderungen mit CDS Views
Bei der Datenmodellierung kundeneigener Projekte innerhalb von S/4HANA ist es nur konsequent, die Core Data Services gezielt zu nutzen. Vielleicht stehen Sie dabei in umfangreichen Entwicklungsprojekten vor ähnlichen Herausforderungen mit dieser Technologie wie wir:
- Je nach Notwendigkeit werden Views ad hoc angelegt.
- Schnittstellen und Zuständigkeiten der Views sind unklar.
- Es kommt zu ungewollter Redundanz, bspw. durch fachlich gleiche Felder in unterschiedlichen, voneinander unabhängigen Views.
- Dabei kommt es nicht selten zu technischen Abweichungen zwischen fachlich gleichen Kennzahlen.
- Zumeist ist auch unklar, welche View für bestimmte Merkmale quellführend ist.
- Namensgebung der Views und Objekte werden unterschiedlich gehandhabt.
- Ein eher unkontrollierter Aufbau von Abhängigkeiten erschwert die Weiterentwicklung.
- Aufwände der Abstimmungen von Teams, deren Aufgaben voneinander abhängen, steigen.
In Konsequenz werden die Datenmodelle undurchsichtig, Synchronisationsaufwände zwischen den Teams steigen, viele ungeplante Ad-hoc-Maßnahmen werden notwendig und Test bzw. Qualitätsmaßnahmen steigen in ihrer Komplexität. Dabei leiden Qualität, Kosten, Zeit und Nerven. Auch wenn dann oft der Wunsch entsteht, das Modell nach dem Greenfield-Ansatz neu aufzubauen, ist das nur selten praktikabel.
Mit erhöhten Anforderungen an Flexibilität, Qualität und Laufzeitverhalten steigen die Risiken der oben beschriebenen Problematiken. Eine zeitgleiche Weiterentwicklung über mehrere Teams, wird somit ebenfalls erschwert.
Systematisiertes Vorgehen als erfolgsversprechende Strategie
Welche Maßnahmen können hier helfen? Aus unserer Sicht und aus unseren Erfahrungen ist die Einführung einer frühzeitigen Systematik und deren konsequente Anpassung und Weiterentwicklung an Ihre Bedürfnisse eine erfolgsversprechende Strategie.
Dies kann insbesondere umfassen:
- Entwicklungsrichtlinien, die sich am SAP-eigenen Standard, bspw. SAPs Leitlinien zum Virtuellen Datenmodell, orientieren.
- Eine somit klare Namensgebung von Views und Objekten nach einem einheitlichen Code, der bspw. die funktionalen Aspekte der Entitäten kennzeichnet.
- Architektonische Trennung der Views in Schichten nach Vorbild des Virtuellen Datenmodells der SAP. Damit klare Entkopplung von quellführenden Interface- und Consumption-Views, also in Unterscheidung der Verwendung. Hierdurch insbesondere eine klare Schnittstellenvereinbarungen zu den Abnehmern, wodurch sich insbesondere zumeist zeit- und kostenintensive Kommunikationsaufwände deutlich reduzieren.
- Deutliche Kapselung nach Arbeitspaketen. Damit Attribution von Verantwortungen auf die einzelnen Entwicklungsobjekten.
- Einheitliche Regelung für Dokumentation und Testanforderungen.
Die Vorteile einer Reflexion, Diskussion und Analyse dieser Punkte in einer früheren Projektphase liegen auf der Hand. Die so erzielten Entscheidungsprämissen können frühzeitig in eine Umsetzung eingebracht werden. Erzielte Erfahrungen können Sie dann mit diesen klaren Vorstellungen systematisiert in Folgeprojekte einbringen und entfalten dadurch insgesamt eine positive Dynamik.
IST/SOLL-Analyse als Startpunkt
Als Startpunkt bietet sich die Struktur einer klassischen IST/SOLL-Analyse an, die durch den Aspekt der zeitlichen Entwicklung erweitert wird.
Typische Fragen hierbei können sein:
- Wie sieht aktuell mein Datenmodell aus? Wer entwickelt dieses weiter? Wer ist Abnehmer?
- Was läuft gut, was läuft derzeit nicht gut? Welche Probleme treten immer wieder auf?
- Ohne weitere Maßnahmen: Wie würde sich die Situation weiterentwickeln?
- Welche Kriterien an Datenqualität, Laufzeit, Testbarkeit, Anpassbarkeit usw. möchte ich im SOLL erzielen?
- Wie stelle ich sicher, dass mit zukünftigen Anpassungen diese Kriterien invariant bleiben?
- Welche Architekturidee habe ich? usw.
Ausgehend von einer solchen Beschreibung und Analyse der IST-Situation und einer deutlichen Vorstellung des SOLLs können Sie anschließend systematisch Maßnahmen aufstellen, gruppieren und operationalisieren. Gerne unterstützen wir Sie bei den (Vor-)Überlegungen, wie Sie in Ihrem Entwicklerteam mit CDS Views arbeiten können. Sprechen Sie uns direkt an oder schauen Sie gerne hier bei unserem passenden Angebot vorbei.
