Top 10 SOA-Fallstricke: #4 - Falsch angewandtes kanonisches Datenmodell

Letzte Woche hat Vincent die BDUF-Falle erklärt und diese Woche geht es weiter mit #4: Falsch angewandtes kanonisches Datenmodell (CDM).

CDM ist eines der Wundermittel, die bei SOA-Projekten oft eingesetzt werden. Es soll Missverständnisse beseitigen, die Integration erleichtern und die Integrationskosten senken. Es kann sicherlich all dies erleichtern, aber der Versuch, ein CDM zu verwenden, kann Ihr SOA-Projekt auch in eine endlose Diskussion verwandeln, weil man versucht, zu viel abzudecken, weil es an der Ausrichtung auf das Geschäft mangelt und weil es an Designprinzipien fehlt.

Ein kanonisches Datenmodell (manchmal auch CIM genannt: Common Information Model) definiert die für eine bestimmte Integrationsdomäne relevanten Geschäftseinheiten, ihre Beziehungen und ihre Semantik. Welchen Mehrwert bringt ein gut definiertes und korrekt verwendetes CDM mit sich? Zunächst einmal erleichtert es ein gemeinsames Verständnis dessen, was eine Geschäftseinheit wirklich ist. Ist die Geschäftseinheit 'Kunde' beispielsweise eine Person oder eine Organisation? Oder ist die Geschäftseinheit 'Kunde' eine Rolle, die von einer 'Person' oder 'Organisation' ausgeführt werden kann. Im gleichen Bereich des "Verstehens" erleichtert es ein gemeinsames Verständnis der Beziehungen zwischen Geschäftseinheiten. Dieses gemeinsame Verständnis erleichtert die Kommunikation zwischen Abteilungen und auf breiterer Ebene zwischen Organisationen, wie das SID-Modell von TM Forum zeigt. Und schließlich können die Integrationskosten erheblich gesenkt werden, wenn die zu integrierenden Systeme die gleiche Sprache sprechen bzw. die gleichen Konzepte verwenden (Sprache ist in diesem Fall keine Programmiersprache, sondern ein Verständnis dafür, was eine Geschäftseinheit ist und welche Beziehungen zwischen diesen Einheiten bestehen).

Welche Fallstricke gibt es beim Versuch, einen CDM zu erstellen und zu verwenden? CDM-Entwickler versuchen oft , den Ozean zum Kochen zu bringen und jede einzelne Information, die in der Organisation verwendet wird, einzubeziehen. Dadurch explodiert die Anzahl der zu modellierenden Einheiten und die CDM-Initiative wird zu einer endlosen Übung. Ein CDM ist für den Einsatz in der Integrationsdomäne gedacht und sollte daher nur Entitäten enthalten, die in dieser Domäne relevant sind. Ein weiterer Fallstrick bezieht sich auf den SOA-Fall Nr. 10: Das Not Invented Here-Syndrom und sind von Grund auf neu entwickelte CDMs. Potenzielle Modelle, die wiederverwendet werden könnten, werden ignoriert, während verschiedene potenziell wiederverwendbare Domänenmodelle verfügbar sind(SID, UDEF und AFD). Einige sind branchenspezifisch, aber selbst dann können die Definitionen für Kunden, Verträge usw. oft wiederverwendet werden. Der nächste Fallstrick ist das große flache CDM ohne jegliche Strukturierung. Dadurch wird das Modell schwer zu verwenden und zu verstehen, selbst wenn Sie nur mit einem kleinen Teil davon interagieren müssen. Das verlangsamt die Akzeptanz des Modells. Die Akzeptanz wird auch durch Inkonsistenzen bei den verwendeten Namenskonventionen und Modellierungsmustern verlangsamt. Einer der größten Fehler besteht darin, bei der Definition der CDM-Entitäten und ihrer Beziehungen keine Fachexperten zu konsultieren. Ein CDM sollte, wie jedes andere IT-Artefakt auch, das Geschäft unterstützen. Deshalb muss sichergestellt werden, dass das Modell das Geschäft widerspiegelt und nicht eine reine IT-Sicht ist. Und schließlich gibt es den Fallstrick von CDMs, die auf Modellen von Anbietern oder aktuellen Anwendungen basieren. Ein Modell wie ein CDM sollte Geschäftskonzepte modellieren und daher nicht an Anbieter oder aktuelle Anwendungen gebunden sein. Sowohl Anbieter als auch Systeme kommen und gehen, Ihr Unternehmen überlebt dies hoffentlich.

Um ein Scheitern des CDM zu verhindern, können die folgenden Richtlinien helfen:

• Entwickeln Sie einen CDM im Kontext konkreter Projekte und nehmen Sie Entitäten auf, die für diese Projekte benötigt werden. Sicherlich müssen Sie ein wenig vorausdenken, aber das bedeutet nicht, dass das Modell jede Entität enthalten sollte, die Ihnen einfällt. Wenn Sie in die Zukunft blicken, sollten Sie überlegen, wo das Modell erweiterbar sein sollte und sich auf die Entitäten konzentrieren, die derzeit benötigt werden.
• Ein CDM ist für die Integration gedacht und sollte daher nur Entitäten umfassen, die auf der Integrationsschicht verwendet werden. Entitäten, die nicht zwischen Systemen ausgetauscht werden, sollten nicht Teil des CDM sein. Der hellrote Bereich in der Abbildung rechts veranschaulicht die Informationen, die Teil des CDMs sein sollten.
• Unterteilen Sie das Modell in eine Reihe von Bereichen mit starker Kohäsion zwischen den Einheiten in einem Bereich und loser Kopplung zwischen den verschiedenen Bereichen. Dies erleichtert das Verständnis und die Übernahme des Modells, da sich die Leser leicht auf die für sie relevanten Teile konzentrieren können.
• Prüfen Sie, ob es Modelle gibt, die Sie als Grundlage verwenden können. Es gibt branchenspezifische Modelle, und manchmal enthalten diese Modelle auch generische Konzepte wie Kunden, Produkte, Verträge, Preise usw., die auch außerhalb der jeweiligen Branche verwendet werden können. Beispiele sind SID, UDEF und AFD.
• Arbeiten Sie mit Domänenexperten zusammen. Sie kennen das Geschäft am besten und können Ihnen helfen sicherzustellen, dass das Modell das Geschäft widerspiegelt.
• Definieren Sie eine begrenzte Anzahl von Designprinzipien, die verwendet werden sollen. Dies wird zu einem konsistenteren und leichter verständlichen Modell führen. Klare Benennungskonventionen für Entitäten, Attribute und Beziehungen sind in diesem Bereich ebenfalls hilfreich.
• Geben Sie Beispiele, die zeigen, wie das Modell verwendet werden sollte, wie es nicht verwendet werden sollte und wie es begründet wird.
• Wenn Sie das Modell verteilen, tun Sie das so, dass die Leser leicht darin navigieren können.

Die Definition eines CDM ist eine anspruchsvolle Aufgabe, aber wenn Sie diese Richtlinien befolgen, sollten Sie die Herausforderung meistern. Der Verzicht auf einen CDM in einer SOA kann zu zusätzlicher Komplexität in der SOA führen, da es viele Punkt-zu-Punkt-Verbindungen auf der Datenebene geben wird. Wie bereits in Fallstrick #6 - SOA löst Komplexität nicht automatischist ein CDM eines der Elemente, die die Komplexität reduzieren können.

Nächste Woche nimmt uns Viktor mit auf Platz 3...