Daten- und Architekturstandards in der agilen Entwicklung etablieren

Zeit für die Planung von Standardverfahren zu investieren, zahlt sich langfristig aus. Wir zeigen Ihnen, warum. [...]

Eine Herausforderung für agile Führungskräfte und Teams besteht darin, Daten und Architekturmuster und -standards in der agilen Entwicklung zu definieren und zu befolgen. Es herrscht die Überzeugung, dass es schwierig ist, Daten und technische Standards voranzutreiben, da agile Teams in Sprints arbeiten, die in der Regel zwei bis vier Wochen lang sind, und Product Owner den Backlog in der Regel mit priorisierten Funktionen überfrachten. Normen brauchen Zeit für die Entwicklung; ihre Einhaltung erfordert, dass die Teams genügend Zeit haben, um technische Implementierungen zu planen.

Agile Teams, die einen Sprint durchführen und nur den nächsten planen, werden es schwer haben, Standards zur Formulierung ihrer Entwicklungspläne zu nutzen. Wenn dokumentierte Standards nicht einfach zu befolgen oder zu verknüpfen sind, dann sind Teams weniger effizient, und es ist schwieriger, neue Entwickler in Bezug auf bewährte Architektur und Datenpraktiken zu schulen. Es ist wie ein Team, das ohne Karte oder GPS durch den Wald streift; vielleicht schaffen sie es, zum nächsten Wegweiser zu gelangen, aber sie werden nicht wissen, ob sie den optimalen Weg einschlagen, um in die Stadt zurückzukehren.

Welche Daten- und Architekturprobleme müssen beachtet werden?

Es könnte helfen, Daten- und Architekturstandards in zwei Kategorien einzuteilen:

Standardarchitekturen wie Datenmodelle, Datenpipelines, Technologien zur Realisierung einer Microservices-Architektur, standardisierte CI/CD-Pipelines (Continuous Integration and Continuous Delivery) oder Proof of Concept für neue Technologien. Diese erfordern eine Vorabplanung.

Standardverfahren, einschließlich Namenskonventionen, Testanforderungen, Microservice-Schnittstellenstandards und Usability-Muster. Diese Leitfäden leiten agile Teams bei der Implementierung von Funktionen und der Bewältigung von technischen Problemen. Sie können auch Prozessstandards beinhalten, die definieren, wie Datenmodelle erweitert, CI/CD-Pipeline-Verbesserungen validiert oder ein neuer Microservice Endpunkt dokumentiert werden kann.

Wenn eine Standardisierung Ingenieurarbeit erfordert, dann ist es am besten, diese Arbeit als Epen, Features und Stories im agilen Backlog zu definieren und sie geeigneten Teams zuzuordnen. Diese Teams sollten andere Anwendungsentwicklungsteams als ihre Kunden betrachten und Akzeptanzkriterien für ihre Arbeit definieren. Der Produktinhaber für diese Entwicklung kann ein Daten-, Anwendungs- oder Lösungsarchitekt sein, der bestrebt ist, eine Komponente bereitzustellen, die für agile Teams einfach zu bedienen ist und einen Mehrwert für das Unternehmen bietet.

Andererseits, wenn Standards Daten und Architekturanleitungen für Entwicklungsteams bereitstellen, dann sollten diese Standards eine Grundlage dafür liefern, wie Entwickler User Stories implementieren. Dies erfordert, dass die Teams über fundierte Kenntnisse dieser Standards verfügen und vielleicht eine einfach zu bedienende Wissensdatenbank für Teamleiter und Mitglieder zur Verfügung haben.

Wie die Hybrid-Cloud Herausforderungen im Bereich der Datensouveränität vereinfacht

Agile Entwicklung erfordert kontinuierliche Planung

Viele agile Teams halten zu Beginn des Sprints ihre Planungsbesprechungen ab. Sie überprüfen die priorisierten User Stories, schätzen sie ein und verpflichten sich, während des Sprints an ihnen zu arbeiten.

Dieser Ansatz funktioniert, wenn die Prioritäten der Teams kleine Verbesserungen an bestehenden Anwendungen anstreben. Wenn sie jedoch an neuen Features arbeiten und sich an Daten- und Architekturstandards orientieren wollen, dann reicht eine Just-in-time-Planung nicht aus. Teams haben nicht genug Zeit, um User Stories zu überprüfen und die Implementierung an den Standards auszurichten, und zwar in einem Rutsch, kurz bevor der Sprint beginnt.

Teams, die auf Standards hinarbeiten, müssen früher planen. Ich bevorzuge es, das Meeting zu Beginn eines Sprints als „Commitment Meeting“ zu bezeichnen, bei dem die Teams festlegen, an welchen Stories sie arbeiten werden. Die notwendige Arbeit zur Planung der Umsetzung dieser Stories wird in einer oder mehrerer „Planungssitzungen“ festgelegt.

