Seite 2 von 3

Was ist eigentlich ein Softwarearchitekt?

Die Rolle des Softwarearchitekten wird je nach Unternehmen sehr unterschiedlich interpretiert und durch die jeweiligen Menschen noch unterschiedlicher ausgefüllt. Deshalb gibt es auch nicht DEN Softwarearchitekten.

Im Gegensatz zu anderen Rollen im Softwareengineering scheint jedoch die Bandbreite der unterschiedlichen Interpretationen viel größer zu sein. Deshalb verwundert es nicht, dass es zahlreiche Analogien aus anderen Bereichen gibt, um den Softwarearchitekten, das unbekannte Wesen, etwas greifbarer zu machen. In vielen Präsentationen zu Softwarearchitektur sieht man immer wieder solche Analogien. Gregor Hohpe und Rebecca Whirfs-Brock haben mich mit ihren Vorträgen bei der OOP 2017 inspiriert, eine (sicherlich unvollständige) Aufstellung von Charakterisierungen zu machen.

  • Architekt als Generalplaner: Der Architekt plant alles ganz genau voraus und macht dann den Entwicklern klare Vorgaben bezüglich der Umsetzung. Er ist als einzelne Instanz, die über die Integrität des Gesamtsystems wacht, unabdingbar. (Siehe Martin Fowler, Architectus Reloadus)
  • Architekt als Gärtner: Der Architekt gibt Leitplanken vor, wie ein Gärtner einen Garten strukturiert. Darin wächst dann alles eigenständig und der Architekt beobachtet den Fortschritt und greift korrigierend ein.
  • Architekt als Mentor und Coach: Der Architekt versteht sich als Kümmerer im Projekt und klinkt sich immer wieder an unterschiedlichen Stellen ein. Er hilft Kollegen und unterstützt sie, auch bei Implementierungsaufgaben. Dadurch hat er einen sehr guten Überblick über das gesamte System und ist sehr nah an der Entwicklung dran. (Siehe Martin Fowler, Architectus Oryzus)
  • Architekt als Reiseführer: Der Architekt nimmt andere Rollen in der Entwicklung mit auf eine Reise und kann zu allem etwas erläutern.
  • Architekt als Barkeeper: Der Architekt mixt verschiedene Dinge zusammen: Insbesondere Business und Technologie. Dabei versteht er das Business und zeigt durch die Technologie neue Möglichkeiten auf, die er dann auch realisieren kann.
  • Architekt im Aufzug, Architekt als Mediator: Der Architekt ist in einem Aufzug unterwegs, der zwischen verschiedenen Stockwerken eines Unternehmens fährt. Diese Stockwerke symbolisieren alles von der Entwicklung bis zum Vorstand. Ein Architekt wird dadurch charakterisiert, wie viele Stockwerke er fahren kann, das heißt auf welchen Ebenen er mit den Menschen sprechen kann und auch zwischen den verschiedenen Ebenen vermitteln. Das bezieht sich einerseits auf die Fähigkeit, zwischen Abstraktionsebenen zu springen und andererseits auf die Fähigkeit mit Menschen unterschiedlicher Profession in der Sprache zu sprechen.
  • Architekt als Verkäufer von Optionen, Architekt als Ökonom: Der Architekt betrachtet die Architektur als Menge von Entscheidungen mit ökonomischem Einfluss auf die Entwicklung und die Zukunft des Softwaresystems. Insbesondere ermöglicht der Architekt es, bestimmte Änderungen am System in der Zukunft kostengünstig machen zu können. Dadurch sind in der Gegenwart Investitionen nötig (ähnlich wie bei Optionsscheinen, die es einem erlauben, in der Zukunft bestimmte Geschäfte zu einem festgelegten Preis zu tätigen).
  • Architekt als Stammesältester: Der Architekt als Respektsperson, die aufgrund ihrer Historie und Verdienste einen hohen Einfluss und Anerkennung genießt.
  • Architekt als Pfadfinder: Der Architekt als Entdecker neuer Wege mit einem Sinn für gute Taten.
  • Architekt als Designer: Der Architekt als Gestalter eines Softwaresystems, der wichtige und weitreichende Entscheidungen über das System trifft.
  • Architekt als Phantombildzeichner: Der Architekt als „Extrahierer und Dokumentierer“ von existierender Softwarearchitektur. Wenn Zeugen einen Verbrecher gesehen haben, so können sie ihn oft zumindest grob beschreiben, obwohl sie nie in der Lage wären, ihn zu zeichnen. Diese Aufgabe kommt dem Phantombildzeichner zu, der fundiertes Wissen über die menschliche Anatomie hat und die Kunst versteht, Informationen den Menschen zu entlocken und zu dokumentieren. Die gleiche Rolle können gute Softwarearchitekten einnehmen. Mit ihrem fundierten Wissen über Architektur und Dokumentation können sie gemeinsam mit Entwicklern Informationen extrahieren und geeignet dokumentieren. Obwohl es nicht direkt zu erwarten ist, können viele Entwickler und sogar viele Softwarearchitekten ihre Architektur nicht gut visualisieren, dokumentieren und kommunizieren. Deshalb ist der Phantombildzeichner oft sehr hilfreich.

