Tom,
Vorab erst mal herzlichen Dank für deine Verdeutlichung. Und ja, ich stimme dir, was die Veränderungen für vertikale Lösungsanbieter betrifft, voll und ganz zu. Diese Veränderung findest du aber ebenso bei Inhouse Software-Entwicklern - sie ist also Nischen/Fachübergreifend.
Vielleicht aber sind deine Analysen und Betrachtungen mehr nach Hinten gerichtet, was die Anforderung und/oder Zukunftsperspektiven betrifft? Bitte lass mich das mal in Ruhe darlegen.
Erstens wird der vertikale Markt in dieser Form - sagen wir: mittelfristig - verschwinden. Die klassische Branchenlösung als Standardsoftware vereint nämlich hohen Entwicklungsaufwand mit hoher Spezialisierung (worst of two worlds), und nur deshalb gibt es das überhaupt noch: Weil die Nutzer auf genau diese Lösungen, das Know-How der Anbieter und den hohen Integrationsgrad der Applikationen angewiesen sind (oder das zumindest glauben).
Korrekt, das muss aber nicht schlecht sein, denn es öffnet auch zugleich Chancen. Denn gleichzeitig findet auch ein Generationswechsel bei den Nutzern der vertikalen Lösungen statt. Und da ist es so, dass eher eine Mobile App als eine Laptop App, eher eine "Micro-App", die nur eine Aufgabe in einer Domäne bewältigt, bevorzugt wird, verglichen mit den CRM/ERP/Alles-Könnern. Wo früher das 5.000 EUR/DM POS/Kassensystem mit Mastercard Merchant Verträgen beim Frisuer oder in der Boutique war, ist heute die 49 EUR/Monat iPad/Pos Lösung mit Datenhaltung in der Cloud inkl. Kreditkartenabrechnung alla SumUp installiert.
Das ist nur ein Beispiel, zieht sich aber weltweit durch alle Branchen. Oder wo früher die mit Java EE erstellte Enterprise Lösung Inhouse entwickelt wurde - wohlgemerkt über viele Jahre hinweg von einem Inhouse Team - ist heute eine Microservice-basierte Kollektion von Diensten verfügbar, die von Web UI Frontend-Entwicklern oder nativen Android oder iOS Entwicklern dann benutzt werden.
Man könnte auch sagen, einfachere, kompakte Lösungen, die ohne "Schulung" und "Aufwand" in den Einsatz zu bringen sind und über wenig Merkmale verfügen, werden global bevorzugt. Oder etwas Technischer: "Die Zeiten der großen allmächtigen Monolithen ist vorbei". Ohne "Schulung", da diese Anwendungen sich im Prinzip auf wenige (1-5) Prozessabläufe in einer Domäne konzentrieren. Ohne "Aufwand", weil diese Lösungen vorwiegend in der Cloud installiert und gewartet werden - somit die gesamten administrativen Aufwände, als auch Investitions-Aufwände der Hardware/OS Plattform, entfallen.
Aber es rückt niemand nach
Klar rückt da niemand nach! Was für eine Frage, denkt doch nur mal an deine eigene Biographie! Full-Stack-Entwickler sind in einer derartigen mit "Hypes" überfrachteten Welt nicht mehr möglich und wenn einer ein Full-Stack-Developer ist, der auch noch was drauf hat - also der ideale Kandidat - tja, der gründet heute ein Startup, geht pleite, wird Technologie-Consultant oder schreibt sein "Die Wahrheit über..." Buch.
Während die Softwarewelt insgesamt große Schritte nach vorne macht, von denen unsereins nur eingeschränkt profitiert, sind gerade die vertikalen Anbieter oft damit überfordert, mitzuziehen, weil sich eine Handvoll Full-Stack-Entwickler hochkomplexe und sehr organisch gewachsene Projekte teilt.
Korrekt, und deshalb muss der Anbieter sich erst umstrukturieren, Ziele definieren und mit seinen Full-Stack-Entwickler(n) Schritt für Schritt umschwenken. Unabdingbar ist hier der Aufbau eines neues Produktportfolio, das mit dem Bestehenden harmoniert, aber den oben genannten Anwendungscharakteristika entspricht. Auch das Monetarisierungsmodel muss entsprechend angepasst werden. Wie bereits gesagt, das betrifft nicht nur den vertikalen Anbieter, auch die Inhouse Softwareteams unterliegen diesem Wandel und müssen Ihre Methodik und Ziele anpassen.
Mit anderen Worten, bietet doch eurem Bestandskunden, der eine Kassenlösung mit Backoffice hat, die Mobile-App an, mit der er zu jederzeit Daten aus dem POS Abfragen kann, oder vermietet eine Personal-Urlaubs-Genehmigungs App für die Manager, dann können die von Unterwegs Urlaub genehmigen, statt wie bisher im ERP System vor Ort. Als vertikaler Lösungsanbieter wisst Ihr doch ganz genau, wo euere Kunden einen Bedarf haben bzw. euere Vertriebsleute haben da doch bestimmt Ideen. Es reicht manchmal schon als ersten Schritt neue Funktionalitäten oder Abläufe als eigenständige Lösung entkoppelt von der bestehenden "großen" Anwendung auszuliefern. Und was die Monetarisierung betrifft, naja eure Kunden wollen Investitionen vermeiden, insofern sind Mietmodelle aus bilanztechnischer Sicht immer interessanter und wenn die dann auch noch sich dem jeweiligen Bedarf/User dynamisch anpassen, ist jeder "Leasingfreak" überzeugt. Oder analysiert, was die Startups mit iPad/Android/Web/Cloud in eurem Segment machen und erstellt ein wettbewerbsfähiges Produkt. Und bitte, wischt eure Bedenken über die Cloud/Datensicherheit und das alles weg, erstens ist da viel Panikmache darunter und zweites gewinnt die Bequemlichtkeit immer.
Stellt neues Personal ein, sucht nicht Full-Stack-Entwickler, sucht Web-Anwendungsentwickler mit einer Präferenz auf UX/UI. Da gibt es viele, die keinen Bock auf Backend haben. Nehmt recht früh Fachinformatiker oder Bachelor-only Informatikstudenten und baut diese Schritt für Schritt auf in eure Fußstapfen als Xbase++ Backend und nicht Xbase++ Full-Stack-Entwickler. Delegiert Aufgaben, kleinste Aufgaben an diese, deren Resultat ihr in euren "Fat-Client" oder euer Backend-System einbindet. Bindet Sie ein und isoliert diese nicht - und ändert eure Prozesse.
Selbst wenn die Xbase++-Lösung in den Backend-Bereich rückt und vorne mit React und Cordova und Angular und was weiß ich herumgeschraubt wird, ist die Struktur nur eingeschränkt zukunftsfähig. Während die Softwarewelt insgesamt große Schritte nach vorne macht, von denen unsereins nur eingeschränkt profitiert, sind gerade die vertikalen Anbieter oft damit überfordert, mitzuziehen, weil sich eine Handvoll Full-Stack-Entwickler hochkomplexe und sehr organisch gewachsene Projekte teilt.
Ok, reden wir mal Klartext, welcher folgende Konzepte/Vorgehensmodelle wendest du an:
- Versioncontrol System SVN/GIT oder andere
- Einsatz von Interfaces (Abstrakte Klassen) zwischen Logikkomponenten deiner Anwendung
- Single Responsibility beim Klassenentwurf
- Verfügst du über eine Liste von Refactoriung Mustern für deinen bestehenden Code? Eine Beispiel wäre "Verdrängung von PUBLIC/PRIVATE hin zu LOCAL/STATIC"
- Automatisierter Test der Module
Die Herausforderung besteht nicht darin einen Entwickler zu suchen, der so weitermacht wie bisher, sondern die bestehende Arbeitsmethodik und Prinzipien so zu transformieren, dass Dritte damit klar kommen und sich einklinken können. Die vorgenannte Liste von mir ist zwar nicht vollständig, aber in Wirklichkeit sind das vielleicht zehn Punkte, die es in der Methodik zu ändern gilt und schon wird mit jedem Tag das bestehende System zukunftsfähiger - wie du es nennst. Meiner Erfahrung nach würde ich sagen, das Ganze kann in einem 3-4 Tage Kurs vermittelt werden, und nach ein paar Monaten muss darüber reflektiert werden, was umgesetzt wurde und was nicht und entsprechend gegengesteuert werden. Ist nicht schlimm, tut nicht weh - ist aber nach vorne gerichtet. An Tag 1 und/oder 2 müßte sogar die Geschäftsleitung dabei sein.
Aber irgendwann wird das nicht mehr gehen. Und immer mehr Firmen werden dazu übergehen, sich von Beraterfirmen modulare Konzepte zusammenklicken zu lassen, mit denen sie dann dasselbe erreichen. Okay, noch nicht heute, aber sehr lange ist das nicht mehr hin.
Ja, sehr beindruckend (ja, ich weiß, Ironie ist im geschriebenen Wort schwer zu übermitteln), vor allem die "Baukästen", die eine Vielzahl von fertigen Schnittstellen zur Integration mitbringen und noch ein Workflow Modul integriert haben - beeindruckend und mit Sicherheit ausreichend, wenn man berücksichtigt wie umfangreich die Systeme angepasst werden können - aber das ist jetzt und heute. In 5, oder 10 oder 15 Jahren sind diese System genauso wenig beherschbar, wie der Monolith auf dem Desktop oder die J2EE Applikation im Rechenzentrum. Nur dass jetzt der Hersteller des Systems im Rahmen seines Lebenszyklusmanagements die 1. Generation des Baukastens nach 5 Jahren aus der Wartung nimmt und die 2. Generation nach 10 Jahren - mittlerweile wurde die Anpassung zwei mal auf unterschiedlichen Systemen durchgeführt und die dritte Generation lässt bestimmte Modifikationen nicht mehr zu - weil eure Modifikationen ein sogenanntes Minoritätsszenario darstellen. Das Unternehmen startet nun Überlegungen das Ganze wieder im Haus zumachen. "History repeats itself"
Ich verstehe, dass diese Baukästen beeindrucken, aber wie alles in der Welt, ist nicht alles schwarz/weiss, sondern eher grau und die Probleme der in die Jahre gekommenen vertikalen spezialisierten Lösung und der Baukästen-Lösung nähern sich über die Zeit.
Letzteres gilt im Übrigen auch für die vor 10 oder 15 Jahren erstellten Java oder .NET Applikation - egal was - nach 10 oder mehr Jahren ist da alles Legacy und ein neu hinzukommender Entwickler lacht sich scheckig - das ist ein Zitat - wenn nicht irgendwann gegengesteuert wird. Und darum dreht es sich, sich nicht dem ach so vermeintlichen Schicksal ergeben, sondern gezielt gegensteuern.
Wie du vielleicht aus meinen Ausführungen erkennen kannst, setzten wir uns bei Alaska Software mit dieser Problematik schon länger auseinander. Ich war auch schon bei vertikalen Anbietern oder Inhouseteams und wir haben genau jene Konzepte oder Vorgehen besprochen. Und ja, aus 2 Full-Stack-Entwicklern werden dann 2 Half-Stack Xbase++, ein Half-Stack IchLerneXbase++ und 2 Half-Stack Non-Xbase++ Entwickler. Aber das Unternehmen stellt sich nun dem neuen Wettbewerb, verändert sich, was ein durchaus spannender Prozess ist. Das Tolle daran ist - ich werde plakativ - wie plötzlich ein frischer motivierender Wind durch die Bude weht und selbst Vertriebler, die bereits die Rente planten, dann doch mal anfangen zu rechnen, was bei einem Abo-Model so an kumulativen Provisionen über Jahre zusammenkommt und möglicherwiese die dann etwas später fällige Rente doch ganz üppig aufstockt - Ende der Fiktion.
Natürlich gibt es auch andere Unternehmen - ich war mal vor 3 Jahren bei einem vertikalem Anbieter in DE - auch Marktführer blabla - und der Geschäftsführer hat vor versammelter Entwicklungsmannschaft mir als Vorgabe gegeben, dass es Ihn nur interessiert, welche Technologien er heute einsetzten soll, damit es bis zu seiner Rente reicht - das war echt super motivierend für die 5 Xbase++ Entwickler im Konferenzraum
. Wir haben denen dann die Xbase++ Lizenzen ohne Support geschenkt, viel Spass gewünscht und gebeten die Alaska Software nicht mehr zu kontaktieren. Ich weiß, war bescheuert von mir, aber Unternehmen/er haben eine gesamtgesellschaftliche Verantwortung und da einfach nur an die eigene Rente zu denken, Mitarbeiter und Kunden sozusagen geplant im Regen stehen lassen - das geht gar nicht.
Und ja, ich weiss diese Veränderungen gefallen Manchen nicht. Ich erinnere mich an ein Unternehmen - auch vertikaler Lösungsanbieter - die Desktop App wurde über 10-15 Jahre von einem Mitarbeiter erstellt und gepflegt, dieser ist dann ausgeschieden und ein Kollege hat sich eingearbeitet, der auch Clipper kannte und auch ein wenig Xbase++. Was dann aber passierte, war der Hammer, der Geschäftsführer bittet um eine Termin - in diesem erklärt er mir, dass der neue Mitarbeiter ihm gesagt hat, dass man mit Xbase++ auch auf SQL Datenbanken mittels ODBC zugreifen kann und auch später die PostgreSQL direkt verwenden kann, auch dass man mit Xbase++ Web Anwendungen bauen kann - der Herr ist aus allen Wolken gefallen, als er das gehört hat - warum? Naja, sein bisheriger Mitarbeiter hat es über viele Jahre hinweg immer wieder verneint und klargestellt, dass das eben nicht mit Xbase++ geht. Der Punkt, der Entwickler hat in Wirklichkeit keinen Bock mehr gehabt auf diese Veränderungen und ihm war die Firma egal - jetzt ist er weg, die Firma hat mittlerweile mehrere Xbase++ Entwickler und sieht wieder eine Zukunft.
Dieser Wandel ist manchmal sogar nur dadurch zu beherrschen, indem man eine neue Gesellschaft ausgliedert, an einem anderen Ort/Gebäude, indem jetzt die Produktentwicklung - also Xbase++ Entwickler und neue zusammen ohne das "Historische Umfeld" arbeiten - auch das habe ich schon erlebt.
Wir bei Alaska Software wollen diesen Wandel aktiv gestalten, deshalb die "cloud-first" Strategy und auch die WebUI für den Desktop usw usf. Mit anderen Worten: wir wollen euch eine Cloud-Plattform auf der Grundlage von Xbase++ zur Verfügung stellen, die nur Xbase++ Know How voraussetzt, es aber ermöglicht die im 11. Absatz genannten Szenarien und andere umzusetzen. Lasst uns einfach noch ein paar Monate Zeit, damit wir die Prioritäten richtig hinbekommen - wir haben hierzu ja viel Feedback im Rahmen unserer "cloud-first" Ankündigungen bekommen und arbeiten mit einigen Firmen hier sehr intensiv zusammen, um die Use-Cases und Business-Szenarien zu verstehen und bestmöglichst abzudecken.
Hoffentlich habe ich jetzt keinen Stuss geschrieben
Mit besten Grüßen aus Eschborn
Steffen F. Pirsig
Alaska Software Inc.
P.S. Diesen Thread sollten mal ein paar Geschäftsführer/Produktmanager von vertikalen Lösungsanbietern, die mit Xbase++ arbeiten, lesen (und verstehen)
Edit: QUOTES für die bessere Übersichtlichkeit eingefügt von HaPe.