Wir begleiten hin und wieder Projekte, in denen ein ganzes System oder ein Systemteil von Grund auf neu aufgebaut werden soll. Dabei stellt sich dann ganz natürlich die Frage, ob man nicht auf einer existierenden Technologie bzw. einem Softwareprodukt aufbauen könnte, um Aufwand für die Entwicklung zu sparen und so schneller an den Start zu kommen. In diesem Artikel geht es darum, solche Entscheidungen fundierter zu treffen.

Beispiel: In einem Projekt, das wir begleitet haben, sollte eine Datenplattform (Datendrehscheibe) aufgebaut werden, um Anbieter und Konsumenten von Daten zusammenzubringen. Dafür waren viele Features angedacht: Markplatz für Daten, Suche nach passenden Datenarten, Anlegen von Subscriptions, Harmonisierung von Daten über unterschiedliche Anbieter hinweg, Datenübertragung von Anbietern zu Konsumenten und vieles mehr. Es war völlig klar, dass man ein solches Produkt für den spezifischen Anwendungszweck nicht von der Stange kaufen kann; dennoch haben wir uns nach passenden Technologien umgeschaut, um damit bestimmte Basis-Funktionalitäten einfacher umsetzen zu können, wie oben beschrieben.

Auf der Management-Ebene passt es leichter …

Der CEO war ein sehr guter Netzwerker und hatte viele Kontakte. So saßen wir bei vielen Produktvorstellungen und Technologiedemos mit sich in Regelmäßigkeit wiederholendem Muster: Man beschreibt in groben Zügen, was die Vision ist, welche Ideen man hat und was man dafür gut brauchen könnte, und dann kommt recht schnell die Versicherung: „Das ist mit unserem Produkt kein Problem!“ In unserem Beispiel ging das etwa so „Was Sie da beschreiben, ist ja eigentlich ein Integrationsproblem, über Organisationsgrenzen hinweg. Unsere Enterprise Service Bus Plattform ist genau für solche Aufgaben gemacht. Damit können Sie hervorragend …“

Dass Anbieter so argumentieren, ist natürlich nachvollziehbar. Sie haben ein inhärentes Interesse ihr Produkt zu vermarkten und genau in diesem Licht muss man diese Diskussionen auch bewerten. Ein solcher Anbieter wird nicht denken: „Was ist der beste Lösungsansatz für die beschriebene Problemstellung?“, sondern „Wie bekomme ich die beschriebene Problemstellung möglichst gut auf unser Produkt gemappt?“. Und was fehlt, kann man ja ganz einfach noch dazubauen. Klingt harmlos, ist aber oft der erste Schritt in eine sehr teure Sackgasse.

Das Management liebt solche Gespräche. Wenn die Flughöhe nur hoch genug ist, sieht auf einmal alles total passend aus. Und mit viel persönlicher Überzeugungskraft klingt die präsentierte Lösung dann schnell wie der logische nächste Schritt. Insbesondere wenn man selbst noch in einer frühen Phase der Findung ist und sich schon potentielle Lösungen als Inspiration anschaut: Dann fällt der Abgleich noch schwerer und der Fürsprecher für das Produkt hat noch leichteres Spiel. Gerne gezogenes Argument ist dann auch: „Das integriert sich dann super in ihre bestehende Landschaft von Anbieter ABC.“

… als in der fachlichen und technischen Realität

Das Management ist in Gesprächen schnell begeistert: Cool, das passt, wir kommen schnell voran! Darin steckt aber ein großes Risiko: Bleibt man auf der hohen Abstraktion, merkt man erst später, wie wenig die angebotene Lösung tatsächlich passt.

Jede Technologie und jedes Softwaresystem kommt mit zahlreichen Annahmen zu deren Nutzung und Kontext. Bei einer für das eigene Vorhaben ungeeigneten Lösung ist man schnell mehr mit „passend machen“ beschäftigt als mit der Entwicklung der Kern-Funktionalität. Das Basteln an Workarounds frisst schnell den Vorteil durch die bereitgestellte Basisfunktionalität auf. Im Ergebnis ist man dann ganz schnell beim Gegenteil von dem, was man sich eigentlich erhofft hat: man ist langsamer und teurer unterwegs.

Für das Management ist diese Beurteilung nicht zu machen; dafür sind sie zu weit weg von der Technik. Deswegen ist es umso wichtiger, dass wir als Techniker diese Perspektive einbringen und eine fundierte Beurteilung der angebotenen Lösung vornehmen.

Wie sichert man eine Auswahlentscheidung ab?

Ein Softwareprodukt „von der Stange“ ist offensichtlich nicht für die eigenen Bedürfnisse erstellt worden. Das heißt nicht, dass es nicht passen könnte oder nicht passend gemacht werden könnte oder dass man vielleicht auch seine Bedürfnisse etwas einschränken könnte.