Gregor Hohpe @ OOP 2017: Architekt als Phantombildzeichner

  • Architekt als Technologieexperte: Der Architekt als Kenner von Technologien in einem bestimmten Technologiebereich. Diese Übersicht erlaubt ihm, Technologien zu identifizieren, zu bewerten und auszuwählen.
  • Architekt als Domänenexperte: Der Architekt als Kenner der Domäne, für die ein System entwickelt wird.
  • Architekt als Möwe: Der Architekt stürzt sich auf ein bestimmtes Thema herab, wirbelt dort einigen Staub auf und fliegt dann wieder von dannen J
  • Architekt als Astronaut: Der Architekt bewegt sich in ganz anderen Sphären und ist so weit von der Entwicklung weg, dass er kaum was über den System weiß, wenig Einfluss hat und bei den Entwicklern wenig Wertschätzung erfährt.
  • Architekt im Elfenbeinturm: Der Architekt ist eher wissenschaftlich angehaucht und schottet sich von der eigentlichen Entwicklung ab. Damit geht es ihm so ähnlich wie dem Astronauten.
  • Architekt als Powerpoint-Künstler: Der Architekt als Ersteller von schönen Powerpoint-Bildern, die mit der Realität (dem Code) häufig wenig zu tun haben und ihm deshalb bei Entwicklern wenig Respekt einbringen.

Diese Analogien greifen akzentuiert bestimmte (positive wie negative) Eigenschaften des Softwarearchitekten heraus und machen sie verständlich. Letztlich dürfte natürlich keine der Analogien einen Softwarearchitekten wirklich komplett beschreiben und sie schließen sich auch nicht gegenseitig aus. Sie erläutern aber sehr gut verschiedene Persönlichkeitstypen und verschiedene Arbeitsauffassungen.

Da es auch keine einheitliche Definition von Softwarearchitektur gibt, ist es natürlich kein Wunder, dass auch bei Softwarearchitekten keine einheitliche Auffassung existiert. Die Vielfalt der Analogien sollte aber sowohl Softwarearchitekten selbst helfen, über ihr Tun zu reflektieren und anderen Personen die Gelegenheit eröffnen, Softwarearchitekten besser zu verstehen.

Unabhängig von der Analogie scheint Softwarearchitekt aber ein toller Job zu sein. Zum wiederholten Male landete er bei „Best Jobs in America (CNN Money)“ auf dem ersten Platz :-).

CNN Money: Best Jobs in America (2015)

Die Liste mit Analogien für Softwarearchitekten ist bestimmt noch viel länger und darf gerne in den Kommentaren ergänzt werden!

On Tour: OOP 2017, München

OOP 2017

Wir freuen uns sehr, bei der OOP 2017 als Sprecher dabei sein zu dürfen. Mit 8 Tracks zu spannenden Themen rund um Softwareentwicklung verspricht die OOP wieder ein echtes Highlight zu werden.

Who is engineering the Software, which is eating the world?

Software revolutioniert fast jede Art von Business durch neuartige Ökosysteme. Die Erstellung erfordert Kompetenzen, die weit über das klassische Systems- und Software-Engineering hinausgehen. Zentrale Herausforderungen sind höhere Komplexität bei kürzerer Time-To-Market, geteilte Verantwortung und Kontrolle über mehrere Unternehmen und Domänen hinweg sowie die immer höher werden Anforderungen an Sicherheit, User Experience, und andere Qualitäten. Wir charakterisieren Softwareökosysteme und zeigen notwendige Kompetenzen, um diese zu bauen.

