Die Scandio ist immer bemüht Energie zu sparen. Wir geiseln uns nicht und wenn es das Projekt erfordert, bleibt auch einmal eine Workstation über das Wochenende in Betrieb, damit man per VPN darauf arbeiten kann. Dennoch konnten wir seit der Gründung der Scandio als Software-Unternehmen den Stromverbrauch jedes Jahr senken! Das hat sich in den Kosten leider nicht niedergeschlagen, aber das ist ein anderes Thema.

Gelungen ist uns das, weil wir früh auf die Nutzung der Virtualisierungstechnik gesetzt haben und einige Dienste vollkommen in das Internet verlegt haben. Als die Scandio im September 2003 die jetzigen Firmenräume in München bezogen hat, war der so genannte Serverraum bis unter die Decke voll mit Infrastruktur-Servern und Projektmaschinen. Wir entwickeln webbasierte Software und benötigen für fast jedes Projekt eine Entwicklungsumgebung, die der zukünftigen Produktionsumgebung nachempfunden ist. Betreuen wir das Projekt dauerhaft, so bleibt das Entwicklungs- und Testsystem über einen längeren Zeitraum erhalten.

Betritt man heute den Technikraum, so steht dort ein 19 Zoll Rack, dass zu 75% gefüllt ist und zwei weitere PC-Server mit einem Monitor und einer Tastatur. Alles andere ist verschwunden.

Auf drei VMware ESX Servern betreiben wir unsere eigene Infrastruktur und alle Projekt-Server. Dabei ist zu beachten, dass wir sogar unsere Windows Domäne mit dem Active Directory virtualisiert haben. „Aber es gibt doch Serveranwendungen, die man nicht virtualisieren kann“ hören wir immer wieder. Das sehen wir anders und eine Oracle 10g Instanz schnurrt virtuell genauso gut oder schlecht wie auf einer physikalischen Hardware. Intranet, Enterprise Wiki, CRM und Auftragsverwaltungssystem genauso wie die Browser-Testmaschinen für IE6, IE7 und IE8, Firefox in alten Version usw. So konnten wir nicht nur Energie sparen sondern auch die Effizienz trotz freier Betriebssystemwahl der Mitarbeiter steigern.

Wo Licht ist, da ist auch Schatten! Der ersten Platten-Crash haben wir schon hinter uns. Dabei fällt eben nicht eine Maschine aus sondern alle der defekten VMware-Instanz. Aber ein gutes Backup ist ja bekanntlich alles!

Mail, Kalender und unser Web haben wir in die Cloud verlegt und konnten so die Aufwendungen für die Systemadministration enorm reduzieren. Und natürlich noch einmal Energie sparen.

Wir sind noch lange nicht am Ende und sehen noch weitere Einsparungspotentiale für eine umweltfreundliche IT-Infrastruktur.

Scrum ist ein Vorgehensmodell der agilen Softwareentwicklung. Einfach ausgedrückt wird davon ausgegangen, dass jeder Prozess der Softwareentwicklung so komplex ist, dass er sich nicht in einem Schritt durchführen lässt. Iterative Schritte ( Sprints ) sind die logische Folge. Innerhalb der selbstbestimmten Aufgabenpakete übernimmt das Team die Verantwortung für die Umsetzung. Das Diktat von oben wird dabei abgelehnt. Der Product Owner ( Auftraggeber ) kann über User Stories seine Wünsche mitteilen und auch Vorschläge zu Priorisierung geben. Die Auswahl, welche User Story in welchem Sprint durchgeführt wird entscheidet das Team.

Weitere Informationen zu Scrum sind auf Wikipedia und in der einschlägigen Literatur zu finden.

Die Scandio hat dieses Modell erfolgreich in der Entwicklung der Suchmaschine SEBOL, die auf Apache Lucene basiert eingesetzt. SEBOL wird zu einem Großteil aus eigenem Antrieb entwickelt, das bedeutet der Product Owner kommt aus dem eigenen Haus. Innerhalb der Produktentwicklung beziehungsweise bei Eigenentwicklungen zeigen sich die Stärken von Scrum sehr schnell. Diese sind eine besonders hohe Qualität, sofort einsetzbare Ergebnisse, permanente Selbstkontrolle und eine extrem hohe Flexibilität.

