Das war die Frage, die mir durch den Kopf ging, als ich aus einem eineinhalbstündigen Treffen mit 6 Teilnehmern herausging. Das Problem war gar nicht so kompliziert, wir gingen mit 3 alternativen Lösungen in die Besprechung: warum dauerte es also so lange, bis wir uns für eine entschieden hatten? Diese Frage beschäftigte mich immer wieder und dann erinnerte ich mich an das Buch"Simple Architectures for Complex Enterprises" von Roger Sessions. Anhand seines Ansatzes konnte ich feststellen, ob wir die richtige Wahl getroffen hatten, und ich beschreibe die Ergebnisse weiter unten.
Einzelheiten zu den Berechnungen finden Sie in dem Buch. Es lohnt sich, es zu lesen, und wenn Sie mit einer kürzeren Version beginnen möchten, finden Sie hier ein Whitepaper. Die kurze Zusammenfassung ist, dass Einfachheit alle anderen Qualitätsaspekte eines Systems übertrumpft. Einfache Systeme sind leichter zu pflegen, leistungsfähiger, besser skalierbar usw. Einfach ist das Gegenteil von komplex und mit seinem Ansatz können Sie die relative Komplexität verschiedener Alternativen berechnen. Die Anzahl der Geschäftsfunktionen und die Anzahl der Verbindungen pro System sind der wichtigste Input für die Berechnung. Diejenige mit der geringsten Komplexität ist die beste Alternative.
[caption id="attachment_7359" align="alignright" width="169" caption="Start situation"]
[/caption]
Genug der Theorie, was ist nun das Problem? Das Bild rechts ist die Systemlandschaft, die es bereits gibt. In Wirklichkeit gibt es noch mehr Systeme in der Umgebung, aber ich habe mich auf die Systeme beschränkt, die in den Alternativen berücksichtigt werden. Die Systeme A/B/C/D sind alle Teil einer Erfüllungskette und wie Sie sehen können, sind sie alle durch EAI-Adapter entkoppelt. Das Datawarehouse (DWH) wird mit Produktdaten gefüttert, die von den Systemen der Fulfillment-Kette geliefert werden.Die Funktionalität, die in der Kette von System A bis D genutzt wird, beschränkt sich jetzt auf die Auftragsabwicklung. Allerdings benötigt System A nun einen Informationsdienst, der es ihm ermöglicht, über bestimmte Eigenschaften der an System B übermittelten Bestellung zu entscheiden:
- Details der gelieferten Produkte, die in System B und C vorhanden sind (und auch in das DWH eingespeist werden)
- Geschäftsregeln, die nur in System C bekannt sind
- Geschäftsregeln, die nur in System D bekannt sind
Um die Komplexität der bestehenden Situation zu berechnen, habe ich
die im Whitepaper enthaltene Kalkulationstabelle verwendet. Wenn Sie die Anzahl der Geschäftsfunktionen und Verbindungen pro Subsystem in die Tabelle eingeben, kommen Sie auf 157 SCUs (Standard Complexity Units, siehe
Whitepaper für Details). Das bedeutet noch nicht viel, aber sobald wir die Berechnungen für die Alternativen durchgeführt haben, werden wir den relativen Anstieg der Komplexität erkennen können. Die Berechnungen für die bestehende Situation und die drei 3 Alternativen finden Sie in
dieser Tabelle.
Wie wollen wir diesen Informationsdienst realisieren? Wie gesagt, es wurden drei Alternativen auf den Tisch gelegt. Ich werde jede von ihnen und ihre relative Komplexität anhand der Berechnungen von Roger Sessions beschreiben.
[caption id="attachment_7361" align="alignright" width="209" caption="EAI coordination, no DWH"]
[/caption]
In dieser Alternative wird ein zusammengesetzter EAI-Dienst erstellt, der von System A aufgerufen wird und anschließend die erforderlichen Details von System B erhält, dann System C auffordert, diese anzureichern und seine Geschäftsregeln anzuwenden und schließlich System D auffordert, seine Geschäftsregeln anzuwenden. Danach ist er in der Lage, die Antwort an System A zurückzuschicken.
Wenn Sie die Anzahl der Geschäftsfunktionen und Verbindungen pro Subsystem in die
Kalkulationstabelle eingeben, kommen Sie auf 422 SCUs. Wenn Sie also eine neue Komponente und 4 neue Verbindungen hinzufügen, verdreifacht sich die Komplexität fast!
[caption id="attachment_7369" align="alignright" width="214" caption="EAI Coordination with DWH"]
[/caption]
In dieser Alternative wird ein zusammengesetzter EAI-Dienst erstellt, der von System A aufgerufen wird und anschließend die erforderlichen Details vom DWH (statt von System B) erhält, dann System C auffordert, diese anzureichern und seine Geschäftsregeln anzuwenden, und schließlich System D auffordert, seine Geschäftsregeln anzuwenden. Danach ist es in der Lage, die Antwort an System A zurückzusenden.
Wenn Sie die Anzahl der Geschäftsfunktionen und Verbindungen pro Subsystem in die
Kalkulationstabelle eingeben, kommen Sie auf 408 SCUs. Das ist also besser als Alternative 1 und die geringere Komplexität ist hauptsächlich darauf zurückzuführen, dass System B jetzt nur noch 2 Geschäftsfunktionen hat.
[caption id="attachment_7377" align="alignright" width="173" caption="Down the chain"]
[/caption]
Bei dieser Alternative gibt es keinen zusammengesetzten EAI-Dienst, der die Orchestrierung vornimmt, sondern die Anfrage wird wie bei normalen Aufträgen die Erfüllungskette (einschließlich EAI-Adapter) hinuntergeschoben. Jedes System und jeder EAI-Adapter stellt einen neuen Dienst zur Verfügung. Sobald System D das Ergebnis erstellt hat, durchläuft es die Kette durch alle Systeme, bevor es an System A weitergegeben wird. Auf den ersten Blick scheint dies eine gute Lösung zu sein, da ein ähnliches Muster wie bei der Auftragsabwicklung verwendet wird, aber jedes System/jeder EAI-Adapter hat jetzt eine zusätzliche Geschäftsfunktion und zusätzliche Verbindungen.
Wenn Sie mit der
Kalkulationstabelle nachrechnen, kommen Sie auf 715 SCUs. Dies ist also die komplexeste der drei Alternativen.
Fazit
Für welche Alternative haben wir uns entschieden, bevor wir gerechnet haben? Wir haben uns für Alternative 2 entschieden und da diese die geringste Komplexität aufweist, haben wir die richtige Wahl getroffen. Wir hätten jedoch viel schneller zu dem Ergebnis kommen können, wenn einer von uns die Berechnungen vor dem Treffen durchgeführt hätte. Und außerdem hätten wir eine "formale" Argumentation, warum diese Alternative die beste ist. Ich verwende diesen Ansatz jetzt häufiger. Was sind Ihre Erfahrungen, wenn Sie diesen Ansatz verwendet haben?
