Tag Archives: Agile

IT architecture

Rethink reuse

Although I cannot share details of my current work except of fancy presentations there’s one general topic that keeps haunting me in a lot of discussions: The question of reusing code and components across platforms, target audiences, use cases, etc.

At first glance it looks like a brilliant idea: You build something once and use it several times for various use cases. Technicians love such a concepts because they’re motivated by complex problems; business people of course are fond of possible cost-reduction; IT architects love to draw boxes with arrows around them and usually feel big pain when comparable boxes appear twice in their diagrams.

The problem: Good ideas do not always work out. And what annoys me the most is the fact that software reuse seems to be an unchallenged goal, a mantra nobody dares to question. A lot of the obvious side-effects are rarely considered when going for reuse, such as:

  • growing complexity by serving additional requirements. This complexity exists in many areas, e.g. coding, testing, decision-making, etc.
  • operational issues by serving multiple target groups/stakeholders, e.g. when can you do a maintenance window?
  • losing advantages you’d have from very focused implementations, e.g. performance, optimized UX, etc.

The Space Shuttle: a terrible example of reuse

Let’s look at an example outside of my world of IT: The Space Shuttle – or better called the Space Transportation System (STS) – is an almost perfect case study where cost reduction and related benefits where promised from reusing components.

Just by looking at the picture below you can actually see (or at least imagine) all the parts which were only needed to fulfill reuse: wings with their heat shield, a tail, landing gear including unnecessarily heavy tyres, a fully functional cockpit for landing, solid liquid boosters (two rockets on the side) which fell down back into the ocean, etc.

As it turned out the Space Shuttle was limited in capacity, only reached low orbits, was more expensive and eventually killed more people than any other comparable space launch system. (A nice read on forbes.com)

Space Shuttle Launch
One of the most impressive vehicles ever built – and a total fail: The Space Transportation System.

Not being an expert on space travel let’s get back to IT. The example above just shows that there was tremendous overhead just to satisfy the requirement of reuse. As an architect I will in the future try to think twice and try to locate the space shuttle projects amongst my tasks. Reusing stuff is really cool, but only as long as it makes sense.

business

Selbständig neue Wege gehen

Nach spannenden Jahren an der WU ist es für mich an der Zeit, einen neuen Weg zu beschreiten.

Und da ich wohl kaum einen abwechslungsreicheren Job als meinen bisherigen finden werde, führt der Weg in die Selbständigkeit.

Die Firma ist gegründet, sie heißt c99 und wohnt (noch) daheim im Bügelzimmer, die ersten Umsätze sind getan, und – am Wichtigsten – es macht wirklich Spaß!

frere
Visitenkarten druckfrisch in den Händen meiner Grafikerin.

Manage complexity

Business und IT sind unglaublich komplex – oder schlimmer noch – kompliziert. Ein zentrales Thema meiner bisherigen Arbeit war der langfristige Umgang mit betrieblicher Komplexität. Dazu zählen unklare Anforderungen genauso wie häufige Änderungen, Zeitdruck, Ressourcenmangel oder externe Gesetzgebung.

Ich habe an der WU vermutlich um die zwei Millionen Zeilen Code geschrieben und dabei wohl jeden Fehler begangen, aber – anders als externe Berater – diese auch selbst ausbaden müssen. Ich habe mich in unzähligen Umgebungen (Webanwendungen, Data Warehouse, Zutrittskontrollsysteme, Smartcards, SAP FI/CO und HCM, Kiosk Terminals) und Programmiersprachen (Python, JavaScript, Perl, PL/SQL, C, ABAP, Java, PHP) ausgetobt.  Ich habe viel gelernt und habe nun ebenso viele Ideen.

ddd
“Wie gründe ich eine GmbH?”, angewandte Komplexitätsreduktion: Mein Weg zur eigenen Firma.

Ich werde mich dem Thema Komplexität widmen – sei es als Berater, Entwickler oder in einer gänzlich anderen Rolle. Die Nachfrage danach ist jedenfalls enorm.

What’s in a name, what’s in a logo?

Abschließend nun ein wenig Namens- und Logo-FengShui, weil ich sehr oft gefragt wurde, was denn c99 zu bedeuten hätte.

dfh
Logo und Subline der c99 Business Services GmbH.

Das c steht für 100 Begriffe wie createconsult, code, communicatecompete oder cooperate – jedenfalls nicht für complicate. Den guten 99 will ich mich widmen, complicate gilt es zu verhindern. Außerdem sind die 99 eben nicht 100 – für manche hat das den Touch von unfertig, für mich von Effizienz und Pragmatismus. Aber wer beim nächsten Waschmitteleinkauf 10,99 zahlt und dabei an c99 denkt – auch ok.

Das Logo wiederum spielt mit einer Referenz zur Chemie: Unsere physische Welt besteht aus lediglich knapp über hundert Elementen. Die unglaubliche Vielfalt wird erst durch Kombinationen dieser wenigen Einzelteile erreicht. Modularität spielt jedenfalls auch in der IT eine herausragende Rolle. Die stilisierten Atombrücken – in der IT würde man sie Interfaces nennen – stellen diese Kombinationsmöglichkeiten dar.

Und ganz nebenbei: Das kleine c ist der 99. Buchstabe im Unicode.

tltr;

Mathias ist jetzt selbständig. Abseits des esoterischen Namens und Logos bestehen inzwischen echte Umsätze.

Webseite der c99 Business Services GmbH

IT project management

Campus WU: Drei Jahre in drei Minuten

Drei Jahre intensive (Projekt-)Arbeit, oder physikalisch ausgedrückt: Große Masse mal hoher Geschwindigkeit mal viel Weg.

“Man muß ins Gelingen verliebt sein, nicht ins Scheitern.”
Ernst Bloch

Door Signs

Über 200 Stück am gesamten Campus verteilt: Starten und aktualisieren sich über Netzwerk, gehen nachts schlafen, lesen Blinden die Belegung vor und kosten dabei ein Viertel der ursprünglichen Planung.

hj
61 der über 200 Displays vor Ort. Die angezeigte MAC-Adresse diente als Key bei der Inbetriebnahme.

Blogs dazu:

Self Service Terminals

Zehn Selbstbedienungsautomaten vor dem Study Service Center: Eine technische Herausforderung, barrierefrei, verbesserte Usability und – nach wahnsinnig stressiger Inbetriebnahme – inzwischen stabil.

bsfdb
Zwischenzeitlich haben tausende Studierende die Self Service Terminals im Library Center genutzt. (Sechs Terminals im Bild mittig; © Mathias August 2013)

Blogs dazu:

Final-Teilnahme beim Niederösterreichischen Innovationspreis.

Rooms

Dezentrale Raumbuchung für knapp 30.000 Benutzer_innen: Inhaltlich ist es Logistik pur samt dynamischer Lagerhaltung, Simulation, Statistik und passenden Visualisierungen. Rein technisch eine Herausforderung in JavaScript.

