Tag Archives: standardsoftware

IT explained

sclable: Das “rapid everything” ERP

Vergangene Woche hatte ich das Vergnügen, an einer sneak peek für ein überraschend neuartiges ERP-System teilzunehmen. Das Wiener Startup sclable tritt an, um das SAP oder Oracle von morgen zu werden. Die Ansage ist natürlich zu stark, um zu halten, aber dennoch ist das Produktkonzept mehr als nur einen Blick wert.

Ich würde sclable als Scaffolding Framework mit Workflows und hübschem UI beschreiben. Sagt vorerst wenig: Man kann damit jedenfalls sehr schnell individuelle Workflows in Software gießen und bleibt überdies flexibel. Es klingt ein wenig nach Heiligem Gral der Softwareentwicklung: Vorteile von Standard- und Individualsoftware vereint in einer Lösung, das Ganze durch geschulte Mitarbeiter in Eigenregie durchführbar.

sclable besetzt mit dieser Idee eine – zumindest für mich – komplett neuartige Nische im Unternehmen irgendwo zwischen zur Unhandhabbarkeit gewachsenen Excels, dem von Haus aus unhandhabbaren Sharepoint, der schwerfälligen Business Class mit SAP Workbench oder Oracle Forms sowie der Plugin-Architektur von WordPress.

Bereits nach der kurzen Einführung würde ich mir zutrauen, beispielsweise einen Bestellworkflow für ein mittleres Unternehmen mit sclable innerhalb weniger Stunden umzusetzen. So schnell, wie ich in sclable editiere, kann ich beim besten Willen nicht programmieren.

hgd
sclable at its best: Im Handumdrehen erstellte Entitäten werden mit beliebig komplexen Workflows verknüpft. Die graphische Darstellung ist bereits der halbe Weg zur Dokumentation.

Damit kommen wir zum wirklichen Vorteil: Durch die enorme Geschwindigkeit wachsen Spezifikation, Umsetzung, Test und Dokumentation zusammen. Es ist also vorstellbar alle Präsentationen, Powerpoints, e-Mails und Telefonate zu skippen und gleich gemeinsam mit dem Kunden loszulegen. Solange also die Aufgabenstellung zum Kern von sclable passt (“Mehrbenutzer-Workflow rund um ER-Modell”), ist’s ein Wahnsinns-Tool.

“Don’t ever fight a framework!”

Den Punkt, wo Customizing zur Vergewaltigung wird, darf man allerdings – wie bei jedem anderen Framework auch – nicht übersehen. Dann endet man schließlich wiederum in der Individualentwicklung, und hier würde ich dann generell zu Python/Django greifen. (Nun ja, da greife ich fast immer hin.)

Was paranoide oder Policy-geplagte CIOs beruhigen dürfte, ist außerdem die Info, dass das Produkt nicht nur als SaaS sondern auch on-premise laufen soll. Dank API sind Daten außerdem exportierbar, was langfristige Abhängigkeiten ohne Ausweg unterbindet.

Nachteil ist womöglich PHP als Runtime. Technisch ist es einfach pfui wegen fehlender Namespaces einer besch*** Standard Library, Patch-Wahnsinn, usw. Entwickler gibt’s jedoch genug. (Und mit Wikipedia oder Facebook gibt’s zugegebenermaßen ziemlich große PHP-Projekte, wo auch niemand über die Programmiersprache schimpft…)

Ich bin gespannt auf den Launch und weitere News von sclable.at!

Edit: Markus Nenning hat mich darauf aufmerksam gemacht, dass ERP eine nicht ganz korrekte Schublade für das Produktkonzept ist. Ich hab’s dennoch beim Titel belassen, da man sich mit bekannten Kategorien einfach leichter tut. Aber klar, mit der Flexibilität von sclable könnte man auch ganz andere Schubladen füllen – von Projektmanagement über CMS bis hin zu einem Universitätsverwaltungssystem.

IT project management

Kommerzielle Software, Open Source oder Eigenentwicklung?