Wichtig ist, dass es uns hier um substantiell wichtige Softwaresysteme und Produkte für ein Unternehmen geht. Wenn jemand ein Tool braucht, um seine Bildbearbeitungsaufgaben zu erfüllen, dann kann die Auswahl vielleicht sehr schnell getroffen werden. Je näher aber ein Softwaresystem an das Kern-Business eines Unternehmens heranrückt und die Erbringung dieses Kern-Business ermöglichen soll, desto genauer muss draufgeschaut werden. Dazu empfehlen wir gerne unseren Artikel Software für die Digitale Transformation kann man nicht kaufen, nur selbst bauen.

Bei unserer Betrachtung geht es also hauptsächlich um geschäftskritische, zentrale Software, die als Basis für das Kern-Business und vielleicht auch als Basis für die Kernsysteme dienen soll. Software also, die auch eng mit typischerweise vielen anderen Systemen integriert werden muss.

Es gibt also keinen Grund, zu früh in großen Optimismus zu verfallen. Dafür passt es einfach zu häufig dann doch nicht gut genug. Gerade wenn die Anbieterseite vor Zuversicht strotzt und mit Hochglanz-Folien das Produkt anpreist, dann braucht es einen ruhigen Gegenpol, der mit der notwendigen Portion Neutralität und vielleicht auch Skepsis dagegenhält.

Tiefe in die Diskussion bringen und hinter die Kulissen blicken

Der zentrale Ansatzpunkt für eine gute Auswahlentscheidung ist es, die Diskussion von einer oberflächlichen Verkaufsveranstaltung zu einer tieferen, sowohl fachlichen als auch technischen, Ebene zu führen.

Die absolute Voraussetzung dafür ist, selbst gut genug verstanden zu haben, was man eigentlich erreichen möchte und welche Rolle das gerade betrachtete Softwareprodukt dabei spielen könnte. Während das natürlich extrem offensichtlich klingt, passiert es in der Praxis häufig genug trotzdem nicht. Wie immer hilft es enorm, seine Ideen und Bedürfnisse präzise aufzuschreiben. Dabei sollte sowohl die Grundphilosophie abgedeckt sein als auch zentrale, repräsentative Features und zentrale Qualitätsanforderungen.

Und dann kann es schon losgehen, am besten in Meetings mit Experten des Anbieters der begutachteten Software. Vor allem geht es darum, viel zu fragen und immer wieder nachzufragen. Sich nicht abstrakt zuquatschen lassen, sondern die eigenen Bedürfnisse klar formulieren und dann erklären lassen, wie diese konkret mit dem Kandidatenprodukt umgesetzt werden würden.

Diese Betrachtung hat zwei Ebenen: Wie sieht es für zukünftige Nutzer aus (also über der Haube) und wie funktioniert es architektonisch und technisch (also unter der Haube). Beides ist wichtig!

In dieser Diskussion kommt man schnell zu einer Vorstellung, ob das Produkt zu den eigenen Vorstellungen passen könnte. Gerade beim Abtauchen ins eine oder andere Detail wird einem vieles schnell klarer, z.B. welche Dinge konfigurierbar sind und wie sich Konfiguration dann auswirkt. Wenn das Kandidatenprodukt schon existiert, schaut man sich die Software am besten live an und diskutiert anhand dessen, was zu sehen ist. Anhand anschaulicher Beispiele von Features, Prozessen und Daten lässt sich sehr konkret machen, wie etwas aussehen könnte. Von dort aus ergeben sich auch sofort gute Anschlussdiskussionen über die technische Umsetzung unter der Haube. Man kann sich für alles, was man an der Oberfläche sieht, auch zeigen lassen, wie es umgesetzt ist.

Kompakte Architekturbewertung

So ergibt sich eine abgespeckte, schnelle und kompakte Architekturbewertung. Dabei geht es darum, möglichst viel Relevantes über die vorliegende Architektur zu lernen und zu einer Einschätzung zu kommen, wie gut die Architektur zu Zielen und Bedürfnissen passt. Wir haben hier einige Tipps für diese konkrete Situation einer Architekturbewertung, die als Ergänzung zu üblichen Methoden der Architekturbewertung zu sehen sind:

