Serie: Wie tötet man die Architekturabteilung? Teil 6

Teil 6: Der leitende Betriebsingenieur

Architektonische Aktivitäten konzentrieren sich in der Regel auf die Initiierungs- und Designphase eines Projekts. Im vorigen Beitrag haben wir bereits auf die Bedeutung des architektonischen Denkens bei der Entwicklung von Software hingewiesen. In klassischen Unternehmen wird der Betriebsabteilung relativ wenig Aufmerksamkeit geschenkt. Die Architektur der Infrastruktur ist entscheidend für den Erfolg von Software. Die einzige wertvolle Software ist Software in Produktion. Das bedeutet, dass Sie sich darauf konzentrieren sollten, Software so schnell wie möglich in Produktion zu bringen, damit sie wertvoll ist. Viele agile Praktiken helfen dabei, die Entwicklung zu beschleunigen. Aber wenn Sie sich auf diese agilen Praktiken beschränken, stoßen Sie möglicherweise trotzdem an eine Wand, wenn Sie Ihre Software auf den Live-Systemen einsetzen wollen.

Ein Beispiel: Ein großes Entwicklungsteam entwickelt seit einem halben Jahr Software auf agile Art und Weise mit zweiwöchentlichen Demos von potenziell auslieferungsfähiger Software. Am Ende des Projekts, nach Zustimmung des Kunden, soll die Software kurz vor Jahresende in Betrieb gehen. Dann sagt die Betriebsabteilung, dass es in den nächsten drei Monaten keine Kapazitäten gibt, um die Software in Produktion zu bringen. Sie sagen, man hätte gleich zu Beginn des Projekts eine Anfrage stellen sollen, um sicherzustellen, dass die Kapazitäten eingeplant worden wären.In klassischen Unternehmen gab es eine klare Trennung zwischen Entwicklung und Betrieb. Organisatorische Trennungen wie diese führen zu Übergaben. Im agilen und schlanken Denken sind Übergaben unerwünscht, da sie Verschwendung bedeuten und die Komplexität des Prozesses erhöhen. Der Titel dieser Serie lautet "How to Kill the Architecture Department". Sie hätte genauso gut heißen können "Wie man die Entwicklungsabteilung tötet", "... die Betriebsabteilung", "... die Testabteilung". In unseren früheren Beiträgen haben wir die Architekten aufgefordert, ihre Elfenbeintürme zu verlassen und im Entwicklungsteam mitzuarbeiten.In ähnlicher Weise fordern wir die Betreiber auf, im Entwicklungsteam mitzuarbeiten. Und umgekehrt bitten wir Softwareingenieure, sich am Betrieb zu beteiligen. Wenn sowohl Betreiber als auch Entwickler als Team zusammenarbeiten, können sie die Time-to-Market verkürzen, um Software in Produktion zu bringen. Dies ist Teil der DevOps-Philosophie.(Wiki DevOps)Jetzt fragen Sie sich vielleicht, was das für den Mitarbeiter bedeutet, der früher als Architekt bekannt war: den (Chief) Technical Product Owner und den Senior Software Engineer. Bislang haben wir in unseren Beiträgen beschrieben, dass sich die Spezialisten in jeder Phase der Umsetzung einer User Story auf die architektonischen Aspekte der Software konzentrieren, außer im Betrieb.

Beim Betrieb gibt es auch eine Architektur: eine von Rechenzentren, Hardware, Netzwerken, Switches, Firewalls, Caches. Um hier die richtigen Entscheidungen zu treffen, sind Fachwissen und Erfahrung erforderlich. Um diesen Prozess zu erleichtern und sicherzustellen, dass die Entscheidungen mit der Gesamtvision übereinstimmen, brauchen Sie einen Senior Operations Engineer. Der Senior Operations Engineer arbeitet eng mit dem Senior Software Engineer zusammen. Beide nehmen am Entwicklungsteam teil. Bei einigen Änderungen muss der Senior Operations Engineer bereits zu einem früheren Zeitpunkt des Prozesses Entscheidungen treffen. Zum Beispiel, wenn alte Software in der Produktion problematisch ist und neue Funktionen das Problem vergrößern. Bei strategischeren Entscheidungen arbeitet der Senior Operations Engineer mit dem Chief Technical Product Owner zusammen, dessen Aufgabe es ist, die übergeordneten Geschäftsmanager davon zu überzeugen, dass eine größere technische Änderung erforderlich ist. Die wichtigsten Punkte, auf die der Senior Operations Engineer achten muss, sind: Verwaltbarkeit und Wartbarkeit, unabhängig davon, ob das Unternehmen DevOps einsetzt. Der Senior Operations Engineer kann ein guter Sparringspartner für den Technical Product Owner sein, um die Verwaltbarkeit der Software zu verbessern. Infrastrukturwissen ist rar und spezialisiert.Umgekehrt können sich Entscheidungen in der Infrastruktur auf die Entwicklung von Software auswirken. Auf diese Weise besteht eine Beziehung zwischen dem Senior Operations Engineer und dem Senior Software Engineer.Bislang wurde in dieser Serie ein Modell für die Beteiligung von Architekten an einer agilen Organisation beschrieben. Einige der Änderungen, die erforderlich sind, um damit zu beginnen, haben eine große Wirkung. Die Frage ist: Wie können Sie als Architekt zu dieser neuen Arbeitsweise beitragen? Der nächste Beitrag wird sich mit Fragen wie diesen befassen! Bleiben Sie dran!

Mehr aus dieser Serie

    
How to Kill the Architecture Department - Part 1
    
How to Kill the Architecture Department - Part 2
    
How to Kill the Architecture Department - Part 3
    
How to Kill the Architecture Department - Part 4
    
How to Kill the Architecture Department - Part 5
    
How to Kill the Architecture Department - Part 6
    
How to Kill the Architecture Department - Part 7