fff
Screenshot: User Interface der Raumbuchung für Studierende.

Blogs dazu:

Byte Bar und Leitsystem Terminals

fgfg fg
Die ByteBar- und Leitsystem-Terminals vor der Montage am Campus WU; Codename “Super-Toblerone”.

Surfstationen mit Login mittels berührungsloser Karte; Touchschirm, barrierefrei. Das Schwesterprojekt “Leitsystemterminal” dient zur Orientierung am Campus.

Blogs dazu:

API

gsg
Digital Signage Screens, die prominentesten Kunden unserer Lehrveranstaltungs-Daten API.

Viele unserer Daten sind – auch öffentlich – über Programmierschnittstellen verfügbar. So greifen alle hier beschriebenen Services auf dieselben Daten zurück, überall liest dieselbe Stimme Blinden vor, überall läuft dieselbe Logik, das Design ist gleich: managing complexity eines übergroßen Projekts eben.

Identmedien RFID

Eine Studierende holt sich einen Ausweis, verschließt ihre Sachen in einem der 3.600 Spindkasteln, bezahlt anschließend bargeldlos in der Mensa und öffnet einen gebuchten Projektraum: Keine Selbstverständlichkeit, läuft aber (immer besser).

Campus GIS

Geo-Informationssystem des Campus WU: Verortung von Personen und Organisationen, Suche nach POIs, Modellierung eines Routingnetzwerks zur Navigation, Flug einer Drohne für hochauflösende Luftbilder. Tool live: gis.wu.ac.at

Detaillierte Pläne, Suche, Routing bis hin zum Buch
Im Screenshot: Detaillierte Pläne der Regale zum Auffinden von Büchern in der Universitätsbibliothek.

Thanx + Uff!

Gerne würde ich hier behaupten, ich hätte das Alles programmiert, habe aber dann doch oft nur E-Mails geschrieben oder bin in endlosen Meetings gesessen. Ich musste langweilige Ausschreibungstexte querlesen, extern erdachte Konzepte ertragen, Kostenschätzungen durchs Haus schicken, Ideen verteidigen und am Widerstand Dritter scheitern sehen… Vier Befestigungsschrauben meiner Terminals kosteten mich so ein halbes Jahr Abstimmungsaufwand.

Als im Feuer getaufter Planerschlossertischlerdesignerentwickler kann ich nun verorten, kollaudieren, ausschreiben, beschaffen, eintakten, einbringen, einkippen, und Katzen hüten. Ich habe am Weg viele beeindruckende Menschen kennengelernt und dafür bin ich dankbar.

Es war ein Heidenspaß, ein Riesenstress und manchmal auch ein Mordsärger, vor allem aber war’s einzigartig und großartig. Wann und wo wird also der nächste Campus gebaut?

hacks

Writing emails to a website

Unix’ beauty lies in the fact that you can easily build powerful systems out of simple components. This post describes an email-to-database interface for one of our web applications using Python and some Unix tools.

Users came up with the urgent need to annotate database records with arbitrary content. Rather than bending our application into a document management system (which apparently it is not) I came up with the idea to offer an email-to-website service.

Or as my friend Florian put it: “With a few billion users, email is quite a succesful social network.”

Mailing to a script

In order to write mails to a program rather than a conventional mailbox you need to edit the file /etc/aliases .

booking:        |/opt/wu-wien/roomsmta/bin/booking.sh

Here I’m sending the mail to an address called booking. Every incoming mail invokes the shell script booking.sh.

If you want to forward your mail to other locations simply add mailboxes or addresses after a comma. Don’t forget to run newaliases after the file is saved.

 Shell wrapper

#!/bin/sh

PYTHON_EGG_CACHE=/opt/wu-wien/roomsmta/cache
export PYTHON_EGG_CACHE

exec /opt/wu-wien/roomsmta/bin/booking.py

The incoming mail is passed to a shell script which sets some environment variables needed for virtualenv. The Unix command exec passes standard input on to the Python script. The result will be a custom Python interpreter set up with its very own environment.

The Python script

My script reads the email from STDIN, does some parsing magic and eventually puts the content into a database. (For reasons of clarity I have omitted the latter part in my example.) Since my mail configuration saves the mail in a proper mailbox as well I do not store attachments in the database. If you’re interested in parsing attachments I recommend Ian Lewis’ post.

#!/opt/wu-wien/roomsmta/v_mtapy/bin/python
import email.FeedParser
from email.utils import parseaddr

import sys, os
import base64
import re

import cx_Oracle

def parse_email(email_input):
    """Return message object"""
    
    parser = email.FeedParser.FeedParser()
    msg = None
    for msg_line in email_input:
       msg = parser.feed(msg_line)
    msg = parser.close()
    
    return msg


class Email(object):
    
    
    def __init__(self, msg):
        
        self.msg = msg

        self.subject = msg['Subject']
        self.date = msg['Date']
        (self.from_name, self.from_email) = parseaddr(msg['From'])
        
        self.to_email = parseaddr(msg['To'])
        
        self.has_attachments = 0
        
        msgbody = []


        for part in msg.walk():
            
            if part.get_content_type() == 'text/plain':
                
                if part['Content-Transfer-Encoding'] == 'base64':
                    body = unicode(base64.b64decode(part.get_payload()), part.get_content_charset(), 'replace' )
                
                else:
                    
                    try:
                        body = unicode(part.get_payload(), part.get_content_charset(), 'replace')
                    except TypeError:
                        # if no charset is given
                        body = unicode(part.get_payload())
                msgbody.append(body)
                
            elif part.get_content_type() == 'text/html':
                
                html = unicode(part.get_payload(), part.get_content_charset(), 'replace')
                raw = nltk.clean_html(html)          

                msgbody.append(raw)
                #print raw.encode('utf8', 'replace')

            elif part.get("Content-Disposition"):
                #print part.get("Content-Disposition")

                self.has_attachments = 1
                msgbody.append(u'ATTACHMENT: %s' % (part.get_filename(),))

        self.body = u'\n'.join(msgbody)
    
    def save(self):
        
        print 'GOING on to save'


if __name__ == '__main__':
    
    
    email_input = sys.stdin.readlines()
    msg = parse_email(email_input)
    
    Email(msg).save()

Testing the setup

Testing your code turns out to be a nightmare since you will need a mail client to invoke your script. Fortunately Unix comes with pipes which mock the email behavior:

less my_test_mail.eml | ./booking.py

Addressing records in the database

Did you know that you can have plus signs in a valid mail address?

Until now we have written all our email to booking@servername. But what you need in an application context is the possibility to clearly  attribute incoming email to specific database records. I have seen some solutions carrying the magic in the subject field, but I prefer RFC2822‘s possibility to write content after a plus sign into the address field. In my case this will either be the record’s id and the database instance in use (i.e. test or production).

        tocc = '%s %s' % (self.msg['To'], self.msg['Cc'])

        # has formats:
        #   booking+1234T@localhost
        #   booking+1234P@localhost
        #
        m = re.search('booking\+\d+[PT]', tocc)
        
        try:
            
            tocc = m.group(0)

            instance = tocc[-1:] 
            tid = tocc[:-1].replace('booking+','')
            
            return (instance, tid)
        
        except AttributeError:
            raise NoEventFound

