Microservices und Organisationsstruktur. Welche Arten von Teams werden den Erfolg sicherstellen?

Wenn wir über Microservice-Architektur sprechen, gibt es vor unseren Augen eine Reihe von autonomen, fast voneinander unabhängigen Komponenten. Die Isolierung ist der Eckpfeiler eines jeden Mikroservicesystems. Aber selbst wenn wir zuversichtlich sind, Mikrodienste zu schaffen, stellt sich die Frage, inwieweit die Organisationsstruktur für eine solche Aufgabe bereit ist. Können wir die Chancen und Grenzen von Microservices nutzen? Wie können Teams angepasst werden, um mit dieser Architektur erfolgreich zu arbeiten? In diesem Artikel werden wir versuchen, den organisatorischen Aspekt der Entwicklung eines Mikroservice-Systems zu diskutieren.

Traditioneller Ansatz

Große Wirtschaftsunternehmen wurden in der Vergangenheit als eine Reihe von Funktionseinheiten organisiert: Finanzen, Marketing, Betrieb, Personalwesen und so weiter. Die Notwendigkeit der digitalen Automatisierung von Geschäftsprozessen hat das Unternehmen veranlasst, eine weitere funktionale Einheit zu bilden - die IT-Abteilung. In der Folge wurde die IT-Abteilung wiederum in Funktionsteams aus Programmierern, Testern und Systemadministratoren aufgeteilt - nach dem Prinzip, Gruppen von Spezialisten mit bestimmten Kenntnissen und Funktionen zu kombinieren. Das Muster des organisatorischen Denkens ist ganz klar zu erkennen. Und seine Stabilität hängt nicht so sehr mit der Zurückhaltung bei der Analyse der Wirksamkeit des Managements zusammen, sondern mit der großen Trägheit der Prozesse und dem Fehlen offensichtlicher Herausforderungen, die den Erfolg des Unternehmens gefährden würden.

Die Trennung der Mitarbeiter nach ihren Funktionen schafft jedoch zwangsläufig eine Distanz zwischen den Teams. Wenn Softwaretests von einem separaten Testerteam durchgeführt werden, konzentrieren sich die Entwickler ausschließlich auf das Schreiben von Code und kümmern sich wenig um dessen Testbarkeit. Infolgedessen weist das Softwareprodukt zahlreiche Abweichungen bei den Spezifikationen auf, und noch schlimmer, Teams werden allmählich zu getrennten Teams.

Hinweis: Eine Silo-Mentalität ist eine Zurückhaltung beim Teilen.
Informationen mit Mitarbeitern anderer Abteilungen derselben Organisation. So
Verhalten führt oft zu einer Abnahme der organisatorischen Wirksamkeit und im schlimmsten Fall
Fall führt zur Zerstörung der Unternehmenskultur.

Darüber hinaus verlangsamt sich der Entscheidungsprozess in rein funktionalen Einheiten unweigerlich. Die Kosten für die Koordination von Teamarbeitsplänen steigen. So müssen beispielsweise die Qualifikationen und Erfahrungen der gleichen Tester unter Berücksichtigung der von den Entwicklungsteams geforderten Besonderheiten ständig ausgewogen werden. Ja, und eine hohe Eintrittsschwelle und die Notwendigkeit des Wissenstransfers verlangsamen den Prozess: Externe Experten müssen den Aufgabenkontext ständig wechseln, um Anfragen von verschiedenen Teams zu bearbeiten.
Als Unternehmen mit einer traditionellen Organisationsstruktur die Notwendigkeit hatten, auf Herausforderungen, die ständig aus dem Geschäft resultieren, fast augenblicklich zu reagieren, waren ihre IT-Abteilungen nicht in der Lage, die Effektivität der Lösungen sicherzustellen. Die rasante technologische Entwicklung hat diese Verzögerung nur noch verstärkt und die Aufgabe erschwert, das erforderliche Maß an Motivation und Professionalität in engagierten Teams aufrechtzuerhalten, die der Entwicklung dienen. Und da die Hauptaufgabe der IT darin bestand und besteht, den gesamten Lebenszyklus eigenständiger Produkte (einschließlich Mikrodienstleistungen) effektiv zu gewährleisten, wurde die Notwendigkeit offensichtlich, Teams von horizontal ausgerichteten funktionalen zu vertikal ausgerichteten, autarken und autonomen Teams umzustrukturieren.

