Untertitel: “Redefining the Architect’s Role in the Digital Enterprise”, von Gregor Hohpe

Unterschiedliche Zugänge zum Thema Architektur

Wer sich mit dem Thema Software-, IT- oder Enterprise Architektur beschäftigt - gar ein wenig Recherche betreibt - erkennt, dass es zu dieser Disziplin nach wie vor unterschiedliche Zugänge hinsichtlich der zugrundeliegenden Methodik und dem in der Praxis relevanten Arbeitsweise hat. Im Versuch eine entsprechende Standardisierung voranzutreiben, bieten Methoden wie TOGAF oder Zachman umfassende Modelle bzgl. der Vorgehensweise und beinhalten Regelwerke samt zugehörigen Zertifizierungen. Jedoch ist es fraglich ob derartige Herangehensweisen angesichts der immmer rascher voranschreitenden Digitalisierung überhaupt noch in der Praxis umsetzbar und abbildbar sind. Daher stellt sich die Frage nach pragmatischeren, flexibleren Ansätzen, welche - auch gemäss dem Agilen Manifest - “Individuen und deren Interaktionen über Prozesse und Tools” stellen. Hohpe vertritt genau jene Gruppe von Pragmatikern die aus ihrer eigener Erfahrung heraus Beobachtungen, Heuristiken und Handlungsprinzipien formulieren, was doch eher einer leichtgewichtigen und agilen Herangehensweise entspricht.

Zur Person

Hohpe selbst ist kein Unbekannter, wer sich schon mal ernsthaft mit dem Themen Integration oder Middleware beschäftigt hat, kennt sicher auch sein Standardwerk Enterprise Integration Patterns (zugehörige Webseite https://www.enterpriseintegrationpatterns.com). Wissenswert ist zudem, dass Herr Hohpe als Senior Principal Evangelist bei Amazon Web Services (AWS) tätig ist. Auf seiner Webseite https://www.architectelevator.com finden sich weitere Informationen zu seinen Büchern wie auch diverse Blogposts.

Grundverständnis gemäss Hohpe

Um ein Grundverständnis zur Arbeitsweise eines Architekten herzustellen, verwendet Hohpe (wie auch schon im Titel ausgewiesen) die Analogie eines Aufzugs, mit welchem die verschiedenen Stockwerke in einem Unternehmensgebäude erreicht werden können. Seiner Ansicht nach ist es für einen Architekten essentiell, mit den unterschiedlichen Stakeholdern auf allen Ebenen - sei es auf der Ebene der Geschäftsführung, dem mittleren Management oder direkt mit den Technikern - in Kontakt zu treten, um eben auch den jeweiligen Handlungsspielraum genau einzuschätzen wie auch den Personen gegenüber stets den Kontext mitsamt den relevanten Informationen bieten zu können.

Zusammenfassung

Die folgende Auflistung fasst in Form von Notizen die wichtigsten Eckpunkte/Leitlinien zu diversen im Buch behandelten Themen dar.

Rollenverständnis eines Architekten:

  • “An architect should be someone who actually builds”
  • “… a good gardener, just like a good architect, is no dictatorial mater planner and certainly doesn’t make all the detailed decisions about in which direction the grass should grow.”
  • its the architect’s job to translate technical options into meaningful choices for the business.

Architekt - Vorgehensweise und Fähigkeiten:

  • “Periodic gluing, gardening, guiding, impressing and a little bit of all-knowing every now and then can make for a pretty good architect.”

Business vs. IT:

  • “Enterprise architecture is the glue between business and IT architecture.”

Wert der Architektur im Unternehmen:

  • “Generally, good architecture buys you flexibility”.
  • “The set of design decisions about any system that keeps its implementors and maintainers from exercising needless creativity.”

Automatisierung

  • “If it hurts, do it more often”
  • “Automate Everything; What You Can’t Automate, Make a Self-Service”
  • “automation is not just about efficiency but primarily about repeatability and resilience.”

Standardisierung der IT Plattform

  • “Platform standards essentially split the IT into two parts: a lower layer that standardizes those elements that are unlikely to form a competitive differentiator and an upper layer of the in-house-developed software that provides direct business value and competitive differentiation.”
  • “The standard with the biggest economic impact have been compatibility or interface standards: specifications that allow interchangeability of parts”

Experimentieren

  • “Play is work.”

Zusammenarbeit, synchron/asynchron; remote versus vor Ort:

  • “Writing scales”
  • “Avoid Sync Points - Meetings Don’t Scale”
  • “Phone calls, …, in an open environment, the not only interrupt you but also your coworkers.”
  • “I very much value personal interaction for brainstorming, negotiation, solution finding, bonding or just having a good time.”

Digitales Mindset:

  • “Code is what software innovation is made of, so if you want to be digital, you’d better learn to code!”
  • “the main competitive asset for an organization is its ability to learn fast.”

Facts

Rating

Persönlich bewertet erhält das Buch im Geigerzähler-Rating (Skala 1 (= Flop) - 5 (= Top)) den Wert 5.