Best Practices für große Connectoren

Wir definieren eine große Skalierbarkeit von Connectors als solche, die mehr als 5000 Arbeitspakete in BWX pro Synchronisierungsanfrage erzeugt. Ein Arbeitspaket in BWX besteht aus einer Kombination aus einer Datei, einem Workflow-Schritt und einem Sprachpaar. Ein Projekt mit 5 Dateien, 2 Workflow-Schritten (Übersetzung + Überprüfung) und 5 Sprachen ergibt also 50 Work Units. Sie können sehen, wie es nicht so schwierig ist, über 5000 Arbeitspakete zu kommen, wenn Sie diese Variablen multiplizieren. Es ist verlockend, alles in einem einzigen Projekt zu zentralisieren, aber unsere Erfahrung zeigt, dass bei groß angelegten Connectors die Gruppierung von Projekten nach Sprachpaar die beste Vorgehensweise ist. Dies mag einfach eine Frage sein, wie Sie ein Projekt definieren, aber es geht viel tiefer als das. In diesem Artikel werden wir die Auswirkungen dieser Entscheidung in Bezug auf:

1. Nachrichtenvermittlung
2. Problembehebung
3. Risikominderung
4. Warteschlangen/Leistung
5. Automatisierungspotenzial
6. Verwaltungserleichterung
7. Skalierbarkeit

Nachrichtenvermittlung1) Die Messaging wächst exponentiell mit großen Connectors. Wir haben Connectors gesehen, die über 1 Million Nachrichten pro Synchronisierungsanfrage erstellen. Dies führt zu enormer Serveraktivität und Leistungsproblemen, die durch die Aufteilung von Projekten pro Sprachraum gemildert werden können.Problemlösung2) Dies steht in direktem Zusammenhang mit der Risikominderung. Aber bei der Lokalisierung sehen wir oft Probleme, die auf einen bestimmten Sprachraum beschränkt sind und wie sich dies auf das Parsen, die Segmentierung und die Vor-/Nachverarbeitung einer bestimmten Dateisammlung auswirkt. Durch die Aufteilung nach Sprachräumen können sprachspezifische reguläre Ausdrücke, Verarbeitungsregeln und Segmentierung erstellt werden, die hinsichtlich der Gesamtarchitektur wesentlich flexibler sind. Anstatt sich auf allgemeingültige Lösungen zu beschränken, können Sie basierend auf der Region iterieren und letztendlich ein reiferes und vorhersehbareres Verhaltensmuster erreichen, wenn Sie nach Regionen arbeiten. Risikominderung: 3) Durch die Aufteilung von Projekten in einzelne Regionen können Sie das Risiko des Managements mindern, da ein Problem in einer bestimmten Region nicht bedeutet, dass der gesamte Pull-Request-/Liefermechanismus beeinträchtigt ist. Sie können Probleme isolieren und natürlich abgrenzen. Das mag während der SOP nicht wichtig erscheinen, aber wenn unerwartete Probleme auftreten (und das tun sie immer bei der Lokalisierung), werden Sie froh sein, ein Haus aus Ziegeln und nicht aus Stroh gebaut zu haben. Warteschlangen/Leistung4) Anstatt beispielsweise 150.000 Elemente zur Verarbeitung aneinanderzureihen, können Sie 10-mal 15.000 Elemente aneinanderreihen. Auch dies mag kein großer Unterschied erscheinen, da Sie letztendlich die gleichen 150.000 Elemente verarbeiten müssen, aber die Flexibilität, seriell, parallel oder opportunistisch nach Bedarf zu verarbeiten, gibt Ihnen so viel mehr Flexibilität sowie Leistungsbreite. Automatisierungspotenzial5) Typischerweise werden Projektentscheidungen und Workflows in den verschiedenen Ländern asymmetrisch sein. Die Trennung von Projekten pro Standort gibt Ihnen langfristig wesentlich mehr Flexibilität in Bezug auf das Automatisierungspotenzial. Sie können Szenarien haben, in denen Sie vollständig unterschiedliche Parameter und Datensätze haben, wenn Sie nach Regionen trennen, im Gegensatz zur Konsolidierung aller Elemente zusammen.Management6) Dieser Punkt ist ebenfalls kontraintuitiv. Aus managementtechnischer Sicht ist die Konsolidierung in der Regel bewährte Praxis für eine bessere Governance. Aber bei groß angelegten Verbindungen ist das Gegenteil der Fall. Ein Projekt filtert natürlicherweise nach Standort, sodass verschiedene Projektmanager leichter verschiedene Teile des Projekts besitzen können. Dies reduziert die Verwendung von Filtern zur Erstellung von Berichten und schafft eine größere Einfachheit bei der Verfolgung dessen, was in jedem Standort passiert. Skalierbarkeit: Mit groß angelegten Verbindungen erreichen Sie einen Punkt, an dem es einfach unverwaltbar wird, alle Arbeitspakete in einem einzigen Projekt zu gruppieren. Durch die Trennung legen Sie das Grundgerüst für ein langfristig leichter skalierbares Programm. Denken Sie daran, dass sich Dinge multiplizieren, wenn es um Arbeitspakete und Nachrichten geht. Durch die Trennung nach Lokalisierungseinstellungen eliminieren Sie eine der großen multiplizierenden Variablen und ermöglichen es Ihnen, viel einfacher zu skalieren. Schlussfolgerung: Es besteht die Illusion, dass Konsolidierung besser ist. Ein Pull-Request pro Projekt erleichtert das Leben aller. Während das für kleine Skalenverbindungen zutrifft, bricht es bei großen Skalenverbindungen zusammen. Eine Pull-Anfrage pro Projekt erleichtert das Leben aller. Während das für kleine Connectoren gilt, funktioniert es bei großen Connectoren nicht mehr. Unser Ziel ist es immer, elegante und zuverlässige Lösungen für unsere Kunden zu liefern, und wir haben immer wieder festgestellt, dass bei großen Projekten die Methode "Teilen und Erobern" der richtige Weg ist. Konsolidierung in einem einzigen ProjektTrennung nach SprachraumDas gesamte Projekt hat einen Status von 0 oder 1Der Status kann nach Sprachraum geschichtet werdenEinzelne Analyse, Filterung und RegEx-FrameworkFlexibles Framework pro SprachraumEinzelne Warteschlange pro ProjektFlexible Warteschlangen und natürliche Verteilung der VerarbeitungFilterung nach Sprachraum innerhalb des ProjektsEin Filterungsschritt wenigerAutomatisierungsregeln, die für alle geltenSprachraumspezifische Automatisierungsparameter und DatenAlle Eier in einem Korb aus RisikosichtRisiko auf verschiedene Sprachräume verteiltKomplex, um isolieren und zu behebenEin riesiger Faktor weniger, was die Fehlerbehebung erleichtert

Konsolidierung in einem einzigen ProjektTrennung nach StandortDas gesamte Projekt hat einen Status von 0 oder 1Der Status kann nach Standorten gestaffelt werdenEinzelne Analyse, Filterung und RegEx-FrameworkFlexibles Framework nach StandortEinzelne Warteschlange pro ProjektFlexible Warteschlangen und natürliche Verteilung der VerarbeitungFilterung nach Standort innerhalb des ProjektsEin weniger FilterungsschrittAutomatisierungsregeln, die für alle geltenStandortspezifische Automatisierungsparameter und DatenAlle Eier in einem Korb aus RisikosichtRisiko auf verschiedene Standorte verteiltKomplex, um isoliert und zu behebenEin weniger großer Variablen, was die Fehlerbehebung erleichtert