Identifikation von Geschäftsobjekten

[3xplor3r_4daf33]

Hallo,

ich befinde mich gerade im Praktikum und versuche noch ein paar Kriterien für eine Identifikation von Geschäftsobjekten in beliebigen Datenmodellen aufzustellen. Ich hoffe, dass ihr mir dabei helfen könnt.

Im Prinzip geht es darum, dass ich von einem beliebigen operativen System ein Datenmodell bekomme und dieses Datenmodell nach verschiedenen Kriterien durchsuchen soll, wonach dann gesagt werden kann, das Entität x, Entität y und Entität z mögliche GO-Kandidaten sind. Die Datenmodelle werden aus einem Reverse-Engineering gewonnen. Das Tool, was dafür zum Einsatz kommt ist ERwin 7.3.1. Nach dem RE wird das physische Datenmodell in ein logisches umgewandelt bzw. es wird ein logisch/physiches Datenmodell aus dem RE generiert.

Meine bisherigen Ideen sind meiner Meinung nach noch sehr beschränkt und deshalb suche ich hier ein wenig Hilfe. Ich hatte gedacht, zuerst den Systemnamen zu untersuchen, d. h. ich suche nach Synonymen/Homonymen einzelner Wörter im Systemnamen und in der Systembeschreibung, um evtl. mit einer Auflistung aller Entitäten im Datenmodell diese Synonyme wiederfinden und sie als mögliche GO-Kandidaten deklarieren zu können. Die Systembeschreibung wird durch das Tool Enterprise Architect unterstützt. Für die von euch, die das Tool nicht kennen. Im Prinzip lässt sich damit das Domänenmodell der Unternehmung beschreiben, also welche Systeme im Einsatz sind und wie/wo sie eingegliedert werden können. Wie gesagt notiere ich konkrete Begriffe, meist Substantive und suche hierfür nach Synonymen/Homonymen und so weiter, die im Datenmodell vielleicht als Beschreibung von Entitäten wieder auftauchen könnten.

Die zweite Idee ist das Datenmodell nach Entitäten zu durchsuchen, die besonders viele Relationen eingehen, d. h. dessen Primärschlüssel zum Fremdschlüssel anderer Entitäten wird. Ich hatte bspw. eine Entität, die gut 25-30 Relationen eingegangen ist und viele Relationen zu anderen Entitäten einging, die ebenfalls wiederum viele Child-Relationen aufwies. Deshalb wurde sie für mich ein möglicher GO-Kandidat. Eine Child-Relation, die „nur“ ein Ergebnis einer Normalisierung darstellt, ist kann vielleicht als Teilgeschäftsobjekt angesehen werden, bildet aber wie gesagt nur einen Teil des wirklichen Geschäftsobjektes ab.

Nun ist es aber auch schon vorbei mit den Ideen und darum richte ich nun meine Frage an euch. Nach welchen weiteren Kriterien könnte man GO-Kandidaten in einem beliebigen Datenmodell identifizieren, wobei das Datenbanksystem sowie die Plattform irrelevant sind, da ich mich im logischen bzw. konzeptuellen Datenmodell bewege, auch wenn logisch = physisch ist?

Sollte noch etwas unklar sein, bin ich natürlich gern bereit Licht ins Dunkel zu bringen. Vielen Dank und beste Grüße.

[3xplor3r_4daf33]

Sehr gerne … in der Tat habe ich eine gute Woche damit zugebracht, die Begriffe gegeneinander abzugrenzen. Neben Geschäftsobjekt hatte ich die Begriffe Informationsobjekt und Datenobjekt versucht gegeneinander abzugrenzen. Neben dem Wiki-Eintrag habe ich auch mehrere Literaturangaben durchsucht. Ich denke, dass es nicht zielführend ist weitere Definitionen hier zu platzieren. Darum beschränke ich mich auf wenige Sätze aus einer Definition, die mir am besten gefällt.

„Ein Geschäftsobjekt ist ein abgestimmter, fachlicher Begriff für abstrakte oder konkrete Objekte, die im Unternehmen von Relevanz sind, d. h. in engem Zusammenhang mit der Geschäftstätigkeit des Unternehmens stehen und der Modellierung dauerhaft gespeicherter Informationen (Stammdaten) dienen. Beispiele für Geschäftsobjekte sind „Kunde“, „Produkt“ oder „Auftrag“. Geschäftsobjekte können in unterschiedlichen Beziehungen zueinander stehen. Ein Auftrag kann in Teilgeschäftsobjekte zerlegt werden (bspw. „Auftragskopf“ und „Auftragsinhalt“). Ein Kunde kann in einer Erstellt-Beziehung zum Auftrag und ein Auftrag in einer Nutzt-Beziehung zu Produkten stehen.“ Quelle: Jutta Allmendinger: „Der Weg zur Enterprise Application Integration“, S. 41, Vieweg Verlag, 2003.

„Modellierung dauerhaft gespeicherter Informationen (Stammdaten)“ stammt damit aus meiner Feder bzw. aus der Umgebung des Unternehmens heraus und findet sich nicht in der Quelle.

