Close

Negative Velocity: Erhöhen der Komplexitätsgrenze


Eines der häufigsten Ziele in der Softwareentwicklung: die schnelle Bereitstellung von hochwertiger Software.

Schau dir das Vision Statement deines CIO oder CTO an und höre ihnen zu. Die Chancen stehen gut, dass sie dieses Ziel in einer gewissen Art verfolgen. Während es ein häufiges Ziel ist, reicht das Spektrum von Teams, die es erreichen, bis zu Teams, die ewig mit der Softwarebereitstellung kämpfen. Einige Teams bringen ständig neuen Code in die Produktion, wobei es nur zu wenigen Vorfällen oder negativen Auswirkungen auf die Kunden kommt, während andere schon Probleme mit vierteljährlichen Releases haben.

Was verursacht diesen Leistungsunterschied?


Bei der Softwarebereitstellung macht die Komplexität den Unterschied zwischen einer schnellen Bereitstellung von hochwertiger Software und… dem Gegenteil davon. Sie macht den Unterschied zwischen dem wöchentlichen Klingeln der Siegesglocke nach einem erfolgreichen Release und einem unengagierten Softwareteam, das darüber frustriert ist, dass die monatelange Arbeit am neuesten Release zu sechs neuen Bugs und einem Rollback geführt hat.

Vergleiche die Geschwindigkeit und Qualität der neuen Produkte und Funktionen von Startups mit denen eines etablierten, großen Unternehmens. In der Finanzbranche werden großen, etablierten Banken beispielsweise immer mehr Marktanteile von FinTech-Startups abgerungen. Große Banken nennen oft die unfairen Vorteile von FinTech-Startups, die mit weniger regulatorischer Aufsicht arbeiten und keine traditionellen, monolithischen Anwendungsbestände verwalten müssen. Kleinere Teams bieten mehr Flexibilität und die Möglichkeit, sich an die Kundenbedürfnisse anzupassen. Im Wesentlichen haben FinTech-Startups nicht die Komplexität etablierter Banken, wodurch sie schneller und mit geringerem Risiko agieren können. Doch während sie Softwareteams bremsen kann, ist Komplexität nicht immer eine schlechte Sache.

The benefits of SOA

SOA's modularity and standardized protocols enable services to communicate effectively, promoting reusability, interoperability, and scalability. These key benefits translate into tangible advantages for companies:

  • Reusability: Reusing existing services reduces development time and costs and promotes consistency and quality. Companies can accelerate development cycles and improve overall efficiency.
  • Interoperability: Services can communicate and exchange data regardless of their underlying technology or programming language. This facilitates enterprise-wide data integration and collaboration. Interoperability streamlines business processes and helps companies adapt to evolving technologies.
  • Scalability: SOA's modular design enables independent scaling of services to meet fluctuating demands. It ensures applications can handle spikes in traffic or expanding user bases without compromising performance or stability. Companies can adapt their infrastructure to changing needs without costly rewrites or redesigns.

Globales Netzwerk
Zugehöriges Material

Software unter Kontrolle

Symbol: drei Ringe
Lösung anzeigen

Verwalte deine Komponenten mit Compass

Komplexität bei der Softwarebereitstellung


Komplexität kann eine gute Sache sein: Wenn schwierige Probleme gelöst werden, erzeugt das große Glücksgefühle. Das motiviert Teams, mit der Herausforderung zu wachsen, schwierige Probleme anzugehen und eine Branche auf den Kopf zu stellen. Doch es gibt auch einen Punkt, an dem es bei Komplexität nicht mehr darum geht, ein schwieriges Problem zu lösen, sondern negative Auswirkungen auf Softwareteams entstehen.

Organisatorische Komplexität spielt eine Schlüsselrolle bei einer verringerten Effektivität von Softwareteams. Komplexität lässt sich definieren als ein Zustand, in dem viele verschiedene Teile komplizierte Verbindungen oder Beziehungen zueinander aufweisen. In der Praxis ist organisatorische Komplexität die Summe von Informationen, Abhängigkeiten, Änderungen, anderen Teams, Tools und Anfragen, die Softwareteams berücksichtigen müssen, wenn sie mit der restlichen Organisation zusammenarbeiten.

