Im zweiten Teil der Artikelserie geht es um die Basis eines Unternehmensportals, Normalisierung im Service Inventar und die wichtigen Bestandteile einer Architektur. Inbesondere das einzige Datenmodell beim Einsatz einer SOA wird beleuchtet.
einziges Datenmodell im Unternehmen – intrinsische Interoperabilität
Nicht-standardisierte Verträge zwischen Services bzw. unterschiedlichen Anwendungsteilen (größere Granularität) führt zur Erstellung und Implementierung von verschiedenen Datenmodellen, die alle den gleichen Datensatz in der Datenbank der Applikation beschreiben. Um die Unterschiede zu umgehen und zu „übersetzen“ wird eine Datentransformation mit Mapping benötigt. Dies ist jedoch aus folgenden Gründen zu vermeiden:
- die Mapping-Logik muss zusätzlich implementiert und langfristig gepflegt werden
- die Mapping-Logik führt zu Performance-Overhead, da diese zur Laufzeit ausgeführt werden muss
- Datentransformation steigert die Komplexität einer Architektur
Was ist daher naheliegender als im gesamten Unternehmen (oder in einer Domäne des Unternehmens, falls dieses zu groß und komplex ist) ein einziges Datenmodell zu verwenden. Dieses stellt einen Baukasten dar, aus dem eindeutige und einheitliche Attribute für den Aufbau von Datenobjekten und Nachrichten verwendet werden können. Um die Wartbarkeit der Datenstrukturen, welche auf Basis des einzigen Datenmodells entwickelt wurden, auf ein Minimum zu reduzieren und gleichzeitig manuelle Pflegefehler zu vermeiden, empfehle ich das GEFEG.FX-Tool. Dieses stellt durch Vererbung sicher, dass im Datenobjekt die aktuellsten Informationen des Datenmodells zum Einsatz kommen.
normalisiertes Service Inventar
Ein normalisiertes Service Inventar ist wichtig, da hierdurch eine Überschneidung der funktionalen Kontexte der Services vermieden wird. Dieses wird über einen Top-down Erstellungsprozess sichergestellt, an dessen Anfang die Entwicklung eines Service Inventar Blueprints steht. Je nach Größe des Unternehmens ist ein domänenspezifisches Service Inventar ein guter Beginn. Dieses wird unabhängig von anderen Inventaren standardisiert und unterliegt einer selbstständigen Governance. Es enthält größtenteils agnostische Services. Aus diesem normalisierten Inventar können neue Geschäftsprozesse, die das Unternehmensportal aufnehmen soll, mit wenig individueller Entwicklung automatisiert werden.
Aufbau eines Portals auf Service Orientierung
Ein ideales Unternehmensportal sollte eine industrielle Integration von neuen Geschäftsobjekten unterstützen. Eine praxiserprobte, wenig fehleranfällige und wiederholbar/generische Lösung beschleunigt entscheidend die Erweiterung des Portals. Die Unterstützung mit Services basierend auf den Prinzipien von Thomas Erl trägt hierzu ihren Anteil bei.
Standardisierte Verträge mit Schema-Zentralisierung auf Basis eines gemeinsamen Datenmodells können bei der agilen Entwicklung von Benutzeroberflächen (GUI) genutzt werden. Auch eine Aufteilung der Geschäftslogik in einzelne Business Services führt dazu, dass weniger individuelle Entwicklung erforderlich ist.
Um die Geschäftsregeln leichter änderbar und wartbar zu machen, empfiehlt sich der Einsatz einer Rules-Engine. Diese beinhaltet die Policies und kann von zentraler Stelle betreut werden. Eine Abstraktion der Geschäftsregeln von der oftmals proprietären Struktur der Geschäftsregeln ist dabei empfehlenswert (siehe vendor-neutral).
Bestandteile
Eine Unternehmensplattform sollte folgende Bestandteile enthalten
- unternehmensweites bzw. domänenspezifisches einziges Datenmodell, um Datentransformationslogik zu vermeiden
- in Prozessengine ausführbare Geschäftsprozesse (BPMN-Notation)
- erforderliche Services, um die Geschäftsprozesse zu unterstützen
Zusammenfassung
Beim Einsatz von SOA ist es wichtig, dass das jeweilige Projekt über den Tellerrand schaut, um Logic über agnostische Services wiederzuverwenden. So werden die Schwierigkeiten von paralleler Spezifikation und Entwicklung adressiert und Teiler einer Enterprise Architektur wiederverwendet. Die dabei erzielbaren Synergieeffekte zwischen den verschiedenen Lösungsarchitekturen (parallele Projekte) sind dabei oftmals erheblich. Ein Datenmodell sollte angestrebt werden, um intrinsische Interoperabilität zu fördern und Datentransformation zu vermeiden. SOA gibt einem Unternehmensportal Flexibilität durch organisatorische Agilität, jedoch muss man auf Governance achten.