Voilá, I can write mails to booking+1234T@servername.

Mail’s in the database – mission accomplished.

Thanks to Roland and Willi who did the tricky work;-)

hacks

Die Tetris-Maschine

Der innerste Kern meiner Tätigkeit als Softwareentwickler ist die Erschaffung von Algorithmen. Dass das deutlich spannender sein kann als es klingt, will ich anhand eines aktuellen Projekts zeigen.

Beginnen wir mit einer Aufgabe: Gegeben ist die dargestellte Auslastung von vier Hörsälen. Es soll nun eine weitere Veranstaltung zwischen 13:00 und 14:00 (blau markiert) gebucht werden – welcher Raum ist nicht nur verfügbar, sondern auch optimal passend?

In welchem Raum soll der gewünschte Termin (13:00 bis 14:00) untergebracht werden?

Als Algorithmen werden in der Informatik Handlungsanweisungen zur Lösung eines Problems verstanden. Algorithmen können so etwa als Kochrezepte für Computerprogramme verstanden werden. Sie berechnen Manager-Boni, kümmern sich bei Word um die Rechtschreibkorrektur, twittern Aktienkurse oder – wie in meinem Fall – verhelfen der WU künftig zu einer optimierten Ausnutzung der Ressource Raum.

Algorithmisches Denken ist die Umkehrung von Schul-Mathematik. Beim Programmieren ist die Lösung bekannt, aber es gilt den Weg dorthin zu entdecken.

Das Teaching Center am Campus WU: Stählerner Schauplatz für Raumbuchungs-Tetris im XXL-Format. Mathias, 2012.

Jedenfalls: Bei unserem Re-Write der Raumverwaltung für den Campus WU sind wir mit einigen, höchst spannenden Anforderungen konfrontiert: Raumbuchungen sollen künftig automatisch und optimal durchgeführt werden, den Administratoren bleibt allerdings jedwede Flexibilität erhalten. Die Software kümmert sich dabei um Studien- wie Stundenpläne, um Verfügbarkeit der Lehrenden und “Extrawürschteln” ebenso, wie um Minimierung von Buchungslücken oder Reduktion unnötigen Reinigungsaufwands aufgrund zu vieler, “angepatzter” Hörsäle. Die Ressourcen sollen flexibel verfügbar sein (Stichwort dynamische Lagerhaltung), ein allzu häufiger Ortswechsel macht Studierende wie Lehrende aber wohl kaum glücklich.

Wir benötigen daher wieder einmal den “Do what I want“-Button:

       +-----------------+
       |                 |
       | DO WHAT I WANT  |
       |                 |
       +-----------------+
Button, der in jeder Software genau 
das tut, was der User will. 
(Grobkonzept)

Von der Idee zum Algorithmus

Die Aufgabenstellung lautet demnach:

  • Liefere für eine Serie von Terminen (z.B.: ein ganzes Semester) Buchungsvorschläge
  • innerhalb der angefragten Raumkategorie,
  • versuche dabei die gewünschten Zeiten zu erfüllen,
  • d.h. immer dieselbe Beginnzeit zu ermöglichen,
  • vermeide außerdem Raumwechsel,
  • aber vermeide noch viel mehr den Wechsel von Gebäuden.
  • Beachte, dass Buchungen nahtlos aufeinanderfolgen sollten.
  • Entstehen dennoch Lücken, so sind z.B.: 30 Minuten sehr schlecht, weil dieser Zeitraum sicher verloren ist,
  • 90 Minuten hingegen sind gar nicht so schlimm, weil ja noch etwas reinpassen könnte.
  • Bereits “angepatzte” Räume sind leeren vorzuziehen, weil dadurch der Reinigungsaufwand verkleinert wird.
ggg
Geistreiche Bilder vom Entstehungsprozess des Algorithmus. (…)

 

Die Grenzen der Berechenbarkeit

Ein naiver Lösungsansatz wäre nun, alle Möglichkeiten zu versuchen und die beste zu wählen. (Tatsächlich funktionieren viele Algorithmen nach diesem Prinzip.) In diesem Fall bekommen wir aber ein Problem mit der Dimension der Aufgabe:

Will etwa jemand an acht Montagen irgendwann zwischen 9:00 und 12:00 eine zweistündige Lehrveranstaltung abhalten, so ergeben sich (zu) viele Buchungsmöglichkeiten. Entlang eines 15-minütigen Rasters erhalten wir zunächst fünf mögliche Beginnzeiten (9:00, 9:15, 9:30, 9:45, 10:00). Diese fünf Beginnzeiten über rund 50 gleichwertige Seminarräume an acht Montagen ergeben acht mal fünf mal 50 – also zweitausend – Einzelmöglichkeiten. Die Berechnung der Kombinationsmöglichkeiten ergibt 15 Quintillionen [sic – 250hoch8 – eine 15 mit 18 Nullen]!

Wir reden allerdings nicht nur von einer Veranstaltung, sondern von knapp 4000 jährlich mit rund 35000 Einzelterminen – Tendenz Dank erweiterter Buchungsmöglichkeit für Mitarbeiter und Studierende stark steigend. Selbst wenn ein leistungsfähiger Rechner eine Milliarde Kombinationen pro Sekunde ausprobieren würde, wäre die erste Raumbuchung erst nach knapp 500 Jahren fertig…

Tetris

Glücklicherweise gibt es Tetris! Ähnlich wie bei den von oben fallenden Steinen kommen auch die Buchungswünsche Schritt für Schritt herein. Jede Buchung muss auf die jeweils aktuelle Belegung Rücksicht nehmen, kümmert sich aber nicht um das, was noch kommt. Genauso wie bei Tetris ist es auch bei Raumbuchungen sinnvoll, Lücken bestmöglich zu füllen, oder doch für passgenaue Steine in naher Zukunft frei zu halten.

Tetris-Klon von Nintendo: Dr. Mario. Aufgrund unseres akademischen Kontexts an der WU die wohl bessere Analogie.

Die Matrix

Tetris-Analogie hin oder her, noch besteht das Problem der zu vielen Lösungen. Manchmal hilft es, die Aufgabenstellung in kleine Teile zu trennen, das Problem zu abstrahieren, sich typische Situationen aber vor allem auch Grenzfälle (corner cases) zu überlegen.

Eine Terminserie zu unterschiedlichen Beginnzeiten, in Gebäuden und darin enthaltenen Räumen entspricht einer vierdimensionalen Matrix, so einer Art Excel-Tabelle, wo in jeder Zelle nochmal eine Tabelle enthalten ist. (Keine Sorge, so etwas kann auch ich mir nicht wirklich vorstellen.)

