Die Integration von Systemen ist eine soziale Kompetenz

Zusammenfassung Systemintegration innerhalb eines begrenzten Zeitrahmens ist nicht in erster Linie eine technische Kunst. Sie ist eine Frage der sozialen und organisatorischen Fähigkeiten. Arbeiten Sie an der gefühlvollen Seite, und die Technik wird folgen. "Wenn Sie die oben genannten Faktoren nicht gut in den Griff bekommen, wird es Sie sowieso erwischen, egal wie cool, flexibel, modern und großartig Ihre Technologie auch sein mag. Einführung Bei fast jedem Softwareprojekt, das in einem großen Unternehmen durchgeführt wird, müssen wir andere Systeme integrieren. Wenn ein Team ein solches Softwareentwicklungsprojekt in Angriff nimmt, neigen Entwickler und Projektleiter oft dazu, sich auf die Aufgaben zu konzentrieren, die zur Erstellung der Software auf ihrer eigenen Seite erledigt werden müssen, und Scoping-Erklärungen und Haftungsausschlüsse zu verfassen, um sicherzustellen, dass sie nicht mit den Integrationsrisiken belästigt werden. Vor allem dann, wenn das andere System keine geeigneten Schnittstellen zur Verfügung stellt, die Sie nutzen können, und "sie" neue bauen müssen, wird die Beziehung zu dem anderen System in Verträgen auf Distanz gehalten. Verständlich, denn in unseren Projekten können wir offensichtlich nicht die Verantwortung für Arbeiten außerhalb unseres Einflussbereichs übernehmen. Dennoch. Wenn wir wollen, dass unser Projekt wirklich erfolgreich ist, können wir es nicht bei "sie müssen ihr Ding machen, und sie müssen pünktlich liefern" belassen. Wenn sie das nicht tun, kann unser Projekt scheitern, aber es wird nicht unsere Schuld sein!" Nein, das ist nicht gut. Auf diese Weise liefern Sie dem Kunden keinen Mehrwert, sondern halten sich nur den Rücken frei. Bequem, aber keine herausragende Handwerkskunst. Schätzungen Nehmen wir an, Sie möchten wirklich sicherstellen, dass das System, das Sie schreiben, mit allen notwendigen Beteiligten korrekt interagieren kann. Viele Projekte scheitern, weil die zeitlichen Auswirkungen der Interaktion ernsthaft unterschätzt werden. Die Interaktion kann einen enormen Einfluss auf die geschätzte Gesamtprojektzeit haben. Überlegen Sie, was alles arrangiert werden muss:

• Sie müssen mit der anderen Partei kommunizieren und eine Schnittstelle zwischen den Systemen definieren.
• Sie müssen ihren Teil der Schnittstelle selbst erstellen.
• Sie müssen ihr System ausschalten, um Ihre Tests durchführen zu können, solange sie noch nichts haben, mit dem Sie sprechen können.
• Es wird unerwartete Änderungen an der Benutzeroberfläche geben. (Nein, sagen Sie nicht, dass Sie das Design einfach fertigstellen können und damit fertig sind: Es wird IMMER unerwartete Änderungen an der Benutzeroberfläche geben.)
• Sie müssen eine Integrationstestumgebung gemeinsam nutzen. Stubbing ist gut, aber nur bis zu einem gewissen Punkt.
• In der Integrationsumgebung benötigen Sie "konditionierte" Testdaten, die für beide Systeme sinnvoll sind. Wenn Ihr "anderes System" schon eine Weile im Einsatz ist, wird es wahrscheinlich einen vordefinierten Satz von Testfalldaten in seiner Datenbank haben, der natürlich nicht mit Ihren eigenen Testfalldaten übereinstimmt. Sie müssen also für neue, gemeinsame Testdaten sorgen, die sowohl für Sie als auch für das andere System sinnvoll sind.
• Sie benötigen Zugang zu seinem Testsystem. Wenn Sie wirklich Glück haben, verfügt der Kunde über eine integrierte Umgebung für Abnahmetests mit einer produktionsähnlichen Netzwerkinfrastruktur, vielen angeschlossenen Systemen und aufbereiteten Datensätzen. Unwahrscheinlich. Äußerst unwahrscheinlich. Sie müssen also den Zugriff auf die Testumgebung arrangieren, die möglicherweise mehrere Schritte entfernt ist. Einige Unternehmen schirmen ihre Umgebungen durch Subnetze ab: Verschaffen Sie sich Zugang über die Router oder versuchen Sie, einen eigenen Rechner in die Testdomäne zu bekommen: Oft sind das verfahrensintensive Aktivitäten.
• Zum Zeitpunkt der Integration wird man Ihre vereinbarten Spezifikationen anders interpretiert haben (Groß-/Kleinschreibung, long statt int, leicht abweichender Verschlüsselungs- oder Komprimierungsalgorithmus, usw.) und Sie müssen beide Teile dessen, was Sie geschrieben hatten, neu implementieren.