Ein für die Entwicklung der Suchmaschine SEBOL sehr wichtiger Kunde nutzt Scrum in der Eigenentwicklung und hat uns im Projekt als Dienstleister tief integriert. Funktioniert Scrum in der IT-Dienstleistungsbranche? Widerspricht sich das gesamte Vorgehen und die Zuordnung der Verantwortungen nicht dem „Kunde ist König“ Prinzip?

Nein, ja, vielleicht, ein wenig!

Sicherlich sollte man nicht jeden Kunden zu einem Scrum Projekt überreden. Man muss seinen Kunden gut kennen und der Kunde muss sich über die Konsequenzen im klaren sein.

Was aber sind die Konsequenzen?

• Festpreise kann es nicht oder nur innerhalb einer Iteration geben. Ein Projekt besteht aus einer Anzahl Sprints, deren Inhalte vage bekannt sind. Die Entscheidung trifft aber das Team.
• Vollständige Konzepte und Pflichtenhefte gibt es vor Projektbeginn nicht. Es gibt die bis zu diesem Zeitpunkt formulierten User Stories in der jeweiligen Granularität.
• Die Vertragsgestaltung mit Einkauf und Rechtsabteilung sind als schwierig anzusehen.

Aber es gibt auch äußerst interessante positive Konsequenzen!

• Innerhalb des Projektes kann der Product Owner jederzeit die User Stories ändern und erweitern.
• Change Requests gibt es in der Form, wie sie in anderen Projekten auftauchen nicht, denn die Änderung wird schneller erkannt und sofort aufgenommen.
• Die Kosten sind in der Regel keineswegs höher als bei sogenannten Festpreisprojekten mit statischem Pflichtenheft.
• Der Kunde erhält nach jedem Sprint ein Ergebnis und kann früher Feedback geben und durch die User Stories Einfluss nehmen.
• Der Kunde hat das Recht nach jedem Sprint ein Projekt zu stoppen beziehungsweise zu überdenken.

Ein sehr großer Erfolgsfaktor ist das IT-Consulting, das im Vorfeld der Entwicklung und parallel dazu erfolgen muss. Der Consultant muss auf den Kunden einwirken, damit dieser nicht versucht die gesamten Anforderungen auf einmal umzusetzen. Dies erhöht die Komplexität sehr stark. Die User Stories der ersten Stunde sollen das Minimalsystem beschreiben, das dann konsequent erweitert werden kann. Ein früher Einsatz im Unternehmen ist auch für den Kunden der größte Erfolg. Das Feedback der Benutzer kann sofort in die weiteren Entwicklungen einfließen. Ist die Zusammenarbeit von Erfolg gekrönt wächst auch das Vertrauen.

Gegenseitiges Vertrauen und Verständnis für die Bedürfnisse sind sicherlich wichtige Eckpfeiler von Entwicklungsprozessen dieser Art. Die Scandio GmbH ist in der Lage IT-Dienstleistungen mittels der Scrum Methode durchzuführen.

Interessiert? Nehmen Sie Kontakt mit uns auf!

Die Diskussionen zum Thema Change Request reissen nicht ab. Hilfe ist nicht in Sicht, oder doch?

Die Szenarien ähneln sich. Der Kunde ruft den Softwareentwickler an und erklärt diesem, dass er bei bei der Anmeldung auf seinem Portal gerne noch eine Checkbox für die Newsletter-Anmeldung haben möchte. Der Entwickler, weitsichtig wie er ist fragt, was denn mit der Information geschehen soll. „Wir benötigen dies nur als reine Information in der E-Mail, die wir bei jeder Anmeldung erhalten“, antwortet der Kunde schnell und gibt noch den freundlichen Hinweis, dass man es nicht zu komplex und vor allem nicht zu teuer machen soll.

Der Softwareentwickler baut die Checkbox ohne Plausibilitätsprüfungen ein und erweitert die E-Mail Daten um die Information, ob der Newsletter nun erwünscht ist oder nicht. Der Aufwand war gering und das neue Szenario ist sofort live geschaltet worden.