Ereignisorientierung im App-Ökosystem – Architekturdetails als Garant für erfolgreiche Integration

Ereignisorientierung ist in vielen Aspekten für IoT-Systeme geeignet, weil reale Ereignisse verarbeitet werden. Die passende Architektur und Implementierung ist aber alles andere als offensichtlich und erfordert, dass sich Architekten und Entwickler gemeinsam um viele Details kümmern. Wir zeigen Lösungen für ein skalierbares und erweiterbares App-Ökosystem mit Logistikfokus: Error Handling, Schnittstellen, Daten- und Eventmodellierung mit Generierung von Entwickler-spezifischen Sichten, Einfluss auf die Clients und Umsetzung in AWS mit Reactor.

Dieser Vortrag ist zusammen mit unserem Kollegen Balthasar Weitzel.

Wir freuen uns auf eine spannende Konferenz und viele interessante Diskussionen. Hier geht es zum vollständigen Konferenzprogramm.

On Tour: Softwareforen Leipzig, User Group Softwarearchitektur und Softwareentwicklung

Leipzig

Am 29. und 30. November 2016 findet das nächste Treffen der User Group Softwarearchitektur und Softwareentwicklung statt. Themenschwerpunkt ist: „Self-Contained Systems – Ein neuer Weg, um komplexe Anwendungen beherrschbar zu machen?“ Ich werde auch mit einem Vortrag dabei sein und freue mich schon auf viele intensive und spannende Diskussionen zu einem sehr aktuellen Thema.

Modularität: Schon immer gewollt und selten erreicht – Sind Microservices und Self-Contained Systems der Durchbruch?

Modularität war schon das erklärte Ziel, als noch niemand von Softwarearchitektur sprach. Daran hat sich bis heute nichts geändert und aufgrund der stetig wachsenden Größe von Software wird Modularität immer noch wichtiger, um Herr der Lage zu bleiben. Trotzdem hat man in der Praxis selten das Gefühl, dass Modularität wirklich erreicht wurde oder gar dauerhaft erhalten bleibt. Microservices und Self-Contained Systems sind nun die aktuellsten Paradigmen, die Modularität versprechen. Dieser Vortrag blickt auf zahlreiche Entwicklungs- und Renovierungsprojekte zurück, in denen auf Modularität hingearbeitet wurde. Er nimmt Modularität, die Ziele dahinter und die Probleme bei der Erreichung unter die Lupe. Microservices und Self-Contained Systems verdienen dabei als jüngste Hoffnungsträger hinsichtlich Modularität besondere Beachtung.

UX MADE of STEAL – Kreative Beschaffung von Ideen (UX Day 2015)

UX MADE of STEAL
Wir brauchen immer mehr tolle Ideen! Aber woher nehmen, wenn nicht stehlen? Anregungen zur kreativen Beschaffung von Ideen aus meinem Vortrag vom UX Day 2015.

Gestern hatte ich meinen Vortrag beim UX Day 2016 am 13. November in Mannheim angekündigt. Auch im letzten Jahr war ich beim UX Day 2015 in Mannheim dabei, mit einem Vortrag zum Thema:

UX made of STEAL

„Bringt mir neue, innovative Lösungen!“, „Seid doch endlich mal kreativ!“, „Wir müssen uns neu erfinden!“ und ähnliche Aussagen hören wir vermehrt in letzter Zeit. Es scheint jedoch so, als wäre alles schon von anderen erfunden, und die anderen haben sowieso immer die besseren Ideen, so dass wir uns zur Lieferung neuer Ideen fragen müssen: Woher nehmen, wenn nicht stehlen? Ob das vielleicht sogar eine ernsthafte Lösung ist oder wie wir unser Wissen über existierende gute Lösungen gewinnbringend zur Erarbeitung von neuen Ideen einsetzen können, wird in diesem Vortrag diskutiert.

Die Nachfrage nach neuen, kreativen Lösungen oder Produkten steigt stetig an. Immer mehr Menschen sollen in ihrer täglichen Arbeit innovativer werden. Sie sollen ihre „Komfortzone verlassen“ oder „um die Ecke denken“. Das ist aber für viele Menschen leider sehr ungewohnt und oft auch unangenehm. Erschwert wird die Situation zudem dadurch, dass dem ersten Eindruck nach, jede erarbeitete Idee schon lange von anderen bereits erfunden oder erdacht worden ist. Es erscheint vordergründig, als ob es täglich schwerer wird, etwas Neues zu erschaffen. Dies wird zudem noch oft von den eigenen Mitarbeitern bestätigt: „Gibt’s schon. Das brauchen wir gar nicht erst zu versuchen. Das haben andere schon ewig.“ Schnell kann man sich in dieser Situation fragen „Woher nehmen, wenn nicht stehlen?“