All dies gilt also für ein einziges System. Denken Sie daran, was passiert, wenn Sie drei oder vier Systeme integrieren müssen, vor allem, wenn die Daten zwischen diesen Systemen hin und her gehen. Für einen gültigen End-to-End-Roundtrip müssen Sie alle oben genannten Punkte für alle fraglichen Systeme berücksichtigen. Multiplikation, eher als Addition Wenn Sie dies extrapolieren, ist es nicht unrealistisch, mit einem fast exponentiellen Faktor auf die gesamte Dauer Ihres Projekts zu rechnen. Und ich spreche hier nicht von der "reinen Entwicklungszeit", nein, ich meine die Zeit, die benötigt wird, um vom Projektstart zur tatsächlichen Produktion zu gelangen. Ich habe oft Schätzungen gesehen wie "xxx Wochen, plus eine zusätzliche Iteration für jedes System". Das trifft nur zu, wenn diese Systeme nicht miteinander verbunden sind und wenn alle konditionierten Daten und Integrationsumgebungen vorhanden sind, wenn Sie alle Systeme von Ihrem Entwicklungsstandort aus erreichen können UND wenn alle mit der Welt im Reinen sind. Nochmals: unwahrscheinlich. Stellen Sie sicher, dass Sie gleich zu Beginn des Projekts DTAP-Umgebungen (Dev, Test, Accept, Production) anfordern, dasselbe gilt für den (Netzwerk-)Zugang usw. usw. Der Rat lautet also: HÖREN SIE ZU! Multiplizieren Sie lieber, als zu addieren! Sie sind vielleicht nicht so flexibel wie Sie selbst! Agiler Ansatz Wenn wir nun in einer agilen Welt leben würden, wären die Chancen etwas optimistischer. Sie werden auf einer frühzeitigen Integration bestehen, und man wird sich nicht dagegen sträuben, besser noch, man wird mit Begeisterung dabei sein. Sie werden nach und nach gemeinsam an einer coolen Schnittstelle arbeiten, die bei Bedarf immer wieder geändert wird, um zur effizientesten, offenen Lösung zu gelangen. Testdaten werden gemeinsam erstellt, Sie werden voneinander lernen, und wenn einer der Beteiligten ein Problem hat und etwas hinterherhinkt, bieten Sie ihm an, ihm einen Ihrer Experten für genau sein Problemfeld zu leihen, der zufällig auch an dem Projekt beteiligt ist. Seufz. Liebe und Verständnis. Erfolg. Gewinn. Glückliche Kunden. Glückseligkeit. Warum nicht Hm. Wenn das Unternehmen, in dem Sie Ihr Projekt durchführen, groß genug ist, ist dieses Arcadia ein seltener Fund. Die Atmosphäre unter den Entwicklern in traditionellen Unternehmen kann manchmal von Angst und Abscheu geprägt sein.

• Angst, als Entwickler nicht so gut zu sein wie Ihr Konkurrent
• Angst, für Fehler bestraft zu werden
• Abscheu, als Handwerker nicht ernst genommen zu werden
• Abscheu, nicht glänzen und etwas bewirken zu dürfen