Ein Traum von einem Change-Request? Nein sicherlich nicht, denn zwei Wochen später meldet sich der Kunde und möchte eine Liste aller Newsletter-Abonnenten und fragt freundlich, ob man diese gleich als Excel-Liste haben könnte. Weiterhin hatte sich ein Portal-Benutzer beschwert, dass er sich nicht vom Newsletter abmelden kann. Als er erfährt, dass die Daten nicht gespeichert werden, sondern nur als E-Mail versendet werden ist der Kunden enttäuscht und erzählt dem Entwickler etwas von „Selbstverständlichkeitsanforderungen“.

Nach kurzer Abklärung des Falls und der Definition des „richtigen“ Vorgehens erhält der Kunde eine Aufwandsschätzung, die deutlich weitsichtiger aber auch deutlich höher ist, denn trotzdem es sich nur um eine „einfache“ Checkbox handelt sind die Auswirkungen weitreichend. Das Datenmodell ändert sich, die ORM Modelle werden angepasst, es ist eine Exportfunktion geplant und es soll eine Abmeldefunktion mit Double-Opt-In Verifizierung programmiert werden. Unit-Tests werden geändert bzw. neu geschrieben. Weiterhin muss die Dokumentation des System auf den neusten Stand gebracht werden.

Das hätte man von Anfang an machen sollen, lautet es unisono aus beiden Lagern, aber wo lag das Problem? Hätte der Kunde seine Geschäftsprozesse besser durchdenken müssen, bevor er die Anforderung artikuliert hat oder hätte der Entwickler als IT-Berater ihn aktiv auf die Probleme hinweisen müssen? Sicherlich ist beides richtig. Change Requests sind tiefe Eingriffe in ein Software-System und keine kleinen Änderungen. Am besten hilft immer noch: Miteinander reden und zuhören!

Auch eine Bildergalerie ist in das Portal integriert. Der sogenannte Agents-Only Bereich gliedert sich nahtlos in die Consumer Website www.princesscruises.de ein. Wie auch die Website selbst, wird der Agents Only Bereich in vier Sprachen gepflegt und von Reisebüros aus ganz Europa verwendet. In der kommenden Zeit werden neue Funktionen für das Business to Business E-Mail Marketing in das System integriert, das bereits über 5000 Reisebüros nutzen. Die technische Grundlage bildet WordPress als Content-Management System, die Buchungsmaschine, die via Web-Service auf die Server der Reederei zugreift sowie individuelle Entwicklungen der Scandio GmbH.

Aufgrund der anzunehmenden Größe der Indizes war die Backup-Fähigkeit immer ein großes Thema. Die Sicherung eines Suchindex macht dann Sinn, wenn die Wiederherstellungszeit länger als die erlaubte Down-Zeit ist. Die Datensicherung eines Lucene-Index ist unproblematisch, denn Lucene selbst speichert (viele) Dateien in ein Verzeichnis und damit ist die Sache erst einmal erledigt. In SEBOL nutzen wir zusätzlich eine dateibasierte JDerby Datenbank, die beim Backup synchron gehalten werden muss. Dies erreichen wir in dem zum Sicherungstermin die Indizierung kurzzeitig angehalten wird. Währendessen füllt sich die Queue mit den Index-Anfragen, die nach dem Backup abgearbeitet werden.

Grobe Skizze der Queue für den SEBOL Index Server

Zum eigentlichen Thema des Journals. Wenn ein Unternehmen einen Suchindex nachts sichert und der K-Fall erst Stunden später eintritt, so existiert eine Differenz zwischen der Sicherung und dem tatsächlichen Index. Also muss man sich zwei Sachen merken, um einen möglichst zeitnahen Aufsetzpunkt zu finden.

Erstens muss man alle seit der Sicherung abgearbeiteten Request als erledigt in einem persistenten Journal ablegen.

Zweitens muss die Queue der nicht abgearbeiteten Anfragen ebenfalls persistent sein. Das Handshake für den Indizier-Client darf erst nach Speicherung in der Warteschlange erfolgen.

