t3n News Entwicklung

Softwareentwicklung: Warum „Das haben wir schon immer so gemacht“ ins Verderben führt

Softwareentwicklung: Warum „Das haben wir schon immer so gemacht“ ins Verderben führt

Durch das Internet haben sich nahezu alle Anforderungen verändert, die an und Softwareentwicklung gestellt werden. Aber haben das Vorgehen beim Erstellen von Software ausreichend an diese veränderten Rahmenbedingungen angepasst? Ein Gastbeitrag von Stefan Priebsch und Arne Blankerts.

Softwareentwicklung: Warum „Das haben wir schon immer so gemacht“ ins Verderben führt

Software-Entwicklung. Nicht mehr ganz zeitgemäß? (Foto: Last Hero / flickr.com, Lizenz: CC-BY-SA)

Nichts hat die Welt so schnell verändert wie das Internet in den letzten 15 Jahren, vielleicht abgesehen von einigen wirklich großen Meteoriten. Das Internet hat sich vom Nischenprodukt für Geeks zur einer zentralen, die ganze Welt miteinander vernetzenden Kommunikationsplattform entwickelt. Wie hat sich in dieser Zeit die Art und Weise verändert, Software zu entwickeln?

Software für das Internet zu schreiben, bedeutet, sich einigen ganz besonderen Herausforderungen zu stellen. Die Systeme sind rundum potenziellen Angriffen ausgesetzt. Die Anwender sind oft keine Fachanwender, sondern Endverbraucher mit einer sehr kurzen Aufmerksamkeitsspanne. Kein System steht allein in der Welt, sondern es kollaboriert mit anderen Systemen. All das bedingt, dass sich Internet-Software schnell weiterentwickeln muss. Während man eine klassische Bürosoftware oder eine Telefonie-Routing-Software vielleicht einmal im Jahr aktualisiert, sind mehrere Deployments am Tag für Internet-Software nicht unüblich.

Heute wird fast überall agil gearbeitet – oder zumindest nennt man es so. Und natürlich sind heute moderne Technologien wie NoSQL, Message-Queues oder Suchmaschinen schon sehr häufig im Einsatz. IT-Abteilungen sind jedoch noch viel zu stark in alten Denkmustern verwurzelt.

Die Entwicklung im Internet geht rasant voran. In manchen IT-Abteilungen herrschen aber noch alte Denkmuster vor. #FLICKR#
Die Entwicklung im Internet geht rasant voran. In der Softwareentwicklung herrschen oft aber noch alte Denkmuster vor. (Foto: D Petzold Photography / flickr.com, Lizenz: CC-BY-SA)

Softwareentwicklung aus dem letzten Jahrtausend

Eine der wichtigsten Annahmen dieser „alten Weltsicht“ scheint zu sein, dass relationale Datenbanken das Herz und die Seele eines jeden Unternehmens darstellen – oder zumindest für jedes große Unternehmen. Und wenn das so ist, dann ist offenbar eine der wichtigsten Aufgaben bei der Softwareentwicklung die Datenmodellierung. Software-Geek und Autor Robert C. Martin („Uncle Bob“) schrieb vor kurzem in seinem Blog: „Ich beobachtete mit Entsetzen, wie die Entwicklerteams die Datenbasis in das Zentrum ihrer Systeme setzten. Sie waren von dem endlosen Marketing-Hype überzeugt, dass das Datenmodell der wichtigste Aspekt der Architektur war und dass die Datenbasis Herz und Seele des Designs waren.“

Vor rund 30 Jahren war Speicherplatz knapp und teuer. Es war daher wichtig, Daten beim Speichern zu normalisieren, um Redundanz zu vermeiden. Das macht das Ändern von Daten einfach, da nur an einer Stelle geändert werden muss. Das Lesen von Daten allerdings wird erschwert, da von verschiedenen Tabellen verteilte Daten zusammengeführt werden müssen. Bloß: Speicherplatz ist heute kein Problem mehr.

Konsistenzgarantie, das Killer-Feature?

