6 Enterprise-Architecture-Todsünden

Lesen Sie, wie sich Enterprise Architects (nicht) versündigen.
Foto: g215 – shutterstock.comEin Unternehmen am Laufen zu halten, war noch nie leicht. Softwaretools mögen dafür gesorgt haben, dass viele Prozesse schneller, reibungsloser und konsistenter ablaufen. Leider gilt das oft nicht für die, die die Software am Laufen halten müssen. Trotz aller Fortschritte: Enterprise Architecture (EA) bleibt eine Welt, die kaum jemand vollständig durchdringt. Oft nicht einmal die Enterprise Architects selbst, die immer noch lernen und experimentieren, wenn es darum geht, was sie tun sollten – und noch viel wichtiger – was nicht.Auf der Suche nach der optimalen Balance, um die Software Stacks am Laufen zu halten und parallel das Arbeitsleben aller Mitarbeiter so einfach wie möglich zu gestalten, werden EA-Spezialisten wahrscheinlich immer wieder Fehler unterlaufen. Das liegt teilweise an der hochtechnischen und komplexen Natur ihrer Aufgaben. Teilweise jedoch auch an den folgenden sechs Todsünden der Enterprise Architecture, denen die Spezialisten wiederholt erliegen.1. Zu viele Daten (oder zu wenig)Softwareentwickler sind oft sammelwütig. Sie speichern im Cache was sie können, protokollieren jedes Ereignis und fertige fleißig Backups an. Diese Giga- und Petabytes summieren sich. Selbst im Fall sehr niedriger Cold-Storage-Kosten können die Gebühren sich bei großen Datenmengen läppern. Erschwerend kommt hinzu, dass es mit steigendem Datenbestand auch immer diffiziler wird, die richtigen Daten zu finden.Auf der anderen Seite bringt es jedoch ebenfalls Probleme mit sich, zu wenige Daten vorzuhalten. Manche Unternehmen haben versucht, Richtlinien für die Datenaufbewahrung festzulegen und alles zu vernichten, sobald es die Vorschriften erlauben. Das kann jedoch zu einer Art Unternehmensamnesie führen, bei der die Antwort auf jede Frage zu lauten scheint: “Diese Datei existiert nicht mehr.”Alles was Enterprise Architects tun können, um sich der richtigen Balance anzunähern, ist, eine gut geeignete Data-Storage-Architektur zu finden. Das Ziel sollte sein, die richtigen Informationen in einer leicht zugänglichen Struktur abzulegen.2. Sich plattformabhängig machen (oder das Gegenteil)Der einfachste Weg zur Enterprise Software besteht darin, Tools, Portale und Plattformen zu nutzen, die von einem externen Anbieter entwickelt wurden. In vielen Fällen lassen sich 90 Prozent der Arbeit mit der Unterschrift auf einer Bestellung und ein bisschen Code als Klebstoff erledigen. Wichtige Unternehmensteile externen Anbietern anzuvertrauen, birgt jedoch auch Risiken. Vielleicht kauft ein Privatinvestor den Anbieter, entlässt alle guten Mitarbeiter und erhöht anschließend den Preis. Dann haben sich die Vorteile der singulären Plattform schnell erledigt.Auf zu viele verschiedene Plattformen zu setzen, ist jedoch manchmal ebenso kontraproduktiv: Die Vertriebsmenschen der Anbieter versprechen viel, wenn es um Interoperabilität, Kompatibilität und den Einsatz von Standardprotokollen geht. Und selbst, wenn sie dabei nicht übertreiben: Jedes Tool speichert Daten in einer Datenbank. Dabei verwenden manche MySQL, andere PostgreSQL und wieder andere Oracle.Es gibt also auch in diesem Bereich keine einfache Lösung. Zu viele Plattformen schaffen einen Turm zu Babel, bei zu wenigen besteht die Gefahr des Vendor-Lock-in. Über die anfallenden Kosten, wenn die gesamte Entwicklung im eigenen Haus stattfindet, haben wir dann noch gar nicht gesprochen.3. Zu viel Outsourcing in die Cloud (oder zu wenig)Die Cloud hat Enterprise Architects das Leben leichter gemacht. Rechenressourcen sind jederzeit auf Abruf verfügbar, Bestellungen sind nicht mehr nötig und Platz für Racks ebenfalls überflüssig. Alles, was dafür heute noch nötig ist, ist eine Kreditkarte.Die Vorteile liegen auf der Hand. Der größte Nachteil allerdings im Preis: Cloud Computing ist im Vergleich oft erheblich teurer als eine Inhouse-Lösung. Erkundigen Sie sich einfach mal unter CFOs, wie groß die Vorfreude ausfällt, wenn die monatliche Cloud-Rechnung ansteht. Auf der anderen Seite verursachen weitere Mitarbeiter, das Rechenzentrum und das nötige Equipment natürlich ebenfalls Kosten.Manche Enterprise Architects können mit der Cloud große Gewinne erzielen. Das sind im Regelfall diejenigen, die davon profitieren, Ressourcen lastenabhängig zu steuern. Alle anderen EA-Spezialisten müssen, beziehungsweise sollten eruieren, ob sie zu viel oder zu wenig in die Cloud investiert haben.4. Frameworks vergöttern (oder verdammen)Um der Komplexität heutiger Enterprise Stacks gerecht werden zu können, wurden einige Enterprise-Architecture-Frameworks entwickelt. TOGAF ist beispielsweise ein solches strategisches Rahmenwerk, um so gut wie alles aufzubauen, was moderne Unternehmen benötigen. Dazu bietet es eine Reihe von Richtlinien und Best Practices, darunter eine Architekturentwicklungsmethode und ein Architektur-Compliance-Framework. Andere Ansätze, wie das Zachman Framework oder FEAF, führen ihre jeweils eigene Guidelines und Vorschriften für den Aufbau eines Enterprise Stacks ein.Der größte Vorteil der Frameworks liegt in der Konsistenz. Sobald jeder in der Organisation mit den Techniken und Theorien vertraut ist, sollte es einfacher werden, sich in der Software zurechtzufinden. Daten und Code sind (normalerweise) so strukturiert, dass sich alles an einem vorhersehbaren Ort befindet.Einige EA-Spezialisten treiben es diesbezüglich jedoch zu weit. Sie übernehmen nicht nur ein Framework, sondern verschreiben sich einem Kult und stellen die Spezifikationen des Rahmenwerks über alles. Wehe dem, der von diesem Weg abweicht. Selbst, wenn dabei alle mit an Bord des Kults wären, dürften sich andere Problemszenarien ergeben. Etwa, wenn Open-Source-Code, der perfekt funktioniert, abgelehnt wird, weil er nicht dem gewünschten Architekturrahmen entspricht. Oder Anbieterangebote, die eigentlich eine gute Lösung wären, aber nicht in Frage kommen, weil sie unter der falschen Philosophie entwickelt wurden.5. Methodik ist alles was zähltFrameworks können eine Struktur an die Hand geben – aber auch schlampiges, faules oder sogar maliziöses Verhalten begünstigen. Entscheidungen könnten beispielsweise hinausgezögert werden, weil das Team darauf wartet, dass jemand das richtige TOGAF-Formular ausfüllt. Es ist ein schmaler Grat zwischen unterstützendem Rahmen und lähmender Bürokratie.Was es braucht, ist eine Methode, um den Entwicklungs-Workflow zu organisieren. Wenn ein Projekt den Arbeitsaufwand übersteigt, den eine Person an einem Wochenende stemmen kann, sollte es eine Strategie geben. Problematisch wird es dann, wenn diese Methodik am Ende mehr zählt als alles andere.6. Trends blind folgen (oder ignorieren)Enterprise-Architekten orientieren sich gerne an den neuesten Ideen und Modellen in ihrem Bereich. Das passt mit etwas Glück unter Umständen auch tatsächlich zu den Unternehmensbedürfnissen. Aber eben bei weitem nicht immer. Schwierig wird es vor allem dann, wenn Entwicklerteams krampfhaft versuchen, ihren Code an den Trend anzupassen. Dass ganze Code-Basen entsorgt werden müssen, die für ein ehemals trendiges Ziel entworfen wurden, ist längst keine Seltenheit mehr. Trends und aktuelle Entwicklungen völlig zu ignorieren, kann allerdings ebenso ins Verderben führen. Sicher, Ihr Code ist seiner ursprünglichen Vision treu geblieben und verwendet Datenbanken, Formate, Codierungs-Standards und Protokolle, die einwandfrei funktionieren. Wenn allerdings die ganze Welt auf einen Trendzug aufspringt, dann gilt das auch für Tool-Anbieter und potenzielle neue Mitarbeiter. Manche dieser Trends und Modeerscheinungen können zu neuen Standards werden und manchmal sogar zu etwas noch Schlimmerem – rechtlichen Anforderungen.Enterprise Architects haben es nicht leicht. Alles, was sie tun können, ist, vorsichtig zu versuchen, das Richtige für den Tech-Stack des Unternehmens zu tun – und für die IT-Profis, die sich um ihn kümmern müssen. (fm)Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CIO.com.