Mit meiner Studierendengruppe an der FH-Wien habe ich Vor- und Nachteile unterschiedlicher Lösungswege bei der Softwareauswahl diskutiert. Wohl wissend, dass es Mischmodelle gibt, haben wir zunächst drei Extremfälle herausgearbeitet:

  • Kommerzielle und gleichzeitig proprietäre Software – also im Idealfall ein Standardprodukt, welches das betriebliche Problem abdeckt. Es wird lizenziert, dazu gibt es Wartungsverträge, der Anbieter kümmert sich um Installation, Roll-Out und Betrieb.
  • Nicht-kommerzielle, freie Software – also im Idealfall ein Open Source Projekt samt aktiver Community, welche ebenso an dem Problem arbeitet. Das Unternehmen kümmert sich selbst um Installation, Roll-Out und Betrieb.
  • Eine in-house oder externe (Eigen-)Entwicklung – also eine Software, die erst geschrieben werden muss. Noch lange vor der Installation gibt es also ein Softwareprojekt mit Anforderungsanalyse, Umsetzung, Tests, usw.

Sinn der Diskussion war zu zeigen, dass es keine universell beste Lösung gibt. Vielmehr konnten wir fünf Ziel-Kriterien definieren, die in Konkurrenz zueinand stehen:

  • Investitionskosten
  • Folgekosten
  • Geschwindigkeit (Projektdurchlaufzeit)
  • Risikominimierung (Wie “sehr” darf dieses Projekt nicht schief gehen?)
  • Flexibilität (Anpassungsfähigkeit, Weiterentwicklungen)

Lege ich meinen Fokus etwa auf maximale Flexibilität, so werde ich bei der Eigenentwicklung landen. Denn hier stehen mir sämtliche Freiheitsgrade offen, das Ganze allerdings zum Preis der Geschwindigkeit.

randbedingungen
Das Software-Fünfeck.

Im konkreten Einzelfall sind uU einige Kriterien gut miteinand zu vereinbaren, in anderen Situationen widersprechen sie sich total. Die fünf Punkte werden allerdings bei der Zielsetzung von Softwareprojekten hilfreich sein.

Parallel zu diesen Zielkriterien konnten wir drei Randbedingungen herausarbeiten, die den Entscheidungsprozess begleiten. Auch hier gilt, dass die Punkte an die konkrete Situation angepasst werden. IT-Sicherheit wiegt für eine Bank wohl deutlich höher, als für einen Sportverein. Die Randbedingungen sind:

  • Sicherheit
  • Zufriedenheit (Usability)
  • Bestehendes Ökosystem (Passt dieses neue Stück Software in meine IT-Landschaft?)
ddd
Die Randbedingungen.

Wer Interesse an einer Checklist für die Auswahl konkreter Software-Produkte hat, dazu gab’s bereits einen Blog-Beitrag.

IT project management

IT-Outsourcing – heilige Kuh des Managements

Auf meinem Flug nach Mumbai sehe ich eine Dokumentation über den Bau des Londoner Aquatics Centre, dem Landmark der Olympischen Spiele 2012. Selbe Architektin, noch größere Dimensionen spielen sich bekanntlich derzeit am Campus WU ab. Angesichts dieser ehrfurchtgebietenden Superlativa drängt sich eine Frage auf, die ich in den vergangenen Monaten immer wieder gehört habe: “Warum wird die Campus-Software von der WU selbst und nicht von professionellen Anbietern entwickelt?”

Eigentlich sind es zwei Fragen, die hier gestellt werden:

  1. Warum greifen wir nicht auf Standard-Software zurück?
  2. Warum wird Individualsoftware nicht durch Externe entwickelt?

Eins vorweg: Natürlich verwenden (und vor allem integrieren) wir Standardsoftware. Softwareentwicklung wird bei uns in den unterschiedlichsten Konstellationen und natürlich auch von Externen durchgeführt. Aber wir entwickeln etwa mit der Raumbuchung, dem automatisiertem Schließsystem oder den digitalen Hörsaalanzeigen viele Kernthemen der IT am Campus aus gutem Grund selbst.

Kabeltassen im Gebäude W1E - hier fließt schon bald unsere Software durch die Leitung.

Um bei einer Metapher des Bauprojekts zu bleiben wirkt es so, als ob wir unsere eigenen Maschinen, unseren eigenen Stahl und unseren eigenen Beton herstellten. Was bei klassisch-produzierenden Unternehmen sich wohl kaum rechnen würde, ist in der Softwareentwicklung allerdings Normalität. Durch den Wegfall von Fixkosten (keine Stahlwerke notwendig) und die de-facto nicht gegebene Standardisierung habe ich bei jedem Teilprojekt die Möglichkeit, eine individuelle make-or-buy Entscheidung zu treffen.