Das ist natürlich keine gute Grundlage für eine Zusammenarbeit. Da dies aber leider keine Seltenheit ist, sollten Sie besser einen Weg finden, damit umzugehen. So schwierig es auch ist, strukturelle Änderungen vorzunehmen, Sie können dennoch etwas tun, um Ihre Chancen auf eine erfolgreiche Integration zu verbessern. Soziale Kontakte Stellen Sie sicher, dass Sie sich mindestens einmal persönlich mit den Entwicklern des anderen Systems, den Projektleitern und allen anderen Beteiligten getroffen haben. Wenn Sie sich auf der anderen Seite des Ozeans befinden, nutzen Sie Videokonferenzen, wenn es sein muss, auch mit einer noch so miserablen Webkamera. (Keine Ausreden wie "wir haben keinen Raum für Videokonferenzen"). Verwenden Sie Direct Messaging oder Ic zur Kommunikation. Wenn das Unternehmen ein Streaming-Protokoll durch die Firewall nicht zulässt, können Sie natürlich nicht viel tun. Aber in diesem Fall schicken Sie Ihr Foto zusammen mit Ihren E-Mail-Nachrichten. Glauben Sie mir, schon das Wissen, wie Ihr Gegenüber aussieht, kann einen gewaltigen Unterschied machen. Wir sitzen im selben Boot Versuchen Sie, eine Atmosphäre des gegenseitigen Interesses zu schaffen. Es wird wahrscheinlich ein Gefühl der Zusammengehörigkeit um ein System herum geben, ein "Drei Musketiere"-Gefühl in der Entwicklergruppe. Das ist großartig, denn es verbessert den Zusammenhalt des Teams und damit auch den Spaß und die Produktivität. Sie, als Außenstehender, wollen etwas von ihnen, Sie wollen in ihr System eindringen und Sie werden Einfluss auf ihre ursprünglichen Pläne nehmen. Böser Außenseiter! Was Sie also tun wollen, ist, das zu überwinden und zu versuchen, Komplizen zu werden, sie dazu zu bringen, zu erkennen, dass wir für einen Geschäftsprozess arbeiten, der Ihre Integration braucht. "Wir werden dafür sorgen, dass dieser Geschäftsprozess funktioniert, Leute, das ist doch toll, oder? Selbst in traditionellen Entwicklungsumgebungen können Sie einen enormen Vorsprung gewinnen, wenn Sie für diese Art von Beziehungsmanagement sensibel sind. Wenn es mehr als ein System gibt, das Sie integrieren müssen, versuchen Sie, das gleiche Gefühl der Zusammengehörigkeit zwischen allen Systemen zu erzeugen. Versammeln Sie die Teams oder zumindest die Teammitglieder, mit denen Sie zusammenarbeiten werden, und veranstalten Sie irgendwo ein integriertes Treffen und eine Begrüßung. Wenn die Politik überwiegt, halten Sie die Sitzung auf "neutralem Boden" ab, zum Beispiel in einem Café. Zögern Sie keine Sekunde, für alle Getränke und das Essen an der Bar zu bezahlen. Die Kosten dafür sind absolut vernachlässigbar im Vergleich zu dem enormen Gewinn, den Sie in Bezug auf die Risikominderung haben werden. Infrastruktur Eine besondere Bemerkung zur Infrastruktur. Es kann große Unterschiede darin geben, wie gut die Infrastrukturgruppen organisiert sind. In einigen Organisationen reicht ein einfaches Antragsformular für eine Infrastrukturressource aus, um eine gut funktionierende [Maschine/Router/Datenbankzugriff/...] zu erhalten, lange bevor Sie sie dringend benötigen. In anderen Fällen hingegen müssen Sie um jeden Zentimeter UTP kämpfen. Wenn Letzteres der Fall ist, gehen Sie auf die Infra-Gruppen zu, wie Sie auf das andere System zugehen würden: Versuchen Sie, sie zu Ihren Freunden und Verbündeten zu machen. Zwingen Sie sie nicht Es ist nicht schlimm, wenn Sie sich nicht über die endgültige Schnittstelle einig sind. Geben Sie ihnen das Gefühl, dass sie die Nase vorn haben. Auch wenn Sie vielleicht denken, dass die Entwickler von The Other Systems nicht die Größten sind, wissen sie doch viel mehr über ihr System als Sie selbst. Sie müssen nicht alle mögliche Brillanz aus dem Design herausquetschen. Wenn es gut funktioniert, ist es in Ordnung, solange Sie es schaffen, ihnen das Gefühl von Verantwortung und Autorität zu vermitteln. Erinnern Sie sich an die Angst und Abscheu: Wenn Sie ihnen das Gefühl geben können, dass sie die Führung haben und ernst genommen werden, werden sie dankbar für die Gelegenheit sein. Technologie "Hey, wann fangen Sie denn an, über die Technologie zu sprechen? Soap, Webservices, Corba, RMI, OSF/DCE, Vanilla XML über http, was sollen wir verwenden, synchron, asynchron, was?" werden Sie fragen. Meine Antwort lautet: All das ist trivial. Wenn Sie die oben genannten Faktoren nicht gut in den Griff bekommen, wird es Sie sowieso erwischen, egal wie cool, flexibel, modern und großartig Ihre Technologie ist.