Softwareentwicklung in der Zukunft

Wenn wir heute für Kunden Software entwickeln, dann handelt es sich noch oft um monolithische Systeme – in sich geschlossene Softwareprodukte für einen definierten fachlichen Use Case.

Eine grundlegende Änderung der Fachlichkeit führt oft zu umfangreichen Entwicklungsaufwänden oder gar Änderungen an der zu Grunde liegenden Softwarearchitektur. Die Änderungen können damit oft nur in langen zeitlichen Perioden und damit auch kostenintensiven Projekten umgesetzt werden.

Verstärkt wird das Problem durch die Anforderung, eine Software nicht mehr nur noch in klassischen Client-Server-Architekturen zur Verfügung zu stellen, sondern auf diversen mobilen Plattformen.

In einer Zeit der sich immer schneller wandelnden Anforderungen des Marktes sind die Unternehmen aber gezwungen, sich schnell an anzupassen. Die monolitischen System sind dabei hinderlich.

Was wird sich also in der Softwareentwicklung ändern? Schauen wir uns einmal in der sogenannten “Cloud” um. Dort finden sich diverse Beispiele.

Beispiel 1: Landlord
Landlord ist ein Spiel, welches Monopoly-ähnlich funktioniert. Der Spieler findet auf seinem Mobiltelefon die in seiner Umgebung befindlichen Lokationen, z.B. öffentliche Gebäude. Mit seinem Spielgeld kann er ein Gebäude “kaufen” und erhält Miete, wenn andere Mitspieler in seinem Gebäude sind. Spannend daran: das Spiel bedient sich der Lokations-Datenbank und des Check-In-Mechanismus von Foursquare. Will man sich neues Spielgeld kaufen, so werden Abrechnungssysteme anderer Hersteller genutzt. Die Kette verlängert sich, da Foursquare wiederum zum Aufbau seiner Lokationen in der Startphase auf Google Maps zugegriffen hat.

Beispiel 2: Salesforce
Salesforce ist als CRM-Tool hinlänglich bekannt. Es bietet eine Unzahl von API-Schnittstellen, mit der ein Entwickler seine Anwendung an das CRM-System anbinden kann. Ein Salesforce einsetzendes Unternehmen kann das CRM-System neben der üblichen Freiheit der individuellen Konfiguration also vollständig in seine Prozesse einbinden und ist nicht mehr gezwungen, sein CRM selbst zu programmieren.

Beide Beispiele zeigen, dass eine Software in Zukunft vor allem eines benötigt: Schnittstellen zu anderen Systemen – und zwar unternehmensübergreifend. Sicherlich spielen dabei Datenschutzerwägungen eine nicht unerhebliche Rolle, sind aber durchaus zu lösen.

Softwareentwicklung wird sich beschränken müssen auf die wirklichen unternehmensspezifischen Anforderungen und sich koppeln mit Systemen, die allgemeine Anforderungen bereits problemlos bereitstellen. So lassen sich massiv Kosten sparen, indem Standardfunktionen hinzugekauft werden und über eine Schnittstelle angesprochen werden können.

Nebenbei können die bisherigen Anbieter großer Softwareprodukte einen vollkommen neuen Markt erschließen.

Nehmen wir als Beispiel die großen Rechenzentren von Banken. Warum bieten sie keine flexiblen Schnittstellen in ihr Kernbankenverfahren an? Die Banken haben massive Abwanderungen vom Zahlungsverkehr zu Diensten wie PayPal oder den eigenen Bezahlverfahren der großen Anbieter wie Google oder Amazon zu verzeichnen. Was aber kann mir meine Volksbank oder Sparkasse anbieten, wenn ich dort nach einem entsprechenden Dienst anfrage? Nichts…

Und wenn ich dem Gedanken des guten alten Bankschließfaches folge und bei meiner Bank nachfrage, ob ich meine elektronischen Dokumente nicht auch dort hinterlegen kann? Dann gibt es höchstens einen unkomfortablen Dateiabload in einer kleinen Ecke des Homebankings mit einer unattraktiven Schnittstelle.

Oder warum bietet man den Kunden nicht eine sichere E-Mail an für alle Kunden bei einer Sparkasse oder Volksbank (immerhin haben die beiden Gruppen alleine schon einen extrem hohen Marktanteil – wenn man es anhand der ausgegebenen Karten rechnet, sind es rund 70% | Quelle: Bankenverband). Beste technische Voraussetzungen bei aktuell drei und zukünftig zwei Rechenzentren. Mit der Chance für die Banken, diesen Kanal gleich für ein Marketing mit zu benutzen.

Es gibt unzählige Beispiele, wie eine Bank ihr Portfolio zeitgemäß verändern könnte und damit nicht zusehen müsste, wie andere innovative Unternehmen ihnen nach und nach die Marktanteile und damit die Verdienstmöglichkeiten entziehen. Wahrscheinlich mangelt es gar nicht an Ideen. Nur die Umsetzung ist mit der heutigen IT so schwer durchzuführen, dass die Phantasie für solche neuen und innovativen Produkte einfach fehlt.

Social Business: Einführung der Software

Bisher war die Einführung einer Software meist ein Projekt der IT. Installation, Administration, Schulung – und fertig war das Projekt. Auch die Pflege der Software wurde der IT überlassen.

Vergessen wir diese Vorgehensweise bei der Einführung einer Social Software. Wer die Einführung so betreibt, wie oben beschrieben, wird mit einer hohen Wahrscheinlichkeit scheitern.

Warum ist dies so und warum gibt es hier Unterschiede?

Social Software wird nur erfolgreich funktionieren, wenn die Unternehmenskultur passt. Wir sprechen bei der Einführung also von einer Änderung der Unternehmenskultur mit Unterstützung einer passenden Software. Und nicht von einer Änderung der Unternehmenskultur durch Einführung einer Software.

Mit anderen Worten: die Kulturänderung muss verstanden, gewollt und gelebt werden – dann kann eine Software dabei helfen.

Hier liegt ein großes Missverständnis in der bisherigen Vorgehensweise der meisten Softwareimplementierung. Ganz häufig wurden die Prozesse an die Belange der Software angepasst. Über Jahre erfolgreiche Softwareprodukte sind genau anders herum vorgegangen.

Eines ist gewiss: die IT wird bei der Einführung der Software nur eine untergeordnete Rolle spielen.

Am wichtigsten ist die Geschäftsführung: sie muss die Änderung wollen und – ganz wichtig – auch vorleben. Mitarbeiter dürfen nicht dafür bestraft werden, dass sie Themen veröffentlichen und vielleicht nicht immer genau zu 100% die Deckung zu den Sachen, die auf ihrem Schreibtisch liegen, hinbekommen. Es muss gewollt sein, dass der Mitarbeiter über seinen Tellerrand schaut und auch kommuniziert, was er dort sieht. Natürlich immer im gültigen Rahmen – es geht nicht darum, sensibel zu behandelnde Informationen in die Breite zu streuen.

Die Geschäftsführung muss dies akzeptieren. Ganz im Gegenteil: sie muss solche Verhaltensweise belobigen und ausdrücklich fordern und fördern. Erst wenn die Mitarbeiter sehen, dass es die Geschäftsführung ernst meint, wird sie die Hemmungen verlieren und mitmachen.