Funktionsübergreifende Befehle

Ein funktionsübergreifendes Team ist laut Wikipedia eine Gruppe von Menschen mit verschiedenen funktionalen Aufgaben, die auf ein gemeinsames Ziel hinarbeiten. Innovation ist heute ein führender Wettbewerbsvorteil. Übergreifende Teams fördern Innovation durch kreative Zusammenarbeit - sowohl innerhalb des Teams als auch mit anderen Teams in der Organisation.


Abbildung 1. Funktionale und funktionsübergreifende Teams.

Das funktionsübergreifende Mikroservice-Entwicklungsteam besteht aus Entwicklern, Datenbankingenieuren, Testern, Infrastrukturingenieuren und anderen Spezialisten. Solche Teams nehmen Änderungen schneller vor als funktionale, da sie ihre eigenen Entscheidungen treffen und unabhängig von anderen Teams arbeiten können. Durch den Fokus auf die Verbesserung der Entwicklungszykluszeit und die Implementierung einer kontinuierlichen Bereitstellung können diese Teams Probleme fast sofort lösen.

Shamim Mohammad, IT-Direktor von CarMax, sagt: „In einer sich schnell entwickelnden Welt ist es wichtig, flexible, funktionsübergreifende Produktteams zu schaffen, die schnell Lösungen für ein Problem finden können. Sie sind mit allen erforderlichen Befugnissen ausgestattet, und die Geschäftsführung gibt ihnen nie an, wie sie das Problem lösen sollen, sondern nur, woraus es besteht und welche Leistungsindikatoren für die Arbeit maßgeblich sind. Dieser Ansatz ermöglicht es Ihnen, das Feedback zu verbessern, den Entwicklungsprozess erheblich zu beschleunigen und mithilfe von Trial & Error die beste Lösung für Kunden und Partner zu finden. Wir stellten auch fest, dass Teams bei der Erreichung ihrer Ziele risikoreicher und kreativer sind. Wenn Sie nicht über solche vollständig integrierten Teams verfügen, schauen Sie sich diese an und überlegen Sie, ob Sie für eine erfolgreiche digitale Transformation bereit sind. "

Umfragen des Massachusetts Institute of Technology und des Deloitte Global Human Capital Trend zufolge sind Unternehmen mit einem hohen Digitalisierungsgrad von Prozessen bei der Entwicklung ihrer Innovationen in hohem Maße auf die Anwesenheit funktionsübergreifender Teams angewiesen. 83% der reifen Unternehmen geben zu, funktionsübergreifende Teams einzusetzen. Trotz der gestiegenen operativen Komplexität (zusätzliche Kosten bis zu 16%) erhielten die Unternehmen signifikante Verbesserungen bei den Betriebsindikatoren (bis zu 53%), einen verbesserten Zugang zu Ressourcen und Vermögenswerten (bis zu 37%), eine größere Flexibilität (bis zu 12%) und einen Rückgang der übermäßigen Bürokratie aufgrund der Reduzierung der Hierarchie der Organisationsstruktur (bis zu 11%).


Abbildung 2. Vorteile der Anpassung funktionsübergreifender Teams. Statistik.

Ein reibungsloser und schrittweiser Übergang von funktionalen zu funktionsübergreifenden Teams ist durchaus möglich. Die ersten funktionsübergreifenden Teams bilden sich aus den wertvollsten Geschäftsmöglichkeiten, die ständige Aufmerksamkeit und schnelle Reaktion der IT erfordern. Mitglieder von Funktionsteams werden zu funktionsübergreifenden Teams, vertiefen ihre Erfahrungen und verbessern im Allgemeinen die Teamautonomie und den Entscheidungsprozess. Irgendwann werden die Funktionsbefehle vollständig in funktionsübergreifende Befehle umgewandelt.