Daten werden häufiger gelesen als geschrieben. Selbst in schreibintensiven Web-Anwendungen kommen auf einen Schreibzugriff noch etwa sieben bis zehn Lesezugriffe. Hinzu kommt, dass in den meisten Anwendungen bestehende Daten nur selten geändert werden. Alle Gründe, die seinerzeit für die Normalisierung von Daten sprachen, sind damit zwischenzeitlich weggefallen.

Eine weitere wichtige Eigenschaft relationaler Datenbanken ist, dass sie die Konsistenz der gespeicherten Daten garantieren (können). Das funktioniert performant allerdings nur dann sinnvoll, wenn die relevanten Daten nahe genug zueinander abgelegt sind. Globalisierung und Dezentralisierung sind nicht gerade die idealen organisatorischen Voraussetzungen dafür.

„Unproblemte Lösungen“

In den letzten Jahren haben sich also die meisten Spielregeln grundlegend geändert. Und obwohl die meisten Teams inzwischen zusätzlich die eine oder andere neue Technologie einsetzen, ist die Motivation dafür oft, dass etwas gerade hip ist. Man schafft eine Lösung, ohne das Problem genau zu kennen. Die richtige Architektur entsteht dabei dann manchmal zufällig – oder eben nicht.

In der agilen Welt, in der Entwickler heute arbeiten, wirkt der Begriff „Architektur“ für viele bedrohlich, und „Software-Entwurf“ klingt so stark nach „Big Design Up Front“, dass man lieber darauf setzt, Architektur und Software-Design im agilen Prozess nach und nach entstehen zu lassen. Da man aber von Timebox zu Timebox an immer neuen Features schraubt, kommt die Frage nach den zahlreichen nicht-funktionalen Anforderungen der Anwendung gerne zu kurz. Und da man agil ist, verändern sich die Rahmenbedingungen, und zwar in kleinen und kaum wahrnehmbaren Schritten.

Auseinandergelebt

Nicht optimal: Die Anforderungen und die bereitstehende Architektur trennen sich. #FLICKR# – zugeschnitten
Nicht optimal: Die Anforderungen und die bereitstehende Architektur trennen sich. (Foto: Marcus Sümnick / flickr.com, Lizenz: CC-BY-SA)

Irgendwann kommt dann der Zeitpunkt, an dem die Realität der Anforderungen nicht mehr zu dem passt, was als Architektur vorhanden ist. Das bedeutet nicht unbedingt, dass die Architektur bereits zum Entstehungszeitpunkt ungeeignet gewesen wäre, sondern dass sich Problem und Lösung mit der Zeit voneinander entfremdet haben.

Es gibt zahlreiche bekannte Systeme, die auf PHP basieren und eine breite Nutzerschaft gefunden haben. Als Beispiele seien Wordpress, phpBB, Joomla, Typo3, Drupal, Wikimedia, osCommerce, xt:Commerce, Magento oder SugarCRM genannt. Alle diese Systeme haben gemeinsam, dass sie monolithische Anwendungen sind, die eng mit einer relationalen Datenbank verzahnt wurden. Vermutlich gibt es auch in anderen Programmiersprachen genug solcher Beispiele.

Was vor einigen Jahren mit begrenzten Datenmengen und nicht allzu viel Traffic funktioniert haben mag, reicht heute längst nicht mehr aus. Die monolithische Struktur erlaubt es aber nicht, die Software entsprechend anzupassen. Zur Rettung zieht man daher Caching-Schichten ein, wo es nur geht, oder baut gleich auf Basis eines Web-Beschleunigers wie Varnish ein völlig neues Frontend.

Fazit: Umdenken in der Softwareentwicklung

Eine monolithische, datenbankzentrische Architektur ist heute gerade für das Internet nicht mehr zeitgemäß. Viele Lösungen wurden in den letzten Jahren evolutionär weiterentwickelt, teilweise mit gutem Erfolg. Es ist nun an der Zeit, dass Entwickler und Architekten umdenken, denn zu oft ist der Ausgangspunkt von architekturellen Überlegungen noch ein Konzept aus dem letzten Jahrtausend, das für nicht-funktionale Anforderungen entworfen wurde, die schon längst nicht mehr zeitgemäß sind.