Im Vortrag wird diskutiert, ob vielleicht gerade das eine Lösung unseres Problems darstellen könnte, selbstverständlich im übertragenen Sinne. Warum sollten wir unser Wissen über bereits existierende gute Lösungen immer destruktiv nur zur Ablehnung der eigenen Ideen verwenden? Schließlich können wir die bereits bekannten guten Lösungen als Inspiration konstruktiv nutzen. Bei genauem Betrachten sind nämlich meistens die selbst erdachten Ideen doch nicht ganz genauso schon einmal von jemand anderem erdacht worden (wie die Kollegen aber angeben). Aber gerade weil schon mal jemand zuvor eine gute Lösung für ein (sehr) ähnliches Problem gefunden hat, kann man bestimmte Aspekte dieser Lösung auf das eigene Problem übertragen. So geht es hier nicht um Kopien oder gar Diebstahl von Ideen sondern vielmehr um Inspiration, Transformation oder einen „Remix“. Auch können wir aus vielen bereits existierenden Lösungen für Teilaspekte unseres Problems eine Gesamtlösung zusammenbauen.

Der Vortrag zeigt mit vielen anschaulichen Beispielen, wie diese „kreative Beschaffung“ bereits von erfolgreichen Unternehmen eingesetzt wird. Zudem motiviert der Vortrag sich mit vielen Bereichen und Domänen auch außerhalb der eigenen Arbeit zu beschäftigen, um Lösungsideen von dort in die eigene Arbeit zu übertragen.

 

Beim UX Day 2015 gab es viele tolle Vorträge, Insbesondere möchte ich auf den super guten Vortrag von Roman Rackwitz zum Thema „Gamification – human performance design“ verweisen. Weiter Informationen zum UX Day 2015 findet ihr hier.

Wenn euch mein Vortrag gefallen (oder auch nicht) oder wenn ihr Anregungen und Fragen zum Thema habt, dann schreibt einfach einen Kommentar.

On Tour: UX Day 2016, Mannheim

Mannheim - Rheinufer - Sonnenuntergang

Am 13. & 14. Oktober findet in Mannheim der UX Day 2016 statt. Ich freue mich auch dieses Jahr wieder mit dabei zu sein. Mein Vortrag dieses Jahr trägt den Titel:

„Wir müssen reden!“

Gute Kommunikationsfähigkeiten sind eine wichtige Voraussetzung für nahezu jede Rolle im User Experience Engineering. Selbst unter besten Voraussetzungen:

  • wenn genau der richtige Stakeholder,
  • zum genau richtigen Zeitpunkt zum Gespräch eingeladen wurde,
  • das Gespräch perfekt vorbereitet wurde und
  • in den perfekten Räumlichkeiten stattfindet,

so kommt es dennoch zu einem erheblichen Maße auf die persönlichen Kommunikationsfähigkeiten des UX-Experten an, wie gut oder schlecht die Ergebnisse des Gesprächs sein werden. Dieser Vortrag liefert konkrete Tipps und Tricks von Kommunikationsexperten aus unterschiedlichsten Domänen (Kriminalistik, Jura, Journalistik, uvm.) zur Verbesserung der Kommunikation in persönlichen UX-Stakeholder-Gesprächen.