Höhere organisatorische Komplexität macht es natürlich schwieriger, hochwertige Software schnell bereitzustellen, weil Teams mehr Zeit damit verbringen, sich in der Organisation zurechtzufinden, als schwierige Probleme zu lösen. Wachsende Unternehmen bemerken schnell, dass Softwareteams eine Komplexitätsgrenze erreichen – die Komplexität, die Teams bewältigen können, bevor sie sich auf die Arbeitszufriedenheit sowie die Qualität und Geschwindigkeit der Softwareproduktion auswirkt. Es mag also logisch erscheinen, dass die Verringerung der organisatorischen Komplexität es Teams ermöglicht, sich darauf zu konzentrieren, schwierige Probleme zu lösen und hochwertige Software schneller bereitzustellen. Sehen wir uns an, warum das nicht unbedingt der Fall ist.

Benefits of microservices

Angesichts der Vorteile begannen weitere Teile der Organisation, eine Microservice-Architektur einzuführen, wodurch die organisatorische Komplexität natürlich zunahm. Mehr autonome Teams erforderten mehr Zusammenarbeit, und mehr Microservices bedeuteten mehr Abhängigkeiten. Das Tempo der Veränderungen ging durch die Decke – alle Anzeichen von Software-Sprawl waren zu erkennen. Durch die erhöhte Komplexität stagnierte die Effektivität der Softwareteams, was zu einer verminderten Änderungsgeschwindigkeit führte, und die kognitive Belastung wurde zu einem Problem für die Softwareteams.

Indikatoren der Komplexitätsgrenze


Die Komplexitätsgrenze scheint unausweichlich zu sein, aber es gibt einige Indikatoren dafür, dass sich Teams ihrer Grenze nähern. Ich muss vorwegnehmen, dass es keine absolute Metrik dafür gibt, wie weit die Komplexitätsgrenze entfernt ist, aber diese Indikatoren können dir dabei helfen, deinen Abstand zu ermitteln.

Wenn ein Team mehr Zeit damit verbringt, sich in der organisatorischen Komplexität zurechtzufinden, als schwierige Probleme zu lösen, ist das der deutlichste Indikator dafür, dass es die Komplexitätsgrenze erreicht hat. Die Trends von den Metriken der DORA-Vorlaufzeit für Änderungen (Geschwindigkeit) und der Änderungsfehlerrate (Qualität) zeigen, ob Teams im Laufe der Zeit langsamer oder schneller werden. Auch wenn es noch andere Faktoren gibt, die diese Metriken beeinflussen, sind sie ein guter Indikator für die Effektivität des Teams.

Die Zufriedenheit der Entwickler ist ein weiterer Indikator für das Ausmaß der organisatorischen Komplexität bei den Softwareteams. Entwickler haben eine besonders starke Tendenz dazu, gerne an schwierigen Problemen zu arbeiten und zugleich unnötige Aufgaben zu verabscheuen, die ihnen im Weg stehen. Deshalb ist eine geringe Zufriedenheit der Entwickler ein guter Indikator dafür, dass die organisatorische Komplexität ein Problem für dein Softwareteam ist.

Feature

SOA

Microservices

Architectural style

  • Coarse-grained, centralized

Service granularity

  • Larger, more comprehensive services

  • Smaller, focused services

Independence

  • Services are interdependent
  • May share a database for data storage

  • Services are highly independent
  • Decoupled and autonomous

Communication

  • Synchronous, often message-oriented
  • Uses shared data

  • Asynchronous, often RESTful
  • Avoids data sharing

Data storage

  • Centralized data management
  • Services share database

  • Distributed (decentralized) data management
  • Each service is responsible for its own data management

Scalability

  • Horizontal scaling
  • Scaling specific services can be intricate due to shared resources and centralized communication

  • Horizontal and vertical scaling
  • More granular and focused scaling as services operate independently

Deployment

  • Typically involves deploying the entire application as a single unit

Coupling

  • Services exhibit a degree of coupling due to shared resources and centralized communication

  • Loose coupling with minimal dependencies between services

Indikatoren der Komplexitätsgrenze


Die Komplexitätsgrenze scheint unausweichlich zu sein, aber es gibt einige Indikatoren dafür, dass sich Teams ihrer Grenze nähern. Ich muss vorwegnehmen, dass es keine absolute Metrik dafür gibt, wie weit die Komplexitätsgrenze entfernt ist, aber diese Indikatoren können dir dabei helfen, deinen Abstand zu ermitteln.

Wenn ein Team mehr Zeit damit verbringt, sich in der organisatorischen Komplexität zurechtzufinden, als schwierige Probleme zu lösen, ist das der deutlichste Indikator dafür, dass es die Komplexitätsgrenze erreicht hat. Die Trends von den Metriken der DORA-Vorlaufzeit für Änderungen (Geschwindigkeit) und der Änderungsfehlerrate (Qualität) zeigen, ob Teams im Laufe der Zeit langsamer oder schneller werden. Auch wenn es noch andere Faktoren gibt, die diese Metriken beeinflussen, sind sie ein guter Indikator für die Effektivität des Teams.