Im Idealfall etablieren Teams einen kontinuierlichen agilen Planungsprozess, in dem sie Epen, Features und User Stories kontinuierlich aufarbeiten. Komplexere Workitems, die mehr Planungszeit erfordern, werden mehr als einen Sprint vor der geplanten Implementierung geplant, so dass Teams gründliche Entwicklungspläne erstellen können; kleinere Workitems können den Prozess schneller durchlaufen. Am wichtigsten ist, dass ein frühzeitiges Treffen den Zeitdruck von den Teams nimmt; somit ist es wahrscheinlicher, dass sie Standards berücksichtigen, weil genügend Zeit für die Planung der Implementierung zur Verfügung steht.

Entwicklung von Referenzarchitekturen und Datenmodellen

Eine Möglichkeit, agile Teams auszurichten, besteht darin, Referenzarchitekturen und Datenmodelle zu entwickeln, die den aktuellen Zustand, den kurzfristigen zukünftigen Zustand und längerfristige Ziele darstellen. Diese Diagramme dienen als Roadmap für Entwicklungsteams, damit sie wissen, wie sie ihre Implementierungen am besten an Architektur- und Datenstandards ausrichten können.

Dokumentierte Referenzarchitekturen sind einseitige Diagramme mit Farbcodes und anderen Symbolen, die den aktuellen Zustand von zukünftigen Zuständen trennen. Um sie auf einer einzigen Seite zu platzieren, sollten Architekten einen Umfang von Komponenten definieren, die miteinander verbunden sind und den End-to-End-Service einer oder mehrerer Anwendungen darstellen.

Referenzdatenmodelle können mehrere Diagramme enthalten, je nachdem, wie die Daten in dem Unternehmen verwendet werden. Dazu gehören oft die folgenden Punkte:

• Ein konzeptionelles Datenmodell, das Wirtschaftseinheiten, Beziehungen und wesentliche Transaktionen abbildet.
• Ein analytisches Modell dafür, wie Daten in Datenseen oder Data Warehouses zentralisiert und für Analysen, KI-Experimente und Datenvisualisierungen verwendet werden.
• Ein Datenintegrationsmodell, das Datenquellen, die kritischen Transformationen der aus ihnen geladenen Daten und die primären Datenbanken, in denen die Daten gespeichert sind, anzeigt.
• Ein Dienstmodell, das zeigt, wie Mikrodienste und andere APIs mit Datenbanken verbunden sind.

Diese Diagramme bieten agilen Teams einen Ausgangspunkt, um Standards und zukünftige Richtungen zu verstehen. Architekten sollten sie durch weitere Details wie API-Dokumentation, Datenwörterbücher und eine Liste von Fachleuten für jede Architektur und Datenkomponente ergänzen.

Warum wir nicht zulassen sollten, dass KI für uns schreibt

Schreiben Sie Akzeptanzkriterien, die sich auf Standards beziehen

User Stories sollten das Was, Warum und Für wen der Anforderung darstellen. Im Idealfall sollte der Produktinhaber nicht dokumentieren, wie die Story umgesetzt werden sollte, da dies die Aufgabe von Architekten, Softwareentwicklern und Testern ist. Die Teams sollten für die Bereitstellung der Funktionalität und die Sicherstellung, dass die Implementierung Architektur, Daten, Sicherheit, Devops und andere Standards erfüllt, verantwortlich sein.

Die bloße Dokumentation von Standards und Referenzarchitekturen reicht nicht aus, um Teams dazu zu bringen, sich an sie zu halten. Teams stehen unter zu großem Druck, Code und komplette Releases zu entwickeln, so dass die Überprüfung von Standards nicht immer im Vordergrund steht. Architekten sollten die Verantwortung für die Überprüfung von User Stories, das Treffen mit Teams zum Erfahrungsaustausch und die Anpassung der Implementierung an geeignete Standards übernehmen, indem sie Akzeptanzkriterien in die Story aufnehmen.

Außerdem sollten Softwareentwicklungsmanager mit ihren Teams Akzeptanzkriterien und -standards besprechen, um sicherzustellen, dass sie die Best Practices befolgen und dass die Implementierungen mit zukünftigen Architektur- und Datenstandards übereinstimmen.

Größere Unternehmen werden mehrere Ansätze in Betracht ziehen müssen, um agile Teams an Daten- und Architekturstandards anzupassen. Die Definition von Standards, die Planung vor dem Sprint, das Schreiben von architekturgetriebenen Akzeptanzkriterien und die Definition von Verantwortlichkeiten sind nur einige der Praktiken, die es Teams ermöglichen können, neue Funktionen bereitzustellen, die mit der Architektur übereinstimmen.

*Isaac Sacolick ist der Autor von „Driving Digital: The Leader’s Guide to Business Transformation through Technology“, das viele Praktiken wie Agile, Devops und Datenwissenschaft abdeckt, die für erfolgreiche digitale Transformationsprogramme entscheidend sind. Sacolick ist ein anerkannter Top-Social-CIO, ein langjähriger Blogger im Bereich Social, Agile und Transformation und bei CIO.com sowie Präsident von StarCIO.