Tag Archives: Agile

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…

meta

Schluss mit den Apps!

UPDATE: WUdoo x5 gibt’s inzwischen unter short.wu.ac.at/wudoo - plattformunabhängig und frei verfügbar.

Bevor ich meinen digitalen Rundumschlag gegen Office-Dokumente oder SharePoint beende, um endlich wieder über Dinge, die ich kreiere anstatt nur kritisiere, zu schreiben, muss ich mich hier noch einem Übel annehmen: dem Hype um Apps.

 

Vergangene Woche sprach Sir Tim Berners-Lee in der Spanischen Hofreitschule anlässlich des future.talk 2011  über die Freiheit des World Wide Web. (Dazu: “Das WWW war ein Erfolg, weil es keine Patente gab” auf derStandard.at)

Das Internet ist nicht erst seit dem Arabischen Frühling politische Bühne: Information kann nur dort frei fließen, wo Telekom-Provider und deren Gesetzgeber Netzneutralität garantieren. Abseits der Frage der wertneutralen Datenübertragung ist auch die Datenspeicherung ein brisantes Thema: Immer mehr Content wandert von dezentralen Servern in Richtung Facebook; ein beängstigendes Phänomen, das mich übrigens zur Wiederbelebung dieses Blogs brachte. Die dritte Komponente schwindender Informationsfreiheit ist schließlich der Trend weg vom plattformunabhängigen WWW hin zu (mobilen) Apps. Denn diese sind an Betriebssysteme gebunden und unterliegen der Zensur der Marktplatzbetreiber.

Doch Apps sind gerade modern und somit cool. Und daher beginnt meine Geschichte der Abneigung gegenüber Apps auch ganz anders, und zwar als Erfolgsgeschichte:

WUdoo: (m)eine Success-Story

Als spätestens 2009 Apple’s iPhone seinen Siegeszug durch Österreichs Mobilfunklandschaft begonnen hatte, wurde uns an der WU Wirtschaftsuniversität Wien eines klar: die Zukunft der Nutzung unserer Services liegt (auch) am Smartphone. Genug dieser Erkenntnis, es war Zeit für Nägel mit Köpfen:

Mit der persönlichen Kursübersicht war jedenfalls schnell ein sinnvoller, mobiler Anwendungsfall gefunden. Für die Entwicklung der App holten wir uns Martin Kahr ins Boot, ein absoluter Profi auf der Apple-Plattform – die Zusammenarbeit war unkompliziert, erfolgreich und inspirierend zugleich! Das Backend wie Datenbankabfragen, Authentisierung, etc. hatte ich zwischenzeitlich mit viel Vorfreude in den Fingern programmiert.

WUdoo, Jänner 2010 - die erste universitäre App Österreichs.

Meine Frau Isabella stiftete den Namen WUdoo für das Projekt, das bis dahin holprig als WU iPhone App firmierte.

Die App ging in den Review-Prozess, darauf folgte ungeduldiges Warten über Weihnachten und schließlich, kurz nach Neujahr, war Apple mit deren Voodoo fertig und WUdoo konnte aus dem App Store heruntergeladen werden:

Und es war ein voller Erfolg;-)

Innerhalb kürzester Zeit hatten wir rund 3.500 Installationen. Ein erstaunlicher Marktanteil bei knapp 30.000 Studierenden und Mitarbeiter/inne/n und einem iPhone-Anteil von (damals) schätzungsweise 15%.

Das Feedback per E-Mail oder App Store war atemberaubend, werden IT-Abteilungen ansonsten doch eher als reiner Hygienefaktor im Universitätsbetrieb gesehen. Als vermeintlicher Innovator schafften wir’s schließlich sogar in die Presse; eine Fan-Seite auf Facebook folgte.

Schönheitsfehler im goldenen Käfig

Mit dem Erfolg kamen verständlicherweise sehr bald Ideen und Wünsche für weitere Features von WUdoo. Auf Entwickler-Seite musste ich aber schnell feststellen, dass das Hinzufügen neuer Funktionalität, Testen oder Logging immer aufwendiger wurden. Besonders ärgerlich waren die Updates auf iOS4 und iOS5, die beide Male mit neuartigen Crashes der App überraschten. Mein Punkt: Entwicklung und Betrieb einer Webseite sind deutlich wirtschaftlicher.