Die Einträge in dieser Matrix sind jedenfalls:

  • pro Termin
  • pro Beginnzeit
  • pro Gebäude
  • jede verfügbare Raumnummer
  • mit Bewertung der Passgenauigkeit

Die Passgenauigkeit beträgt 1, wenn der Raum einfach frei ist, 0 wenn er gebucht ist. Sollte ein Termin nahtlos reinpassen, erhöht sich der Wert über 1, bleiben Lücken, so bekommt der Raum Strafabzüge. Die Datenstruktur sieht früher oder später so aus:

{Termin1: {'12:00': {Gebaeude1: {Raum1: 0.47250000000000003, Raum2: 1.6}}},
 Termin2: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 1,
                           Raum2: 1,
                           Raum3: 1,
                           Raum4: 1}}},
 Termin3: {'12:00': {Gebaeude1: {Raum1: 2, Raum2: 2}}},
 Termin4: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 2,
                           Raum2: 2,
                           Raum3: 1,
                           Raum4: 1}}},
 Termin5: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 0.45,
                           Raum2: 0.3375,
                           Raum3: 1,
                           Raum4: 1}}},
 Termin6: {'12:00': {Gebaeude1: {Raum2: 0.45, Raum3: 1, Raum4: 1}}},
 Termin7: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 1, Raum3: 1, Raum4: 1}}}}

Die optimale Buchung

Die beste Lösung findet man nun nicht durch stumpfsinniges Ausprobieren, sondern durch geschicktes Durchschreiten der Datenstruktur. Der Lösungsweg lautet:

FÜR jede Terminanfrage    
  FÜR jede Beginnzeit gereiht nach Häufigkeit terminunabhängig
    FÜR jedes Gebäude gereiht nach Häufigkeit in Beginnzeit
       FÜR jeden Raum gereiht nach Passgenauigkeit in Beginnzeit
         VERSUCHE zu buchen
         ODER gehe weiter

Die Lösung der eingangs gestellten Aufgabe lautet übrigens “Raum B”. Oder wenn Sie zufällig ein Algorithmus sind:

{1: {'12:00': {123456789: {66778801: 0.47250000000000003, 66778802: 1.6}}}}

Übrigens: Geschafft in 0.7 Sekunden anstatt von 500 Jahren.

tltr;

Raumbuchen ist wie Tetris-Spielen; Excel kennt zum Glück keine Tabellen in Zellen.

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…

hacks

Ein Raumangebot, das man nicht ablehnen kann

Meine Blog-Posts zum Thema Campus WU drehten sich bislang eher um Hardware-Projekte. (SB-Terminals, Infoscreens, elektronische Türschilder, etc. – alle müssen mit großer Vorlaufzeit geplant und beschafft werden.) Dabei gibt es mit der Raumverwaltung ein Software-Thema, das sich aus zwei Gründen zu meinem Lieblingsprojekt entwickelt: Einerseits stellt eine Raumbuchungssoftware DAS absolute Querschnittsthema in einem intelligenten Gebäude dar, andererseits wird unser Projekt die Art und Weise, wie Menschen am Campus zusammentreffen um zu lehren, forschen und lernen, nachhaltig verändern. Davon bin ich inzwischen überzeugt.

Room Resourcing – hinter diesem Anglizismus versteckt sich ein WU-weites Projekt, welches die unbürokratische und vor allem effiziente Bereitstellung von Räumen am Campus 2013 zum Ziel hat. Zum process owner gekürt, treffe ich in diesem Projekt, anders als in meiner sonst dienstleistenden Rolle als IT-Fachkraft/Nerd, auch inhaltliche Entscheidungen.

Ausgangslage

An der WU werden pro Semester einige tausend Veranstaltungen abgehalten. Der überwiegende Teil davon ist dem Bereich Lehre zuzuordnen, der – wenig überraschend – unseren Kernprozess darstellt. Die Buchung von Lehrveranstaltungen hat folglich mit zahlreichen Regelungen und Randbedingungen wie Gesetzen, Dienstverträgen, Gehaltsabrechnungen oder Studienplänen zu tun. Die Buchung eines Meetingraums in einem beliebigen Bürogebäude ist mit unseren Anforderungen jedenfalls wenig vergleichbar.

Derzeit werden diese Buchungen über eine zentrale Stelle organisiert. Nur so kann sichergestellt werden, dass alle Veranstaltungen in ein räumlich doch sehr begrenztes Gebäude passen. Buchungswünsche abseits der Lehre, werden von einer separaten Organisationseinheit in ebenso separaten Raumgruppen gebucht. Es wird also ein Prozessproblem durch Aufteilen der Flächen umgangen, was teilweise dazu führt, dass Anfragen trotz freier Ressourcen im anderen Bereich nicht erfüllt werden können.

Veränderte Bedingungen

Durch den Umzug auf den Campus WU wird eines der zentralen Probleme der Universität (großteils) der Vergangenheit angehören: Platznot. Moderne und vielseitig nutzbare Veranstaltungsflächen, Hörsäle, Seminar-, Projekt- und Meetingräume werden Lehre und Forschung Platz schaffen und ihnen dadurch neue Qualität verleihen.

Dennoch wird es weiterhin Engpässe geben. Beliebte Wochentage, Uhrzeiten oder uni-typische Saisonen werden nach wie vor zu Nachfragespitzen führen, die selbst mit dem doppelten Raumangebot nicht befriedigt werden könnten.

Die Herausforderungen bei der Erstellung eines Raumverwaltungssystems besteht demnach im Lösen eines Verteilungsproblems. Dazu kommen einige interessante Ideen – hier also unser Plan:

Chaos pur!

Wie schafft man es also, ein Mehr an Veranstaltungen in einem fix dimensionierten Gebäude unterzubringen? Die Antwort lautet chaotische Lagerhaltung. Dieses Logistik-Konzept beschreibt Lager ohne festes Ordnungssystem. Das bedeutet, dass Pakete dank Identifizierung via Barcodes oder RFID genau dort abgelegt werden, wo sie haargenau Platz finden. Lager werden dadurch besser ausgelastet, Ranbedingungen wie etwa Wegzeiten außerdem optimiert.

Umgelegt auf unser Raumbuchungssystem werden Veranstaltungen eben genau in jenen Räumen platziert, die möglichst lückenlos frei stehen. Es werden also neue Ressourcen frei, weil etwa 45minütige Leerstände oder nicht notwendige Rüstzeiten (Änderung der Bestuhlung) reduziert werden. Ein Leitsatz bei unseren Planungen war es, dass die räumliche Flexibilität der Lehrenden eher eingefordert werden sollte, als die zeitliche. Oder andersrum: Lehrende sollen zu ihren Wunschzeiten lehren, müssen aber mit einem automatisiert zugewiesenen Raum auskommen.

Ich wähle meine Wunschzeit, die Software weist mir automatisch einen passenden Raum zu.