Make or buy?

Für eine Eigenerstellung sprechen jedenfalls die Kosten: Um Urlaubs- und Fehlzeiten bereinigte Stundensätze interner Entwickler betragen rund ein Drittel jener von Externen. Dass bei Dienstleistern und Softwarehäusern ständig die richtigen Experten abrufbereit säßen, ist ein leider allzu weit verbreiteter Irrglaube. Hüben wie drüben muss man Einarbeitungszeiten, Schulungen und Irrwege letztlich bezahlen.

Kommunikation unter Kollegen ist jedenfalls einfacher, als Projektmanagement zwischen Unternehmen. Mit Pflichten- und Lastenheften, die Sales oder Legal jedoch nicht den Entwicklern dienen, mit juristischen Prozessen rund um Beschaffung oder service level agreements, mit Excel-bewaffneten Consultants, die eine zusätzliche Abstraktionsschicht zwischen Anforderung und Umsetzung einziehen, entwickeln sich IT-Projekte sehr schnell zu bürokratischen Meeting-Marathons. Auf diesem Weg entstandene Software tut am Ende oft ganz anderes, als es die Prozessdokumentation sagt, und die Kosten stehen schließlich in zweifelhaftem Verhältnis zum Ergebnis. Ich habe mehrfach die paradoxe Situation erlebt, dass ein schneller, interner Hack bereits fertig war, bevor noch ein Kick-Off stattfand. (…)

Gleichzeitig gibt es allerdings eine Reihe an IT-nahen Dienstleistungen, die sehr gut ausgelagert werden können: Betrieb von Hardware, Grafik-Design oder Dateneingabe sind Beispiele, wo ich kaum überlegen würde.

Immer wenn die technischen Anforderungen entweder niedrig oder extrem hoch sind, jedenfalls  aber wirklich nur wenn die Anforderungen der Benutzer klar sind, dann zahlt sich Outsourcing aus.

Denn dann sind Leistungen überschaubar und somit Preise verhandelbar, und man profitiert vom Spezialwissen der Experten. (Das Stacey Diagramm lässt sich also womöglich auch für make-or-buy Entscheidungen vergewaltigen.)

Die Standarsoft-Mär

Wäre die Diskussion über die Vorteile interner und externer Individualentwicklung nicht ohnehin hinfällig, würde man von vornherein auf Standardsoftware setzen? Nun, vieles, was bei Individualentwicklung zum Einsatz kommt, ist ohnehin standardisierte Software in Form von Betriebssystemen, Datenbanken, Frameworks und Libraries. Software zu entwickeln bedeutet zu einem großen Teil, derartig generell-anwendbare Bausteine zu einem individuell-leistungsfähigen System zu kombinieren.

Gleichzeitig ist vieles, was Standardsoftware heißt, fernab von Standardisierung, wie man sich das etwa bei einem Auto vom Fließband vorstellt. Auch wenn Banken, Airlines oder eben Universitäten Software der Big Player einsetzen, so passiert bei der Integration ins Unternehmen zwangsweise immer wieder dasselbe: Früher oder später enden die Möglichkeiten des Customizing, und Berater, Sub-Firmen oder interne Entwickler schreiben spezialisierte Programme, um das Ding zum Laufen zu bringen. Das bedeutet aber auch, dass die Abhängigkeit von einzelnen Personen auch bei Standardsoftware nicht geringer ist.

Business-IT ohne Abhängigkeit von einzelnen Schlüsselpersonen ist eine Mär!

Mit steigender Komplexität der Anforderungen wird es also zunehmend unwahrscheinlich, dass ein Anbieter genau das erfüllt, was ein ein Unternehmen benötigt. Das Resultat heißt bei Standardsoftware dann erst wieder Individualentwicklung.

Indien - Land der IT-Hotlines und heiligen Kühe. Mathias, Mumbai 2012.

Und hier schließt sich der Kreis, zu den oben gestellten Fragen. Ich genieße jetzt mal meine Tage in Indien – übrigens ein Land, wo mein Job aus genannten Gründen doch nicht so schnell hinwandern wird…