Dass interne oder externe Kunden häufig durch die Forderung nach einer bestimmten relationalen Datenbanktechnologie im Zuge der Aufgabenstellung schon einen Teil der Lösung vorgeben, macht für Entwickler und Architekten das Leben allerdings nicht gerade einfacher. Eine Architekturdiskussion muss von konkreten Technologien unabhängig sein.

Über die Autoren

webarchitektur-stefan-priebschStefan Priebsch (@spriebsch) ist Mitgründer von The PHP Consulting Company. Als Berater und Coach hilft er Teams, erfolgreich Software zu entwickeln. Als Vater von dreijährigen Zwillingen ist er zudem ein ausgewiesener Experte für Skalierungsfragen.

webarchitekturen-arne-blankertsArne Blankerts (@arneblankerts) ist Mitgründer von The PHP Consulting Company. Als Berater und Coach unterstützt er Teams sowohl dabei, sichere und skalierbare Software zu entwickeln als auch die passende Systemarchitektur zu entwerfen.

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
5 Antworten
  1. von sebs am 01.05.2014 (16:23 Uhr)

    Leider entsprechen die Gedanken überhaupt nicht dem effektiven Lean-Prinzip.
    Man weiß häufig gar nicht wo man am Ende mit einer Lösung landet. Besonders da es auch nicht immer eine Sorte von Daten gibt.

    Daher sollte man am Anfang mit einer monolithische, datenbankzentrische Architektur anfangen und bei wachsenden Anforderungen einfach die nötigen Schichten dazwischen packen.

    Gerade wenn es sich um Geschäftsdaten handelt, sollten diese am Ende sogar in einer zentralen relationalen Datenbank abgelegt werden.
    Dies erleichtert das Erstellen von Backups und die Verwendung für zukünftige Zwecke.

    Wer schon einmal von Systemen mit unterschiedlichen Speicherlösungen Backup-Lösungen entwickeln musste, oder eine Migration in ein neues System durchführen sollte hat gemerkt dass nicht alles Gold ist was glänzt.

    Antworten Teilen
  2. von CommentWelcome am 01.05.2014 (17:10 Uhr)

    Selten so einen Schwachsinn gelesen.
    Mit domain Driven Design steht die Anwendungs-Domain mit ihren Bounded Contexts im Mittelpunkt. Dies wird bereits seit Jahren z.b. in TYPO3, aber auch in TYPO3 Neos und TYPO3 Flow praktiziert. Über Repositories und entspr. Persistenz-Treiber ist es mittlerweile voellig egal, was für eine DB-Architektur oder ein NoSQL-Architektur mit Map/Reduce dahinter liegt. Die beiden Herren versuchen lediglich, sich als Heilsbringer darzustellen, und vergessen, daß die Entwickler um Sie herum laengst nicht mehr so monolitisch denken, wie sie annehmen.

    Antworten Teilen
  3. von MacSebi am 02.05.2014 (07:27 Uhr)

    hm... Leider nur ein mittelmäßiger Artikel. Während viel relativ konkret angeprangert wird, wird vermieden die dazugehörige Lösung gleich mitzuliefern. Umdenken? Ja! Nun kommt es auf das "wie" an...

    Antworten Teilen
  4. von Stephan Jaeckel am 02.05.2014 (14:35 Uhr)

    Andersmachen um es Andersmachen Willens? Nein Danke!
    Umdenken, nur um einen Denkprozess belegen zu können? Nein Danke!

    Insbesondere in großen Unternehmen besteht die IT-Infrastruktur aus viel mehr, als "dem Internet". Und gerade eben weil die Gefährdungslage dort so hoch ist, gerade deswegen denken Unternehmen zu Recht darüber nach, ob und wie und wieviel sie von sich und ihren Datenbeständen abgeben können (und dürfen) bzw. wieviel sie davon verteilen wollen und wohin.

    Und nur weil Speicher heutzutage nicht mehr das Problem ist, soll man soviel Speicher nutzen, wie man eben voll bekommt? Auch der kleinste Speicherbaustein kostet Geld, auch das kürzeste Stück Kabel muß bezahlt werden. Wenn heute in einem VW Polo mehr Computertechnik steckt, als in einer Apollo-Kapsel, dann ist dies kein Zeichen von technischem Fortschritt. Es ist ein Zeichen der Ausbreitung einer Technologie, was per se kein Fortschritt im betrieblichen Sinne ist.

    Im Unternehmen können auch einfache und manuelle Handlungen den erforderlichen, prozessualen Erfolg ausmachen. Sicherlich könnte die Tokyoter U-Bahn alle Bahnfahrer zu Beginn ihrer Schicht automatisch in ein Röhrchen pusten laasen und der Computer stellt dann fest, dass die Person nüchtern und fahrtauglich ist und checkt sie ein. Oder man spart sich die IT und lässt sich die Kollegen manuell in einem großen Büro vor vielen anderen eincheken und wo sie selber dann ihre Anwesenheitskarte mit Bild an eine große Wand hängen. Das kostet übrigens keinen Strom, keine IT-Wartung und keine Programmentwicklung!

    Verschwendung beginnt im Kleinen und viele sehr, sehr kleine Dinge und Positionen sind es meist, die ein Unternehmen in kostentechnische Probleme stürzen, Probleme deren Ursache dann nur schwer zu finden sind. In Japan hat man dafür die "drei M" definiert und von etwas zu viel zu haben ist ebenso Verschwendung von Ressourcen des Unternehmens, wie von etwas zu wenig zu haben, um die Aufgaben zu bewältigen.

    Die Grenze zwischen zu viel und zu wenig ist dabei nicht fließend sondern eine fast schon philosophische Grundlagenentscheidung des Unternehmens, die sich in einer Mengen Denken in Architekturfragen ausdrückt. Und nun ist es m.E. (als BWLer) nicht die Architektur, die ein Problem hat sich anzupassen, sondern die permanenten Neuerungen machen eine gut durchdachte Architektur schwierig.

    Noch schwerer wird es, weil ständig neue "Innovationen" auf den Markt kommen, die von Fachabteilungen "unbedingt" benötigt werden und sofort her müssen, sonst wird mit BYOD gedroht. Hierin drückt sich ein Mangel an gutem Denken und gutem Planen außerhalb der IT aus, auf den die IT wenig Einfluss hat. Und es ist ein Mangel, den die IT selber nicht komprimieren kann, egal wie agil sie nun wird.

    Denn selbst die unmöglichsten Verrenkungen bezüglich Schnittstellen, Datenhaltung, Synchronisation und APIs zur Erweiterbarkeit auch kleinster Änderungen können nicht komprimieren, dass ein Mangel an sauberem, koordiniertem und langfristig orientiertem Bedarfsdenkens bei den Fachabteilungen von Unternehmen besteht - egal von welcher Art Fachabteilung wir sprechen.

    Es kann und wird dort nicht technisch genug, nicht datenorientiert genug gedacht, nicht anhand der eigenen Prozesse und des eigenen zukünftigen Bedarfs, auch wenn der aktuell nicht technisch darstellbar oder konkretisierbar ist. Denn auch hier haben wir es mit einem Mangel zu tun: IT kann oft schlecht "Nein" sagen. IT macht abweichend von Architektur, bestehender Infrastuktur sowie Softwarelösungen Dinge oft möglich, weil sie dem Wohl des Unternehmens erkennbar dienen. So aber erzeugt IT auch Begehrlichkeiten, neue Anforderungen und agiert nicht sozial verantwortlich. Zu sozialer Verantwortung im Unternehmen - wie betrieblicher - gehört es nämlich auch, "Nein" zu sagen und verantwortliches Verhalten anderer Abteilungen einzufordern.

    So sind - sozial vereinfacht ausgedrückt - aus den Meisten Fachabteilungen in Unternehmen verwöhnte kleine Kinder geworden, die immer mehr mit ihren technischen Möglichkeiten machen wollen und immer neue Datenfelder und Input erzeugen wollen, ganz so als könnten sie den jetzt schon vorhandenen Input sinnhaft verwerten. Das können sie meist nicht und der höhere Input hat in der Vergangenheit auch nicht zu besseren Output geführt - jedenfalls nicht wesentlich bezogen auf die Investitionssummen. Fakt ist, dass heute nicht wirklich mehr geschafft wird als früher, weil die Produktivität unter dem selbst erzeugten Anpassungs- und Anschaffungsdruck gelitten hat und leidet, weil eben nicht genügend und hinreichend strukturiert nachgedacht worden ist.

    Gesunde Architektur und gesunde Prozesse sind unabhängig von technischen Veränderungen gut und stabil und zielführend, weil sie nicht verschwenden, weil sie gut durchdacht sind und eben nicht der Mode oder kurzfristigen Anforderungen gehorchen müssen (außer wir sprechen von Sicherheit). Fachabteilungen mit ihrer leider meist völlig fehlenden Einsicht und hilfsbereite IT-Abteilungen haben nicht das Recht diese notwendigen Grundlagen für ein gesundes Unternehmen irgendeinem Ziel zu opfern, welches es auch immer sein mag.

    Antworten Teilen
  5. von spriebsch am 02.05.2014 (15:46 Uhr)

    Vielen Dank für Eure Kommentare!

    @sebs: Ich stimme vielem, was du schreibst, zu. Allerdings glaube ich eben nicht, dass man monolithisch und datenbankzentrisch anfangen sollte. Ich will hier nicht den strapazierten Begriff SOA verwenden, aber für mich steht der Begriff "monolithisch" auch für den Versuch, ein sehr großes Problem in einem Schritt zu lösen, anstelle zuerst ein Teilproblem zu lösen und damit Business Value zu generieren. Insofern glaube ich, dass wir mit unseren Ausführungen von Lean-Prinzipien gar nicht so weit weg sind.

    @CommentWelcome: Wer Domain Driven Design praktiziert, denkt schon nicht mehr datenbankzentrisch. Deine Wahrnehmung ist, dass viele Entwickler bereits "Domain Driven" praktizieren. Wir erleben in unserer Beratungspraxis leider oft anders. Bei Teams, die beispielsweise Symfony oder Zend Framework einsetzen scheint Domain Driven Design längst nicht so weit verbreitet wie in der FLOW-Community.

    @MacSebi: Du hast völlig Recht mit Deinem Kommentar. Der obige Artikel ist ein erster Teil und in einem zweiten Teil werden wir über das "wie" sprechen. Der entsprechende Hinweis (der in unserem Originaltext vorhanden war) wurde allerdings von der Redaktion nicht mit veröffentlicht.

    @Stephan Jaeckel: Vielen Dank für Deinen ausführlichen Kommentar, der viel Einsicht beweist. Ich bin allerdings nicht sicher, ob wir beide unter "Architektur" das gleiche verstehen, insbesondere in Bezug auf Veränderungen. Ich würde das gerne per Mail vertiefen, wenn Du möchtest (stefan@thephp.cc).

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Mehr zum Thema Software
Software-, Web-, Frontend-, Mobile-, PHP-Entwickler oder UX-Designer: hardwrk, Sixt, plentymarkets, Otto, FitX, Spark5 und viele mehr haben noch Plätze frei
Software-, Web-, Frontend-, Mobile-, PHP-Entwickler oder UX-Designer: hardwrk, Sixt, plentymarkets, Otto, FitX, Spark5 und viele mehr haben noch Plätze frei

Zweimal pro Woche verweisen wir hier auf aktuelle und interessante Jobangebote aus unserer Stellenbörse „t3n Jobs“. Heute können wir euch 24 Angebote aus den Bereichen „Entwicklung“ und … » weiterlesen

Projektmanagement-Software: 10 kostenlose Lösungen
Projektmanagement-Software: 10 kostenlose Lösungen

Es muss nicht immer die Profi-Lösung sein. Kostenlose Projektmanagement-Software beziehungsweise Einsteigerversionen professioneller Lösungen eignen sich besonders für Freiberufler und kleine … » weiterlesen

Prinzipien der Software-Entwicklung einfach erklärt: SOLID
Prinzipien der Software-Entwicklung einfach erklärt: SOLID

Wer ernsthaft versucht, sich selbst das Programmieren beizubringen, wird schnell auf Objektorientierung, ihre Prinzipien und Designs treffen. In diesem Artikel stellen wir euch eine Methode vor: … » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?