Ist dieses durchgängige Journaling implementiert, kann man im K-Fall das Backup zurückspielen (Restore), den SEBOL Index Server neu starten und über die Parameter den Aufsetzpunkt mitteilen. Das Queue-Management füllt die Warteschlange in der richtigen Reihenfolge mit allen Anfragen seit dem letzten Backup. Somit ist auch im K-Fall der ursprünglich gesicherte Index annähernd sofort wieder aktiv. Je nach Mengengerüst ist die Warteschlange nach einiger Zeit abgearbeitet und der Lucene Index ist auf dem aktuellen Stand.

Weitere Informationen zur Suchtechnologie

Die Skizze wurde mit Gliffy erstellt, das ist unser webbasierter Diagrammeditor im Enterprise Wiki

Berater, Entwickler und Kunden haben eins gemein – Gerne nutzen sie ihr persönliches Wissen und ihre Erfahrungen zur Konzeption von Software und Websites. Dieses Vorgehen ist fraglich, denn oftmals sind es persönliche Vorlieben und Abneigungen, die eine Web-Applikation oder eine Benutzeroberfläche beeinflussen. Ein paar Beispiele hierzu:

„Was im Web nicht auf dem direkt sichtbaren Bereich steht, wird nicht gelesen oder angeklickt!“

Ist das wirklich so? Nein, man könnte dies auch ganz einfach testen, in dem man einen echten Eye-Catcher unterhalb des sichtbaren Bereiches positioniert und misst wie oft im Verhältnis der Gesamtzugriffe darauf geklickt wird. Aber die vermeintliche Erfahrung verhindert dieses Vorgehen. Faktisch ist es so, dass durch die Verbreitung der Scroll-Mäuse und neuerdings der Trackpads das nach unten Scrollen viel einfacher ist als das „Weiter“ und „Zurück“ Klicken.

„Die Erweiterte Suche nutzt sowieso keiner im Intranet!“

Dieser Erfahrungswert führt zu dem Umstand, dass viele Kunden auf eine besondere Suchfunktion verzichten und den Leser für dumm halten. Dabei lautet die Problemstellung ganz anders: Wie baue ich die Suche auf, dass ein Leser oder Kunde auch komplexe Fragestellungen abfragen kann? Hierzu empfehlen wir unseren Artikel Suchnavigationen sind nicht banal!

Berater: “Man könnte in der Auftragsliste die Kurzbeschreibung beim Mouse-Over einblenden.” Entwickler: “Ich halte nichts von Mouse-Over Effekten. Das ist eine Spielerei!“

Der Entwickler versteht dabei nicht den Vorteil des Nutzers, sondern denkt an die Komplexität der Entwicklung. Sicherlich auch ein guter Gedanke – aus seiner Sicht heraus. Durch eine Mouse-Over Einblendung kann aber verhindert werden, dass der Nutzer auf eine Detailansicht wechseln muss, um zu sehen was sich hinter dem Auftrag verbirgt. Hier geht es um Zeitersparnis – Und somit um Geld!

Die Liste an subjektiven Konzeptionselementen kann sehr lang werden. Dabei gibt es meistens eine Möglichkeit das Problem zu testen, zu hinterfragen oder zu analysieren. Um so wichtiger ist es diese Möglichkeiten zu nutzen und der eigenen Subjektivität in der Konzeption Einhalt zu gebieten.

Wir wollten erreichen, dass SEBOL sowohl in der Apache Tomcat Umgebung oder einem anderen JSP Server betrieben werden kann als auch Standalone. Geschwindigkeitseinbußen durften aber nicht hingenommen werden. Den Durchbruch erreichten wir mit Jetty. Jetty ist ein vollständiger Webserver mit Servlet Container, der in die eigene Server-Applikation integriert werden kann. Durch den geringen Overhead, den Jetty mitbringt, konnten wir die gesamte Suchmaschine mit einem standardisierten XML-RPC Protokoll implementieren und dennoch die Performance steigern. Die Implementierung der JSON Schnittstelle war dadurch trivial und die Versionen für die Servlet-Engine und Standalone unterscheiden sich im Sourcecode nicht.

Das XML-RPC Protokoll erlaubt zusätzlich die Implementierung von Client Bibliotheken in unterschiedlichen Sprachen. Derzeit sind die Sprachen Java/JSP und PHP verfügbar. Weitere Bibliotheken sind in Planung. Bei der gesamten Entwicklung hat sich die Entscheidung pro Jetty als durchaus positiv bewiesen.