Um gleich ein Gegenargument zu entkräften: Gelegentliche Ortswechsel einer wöchentlichen abgehaltenen Veranstaltung bedeuten kein großes Malheur, da die Räume ohnehin standardisiert sind. Denn obwohl 2013 mehr Räume zur Verfügung stehen werden, wird es weniger unterschiedliche Raumtypen geben. Ein Bereitstellen der Buchungslage auf Smartphones und Infoscreens reduziert den Planungsaufwand auf ein vertretbares Minimum: Man wird immer sehr schnell sehen können, wo man hin sollte.

Von 5 auf 30.000 Nutzer_innen

Der zweite Paradigmenwechsel passiert auf Ebene der Buchenden selbst. Zurzeit sind das etwa fünf Personen, da der Prozess zentralisiert ist. Doch mit kommenden Jahr will die WU die Buchung in die Hände der Mitarbeiter und Studierenden geben! Alle Menschen an der Universität erhalten dann die Möglichkeit, ihre Veranstaltungen dezentral zu reservieren, unbürokratisch zu verschieben, kurzfristig nach Flächen zu suchen, usw.

Je mehr ich über diese De-Zentralisierung nachdenke, desto mehr freue ich mich auf den Campus WU. Eine Universität, die ihren Mitarbeitern und Studierenden qualitativ hochwertige Räume zur Verfügung stellt, ist ein spannender Ort zum Lernen und Forschen – ein Nährboden für große Leistungen!

Mock-up der Ansicht für Mitarbeiter wie Studierende.

Natürlich gibt es eine Reihe an Randbedingungen wie Planungssicherheit für Lehrveranstaltungen oder Fair Use, da wichtige Veranstaltungen stattfinden müssen, und es nicht sein kann, dass Spaßvögel das Haus “voll-reservieren”. Dem Problem wird mit einem Berechtigungssysten begegnet, welches elegant – weil einfach – als Etappenbuchung konzipiert ist: Lehrveranstaltungen werden frühzeitig eingebucht, Mitarbeiter können ihre Besprechungen erst danach fixieren. Studierende können lediglich kurzfristig nach Räumen für ihre Lerngruppen suchen.

Da wir unsere Software agil entwickeln, ist ein kleiner Bestandteil dieses Moduls bereits produktiv und wird auch heftig genutzt. (Raumansuchen Online)

Querschnitt wohin man schaut

Ich habe das Projekt oben als Querschnittsmaterie bezeichnet und wahrlich, die Software ist der Behälter, wo all das Wissen, all die Konzepte und Überlegungen zum Neubau zusammenfließen.

Elektronische Beschilderung ist das Um und Auf in einem Gebäude, dessen Flächen dynamisch vergeben werden. Schon jetzt versuchen wir mit QR-Codes und NFC-Tags, die physische Welt der Räume mit der Online-Welt zu verknüpfen. Das Öffnen und Schließen eben dieser Säle funktioniert nur in enger Kopplung mit einem Schließsystem, welches vollelektronisch sein und mit Studierenden- wie Mitarbeiterausweis funktionieren wird. Ein Geoinformationssystem kann die Lage der Räume visualisieren, oder auch Räume in unmittelbarer Nähe publizieren. Die Buchung selbst wird via für Smartphones optimierter Webseiten erledigt, oder auf Terminals, die ebenso ein großes IT-Projekt im Schnittpunkt Hardware und Architektur darstellen.

Aus Spaß habe ich alle Software-/Hardwareprojekte mit Codenamen versehen. Als Taucher fiel meine Wahl auf Fische und andere Meeresbewohner. Room Resourcing ist aber kein weiteres Tier, es ist eher der Ozean selbst in dem alle schlussendlich zusammenspielen.

Insofern wird mit diesem Eintrag und dem Themen-Rundumschlag gegen Ende der Countdown zur Inbetriebnahme des Campus WU eingeläutet. Dieser Blog hilft mir persönlich, meine Projekte zu strukturieren und den Fokus nicht aus den Augen zu lassen. Meine Projekte gehen zwischen Jänner und Juni 2013 in die heiße Phase – Danke fürs Lesen // Kommentare willkommen!

tltr;

Am Campus WU wird die Raumbuchung dezentralisiert, unbürokratisch, teils automatisiert und mit vielen, vielen weiteren IT-Themen vermengt.

IT project management

Checklist Softwareauswahl

Knappe eineinhalb Jahre vor Inbetriebnahme des Campus WU werden aktuell zahlreiche Softwareprodukte unterschiedlicher Größe beschafft. Software ist durch ihre nicht überschaubaren Anwendungsmöglichkeiten komplex, die Auswahl des richtigen Produkts daher keine triviale Aufgabe.

Im Zuge der Beschaffung eines Geoinformationssystems (GIS) fand allerdings ein Bilderbuchbeispiel für einen strukturierten Entscheidungsprozess seinen Weg bis zur Vertragsunterzeichnung; ein Beispiel, das ich in abstrakter Form hier gerne teile.

Ausgangspunkt

Wir kaufen also Unternehmens-Software: Diese ist im Jahr 2012 beinahe immer webbasiert, oder zumindest in einer three tier architecture umgesetzt. Das Unternehmen möchte die Gesamtkosten (total cost of ownership) minimieren, dabei aber dennoch eine ausreichend gute Software einführen.

Im Studium lernte ich die Nutzwertanalyse als Werkzeug bei derartigen Entscheidungsprozessen kennen. Als ich sie vor Jahren zum ersten Mal anwenden wollte, erlebte ich allerdings zahlreiche Probleme: Die Punktevergabe samt Gewichtung gaukelt ein genaueres, transparenteres Ergebnis vor, als es tatsächlich ist. Gewichtungen werden oft auch noch nachträglich verändert. Die Betriebswirtschaftslehre nennt das Sensitivitätsanalyse, in der Praxis ist das eher ein Hintricksen zum gewünschten Ergebnis.

Was ich an Methoden agilen Projektmanagements mag, ist weniger die Fähigkeit, Prozesse vielleicht besser steuern zu können, sondern die im Lieferumfang enthaltene Transparenz mit der Unsicherheit und Ungenauigkeit nach außen hin als solche deklariert werden.

Soll heißen: Ich präsentiere hier eine absichtlich zur Checklist verkommene Nutzwertanalyse, weil jedes mehr an Datenpunkten, lediglich mehr Zahlenspiel als sinnvolle Entscheidungsgrundlage bedeutet. Anstatt Punkten und Gewichtungen treten nur noch drei Zustände: KO, entscheidend, relevant. Während KO als Filter zu sehen ist, sind die beiden letzteren rein qualitative Aussagen: “Dieses Kriterium ist entscheidend und Anbieter A ist da wohl ein wenig besser” – mehr ist nicht möglich.

Nutzwertanalyse “light”