Im Prinzip geht es darum die Datenmodelle allen Modellieren zentral in einem Repository zugänglich zu machen. Für mich sind „richtige“ Geschäftsobjekte auch sowas wie Kunde, Produkt, Auftrag, Projekt, etc… Ich muss auch ehrlich sagen, dass sich für mich der Sinn nach der Suche nach Geschäftsobjekten nicht richtig erschließt. Ich wüsste nicht, was es mir persönlich bringt, wenn ich weiß, dass in dem Datenmodell ein Geschäftsobjekt liegt, außer, dass ich dann vielleicht weiß, dass dieses System von größerer Bedeutung für das Unternehmen ist. Anders sieht es da schon wieder in der zentralen Bereitstellung der Datenmodelle aus. Es ist schon wichtig, dass jeder Datenmodellierer Zugang zu allen Datenmodellen hat, um redundante Systementwicklungen zu vermeiden. Um ersteres nochmal aufzugreifen könnte ich mir vorstellen, dass es wichtig ist, Kenntnis von Geschäftsobjekten zu haben um so ebenfalls redundanten Systementwicklungen entgegenzuwirken. Bspw. es geht um das GO Kunde und es gibt im Unternehmen bereits ein Kundenverwaltungssystem, dann können neue Systementwicklungen in dieser Richtung vielleicht vermieden werden, weil es bereits ein System gibt, dass diese Aufgabe unterstützt.

Soweit zu meiner Sicht der Dinge. Ich freue mich auf ein paar Antworten.

LG

[drambeldier]

Moin,

ein unternehmensweites Objektmodell fällt nicht vom Himmel, sondern es wächst über Jahre, deshalb ist der Versuch, heute alle Geschäftsobjekte zu finden, eh zum Scheitern verurteilt.

Ein Objektmodell umfasst genau die Dinge, die den Betreiber einer Applikation interessieren. So sind zB dem Logistiker die Personalangelegenheiten ziemlich egal, der Personaler interessiert sich nicht für den Wareneingang, usw. usf etc pp.

Die Objekte im Unternehmen, die von mehr als einer Applikation benötigt werden, sind für das Unternehmen als Ganzes wichtig, da aber u.U. auch nur bestimmte Sichten. Hier lohnt es sich, Arbeit hineinzustecken, um die Schnittstellen zu definieren.

Nach meiner Erfahrung liest niemand (abteilungs-)fremde Modelle. Einziges Mittel ist eine zentrale Instanz, bei der alle Beteiligten antanzen müssen, wenn sie Speicherplatz benötigen - dort müssen sie sagen, was sie brauchen, und dort sagt man ihnen, was es im Unternehmen schon gibt.

Dann wird SAP eingeführt, und diese flotten Jungs brauchen sich um nichts zu scheren, sie sind ja bald wieder weg. Aber das ist eine ganz andere Geschichte

Gruß Ralf

[3xplor3r_4daf33]

Ich sehe das ähnlich. Auch dieses Unternehmensmodell ist über Jahre gewachsen. Die Größe ist mittlerweile kaum noch überschaubar, dennoch gut dokumentiert.

Es ist ja gerade das Ziel, dass Abteilungen Datenmodelle anderer Abteilungen schätzen und diese bei ihrer Arbeit verwenden, um redundanten Systementwicklungen entgegenzuwirken. Ob diese das nun machen oder nicht, steht auf einem anderen Blatt und ehrlich gesagt, und ich bitte das nicht böse zu nehmen, kümmert mich das auch nicht. Meine Aufgabe für meine Arbeit ist es diese GO-Kandidaten zu identifizieren auch wenn es lange nicht alle sind.

Denoch finde ich deine Kritik wirklich angebracht und werde sie bei Erlaubnis auch versuchen in meiner Arbeit unterzubringen.

Allerdings steht noch die Frage im Raum, welche Kriterien noch zu berücksichtigen sind. Hier nochmal meine bisherigen:

1. Synonyme, Homonyme, Akronyme, etc. auf Entitäten ableiten.
2. Entitäten mit den meisten Relationen berücksichtigen.
3. Entitäten mit den meisten Attributen berücksichtigen.

Ich habe den Eindruck, als sei diese Aufgabe sowieso ein tot geglaubtes Kind. Trotzdem hält der Abteilungsleiter und mein Betreuer daran fest. Ich sehe auch den Sinn dahinter, finde aber die Aufgabenstellung auch etwas misslungen. Leider reichten meine Erfahrungen nicht aus, um das ganze Vorhaben vorher zu durchleuchten. Hätten sie ausgereicht, hätte ich die Arbeit auch nicht angenommen. Nun muss ich da durch und hoffe weiterhin auf ein wenig Hilfe dabei.

LG

[drambeldier]

Hi,

eines der ältesten Mittel ist die Verwendungsmatrix CRUD: Zeilen sind Objekte, Spalten sind Abteilungen, im Kreuzungspunkt steht Create, Read, Update oder Delete. So kriegt man raus, wer mit wem zu tun hat und wer für Objekte verantwortlich ist; mit ein bisschen gutem Willen kann man die Objekte, die von mehreren Abteilungen benutzt werden, als Geschäftsobjekte ansehen.

Gruß Ralf