Die Zufriedenheit der Entwickler ist ein weiterer Indikator für das Ausmaß der organisatorischen Komplexität bei den Softwareteams. Entwickler haben eine besonders starke Tendenz dazu, gerne an schwierigen Problemen zu arbeiten und zugleich unnötige Aufgaben zu verabscheuen, die ihnen im Weg stehen. Deshalb ist eine geringe Zufriedenheit der Entwickler ein guter Indikator dafür, dass die organisatorische Komplexität ein Problem für dein Softwareteam ist.

Vereinfachung ist die falsche Strategie


Wenn Unternehmen erkennen, dass ihre Teams in der Komplexität versinken, starten sie oft ein "Vereinfachungsprojekt", das die Einfachheit in ihrer Organisation wiederherstellen soll. Vereinfachung ist aus zwei Gründen die falsche Strategie: Die Komplexität nimmt schneller zu, als jede Organisation ihre Umgebung vereinfachen kann, und diese "Vereinfachungsprojekte" werden in genau der komplexen Umgebung ausgeführt, die sie vereinfachen sollen.

Die Vereinfachung beginnt typischerweise damit, dass die Anzahl der Anwendungen reduziert wird, indem sie nach Möglichkeit eingestellt oder konsolidiert werden. Um eine Anwendung einzustellen, muss das Team alle vor- und nachgelagerten Abhängigkeiten verstehen: Wer verwendet die Anwendung? Wie wird ihre Funktion ersetzt? Wo und wie werden die Daten archiviert oder migriert? Und das Team muss sich mit vielen weiteren Komplikationen auseinandersetzen, die damit einhergehen. Leider wird der erforderliche signifikante Aufwand nicht mit einer ebenso signifikanten Reduzierung der Komplexität belohnt. Es gibt eine Grenze für die Anzahl der Anwendungen, die ein Unternehmen ohne Auswirkungen auf das Kerngeschäft oder die Benutzererfahrung einstellen kann, aber es gibt keine Grenze dafür, wie viele neue Softwarekomponenten erstellt werden können. In den 12 Monaten, in denen eine Anwendung eingestellt wurde, wurden wahrscheinlich Hunderte neue Microservices erstellt. Da eine gesunde IT-Umgebung mit der Zeit wächst, ist es nicht sinnvoll, sie auf eine feste Anzahl von Anwendungen oder Softwarekomponenten zu beschränken, um die Komplexität zu reduzieren.

Vereinfachungsprojekte beinhalten in der Regel die Überarbeitung der Organisationsstruktur, um die Komplexität der Kommunikation zu verringern. Die unkompliziertesten Organisationsstrukturen bestehen aus großen hierarchischen Teams, bei denen sich alle Mitarbeiter am gleichen Standort befinden. Die kompliziertesten Organisationsstrukturen bestehen aus kleinen, verteilten und autonomen Teams. Nach dem Gesetz von Conway produzieren große hierarchische Teams wahrscheinlich monolithische Anwendungen, während kleine, verteilte Teams wahrscheinlich Anwendungen mit modularen Architekturen wie Microservices produzieren. Da modulare Architekturmuster wie eine Microservice-Architektur die schnelle Produktion von hochwertiger Software fördern, führt die komplexere Organisationsstruktur mit größerer Wahrscheinlichkeit zum Erfolg. Die "Vereinfachung" kann die Organisationsstruktur zwar übersichtlicher machen, aber sie ist kontraproduktiv für das letztendliche Ziel des Vereinfachungsprojekts.

Vereinfachung ist wichtig und lohnenswert, eignet sich aber am besten als Bestandteil der kontinuierlichen Verbesserung von Softwareteams (und Teams von Teams) und nicht als einmalige Aktivität. Vereinfachung kann das Erreichen der Komplexitätsgrenze verzögern, aber sie wird einer Organisation nicht die agile Freiheit einer Startup-Umgebung verschaffen.

Erhöhen der Komplexitätsgrenze


What are the challenges of adopting SOA and microservices?

Um die Effektivität des Softwareteams wiederherzustellen, müssen Organisationen die Komplexitätsgrenze erhöhen. Und um die Komplexitätsgrenze zu erhöhen, muss das Ausmaß der organisatorischen Komplexität gesteigert werden, die ein Team bewältigen kann, bevor die Arbeitszufriedenheit, Qualität und Geschwindigkeit der Softwareproduktion darunter leiden.

