Wie Architektur hervorragende Teams ermöglicht (1): Replikation als schädlich?

Bei Xebia führen wir regelmäßig Diskussionen über Agile Architektur? Was ist das? Was braucht man dafür? Wie sollten Sie das organisieren? Ist es technisch oder organisatorisch? Und viele weitere Fragen... die ich heute nicht beantworten werde, denn wir haben bereits in anderen Blogs über Architektur, ihre Auswirkungen auf SEO und Links gesprochen. Was ich heute tun werde, ist der Auftakt zu einer Blogserie, die sich mit Themen befasst, die oft Teil dieser hitzigen Debatten sind. Im Allgemeinen streben wir mit der Agilen Architektur eine Architektur an, die es dem Unternehmen ermöglicht, sich schnell zu bewegen, ohne dass die IT ein limitierender Faktor für die Umsetzung von Veränderungen ist. Wenn Sie diese Serie lesen, werden Sie feststellen, dass ein Thema immer wieder auftaucht: Autonomie. Manchmal konzentrieren wir uns auf die Architektur der Systeme, manchmal auf die Architektur der Organisation oder der Teams, aber Autonomie ist das übergreifende Thema. Und wenn Sie mit dem Conways-Gesetz vertraut sind, dürfte es Sie nicht überraschen, dass es eine starke Korrelation zwischen Team- und Systemstruktur gibt. Eine Teamstruktur, die sich völlig von Ihrer Systemlandschaft unterscheidet, führt zu Reibungen. Wir sind davon überzeugt, dass das Streben nach optimaler Team- und Systemautonomie zu einer Organisation führt, die in der Lage ist, sich schnell anzupassen und auf Veränderungen zu reagieren. Das erste Thema ist die Replikation von Daten, dies ist eher ein Problem der Systeme (Landschaft) und weniger ein organisatorisches Problem und definitiv nicht das einzige.

Wir alle haben mit Situationen zu tun, in denen:

• die Nutzer eines Datenabrufdienstes (z.B. Kundenkontodaten) verlangen, dass dieser Dienst hochverfügbar ist, oder
• rechenintensive Analysen mit den Daten in einem System durchgeführt werden müssen, oder
• Daten, die einem System gehören, müssen auf eine Weise durchsucht werden, die von diesem System nicht (effizient) unterstützt wird

Ist das System in der Lage, die geforderte Funktionalität in der geforderten Qualität zu liefern, oder führen diese externen Anforderungen zu negativen Auswirkungen auf die Qualität der erbrachten Dienstleistung oder die Wartbarkeit? Sollten diese Anforderungen dem System aufgezwungen werden oder ist ein anderer Ansatz angemessener? Die oben genannten Beispiele könnten alle durch eine Replikation der Daten in ein anderes System gelöst werden, das für die Erfüllung dieser Anforderungen besser geeignet ist, aber ... die Replikation von Daten wird von einigen als schädlich angesehen. Ist das wirklich so? Häufig genannte Gründe gegen die Replikation von Daten sind:

• Die replizierten Daten werden immer ungenauer und weniger aktuell sein als die Originaldaten . Ist das wirklich ein Problem für die spezifische Situation, mit der Sie zu tun haben? Manchmal brauchen Sie wirklich die neueste Version eines Kundendatensatzes, aber in vielen Situationen ist es kein Problem, wenn die Daten Sekunden, Minuten oder sogar Stunden alt sind.
• Die Geschäftslogik, die die Daten interpretiert, wird zweimal implementiert und muss gepflegt werden Ja, und Sie müssen die Kosten dafür mit den Vorteilen vergleichen. Solange die Vorteile die Kosten überwiegen, ist es eine gute Wahl. Sie können sogar in Erwägung ziehen, eine Bibliothek bereitzustellen, die in beiden Systemen verwendet wird.
• System X ist die maßgebliche Quelle der Daten und sollte das einzige System sein, das diese Daten freigibt . Die Beibehaltung dieses Systems als maßgebliche Quelle ist eine gute Praxis und bedeutet nicht, dass auf dieselben (replizierten) Daten in anderen Systemen nur lesend zugegriffen werden kann.