Zuerst zur Software selbst
  1. Erfüllt die Software alle meine mir jetzt bekannten Anforderungen? Gibt es zumutbare Workarounds für fehlende Anforderungen?
    (KO-Kriterium)
  2. Kann die Software deutlich mehr, als ich es will? Paradox: Je mehr unnötige Funktionalität geboten wird, desto schlechter!
    (siehe: Complexity kills!, entscheidend)
  3. Können alle künftigen Endanwender den Client verwenden oder gibt es Einschränkungen bei Browserversionen und/oder Betriebssystemen? Gilt dies auch noch künftig in meinem Unternehmen?
    (KO-Kriterium)
  4. Falls ein mobiles Szenario existiert: Ist der Service mobil nutzbar?
    (relevant)
  5. Ist eine zentrale Authentisierung (Login mit unternehmensweitem Passwort) möglich?
    (KO-Kriterium)
  6. Ist eine zentrale Autorisierung (Übernahme zentral gepflegter Berechtigungen) möglich?
    (relevant)
  7. Falls ein älteres System abgelöst wird: Können Daten übernommen werden?
    (entscheidend)
  8. Wie schätze ich die wirtschaftliche Situation des Anbieters ein? Wird es ihn in fünf Jahren noch geben? Ist sein angebotenes Produkt für ihn selbst wichtig oder wird mir ein Auslaufmodell angeboten? (Product Roadmap) Wie stark ist letztlich meine Abhängigkeit?
    (entscheidend)
    ODER
    Handelt es sich um Open-Source Software? Gibt es andere Anbieter, die auf Basis dieser Software Dienstleistungen anbieten?
    (relevant. Das bedeutet, dass dieser Punkt im Falle von OSS weniger Tragweite erhält.)
  9. Liegen die Daten in einem lesbaren Format vor, oder sind sie im System des Anbieters gefangen?
    (entscheidend)
  10. Kann ich das System (notfalls) selbst administrieren? Gibt es ausreichend Angebote für Dienstleistungen (Beratung, Support, Administration), wenn möglich auch von anderen Anbietern?
    (entscheidend)
  11. Gibt es Referenzen? Habe ich Erfahrung von anderen Installationen des Anbieters in meiner Branche? Welches Feedback ergibt eine Netz-Recherche?
    (relevant)
  12. Was sagen meine Endanwender? Hat Ihnen die Produktpräsentation gefallen? Gefällt ihnen die Software?
    (arrogant, aber: beinahe irrelevant)
  13. Bietet das System offene Schnittstellen für Daten und/oder Automatisierung?
    (entscheidend)
  14. Erfüllt das System meine Sicherheitsanforderungen hinsichtlich Architektur, Datenhaltung, Verschlüsselung, usw.? Ist das Angebot “in der Cloud” bzw. gebe ich unternehmenskritische oder datenschutzrechtlich sensible Daten in fremde Hände?
    (KO-Kriterium)
  15. Darf ich das System in dieser Form einsetzen, oder spricht geltendes Datenschutz-Recht dagegen? Besitze ich eine Meldung beim DVR oder ist gar mit einer Ablehnung zu rechnen?
    (realistischerweise lediglich relevant)
  16. Passt die vom Anbieter vorgeschlagene Vorgehensweise bei der Einführung zu Kultur und Ressourcen meines Unternehmens? Sind etwa Schulungen zeitlich möglich? Wissen alle Stakeholder überhaupt von ihren künftigen Rollen?
    (relevant)

Man sieht, in meiner Auflistung fehlen zentrale Punkte, die normalerweise (stärker) repräsentiert sind. Dazu zählen etwa die Zufriedenheit der Nutzer oder die technische Ausgereiftheit des Produkts.

Bei einer Produktpräsentation etwa bewerten Endanwender eher die sympathische Art des Beraters, nicht aber das Produkt selbst. Bewerten sie in Ausnahmesituationen doch die Software anstatt der Powerpoint-Präsentation, lassen sie sich vom GUI blenden und schaffen es de facto nie, das Gezeigte zu abstrahieren und in ihre Arbeitswelt zu überführen.

Doch auch IT-Spezialisten sind schlecht im Bewerten: In zehn Jahren IT habe ich festgestellt, dass in Systeme nicht hineingesehen werden kann. Die traurige Nachricht lautet, dass man alle Probleme am eigenen Leib erleben wird, bevor man sie mühsam lösen muss. Dabei gibt es kaum Unterschiede zwischen Open Source und kommerzieller Software: Bei ersterer ist tendenziell mehr Expertenwissen bei der Problemlösung vonnöten – bei höheren Erfolgsaussichten -, bei zweiterer sind zeitlicher Aufwand (Support-Hotline!) und monetärer Einsatz (Beratertage) weitaus größer.

Den Reifegrad einer Software anhand des Namedroppings von Programmiersprachen, Protokollen, Datenbanksystemen, Dateiformaten, usw. feststellen zu wollen, ist blanker Unsinn. Verwendete Technologie und Qualität korrelieren äußerst schwach. Die Eckpunkte von Softwarequalität lauten Entwicklungsprozess, automatisiertes Testen, Sourcecodemanagement, Erfahrung & Motivation, … – alles Dinge, die von außen gänzlich unsichtbar sind.

… und dann das Geld

Nun zu den Kosten: Diese sind bei Hardware und Lizenzen zwar noch vergleichbar, aber oft stellen Schulungen, Beratungsleistungen, Support u.ä. ein großes Problem dar. Veranschlagt ein Anbieter etwa das Doppelte für Beratungsleistung, kann es gleich mehrere Gründe dafür geben: Das System ist schwieriger einzuführen, die Berater sind teurer, der Anbieter ist vorsichtiger bezüglich des Projektfortschritts, usw.

Ein möglicher Ausweg ist die Aufschlüsselung der Kosten in angebotene Gesamtstunden und Stundensatz. Der Median der angebotenen Stunden (über alle Angebote hinweg) ist zunächst die beste Näherung für den Aufwand. Mit dem jeweiligem Stundensatz multipliziert kommt man so zu normierten Angeboten hinsichtlich der Dienstleistungen.

Diese so errechneten (fiktiven!) Angebote sollten Basis eines Preisvergleichs sein.

Eine Pattstellung zwischen zwei Anbietern ist aufgrund der bestehenden Unsicherheit nach wie vor äußerst wahrscheinlich. Möglicher Ausweg hier: Beauftragung beider Anbieter mit einer in maximal acht Wochen durchführbaren Pilotphase bei voller Transparenz des Modus und fairen Bedingungen.

Diese Vorgehensweise stellt die beiden Anbieter in direkten Wettbewerb. Man kann davon ausgehen, dass die “Motivation” auf beiden Seiten hoch sein wird. Auch im nachfolgenden (Groß-)Projekt – wenn dann die Auswahl letztlich getroffen ist – kann das Ergebnis der Pilotphase als Qualitätsreferenz dienen. (Der Anbieter legt sich selbst eine hohe Latte.)

Während die Methode bei kleineren Beauftragungen übertrieben scheint, stellt sie bei wichtigen Projekten eine probate Möglichkeit dar, Entscheidungsunsicherheit tatsächlich zu reduzieren.

hacks

Terminal-Update