Platform Engineering ist ein wichtiges Konzept für die Erhöhung der Komplexitätsgrenze einer Organisation. Starke Platform-Engineering-Teams reduzieren die kognitive Belastung von Softwareteams, indem sie ihnen die Komplexität der Organisation bei der täglichen Arbeit abnehmen. Wenn Platform Engineering korrekt implementiert wird, wenden die Teams weniger Zeit für die organisatorische Komplexität auf und können sich stattdessen auf das Lösen schwieriger Probleme konzentrieren.

Can SOA and microservices coexist?

Genau deshalb hat Atlassian Compass, eine Developer-Experience-Platform, entwickelt. Compass ermöglicht es, die Komplexitätsgrenze zu erhöhen, indem es Softwareteams erleichtert wird, die organisatorische Komplexität mithilfe des Komponentenkatalogs, der Metriken und Scorecards zu bewältigen und sich auf eine gesunde Entwicklungskultur zu konzentrieren. Der wichtigste Punkt dabei ist, dass die organisatorische Komplexität bei Atlassian nicht abgenommen hat. Sie ist sogar weiter gewachsen, da immer mehr Bestandteile der Organisation auf eine Microservice-Architektur umstiegen sind. Wir haben es den Softwareteams ermöglicht, weniger Zeit für diese Komplexität aufwenden zu müssen, was eben der Unterschied zwischen einem Vereinfachungsprojekt und dem Erhöhen der Komplexitätsgrenze ist.

Atlassian hat über 10.000 Mitarbeiter und über 17.000 Softwarekomponenten, aber seine Softwareteams arbeiten größtenteils mit der Freiheit eines Startups und stellen hochwertige Software schnell bereit. Der Schlüssel zum Erfolg? Das Erhöhen der Komplexitätsgrenze, um die Effektivität der Softwareteams zu verbessern.

Hier sind zwei erste Aktionen, um deine Komplexitätsgrenze zu erhöhen:

  • Verfolge und bewerte deine DORA-Metriken. Wie sehen die DORA-Metriken für dein Team aus? Falls du sie noch nicht verfolgst: Die DORA-Metriken sind bei Compass sofort einsatzbereit.
  • Analysiere und bewerte die Zufriedenheit der Entwickler. Wie geht es den Entwicklern in deinen Softwareteams? Die meisten Organisationen führen Umfragen zur Mitarbeiterzufriedenheit durch. Frag nach den Meinungen, aufgeschlüsselt nach Funktionsbereichen, um einen Einblick in die Zufriedenheit der Entwickler zu erhalten. Zu den wichtigsten Fragen zählen Bewertungen der folgenden Aussagen:
    • Ich bin stolz auf die Bereitstellung
    • Der Stress bei meiner Arbeit ist zu bewältigen
    • Ich verstehe, wie meine Arbeit zu den Unternehmenszielen beiträgt

Alternativ erfasst Compass diese Informationen während des CheckOps-Rituals, bei dem die Teams erklären, wie sie die letzte Woche fanden und was besser gewesen wäre.

Um die Komplexitätsgrenze zu erhöhen, ist eine Kombination aus Tools, Prozessen und Ritualen erforderlich. Eine Developer-Experience-Platform wie Compass kann dir dabei helfen, den Systemzustand zu verstehen, Abhängigkeiten abzubilden und regelmäßige Rituale zu entwickeln, um die Komplexitätsgrenze zu erhöhen und das wahre Potenzial der Softwarebereitstellungsteams in deiner Organisation zu nutzen.

Teste Compass noch heute kostenlos.

How does each architecture impact deployment and DevOps practices?

Both SOA and microservices deployments benefit from Open DevOps practices. However, the specifics will differ depending on the architecture. 

SOA typically involves monolithic deployments, where teams deploy an entire application as a single unit. This approach requires careful coordination between teams. It can be time-consuming and complex, especially for large applications.

DevOps emphasizes collaboration and automation between development and operations teams to address these challenges. This enables more frequent and reliable deployments. By automating testing, configuration management, and infrastructure provisioning, DevOps can help streamline SOA deployments and minimize errors.

Microservices architecture enables more granular deployments. Teams deploy each microservice independently. 

DevOps principles are also essential for microservices deployments. DevOps practices such as continuous integration and continuous delivery allow teams to automate the process of testing, deploying, and building microservices. This facilitates rapid and frequent releases.


Diesen Artikel teilen
Nächstes Thema

Lesenswert

Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.

Abbildung: DevOps

Compass-Community

Illustration: Überwindung von Hindernissen

Tutorial: Erstellen einer Komponente

Abbildung: Karte

Erste Schritte mit Compass (kostenlos)

Melde dich für unseren DevOps-Newsletter an

Thank you for signing up