Wie Sie sehen, ist es nie eine Schwarz-Weiß-Entscheidung. Sie müssen eine ausgewogene Entscheidung treffen und die Vorteile und Kosten beider Alternativen berücksichtigen. Die gewonnene Autonomie und die daraus resultierenden geschäftlichen Vorteile können die zusätzlichen Entwicklungs-, Hosting- und Wartungskosten für die Replikation von Daten leicht aufwiegen. Ein paar konkrete Beispiele aus meiner eigenen Erfahrung: Wir hatten eine Situation, in der eine CRM-Systeminstanz Daten besaß, die auch in einem 24x7-Notfall-Supportprozess benötigt wurden. Die Daten waren durch eine Reihe von Datenabrufdiensten gut zugänglich. In dieser Organisation war das CRM-System so eingerichtet, dass die meisten Komponenten redundant waren, aber bei Aktualisierungen war das System als Ganzes trotzdem mehrere Stunden lang nicht verfügbar. Das war nicht akzeptabel, da die Daten in einem 24x7-Notfall-Supportprozess benötigt wurden. Ein Upgrade des CRM-Systems ohne Ausfallzeiten war nicht möglich oder würde $$$$ kosten. In dieser Situation waren die Kosten für die Replikation der CRM-Systemdatenbank in ein anderes Rechenzentrum unter Verwendung von Standarddatenbankfunktionen und der Zugriff der Datenabrufdienste entweder auf diese replizierte Datenbank oder auf die ursprüngliche Datenbank (als Fallback) viel billiger als der Versuch, das CRM-System selbst hoch verfügbar zu machen. Die replizierte Datenbank wäre auch dann noch verfügbar, wenn das CRM-System aufgerüstet würde. Ja, wir umgehen die Geschäftslogik des CRM-Systems für die Interpretation der Daten, aber in dieser Situation war die Logik so einfach, dass die Kosten für die Neuimplementierung und Wartung in einem neuen, leichtgewichtigen Dienst (getrennt vom CRM-System) vernachlässigbar waren. Ein weiteres Beispiel stammt von einem Telekommunikationsanbieter, der eine Kette von Fulfillment-Systemen verwendet, in denen er alle an seine Kunden verkauften Netzwerkprodukte registriert (z.B. Internetzugang, Telefonie, Fernsehen). Jede Produktinstanz hängt von Instanzen ab, die in einem anderen System registriert sind, und wenn Sie tief genug eindringen, gelangen Sie zu den physischen Netzwerk-Hardware-Ports, auf denen sie läuft. Die Systeme, die alle Produkte registrierten, verwendeten ein relationales Modell, das für die Registrierung in Ordnung war. Fragen wie "Welche Kunden sind betroffen, wenn diese Produktinstanz ausfällt?" waren jedoch unmöglich zu beantworten, ohne die CPUs in diesen Systemen zu überhitzen. Indem wir alle Änderungen an den Registrierungen in einem separaten System veröffentlichten, konnten wir den gesamten Bestand an Dienstleistungen als Netzwerkdiagramm modellieren und problemlos Analysen durchführen, ohne die Abwicklungssysteme zu beeinträchtigen. Die Tatsache, dass die Daten (höchstens) ein paar Sekunden alt waren, war absolut kein Problem. Und ein letztes Beispiel: Manchmal möchten Sie eine vollständige (phonetische) Textsuche in einer Teilmenge Ihres Domänenmodells durchführen. Relationale Datenmodelle bringen Sie schnell in eine unwartbare Situation. Ihre SQL-Abfragen erfordern viele Tabellen, viele ineffiziente "LIKE '%gold%'" und Entwickler, denen es schwer fällt zu verstehen, was eine Abfrage eigentlich tun soll. Die Replikation der Daten in eine Suchmaschine macht die Suche viel einfacher und bietet mehr Möglichkeiten für Abfragen, die in einer relationalen Datenbank nur schwer zu realisieren sind.Wie Sie sehen, kann die Replikation von Daten die Autonomie von Systemen und Teams erhöhen und dadurch Ihr System oder Ihre Systemlandschaft und Ihre Organisation agiler machen. D.h. Sie können neue Funktionen schneller realisieren und sie Ihren Benutzern schneller zur Verfügung stellen, weil die Kopplung mit anderen Systemen oder Teams reduziert wird. In einem nächsten Blog werden wir ein weiteres Thema behandeln, das sich auf die Autonomie von Teams oder Systemen auswirkt.