Abbildung 3. Übergang zu einem funktionsübergreifenden Team.

Die Entstehung von Plattformteams

Die bloße Anwesenheit funktionsübergreifender Teams bedeutet jedoch nicht, dass wir die besten Voraussetzungen für die Schaffung von Mikrodiensten geschaffen haben und die Anforderungen des Geschäfts am effektivsten erfüllen. Es gibt noch eine Reihe von Aufgaben im Zusammenhang mit der Entwicklung, dem Support und der Wartung, von denen die wichtigsten folgende sind:

• Synchronisation (Konsistenz) von Daten;
• Daten veraltet
• Sicherheit;
• Interservice-Kommunikation;
• Service-Entdeckung;
• Verteilte Protokollierung und Überwachung;
• Zyklische Abhängigkeiten zwischen Diensten und Debugging;
• Testen;
• Zuverlässigkeit und Fehlertoleranz;
• Leistung.

Die meisten von ihnen sind keine lokalen Aufgaben eines bestimmten Mikrodienstes. Dies sind die Aufgaben der gesamten Systemebene und beziehen sich eher auf die Infrastruktur des Microservice-Systems. Viele Organisationen bezeichnen diese Infrastruktur als "Plattform", auf der Mikrodienste erstellt und entwickelt werden.

Tatsächlich steigt mit dem Wachstum der Organisation die Abhängigkeit von den verwendeten Technologien. Es treten immer häufiger mehrere Inkonsistenzbereiche auf, was dazu führt, dass das Unternehmen nicht mehr in der Lage ist, schnell auf dem Markt voranzukommen, sich bietende Chancen zu bewerten und Innovationen zu entwickeln. Ein möglicher Ausweg aus dieser Situation ist der Übergang zur Nutzung einer „digitalen Plattform“, die aus „Opportunity-Blöcken“ in den wichtigsten Tätigkeitsbereichen des Unternehmens besteht (z. B. Infrastruktur für die Bereitstellung von Lösungen oder die Interaktion mit dem Kunden). Digitale Plattformen verringern die Kluft zwischen Konzepten und Investitionen. Verbesserung der Systemstabilität und vor allem des Mikroklimas innerhalb der Organisation.

Viele IT-Organisationen fragen sich: Wie viele Mitarbeiter müssen zugewiesen werden, um direkt am "Produkt" und auf der "Plattform" zu arbeiten? Eines der wichtigsten Argumente für eine solche Personentrennung ist Folgendes: Eine digitale Plattform benötigt Eigentümer, die sich für die Einhaltung der von der Plattform festgelegten Grundsätze einsetzen, über umfangreiche Erfahrung und ein hohes Maß an Fachwissen bei der Entwicklung, Implementierung und Wartung von Plattformen verfügen.

Um die Notwendigkeit der Einführung digitaler Plattformen als eigenständiges Produkt zu veranschaulichen, wenden wir uns einem der Grundprinzipien von Microservices zu: der Verwendung intelligenter Filter und einfacher Kanäle.

Egal wie einfach der Kanal ist, es wird immer noch ein Besitzer benötigt. Und wenn es viele Teams gibt, von denen jedes „seinen eigenen Microservice“ besitzt, wer ist dann für ihre Interaktion verantwortlich? Für die Entdeckung von Diensten, für die Sicherheit, die Überwachung auf der Ebene des gesamten Systems (oder sogar auf der Ebene der Organisation, wenn es um die systemübergreifende Ebene geht)? Wer wird für umfassende Tests verantwortlich sein? Wenn wir anfangen, diese Verantwortlichkeiten bestimmten Mikroservice-Entwicklungsteams zuzuweisen, welche Strategie und Auswahlkriterien werden wir anwenden? Und schließlich, bleiben solche Teams (Entwicklung, daran erinnere ich Sie) in ihren Produkten flexibel und autonom? Es scheint, dass die Zeit gekommen ist, in der das Plattformentwicklungsteam auf der Bühne erscheinen sollte!

