Bringen Sie Innovation und Zuverlässigkeit in ein Gleichgewicht, indem Sie den Code stabil halten, die Benutzer zufrieden stellen und Technik um der Technik willen meiden. [...]
CIOs und IT-Leiter befinden sich in einem Paradoxon konkurrierender Prioritäten bei der Entwicklung, Verbesserung und Modernisierung von Anwendungen. Auf der einen Seite streben sie nach Innovation, nach Erfahrungen, die die Endbenutzer begeistern, und nach agilen Entwicklungspraktiken, die die schnelle Bereitstellung neuer Geschäftsfähigkeiten ermöglichen. Auf der anderen Seite sorgen sie sich um die wachsende technische Verschuldung, stellen sicher, dass Anwendungen die richtigen Sicherheitsvalidierungen durchlaufen, und demonstrieren, ob Prototypen in Produktionsumgebungen funktionieren und skaliert werden können.
Ja, CIOs und IT-Leiter wollen ebenfalls ein Stück vom Kuchen. Sie kennen all die Wünsche, Must Haves und Wunschlisten ihrer Entwickler und Entwicklungsleiter. Mehr Zeit, um Code „auf die richtige Art und Weise“ zu entwickeln, mehr Leute im Team, bessere Schulung, eine flexiblere Entwicklungsinfrastruktur, moderne Tools für die Anwendungsentwicklung, bessere Einbindung der Interessengruppen und klar definierte Prioritäten stehen auf der Liste aller.
IT-Führungskräfte werden mit ihren Teams auf deren Bedürfnisse abgestimmt, müssen sich aber auch den geschäftlichen Realitäten stellen, wenn es darum geht, die digitale Transformation voranzutreiben, mit Budgetrestriktionen zu arbeiten und Compliance-Anforderungen zu erfüllen.
CIOs möchten, dass die Anwendungsentwicklungsteams wissen, wie sie umsichtige Entscheidungen unter Berücksichtigung von Kompromissen treffen können, welche Schritte zu unternehmen sind, um sicherzustellen, dass das Entwickelte tragfähig ist, und warum die Zusammenarbeit mit Endbenutzern, Interessengruppen, Architekten und dem Betrieb ebenso wichtig ist wie die Fertigstellung der Anwendung.
Um diesen Paradoxien zu begegnen, hoffen die CIOs, dass ihre Entwicklungsteams die Entwicklungsprinzipien und Kompromisse nachvollziehen können. Hier sind fünf zu berücksichtigen.
Ausgleich zwischen technischer Verschuldung und Innovation
Es ist für Entwicklungsteams sehr einfach, sich für Innovationen zu begeistern oder den Rückstand durch neue Technologien zu vergrößern. CIOs und IT-Führungskräfte wollen Innovationen, aber sie sind auch besorgt, wenn Entwicklungsteams sich nicht um technische Verschuldung kümmern. Ein gesunder agiler Auftragsbestand sollte zeigen, dass die agilen Teams ein ausgewogenes Verhältnis von Spitzen, technischer Verschuldung, neuen Funktionen und betrieblichen Verbesserungen erreichen.
Die Prioritätensetzung bei agilen Teams sollte dem Produkteigentümer obliegen. IT-Führungskräfte können jedoch Grundsätze aufstellen, wenn die Produkteigentümer es versäumen, technische Schulden zu priorisieren, oder wenn sie Prioritäten für Funktionen erzwingen, ohne die vom agilen Team empfohlenen Innovationsspitzen zu berücksichtigen.
CIO- und IT-Leiter sind ebenfalls realistisch und wissen, dass neue Implementierungen wahrscheinlich mit zusätzlichen technischen Schwierigkeiten verbunden sind. Sie wissen, dass Entwickler manchmal Abstriche machen müssen, um Fristen einzuhalten oder effizientere Kodierungsoptionen während der Implementierung zu finden. Man kann vernünftigerweise erwarten, dass neu entstandene technische Schulden im Quellcode und in den agilen Rückständen kodiert sind und dass die Teams versuchen, sie auf der Grundlage von Prioritäten anzugehen.
Entwickeln Sie stets sicheren und wartungbaren Code
Entwicklungsteams stehen unter erheblichem Druck, den Endbenutzern Funktionen und Fähigkeiten möglichst schnell zur Verfügung zu stellen. Das ist sicherlich ein Grund dafür, dass Teams neue technische Schulden machen, aber es ist eine schlechte Entschuldigung für die Entwicklung von Code, der nicht wartbar ist oder Sicherheitsstandards umgeht.
IT-Führungskräfte wollen keinen Spaghetticode, und sie wollen auch keinen übermäßig komplexen Code, der von fortgeschrittenen Ingenieuren gewartet werden muss. IT-Führungskräfte sind für die langfristige Wartung des von ihnen gelieferten Codes verantwortlich, da sie wissen, dass Entwickler und Teams für neue Projekte eingesetzt werden. Sie erwarten, dass der Code Architekturmustern, Codierungsstandards, Namenskonventionen, Protokollierungsmustern und Ausnahmebehandlung folgt.
Sie erwarten auch, dass die Entwicklungsteams bei der Definition und Weiterentwicklung von Standards zusammenarbeiten. Da sich Technologie, Plattformen und bewährte Verfahren ständig weiterentwickeln, können sich Organisationen nicht darauf verlassen, dass Architekten alle Richtlinien besitzen und spezifizieren.
Erfreuliche Benutzererfahrungen schaffen, die Leistung und Skalierbarkeit bieten
In den Anfängen der Webentwicklung hatten Software-Teams schwierige Kompromisse in der Anwendungsarchitektur und im Design.
Ein Ansatz sah vor, dass der Entwicklungsprozess mit der Entwicklung der Back-End-Datenbank und der Codierung der Geschäftslogik durch die Teams begann. Die Ingenieure schufen wiederverwendbare und skalierbare Lösungen, aber die Implementierung schränkte die Benutzerfreundlichkeit und das Design oft ein.
Bei dem anderen Ansatz beginnen die Webentwicklungsteams mit den Front-End-Designs und liefern den Endbenutzern großartige Erfahrungen. Bei diesen Entwürfen wurde die Geschäftslogik jedoch häufig in serverseitigen Vorlagen implementiert oder häufige Service-Anrufe getätigt, was zu Anwendungen führte, die nicht gut funktionierten oder nicht wie erforderlich skalierbar waren.
CIOs müssen großartige Erfahrungen und Leistung liefern. Heute können Entwicklungsteams Wireframing-Tools, Low-Code-Plattformen, Feature-Flagging-Funktionen, Micro-Service-Designmuster, bewährte Verfahren, Testautomatisierung und Cloud-Architekturen nutzen, um beides zu erreichen.
Vermeiden Sie das Kodieren, um Probleme der Technik um der Technik willen zu lösen
Wenn ich mit Entwicklungsteams während ihrer agilen Planungssitzungen zusammensitze, höre ich mir die zugrunde liegenden Problemaussagen an und stelle sie in eine von mehreren Kategorien. Die besten Funktionen und Stories zielen darauf ab, Fähigkeiten für eine bestimmte Gruppe von Endbenutzern zu liefern oder zu verbessern. Möglicherweise sehe ich auch dedizierte Spitzen, um neue Lösungen zu testen oder neue Fähigkeiten zu prototypisieren. Manchmal werden technische Schwierigkeiten innerhalb der Implementierung einer Benutzergeschichte angesprochen. Zu anderen Zeiten ist die Arbeit so umfangreich, dass mehrere dedizierte Stories im Rückstand sind. All dies sind gute Beispiele für Arbeiten, die der Produkteigentümer überprüfen und nach Prioritäten ordnen sollte.
Manchmal sehe ich Arbeiten, die auf die Lösung eines Technologiebedarfs abzielen. Am unteren Ende könnten es Utility-Klassen zur Unterstützung von Konfigurationen und Serviceverbindungen sein. Ich habe auch gesehen, wie Teams versuchen, Lösungen für die Verwaltung von Mikroinhalten, Low-Code-Funktionen und API-Verwaltungstools zu entwickeln.
Die meisten Entwicklungsteams sollten es vermeiden, technologische Kapazitäten zur Lösung technologischer Probleme einzusetzen. Robuste Lösungen für technische Probleme sind oft über Open-Source-Bibliotheken, öffentliche Cloud-Computing-Dienste, Low-Code-Funktionen und kommerzielle Softwaredienste verfügbar. Architekten und Entwicklungsteams sollten diese Optionen evaluieren, bevor sie sich für die Entwicklung von „Tech for Tech’s Sake“-Lösungen anmelden.
Halten Sie sich an Data Governance-Standards
Das Letzte, was CIOs und IT-Leiter sehen wollen, wenn Entwicklungsteams Anwendungen erstellen oder verbessern, sind mehr Datensilos, doppelte Datenquellen oder schlecht entwickelte Datenstrukturen. Für die meisten Unternehmen übersteigt der Umfang der Datenverschuldung oft die technische Verschuldung, und die geschäftlichen Auswirkungen sind beträchtlich. Bitten Sie einfach jeden Datenwissenschaftler, sich einen Überblick über die Zersiedelung von Datenquellen zu verschaffen, die über Data Warehouses und Datenseen in Unternehmen verteilt sind.
Es ist heutzutage unglaublich einfach, neue relationale Datenbanken, NoSQL-Datastores und Datenseen zu erstellen. Das ist sowohl ein Segen als auch ein Fluch, und die Frage ist, wie man Entwicklungsteams dabei helfen kann, zu wissen, welche Datenquellen verfügbar sind und wie man am besten mit ihnen zusammenarbeitet. Die Überprüfung von Datenkatalogen, API-Portalen und Stammdatenquellen sollte für Entwicklungsteams der erste Schritt vor der Erstellung neuer Datenstrukturen sein.
Wenn neue Datenstrukturen benötigt werden, sollten die Teams Datenmodellierungstools verwenden und Data Governance-Standards als nicht verhandelbare Praktiken einsetzen.
Zusammenfassend lässt sich sagen, dass CIOs und IT-Führungskräfte Innovation, Schnelligkeit, zufriedene Endbenutzer und Entwicklungsteams wünschen, die mit Begeisterung geschäftliche Herausforderungen lösen. Aber sie benötigen auch Zuverlässigkeit, Leistung, Effizienz, Skalierbarkeit, Sicherheit und Anwendungen, die langfristig gewartet werden können. Dies sind keine Ziele, die sich gegenseitig ausschließen, aber praktische Kompromisse kommen in jeder Version, jedem Sprint und jeder Anwendergeschichte vor. IT-Unternehmen sollten als Teil ihres Entwicklungsprozesses technische Prinzipien definieren und ihre Implementierungen erörtern.
*Isaac Sacolick ist der Autor von „Driving Digital: The Leader’s Guide to Business Transformation through Technology“ (Leitfaden für Unternehmensumwandlung durch Technologie), der viele Praktiken wie Agile, Devops und Datenwissenschaft behandelt, die für erfolgreiche digitale Umwandlungsprogramme entscheidend sind. Sacolick ist ein anerkannter Top-Social-CIO, langjähriger Blogger bei Social, Agile and Transformation sowie CIO.com und Präsident von StarCIO.
Be the first to comment