Weitere Informationen zur Scandio Suchtechnologie.

Ein Anwendungsfall beschreibt die Interaktionen zwischen Nutzer und System, die notwendig sind, um ein fachliches Ziel des Nutzers zu verwirklichen.

Das klingt ja schon mal ganz toll, aber was ist mit Aktionen die keinen Nutzereingriff erfordern. Wie werden diese beschrieben? Wo steht, was implizt ausgelöst wird? Die Theorie hat immer einen geeigneten Platz dafür. Die Realität sieht anders aus. Wir stellen die Behauptung auf, dass Konzepte, die zum großen Teil aus Anwendungsfällen bestehen gerade einmal zu 50% bis 60% der Anwendung beschreiben. Dazu schreibt Wikipedia:

Die Granularität von Anwendungsfällen kann sich stark unterscheiden: Auf sehr hohem Niveau beschreibt ein Anwendungsfall lediglich sehr grob und abstrakt, was passiert.

Was fehlt? Grundsätzlich ist das abhängig von dem zu erstellenden Softwaresystem. Als Erstes sollte eine textuelle vollständige Beschreibung der Anwendung entstehen. Weiterhin empfehlen wir die Prozesse, die in der Applikation abgebildet werden gesondert zu beschreiben, sei es als Diagramm oder als Fließtext.

Aus den modernen Methoden der Softwareentwicklung (Agile Entwicklung) und des Projektmanagements (SCRUM) haben wir gelernt, dass es dem Kunden viel einfacher fällt eine User Story (kurze prägnante Anforderung die auf ein Karteikärtchen passt) zu verfassen als das System zu beschreiben. Diese User Stories sind Teil der Konzeption.

Als letztes gilt es, dass in Anwendungen mit Benutzerschnittstelle (und das sind fast alle) sogenannte Wireframes oder Mockups zu erstellen sind. Dabei handelt es sich um ein Bild der Anwendung wie sie der Benutzer sieht. Man erstellt diese Wireframes gemeinsam mit dem Kunden. Das hat mehrere Vorteile. Erstens ist der Kunde in der Lage sich die Anwendung tatsächlich vorzustellen und kann dann prüfen, ob seine User Story auch erfüllt ist. Zweitens erkennt man durch die gemeinsame Arbeit Anforderungen, die sonst im Verborgenen geblieben wären.

Ein gutes Konzept einer Software beinhaltet also wesentlich mehr als Anwendungsfälle.

Die Scandio ist Atlassian Partner. Nicht erst seit gestern sondern schon eine ganze Weile. Warum? Die Produkte von Atlassian gefallen uns. Am besten finden wir das Enterprise Wiki System Confluence und den Issue Tracker JIRA. Manchmal denken wir Confluence kann Eier legen Denn es hilft unseren Kunden und auch uns selbst in vielen Bereichen des Geschäfts. Es ist wahnsinnig vielseitig. Vom Intranet über die Dokumentation bis hin zu Blog des Geschäftsführers. Alles ist damit abzubilden. Und wenn es einmal nicht auf Anhieb klappt, dann gibt es sicherlich ein Plugin im riesigen Plugin Verzeichnis bzw. wir programmieren ein Plugin!

Aber die Einführung hat auch Tücken. Überall sind Stolperfallen augestellt. Bald merkt man, dass nicht die Software das Problem ist, sondern deren Integration in das Unternehmen. Dies ist sowohl technisch als auch arbeitspsychologisch zu sehen! Ein im Grunde anarchisch ausgelegtes System muss bei den Mitarbeitern erst einmal ankommen und Akzeptanz finden. Und es benötigt höchste Aufmerksamkeit auch aus der Unternehmensführung.

Gerade in der Anfangsphase der Einführung des Wiki-Systems sind externe Berater von Vorteil. Workshops, Schulungen und andere Hilfestellungen beschleunigen den Prozess ungemein. Unsere Kunden profitieren dabei von der Projekterfahrung der Scandio.

Weitere Informationen gibt es hier.