Das Platform Development Team (kurz Platform Team) ist ein spezialisiertes funktionsübergreifendes Team, das die digitale Plattform verwaltet - die Grundlage für die Bildung von APIs, Tools und Services, deren Wissen und Support in einem unabhängigen internen Produkt organisiert sind.

Die Strategie für digitale Plattformen konzentriert sich auf die Bereitstellung von Geschäftswert. Um Inkonsistenzen beim Aufbau eines Mikroservice-Ökosystems zu beseitigen, konzentriert sich die Strategie auf fünf Hauptbereiche der Bereitstellung von technologischen Lösungen:

• Lieferinfrastruktur;
• API-Architektur und Fehlerbehebung;
• Self-Service-Daten;
• Experimentelle Infrastruktur und Telemetrie;
• Interaktion mit dem Kunden.

Abbildung 4: Strategie für digitale Plattformen

Eigenständige Microservice-Teams erhalten die Möglichkeit, die Plattform zu nutzen, um den Support für die Funktionen ihrer Produkte zu beschleunigen und gleichzeitig den Grad der erforderlichen teamübergreifenden Koordination zu verringern.

Zweifellos hat das Konzept dedizierter spezialisierter Plattformteams sowohl Vor- als auch Nachteile:

Die Vorteile umfassen:

• Vereinheitlichung und Reihenfolge der Kommunikationskanäle;
• Kontrolle bei gleichzeitiger Wahrung der Flexibilität der einzelnen Entwicklungsteams.

Die Nachteile sind:

• Zeitaufwand zur Anpassung der Strategie in der Organisation;
• Bedarf an zusätzlichen Ressourcen - Das Plattformteam muss die Besonderheiten der verschiedenen Mikroservice-Teams sowie die Formulare für die Erstellung einer einheitlichen Plattform untersuchen.
• Wenn die Plattform nicht ordnungsgemäß implementiert wird, wird dies zu einem Engpass in den Prozessen des Unternehmens.

Daher müssen wir mögliche Probleme und Risiken bei der Planung von team- und teamübergreifenden Aktivitäten innerhalb der Organisation berücksichtigen.

Synergie der Interaktion

Wie kann eine Interaktion mit dem Plattformteam stattfinden? Es gibt mehrere mögliche Ansätze, zwischen denen zwei unterschieden werden können:

• Nutzung der Plattform als Produkt. Das Plattformteam aktualisiert regelmäßig die Plattformversionen und stellt sie den Microservice-Teams als Produkt-API zur Verfügung. Dies kann ein Image einer virtuellen Maschine oder ein Container mit verbesserten (im Vergleich zur vorherigen Version) Funktionen oder ein erweiterbares Framework sein.
• Penetration in Microservice-Teams, wenn ein Vertreter des Plattformteams im Microservice-Team anwesend ist (oder eines der Mitglieder des Microservice-Teams für die Kommunikation mit dem Plattformteam zugewiesen ist). Bei Verwendung dieses Ansatzes haben Mikroserviceteams die Möglichkeit, schnelleres Feedback mit dem Plattformteam zu erhalten und Änderungen an der Plattform vorzunehmen.

Abbildung 5: Interaktion mit dem Plattformentwicklungsteam: Links die Plattform als Produkt, rechts das Eindringen in die Teams.

Fazit

Abschließend möchte ich noch einmal betonen, dass die Organisationsstruktur es ermöglichen sollte, die Vorteile der architektonischen und technologischen Wahl wirksam zu nutzen. Das Gesetz von Conway besagt, dass eine Organisation versucht, Projekte zu erstellen, die Kopien der Organisationsstruktur sind. Ich bin aber auch geneigt zu glauben, dass das Gegenteil der Fall ist: Die Struktur des Systems sagt der Organisation, welche Struktur für die Implementierung am besten geeignet ist.

Um die erforderliche Reaktionsqualität auf Geschäftsanforderungen zu gewährleisten, muss die moderne IT-Branche über ein Höchstmaß an organisatorischer Flexibilität verfügen. Um die Wirksamkeit des Systems, das wir schaffen wollen, nicht zu verlieren, müssen wir die Notwendigkeit und die Möglichkeit organisatorischer Veränderungen berücksichtigen.