Das persönliche Interview ist immer noch eines der wichtigsten Instrumente zum Erheben und Validieren von UX Anforderungen. Es gibt viele Techniken, Methoden und Werkzeuge, die uns dabei unterstützen, die Interviews zu planen und die richtigen Stakeholder für diese Interviews zu identifizieren. Noch mehr Unterstützung gibt es, die UX Experten helfen, die zu erhebenden Informationen festzulegen und somit auszuwählen, welche Fragen den Stakeholder genau gestellt werden sollen. Jedoch egal wie gut das Interview vorbereitet und aufgesetzt wurde, im Interview selbst, hängt es dann jedoch erheblich von den persönlichen Kommunikationsfähigkeiten des UX Experten ab, ob das Interview erfolgreich verläuft oder nicht. Es gibt somit viel Unterstützung für das WANN, WER und WAS aber fast keine Unterstützung für das WIE. Die im UX-Stakeholder-Interview benötigen Kommunikationsfähigkeiten unterscheiden sich nicht (stark) von den Kommunikationsfähigkeiten von Experten aus anderen Domänen, in den es ebenfalls wichtig ist, Informationen zu erheben und zu validieren. Polizisten müssen Informationen von Zeugen und Verdächtigen erheben und auf ihren Wahrheitsgehalt hin beurteilen. Ähnliches gilt für Anwälte, die zudem noch die Aussagen von Gutachtern einschätzen müssen. Auch für Reporter ist das persönliche Interview ein wichtiges Mittel zur Erhebung von Informationen. Aber auch die Gesprächsführung beim Dating oder im Job-Interviews ist ähnlich zum UX-Stakeholder-Interview, da auch hier versucht wird, Informationen vom Gegenüber zu erhalten und diese auf ihren Wahrheitsgehalt hin zu überprüfen. Es gibt viele Tipps & Tricks aus diesen Domänen und Disziplinen, die auch in UX-Stakeholder-Interviews angewendet werden können. Dies gilt nicht nur die verschiedenen Phasen des eigentlichen Interviews, sondern auch die Interview-Vorbereitung und -Nachbereitung.

Ich bin seit vielen Jahren ein großer Fan der Veranstaltung und freue mich daher schon jetzt wieder auf einen tollen Tag in Mannheim. Alle Informationen zum UX Day 2016 gibt es hier! Dieses Jahr gibt es zum ersten Mal einen zweiten Veranstaltungstag, an dem die UX Masterclass stattfinden wird.

On Tour: The Architecture Gathering 2016, München

München

Am 12. und 13. Oktober findet in München The Architecture Gathering 2016 statt. Letztes Jahr war die Veranstaltung ein voller Erfolg mit vielen Teilnehmern, hochkarätigen Sprechern und tollen Vorträgen. Dieses Jahr sind wir auch mit einem Vortrag dabei und freuen uns schon sehr auf die Veranstaltung:

Wie finden Softwarearchitekten den Weg zu User Experience? Mit Google Maps!

Eine hervorragende Softwarearchitektur und eine tolle User Experience sind zentrale Erfolgsfaktoren von Softwaresystemen. Unser Vortrag betrachtet das Spannungsfeld zwischen diesen beiden Bereichen. Dabei gehen wir nicht nur auf die durchaus unterschiedlichen Personengruppen der Softwarearchitekten und UX Designer ein, sondern betrachten auch den Zusammenhang und die Tradeoffs zwischen tollen UX Konzepten und technischen Konzepten, die zur Umsetzung benötigt werden. Wir illustrieren am Beispiel von Google Maps, welche architektonischen Höchstleistungen notwendig sind, um die Google-Experience zu erreichen, das heißt: Google-typische Einfachheit zu gewährleisten und Google-typische Mega-Dienste überhaupt zu ermöglichen. Der Vortrag zeigt auf, wie trotz der unterschiedlichen Charaktere von Architekten und UX Designern großartige Systeme erschaffen werden können.

Wir freuen uns auf zwei spannende Tage mit inspirierenden Vorträgen, Begegnungen und Diskussionen. Alle Informationen zum Architecture Gathering 2016 gibt es hier.

IEEE Software: Piloting a Mobile-App Ecosystem for Smart Farming

IEEE-SW

In der aktuellen Ausgabe von IEEE Software erscheint unser Artikel zu einem mobilen App-Ökosystem für die intelligente Landwirtschaft. Der Artikel entstand zusammen mit Susanne Braun und Ralf Carbon. Hier die Einleitung der Editoren Olaf Zimmermann und Cesare Pautasso:

„As interconnected mobile applications plow their way into every possible application domain, they often require offline processing capabilities. Susanne Braun, Ralf Carbon, and Matthias Naab report from the  field that architects and developers must challenge traditional data management assumptions when they’re designing such mobile-app ecosystems. The authors designed a custom-solution architecture that balances conflicting quality attributes and harvested their architectural decisions on data replication and offline synchronization in the presence of unreliable network connectivity. We thank them for sharing this experience with us. —Cesare Pautasso and Olaf Zimmermann“