Ein kurzes Update zu unserem Projekt Octopus, einfach weil’s so geil läuft. (Und ich hasse normalerweise das Wort geil, aber in diesem Fall ist es angebracht!)

Unser heldenhafter Möbelprofi hat’s vollbracht: Alle Komponenten sind im Gehäuse sicher und für zukünftige Wartungen optimiert untergebracht. Außenrum bleibt das Interface “clean” und daher für die Benutzer übersichtlich. Der A4-Drucker ist dank Umbau des Papierauswurfs runter auf eine Fehlerrate von 1:300 und somit unterhalb der Quote, die wir mit den Originalteilen des Herstellers messen. Sämtliche Bedienelemente befinden sich in Greifhöhe für Rollstuhlfahrer. Die L-förmige Lichtleiste wird das Bedienkonzept einer Art “Farbleitung” ermöglichen. Aber was schreibe ich, wenn es Bilder gibt:

Der Mock-up ist beinahe fertig. Ursprüngliches Ziel - ein "cleanes" Interface - geschafft.

Materialkunde

Für jemand, der normalerweise mit Bits und Bytes zu tun hat, ist die Wahl der Materialen zugegebenermaßen eine Herausforderung. Immerhin sind Langlebigkeit, Kosten, Widerstandsfähigkeit gegen Reinigungsmittel und Vandalismus zu bedenken. Unser Ergebnis: Weiße Melaminplatte auf blankem Stahl – passend zum Gebäude, das mit Sichtbeton und schrägen Wänden auffallen wird.

Lokalaugenschein am künftigen Standort - ein echter Business-Termin.

Software: Python, Python, Python!

Abseits vom Möbelstück hat sich auch bei der Software unglaublich viel getan.

So wurde etwa beim Bezahlmodul eine proprietäre Library durch eine quelloffene Implementierung des Protokolls ZVT 700 in Python ersetzt. Damit können wir, von der Plattform unabhängig, den Leser der Card Complete einsetzen. “Abfallprodukt” dieser Entscheidung ist, dass wir künftig auch Zahlungen per Kreditkarte akzeptieren können.

Integration "Bankomat": Hard- und Software verschmelzen mit unserem Terminal.

Bei Webcam und den drei (!) Druckern lautete die Marschrichtung ebenso hin zu offenen Schnittstellen. Protokolle wie Apples CUPS machen die Ansteuerung der einzelnen Komponenten einfach(er), da viel der Komplexität versteckt wird. Anstatt des Modells “Treiber + lokal Anstecken” hat sich ein rein TCP/IP-basierter Aufbau durchgesetzt.

Als User Interface Library fiel die Wahl auf Nokias Qt – ein Wahnsinn in Sachen Flexibilität und Robustheit. (Nicht zuletzt darum tut mir der Einstieg von Windows Phone 7 bei Nokia im Herzen weh…) Die Python Bindings für Qt (PyQt) ermöglichen die Entwicklung in reinem Python-Code. Mit QWebview, einem für den User unsichtbar  in das UI eingebetteten WebKit (Google Chrome), werden wir einen Teil der Funktionalität mittels Web-Technologien implementieren. Diese hybride Art der Applikationsentwicklung wird ansonsten häufig bei mobilen Apps betrieben, um Apps auf Android, iOS und Co. mit nur einer Codebasis zu betreiben. Bei uns geht’s allerdings eher um die Entwicklungsgeschwindigkeit, da HTTP schlicht die lingua franca in der IT ist.

Richtig abgehoben wird das Projekt letztlich bei der Lichtsteuerung, einem Bedienkonzept, welches Benutzer anhand von Lichtimpulsen und Farben anstatt von Beschriftungen und Erklärungstexten leiten soll. Ein prototypisches Video kann bei Google Plus angesehen werden.

Photoshooter

Obwohl ich mich eher um die Projektabwicklung, als um die tatsächliche Implementierung kümmere, wollte ich eine Sache selbst hinbekommen: Die Software für den Photoshooter. Jeder WU-Student kennt das Ding, muss man doch am Tag der Inskription genau dort hinein lachen…

Erste Erfolge mit der Webcam.

Eines war mir jedenfalls nicht so ganz klar, als ich das Modul übernommen hatte: Dass ich eine long and winding road begehen würde bevor das Ziel auch nur halbwegs in Blickweite sein würde…

Kurzum, nach zahllosen gescheiterten Versuchen mit diversen APIs von VoIP-Clients bis hin zum Sourcecode der Kamera des Nokia N900 bin ich nun mit opencv glücklich. Diese Library für maschinelles Sehen tut aber nur am Rande, wonach ich hauptsächlich gesucht habe. Fokus liegt eher bei der Bilderkennung, und so war dann auch – das nächste “Abfallprodukt” – eine Gesichtserkennung schnell implementiert. Während man jetzt den Bildausschnitt mit dem Gesicht manuell auswählen muss, übernimmt das künftig die Software. Die überraschend geringe Fehlerrate bei der Gesichtserkennung trägt außerdem dazu bei, dass künftig nur noch erkennbare Bilder akzeptiert werden. Ein, wie ich, fauler Programmierer spart sich außerdem das ganze Gezoome und Gecroppe im UI.

Gesichterkennung mit Intels opencv: Das Gesicht kommt künftig automatisch erkannt auf den Studierendenausweis. Ergebnis sind ein einfacheres UI und eine indirekte Qualitätskontrolle, da der Algorithmus nur richtig belichtete Gesichter erkennt.

Linux statt Windows

Plattformunabhängigkeit, Python, offene Schnittstellen – all das dient letztlich dazu eine der letzten Domänen von Windows zu beenden: Jene der interaktiven Terminals. Unser Betriebssystem wird Ubuntu Linux 12.04 LTS. Mit TFTP-Boot und automatisiertem Checkout aus dem SVN-Repository ist auch hier die Reduktion der Wartung bereits Teil des Kernkonzepts.

Schon während der Entwicklung setzen wir auf continuous integration. Das bedeutet, dass zwei Testrechner laufend selbständig nach neuen Releases suchen und sich im Falle notwendiger Updates automatisch aktualisieren. Was jetzt also das Testen ungemein erleichtert, bedeutet im Produktivsystem einen stabilen Rollout-Mechanismus, der keinerlei manuelle Eingriffe benötigt.

Und noch so viel zu tun…

Nach einem guten halben Jahr Entwicklung sind wir nun an dem Punkt, wo alle Teile für sich alleine funktionieren. Nun heißt es, die einzelnen proofs-of-concept zu einem Ganzen zu verbinden und danach zu testen, zu testen und zu testen. Bis hierher sieht es also gut aus, aber die Geschichte bleibt spannend…

hacks

Service Terminal Plus, oder wie ich lernte, Automaten zu bauen

Das für Außenstehende wohl spannendste, weil greifbarste, Projekt meiner Tätigkeit ist das Service Terminal Plus. Mit beinahe 500.000 Euro Budget geht am Campus WU der Nachfolger der heutigen Selbstbedienungsterminals in Betrieb. Zeit für einen Erlebnisbericht, der sich für mich wie eine Hintergrundgeschichte zur (zweiten) Mondlandung schreibt…