Währenddessen regte sich bei den Benutzer/inne/n von Android, Blackberry und Co. Unbehangen, warum wir als Universität nur Apples Betriebssystem unterstützten. Gute Frage eigentlich, ich wusste jedenfalls nur eine enttäuschende Antwort: Das Multiplizieren der oben geschilderten Probleme auf die jeweils nächste Plattform wollten wir uns nicht antun. (Christoph Weber entwickelte dann doch noch den schlanken WUdoo-Klon WUdroid, aber für mich war die Sache mit den Apps bereits gelaufen.)

Optimierte Webseiten sind besser!

Unser Ansatz: Webseiten sowohl für Desktops als auch für Smartphones erstellen - einmal entwickeln und warten, überall verwenden!

Im Laufe des Jahres 2010 setzte ich mich immer stärker dafür ein, den Irrweg mit den Apps nicht mehr zu beschreiten. Die Kolleg/inn/en vom CMS-Team taten dann auch einen tollen Job, als die WU Anfang diesen Jahres eine mobile Webseite (m.wu.ac.at) anstatt einer WU-App präsentierte.

Meine eigenen Projekte waren ähnlich gestrickt: Mit dem WU Directory ging eine Webseite in Betrieb, die sowohl für Desktop und Smartphone konzipiert war.

Für Neugierige: Detailseite am Desktop öffnen und die Elemente wie Menü, Spalten, Schriften usw. beim Verkleinern des Browserfensters beobachten. Die gut lesbare Anzeige am iPhone ist im Screenshot dargestellt.

Was passiert mit WUdoo?

Nun, die Entwicklungen an einem Nachfolger in Form einer mobil nutzbaren Webseite laufen. Damit wird die Anwendung für alle Smartphones, aber natürlich genauso für Desktops zur Verfügung stehen. Wir ersparen uns aufwendiges Programmieren für iOS, Android usw. Diesen Vorteil wollen wir in ein vielleicht umfangreicheres, vielleicht auch “nur” fehlerfreieres Produkt stecken.

Ob wir WUdoo (mutwillig) abdrehen, oder einfach nur auslaufen lassen, muss ich mir noch überlegen. Im Internet herrschte von Anfang an befruchtende Konkurrenz. Wenn schließlich die Studierenden meinen, das neue, webbasierte WUdoo sei viel besser, als das alte aus dem App Store, dann kann ich zufrieden sein.

hacks

Interactive Digital Signage with MS Kinect

Despite the high bullshit to fact ratio SIME Vienna was fruitful as Florian Dorfbauer (LaGentz) and I came up with the idea of using Microsoft’s Kinect as a controlling device for public user interfaces.

At WU Wirtschaftsuniversität Wien we’re throwing the current course schedule on large screens. Given the fact that we have up to two hundred courses in the list but – in contrast to airports – only a limited budget for the task the students are presented a slideshow rather than an array of expensive displays. You can imagine that it’s quite boring to watch the screen for a few minutes until your content appears…

Enough of background talk, here’s a video of the prototype solution.

What next?

The nice thing about the proof of concept is that it uses a web browser for content display. So anything can be displayed. The commands from Kinect are entered into the browser as key strokes (thus no browser APIs, compilation, or anything involved).

The challenge from here will be twofold: First we still need a user interface that automatically explains the  interaction possibilities to the user. Second, the Kinect is a brandnew device designed for your living room. So we have no data on its durability out in the field…

hacks

Redesign SAP Finanzbericht

Zur Thematik, dass erfolgreiche ERP-Systeme nicht zwangsweise durch einfach bedienbare User Interfaces glänzen, habe ich bereits gebloggt. Spätestens, seitdem ich meine eigene Kostenstelle verantworte, war’s nun aber höchste Zeit, den Bericht, der mir Überblick über meine Finanzen geben sollte, zu überarbeiten.

Zu allererst ein Blick auf den Status Quo

Nach einigem Herumgeklicke und der Erkenntnis, dass SAP-Jahre aus 16 Monaten bestehen, erreiche ich Woche für Woche den Überblick über meine Kostenstelle im Look & Feel von Teletext, aka SAP GUI.

Der Bericht listet alle von mir unterschriebenen Rechnungen mit Betrag, Datum, Belegtext sowie Kostenart. Um den Leser nicht mit Details zu verwirren (so interessant sind meine Zahlen nun auch wieder nicht), habe ich die Berichtsstruktur hervorgehoben:

Der Bericht zeigt auf Kontierungselemente (Kostenstellen) gebuchte Kosten aufgeschlüsselt nach Kostenarten (Konten). Die Logik des Berichts orientiert sich mMn zu stark am System.

Im Großen und Ganzen befinden sich auf der Seite zwei interessante Blöcke: eine Übersicht oben links, sowie eine Tabelle mit den Buchungen darunter.

Wenn ich mir nun überlege, welche Aufgaben ich mit dem Bericht abwickeln muss, dann sind das nach absteigender Wichtigkeit:

  1. Überblick über Planungs- sowie Ist-Stand meiner Finanzen
  2. Details zu einzelnen Rechnungen (z.B.: im Falle von Reklamationen)
  3. Analyse meiner Kostenstruktur nach Zeit und Kostenart

Traurig, aber wahr: bereits der erste Task ist mit dem Bericht nicht ohne Weiteres möglich. Die Transaktion, also der SAP-Name für eine Bildschirm-Maske, listet entweder Plan- oder Ist-Daten. Die jeweils andere Ansicht erreicht man durch Beenden und Neustart des Berichts nach anderen Auswahlkriterien. (…)

Finanzbericht Marke Eigenbau

Eine kleiner Entwurf auf einer McDonalds-Rechnung (ein so genannter Low-Fidelity Mockup) und ein paar Stunden Datenexport, HTML, SQL, Javascript und Python später ist die Alternative fertig: Eine Webseite, die die drei oben genannten Tasks auf einen Blick ermöglicht.

Der Kasten oben links bietet mir die Gesamtsummen von Ist und Plan als Zahlen, zusätzlich verdeutlicht ein Prozentwert das Verhältnis (Wieviel ist schon weg?).  Darüber ein einziges Auswahlfeld für das Berichtsjahr, kein Formular-Moloch. Rechts daneben befindet sich Säulendiagramm, das mir dieses Plan/Ist-Verhältnis nochmal grafisch verdeutlicht. Bei mehreren Jahren – bei mir nicht der Fall – sieht man so automatisch den Budgetverlauf.

Die Details zu einzelnen Rechnungen finden sich darunter. Die Tabelle verwendet das jQuery-Plugin DataTables, welches Such-, Sortierfunktion und Pagination bietet. So sind ein Sortieren nach Datum, oder das Suchen einer bestimmten Rechnung keine große Hexerei. Die rein Client-seitige Umsetzung sorgt dafür, dass das Ding responsive bleibt.

Alternativvorschlag: Ein Überblick über Plan und Ist (gleichzeitig!) oben links, eine Tabelle aller Buchungen mit Sortier- und Suchfunktion darunter. Oben rechts ein paar grafische Darstellungen eben jener Daten.

Den Zuckerguss stellen die drei Diagramme im TabbedView oben rechts dar. Neben dem bereits besprochenen Jahresüberblick, gibt es noch ein Liniendiagramm, welches den Planungsstand mit dem Iststand unterjährig vergleicht. Dadurch dass auf Jahresebene geplant wird, ist eine kumulative Auswertung sinnvoll.

Die wichtigste Frage auf einen Blick beantwortet: Bin ich drüber oder drunter?

Abschließend noch eine Auswertung nach Kostenarten, die eine hierarchische Datenstruktur mit variabler Tiefe darstellen. In diesem Fall habe ich mich für eine Treemap entschieden. Diese codiert zwei Variable (Größe des Rechtecks entspricht der Summe; Farbe ist die Abweichung) in eine klickbare Fläche. Das “Entdecken” der Kostenzusammensetzung macht so richtig Spaß.

Sehr schöne Visualisierung einer hierarchischen Datenstruktur: die Größe entspricht der Summe, die Farbe der Plan/Ist-Abweichung

Die hier dargestellte Kritik an aktuellen Berichten ist positiv gemeint und soll keineswegs als SAP-Bashing missverstanden werden. Dass die Software derart erfolgreich war, ist und vermutlich bleiben wird, hat schon seine guten Gründe. Ich bin selbst überrascht, wie sich mein Blick auf eben jenen Bericht verändert hat, seitdem ich auch wirklich ein Anwender bin. (…)