Mehr zu diesem Thema von uns: Never Again Offline?!? Video von SATURN 2015

Buch: Pragmatic Evaluation of Software Architectures

bookcover

In Kürze erscheint unser Buch Pragmatic Evaluation of Software Architectures, das ich zusammen mit meinem Kollegen Jens Knodel vom Fraunhofer IESE geschrieben habe.

Architekturbewertung leistet einen wesentlichen Beitrag zu Softwaresystemen mit hoher Qualität und zu fundierten Entscheidungen im gesamten Lebenszyklus eines Softwaresystems. Unser Buch stellt einen pramatischen Ansatz zur Architekturbewertung vor und präsentiert Erkenntnisse aus mehr als 75 Architekturbewertungsprojekten für Kunden aus unterschiedlichsten Branchen und Ländern, die wir in den letzten 10 Jahren durchgeführt haben. Wir zeigen neben der Methode auch zahlreiche Beispiele und Lessons Learned.

Das Buch ist entlang häufig gestellter Fragen aufgebaut und zeigt auch in der Praxis häufig gemachte Fehler und wie diese vermieden werden können. Das Buch wendet sich insbesondere an Praktiker in der Softwareentwicklung und gibt ihnen einen Leitfaden zur erfolgreichen Bewertung von Softwarearchitekturen an die Hand. Außerdem zielt das Buch darauf ab, Wissenschaftlern empirisch fundierte Einblicke in die praktische Bewertung von Architekturen zu geben und Inspiration für zukünftige Bewertungsmethoden und -werkzeuge zu sein.

Pragmatic Architecting – Webseite zum Buch

Vom 22.05. bis 22.06.2016 gibt es das Buch mit 20% Rabatt zur Vorbestellung bei Springer: Dazu einfach den Code NcB72JwXp22Y3Bg verwenden.

Buch bestellen bei Springer

Buch bestellen bei Amazon

On Tour: Bitkom AK Softwarearchitektur, Frankfurt

Bitkom AK Softwarearchitektur

Der Bitkom AK Softwarearchitektur trifft sich am 07. Juni 2016 in Frankfurt zum Thema: Moderne Rollenbilder für das Software Engineering

Wir sind auch mit einem Vortrag dabei:

Who is engineering the Software, which is eating the world?

Software revolutioniert die Welt und fast jede Art von Business durch Digitalisierung und neuartige Ökosysteme. Die Erstellung solcher Systeme erfordert Kompetenzen, die weit über das klassische Systems- und Software-Engineering hinausgehen. Zentrale Herausforderungen dabei sind domänenübergreifendes Arbeiten, immer höhere Komplexität bei trotzdem geforderter kürzerer Time-To-Market, geteilte Verantwortung und Kontrolle über mehrere Unternehmen hinweg sowie die immer höher werdenden Anforderungen an Sicherheit, User Experience, und andere Qualitäten. Wir stellen in diesem Vortrag die Charakteristiken von Softwareökosystemen vor und welche Kompetenzen notwendig sind, um diese zu bauen.

Hier geht es zur Agenda und zu Infos zum Veranstaltungsort.

Wir freuen uns auf spannende Diskussionen zu vielfältigen Facetten zukünftiger Rollenbilder im Softwareengineering.

Die Grüne Wiese ist nur noch eine Illusion!

Kreative Entwickler wünschen sich Projekte auf der Grünen Wiese. Jedoch zerstören weit mehr Einschränkungen als nur Legacy-Systeme diesen Wunschtraum.

"Die Grüne Wiese ist nur noch eine Illusion!"

Wir Softwareentwickler fühlen uns zunehmend eingeschränkt, beengt und nahezu erstarrt in unserem Schaffen und unserer Kreativität. Statt möglichst viel zu gestalten sind wir den Zwängen historisch gewachsener Systeme, überbordender Wartungsaufwände, verschleppter Modernisierung und veralteter Technologien erlegen. Das liegt daran, dass wir häufig in sogenannten Brownfield-Projekten arbeiten müssen, bei denen wir uns mit Legacy-Systemen rumärgern müssen.

Deshalb wünschen wir uns sehr oft, endlich mal wieder ein System auf der Grünen Wiese (Greenfield) hochzuziehen und die volle Freiheit zu genießen. Die Grüne Wiese lockt uns mit allem Gestaltungsspielraum und verspricht uns, mit unserer Kreativität die kompromisslos beste Lösung zu erreichen.