• Man muss sich klarmachen, dass hier eine grundsätzlich andere Ausgangssituation vorliegt als bei der Bewertung eines individuell entwickelten Systems: Das System wurde nicht im Wissen der eigenen Anforderungen gebaut, sondern es hat eine ganz andere Historie. Deswegen müssen etwas andere Maßstäbe in den zu erwartenden Kompromissen angelegt werden.
• Es ist klar, dass die Entwicklungsverantwortlichen die eigenen Anforderungen noch nicht kennen, deshalb muss man sie passend und kompakt erläutern. Es ist also ziemlich viel Dialog nötig und nicht nur „Vorführung“.
• Die Tipps, die wir im Artikel „Ich will sehen.“ formuliert haben, lassen sich auch hier alle anwenden.
• Wie viel Zeit und Aufwand man investieren muss, hängt wie immer von Größe des Systems, organisatorischer Komplexität und Kritikalität ab.
• Manchmal kann man nach kürzester Zeit sagen, dass ein Kandidatenprodukt nicht passt, einfach weil zu große Lücken zum Bedarf bestehen. Dann ist man mit der Untersuchung schon fertig. Wenn es hingegen passend aussieht, muss man etwas länger schauen, damit die wesentlichen Aspekte tatsächlich in Breite und Tiefe gut abgedeckt werden. Das ist ein wesentlicher Unterschied zu einer „üblichen Architekturbewertung der eigenen Software“, wo man sich gerade wenn das Ergebnis unerfreulich ist, umso tiefer in das eigene System reinhängen muss, um es wieder auf die richtige Bahn zu lenken.

Es ging uns schon häufig so, dass wir solche Diskussionen in Auswahlprozessen begleitet beziehungsweise durchgeführt haben und dann kam nach recht kurzer Zeit, typischerweise so nach einer Stunde, schon die Rückmeldung: „So genau wollte es noch nie jemand wissen!“. Das ist natürlich bezeichnend, wenn eine Untersuchung von ca. einer Stunde schon als so außergewöhnlich tief wahrgenommen wird. Wir fragen uns dann gerne, wie andere Auswahl- bzw. Verkaufsgespräche so laufen und auf welcher Basis dann die Entscheidung wirklich getroffen werden kann.

Vergleich zwischen mehreren Kandidaten

Besonders spannend wird die Situation, wenn es mehrere Kandidaten zur Auswahl gibt. Typischerweise sind diese recht unterschiedlich, und zwar in vielerlei Hinsicht.

Auch hier ist das obige Vorgehen natürlich anwendbar. Besonders spannend ist dann aber die Zusammenführung der Ergebnisse, die Herstellung von Vergleichbarkeit und wie man daraus wirklich eine Entscheidung bzw. Entscheidungsvorlage ableitet.

Neben der Bewertung des Systems, seiner Benutzung und seiner Architektur spielen hier natürlich noch viele weitere Aspekte mit rein, z.B.:

• Ökonomische Aspekte wie Lizenzgebühren und auch rechtliche Fragen
• Perspektive der Langfristigkeit, mit der ein Produkt angeboten wird
• Art der Kooperation zwischen Anbieter und Käufer, vor allem bei größeren Anpassungen und Integrationen

Diese Aspekte gegeneinander abzuwägen kann im Einzelfall sehr herausfordernd und diffizil sein. Dafür gibt es auch kein allgemeines Rezept. Wichtig ist es, möglichst neutral zu arbeiten und eine gewisse verbleibende Unschärfe auch nicht durch vermeintliche Präzision kaschieren zu wollen. Im Zweifel ist es ehrlicher und besser zu sagen, dass die Kandidaten in vielen Aspekten zu einer ausgeglichenen Bewertungssituation geführt wurden, dass man sich aber bei einem Kandidaten eine deutlich bessere Zusammenarbeit vorstellen kann. So entscheidet dann eventuell ein eher „softes“ Argument, das aber in der täglichen Arbeit später einen großen Unterschied machen kann.

Fazit

Es ist nachvollziehbar, dass Anbieter ihr Produkt verkaufen wollen. Sie haben einen Hammer, und damit ist auch klar, dass sie die Problemstellungen ihrer potentiellen Kunden zum Nagel machen; oder ihnen zeigen, wie man es als Nagel sehen kann.

Für einen selbst ist aber die wichtigste Aufgabe, die geeignetste Lösung für das Vorhaben zu finden. Deswegen ist die wichtigste Empfehlung in Besprechungen mit Technologieanbietern: skeptisch sein! Wir müssen Dinge konkret machen und unter die Haube schauen. Um schnell zu einer Einschätzung zu kommen, können wir eine kleine Turbo-Architekturbewertung machen: Wir gehen anhand von konkreten Beispielen durch, lassen uns zeigen, wie diese mit der Lösung umgesetzt werden können und lassen uns daran erklären, wie diese technisch umgesetzt sind.

So kommen wir sehr schnell zu einer schon recht belastbaren Einschätzung, ob wir es grundsätzlich mit einer passenden Lösung zu tun haben, die wir weiterverfolgen können.