Beim Service Terminal Plus handelt es sich um einen interaktiven Terminal, der RFID-Leser, Kartendrucker, Touchscreen, Webcam, Bezahlfunktion für Bankomat und Kreditkarte, Ausdruck auf Normal- und Zeugnispapier im A4-Format, zusätzlich Rechnungsdruck auf Thermopapier sowie Lichtsteuerung vereint. Kein Wunder also, dass der interne Codename des Projekts Riesenkrake lautet, besitzt der Automat wie sein tierisches Vorbild (mindestens) acht Arme und neun Gehirne…

Aktuelle Version der SB-Terminals an der WU Wirtschaftsuniversität Wien: Foto für den Ausweis, Rückmelden inkl. Bezahlen, Ausdruck von Zeugnissen und Bestätigungen.

Die aktuellen SB-Terminals wurden 2001 von Siemens geliefert, zwischenzeitlich mussten einige Hardwarekomponenten getauscht werden. Die Software wurde 2006 aufgrund vieler Ändeurngswünsche komplett neu in-house entwickelt.

Dank der in zehn  Jahren Betrieb gesammelten Erfahrung wollen wir nun einen Automaten bauen, der in seiner Wartbarkeit deutlich verbessert wird. Die spannendsten Änderungen spielen sich allerdings auf Seiten der Benutzungstauglichkeit ab, wo wir in den vergangenen Monaten einige interessante Ideen geboren, aber vor allem auch zur Reife gebracht haben.

Künftiger Standort ist das LLC am Campus WU. Wir nehmen Anleihe an der Architektur und holen den "Geist des Gebäudes" ins Projekt.
Eine der ersten Studien zum Service Terminal Plus.

Barrierefreiheit: Einer für Alle!

Ein Thema, das keinesfalls zu kurz kommen darf, lautet Barrierefreiheit. Die bisherige Lösung bot zehn Terminals für normale Menschen und einen für Behinderte.

Wem sich beim vorigen Satz auch der Magen umdreht, mir geht’s genau so.

Wir wollen weg vom Separieren von Menschen mit Behinderungen hin zu Gleichbehandlung. Das heißt im konkreten Fall, alle Terminals werden (mit Kompromissen) barrierefrei sein. Das bedeutet aber auch, dass viele Studierende sich werden bücken, Rollstuhlfahrer eben auch strecken müssen. Mir gefällt der Ansatz, etwas fundierter nennt sich das Inklusion.

Die Bedienelemente werden auf einem Kragarm platziert, der für Rollstühle unterfahrbar ist.

Zielsetzung mit dem nächsten Protoypen wird unter anderem sein, Rollstuhlfahrer testen zu lassen, um so zu verwertbarem Feedback abseits abstrakter Gesetzesnormen zu kommen.

Technische Neuerungen

Doch auch technisch wird sich viel tun. Seit Smartphones und Tabs will niemand mehr einen resistiven Touchschirm bedienen – die neue Generation ist kapazitiv und bietet deutlich erhöhten Bedienkomfort. Teure, weil vandalismussichere Tastaturen sind dank dieser Technologie ebenso Geschichte – das erledigt neuerdings die Software.

Die größte Innovation scheint uns aber im Bereich des Druckens zu gelingen: Während in der aktuellen Version immer wieder Papierstaus auftreten, glauben wir, das Problem nun endgültig geknackt zu haben. Dank Modifikation des Beförderungsmechanismus wird der Drucker rückwärts verbaut. Das bedeutet, dass künftig sämtliche Wartungsarbeiten von hinten durchgeführt werden, während vorne das User Interface keine Ladeklappen benötigt, also “clean” bleibt. Gemäß dem alles beherrschenden Motto “Was nicht existiert, geht nicht kaputt”, kann Papier nirgends mehr stecken bleiben. Es fällt einfach nach unten in eine Lade.

Das Innenleben eines Lexmark T652dn: Wir ändern die Richtung des Papierauswurfs und erreichen: Drucken vorne - Nachfüllen hinten.

Einheitliches User Interface (UI)

Als Softwareentwickler denke ich bei UI vorrangig an das, was sich letztlich am Bildschirm tut. Doch beim Service Terminal Plus ergeben sich durch den Möbelbau ungeahnte Möglichkeiten: Wie am Foto der aktuellen Generation erkennbar, ist das physische UI zurzeit stark zerklüftet. Drucker, Bankomatkassa und Kartenleser befinden sich in einem separaten Möbelstück rechts des Bildschirms. Der Zahlungsbeleg hingegen wird unterhalb des Bildschirms gedruckt, weit weg also vom eigentlichen Bezahlvorgang. Zumindest ich finde so etwas verwirrend.

Am Mockup des Möbelbauers werden die Komponenten verortet. Zusammengehöriges wird mittels Fräsung umrandet und dadurch zusammengefasst. Eine Lichtsteuerung leitet schließlich den Benutzer von Bedienfeld zu Bedienfeld.

Agil versus legal, oder: Grenzen des Outsourcings

Wie auf den Bildern erkennbar haben wir Spezialmöbelbauer im Team, mit denen die Zusammenarbeit auf Basis von Mock-ups abläuft. Es ist unglaublich hilfreich und effizient, ein Projekt anhand eines an-greifbar-en Prototypen zu be-greifen, anstatt detailliert zu planen. Das Gesamtprojekt ist schlicht zu komplex, als dass man es abschließend spezifizieren könnte. Trial and Error ist hier der richtige Weg.

Eine der größten Herausforderungen des Projekts liegt daher weitab aller technischen Sphären: im Vergaberecht, an das sich öffentliche Auftraggeber halten müssen. Beschaffungen ab gewissen Schwellenwerten haben über Ausschreibungen zu erfolgen. Was etwa bei Standardmöbeln zu transparenter und effizienter Haushaltsführung führt, stößt bei derartigen Spezialthemen an Grenzen. Die Aufgabe lautet daher, gemeinsam mit einem vertrauenswürdigen Partner ein Produkt zu entwerfen, dass später als Referenz für eine Ausschreibung an einen unbekannten Bieterkreis dienen soll. Im Regelfall stellt sich diese Schwierigkeit nicht, da oft so genannte Integratoren wie IBM oder eben Siemens eine Gesamtleistung anbieten. Die Erfahrung lehrt uns aber, dass es viele Themen gibt, die besser in-house gelöst werden, da ein komplexes Projekt nicht beliebig auf Externe verteilbar ist.

Getting real!

Wer sich von den Entwicklungen aus nächster Nähe überzeugen will: Bereits im Sommer 2012 soll “Nummer 1” noch am Altstandort in Betrieb gehen. Dann wird sich zeigen, ob sich die vielen, vielen Arbeitsstunden hinter Monitoren, Mock-ups und Kaffeemaschinen rechnen…