Gerne würden wir alles was wir haben hinter uns lassen und nochmal komplett neu entwickeln (siehe auch „Das neue System muss aber das Gleiche können …“). Noch lieber würden wir wie ein neues Startup, losgelöst von eingefahrenen Prozessen und Vorschriften, agieren und ein komplett neues System auf der Grünen Wiese hochziehen.

Was zerfurcht die Gründe Wiese?

Leider ist die Grüne Wiese heute nur noch eine Illusion und ihre Bebauung bleibt damit ein Wunschtraum. Nachfolgend zeigen wir 4 Kategorien von Einschränkungen, die uns die Grüne Wiese so gut wie immer verbauen, obwohl weit und breit kein Legacy-System zu sehen ist.

  1. Integration
  • Zunehmende Vernetzung: Fast kein System wird heute noch in Isolation gebaut. Daher zerfurchen uns die Vorgaben und Schnittstellen der Partner-Systeme die Grüne Wiese.
  • Ökosysteme: In Ökosystemen sind wir nie alleine. Deshalb verschandeln uns Kompromisse mit unseren Ökosystem-Partnern die Grüne Wiese.
  • Social Media: Die Erwartungshaltung von Nutzern ist heute eine tiefgreifende Integration mit globalen sozialen Netzwerken (z.B. Login mit Facebook oder Twitter). Die damit einhergehenden Vorgaben torpedieren die Grüne Wiese.
  1. Technologien
  • Frameworks: Frameworks und Technologien ermöglichen uns, dass wir uns besser auf unsere Kernfunktionalität fokussieren können. Die damit einhergehenden Einarbeitungsaufwände und Beschränkungen verhageln uns die Grüne Wiese.
  • Cloud Computing: Infrastructure-as-a-Service (IaaS) und Platform-as-a-Service (PaaS) bieten uns extreme Skalierbarkeit. Die Einhaltung der dazu notwendigen Architekturvorgaben verbaut uns die Grüne Wiese.
  • Mobile: Wenn wir erfolgreiche mobile Apps anbieten wollen, kommen wir an iOS und Android nicht vorbei. Die Entwicklungsplattformen, die Bereitstellung über App-Stores und die aufgezwungenen Geschäftsmodelle untergraben die Grüne Wiese.
  1. Richtlinien
  • Styleguides: Eine konsistente Benutzung und positive User Experience wird durch die Einhaltung von Styleguides erleichtert. Dadurch sind der Kreativität und Innovationen Grenzen gesetzt, die die Grüne Wiese ramponieren.
  • Enterprise Architecture: Mit der Vorgabe einer Enterprise Architecture verhindern große Unternehmen unkontrollierbaren Wildwuchs auch bei der Technologieauswahl. Diese Einschränkung zerstört die Grüne Wiese.
  1. Erwartungen
  • Erwartungshaltung der Nutzer: Bei vielen Nutzern hinterlassen weit verbreitete (de-facto Standard-) Anwendungen (wie z.B. Microsoft Word) eingebrannte Erwartungshaltungen bezüglich Benutzung und Funktionalität. Diese verbrennen die Grüne Wiese.
  • Aktuelle Trends: Was Nutzer als zeitgemäße und moderne Anwendungen wahrnehmen unterliegt sich ändernden Trends (wie z.B. Flat Design). Die Berücksichtigung dieser Trends verhunzt die Grüne Wiese.

Offensichtlich treffen diese Einschränkungen leider nicht nur auf Großunternehmen zu, sondern auch auf Startups. Lediglich die vorherrschenden Einschränkungen unterscheiden sich je nach Umfeld, in dem wir arbeiten.

Vergessen wir also den Wunschtraum von der Grünen Wiese. Verwenden wir lieber unsere Energie, um die verbleibenden Freiheitsgrade optimal auszunutzen, statt dem Phantom „Grüne Wiese“ hinterherzujagen.

"Verbleibende Freiheitsgrade ausnutzen!"

Kennt ihr noch weitere Einschränkungen in unseren oder weiteren Kategorien, dann schreibt diese bitte in den Kommentarbereich. Und vergesst nicht ein schönes Verb, wie dadurch die Grüne Wiese in Mitleidenschaft gezogen wird 😉

« ältere Beiträge « Neuere Beiträge

© 2017 mibinu

Theme von Anders NorenNach oben ↑