The Spoken Word

Eigentlich hätte ich den Beitrag mit einer anderen Ãœberschrift versehen soll .. z.B. “Dienstleistung - Balanceakt zwischen den Welten”, das wäre aber etwas zu theatralisch und würde ganz sicher meinem Stil nicht entsprechen.
Also versuche ich es etwas bodenständiger.

Als Dienstleister im Software-Umfeld etntwickelt man einerseits Lösungen für Kundenprobleme, andererseits kommt man aber auch um Fragen der Wartung und der Fehlerbehandlung nicht herum. Unter Wartung kann man dabei Weiterentwicklungen verstehen, aber auch Vorgespräche dazu. Unter Fehlerbehandlung verstehe ich in diesem Falle aber nicht die techn. Fehlerbehandlung, sondern eher Anfragen, die sich auf Fehler beziehen, die durch den Betrieb nicht gelöst werden können.

Typischerweise liegt es nahe, diese Fehler an die Entwickler weiterzureichen, da diese die Komponenten entwickelt haben und für die Fehlerbehebung am Besten durchführen können.
Ist man in einem überschaubaren Projekt, oder handelt es sich um Anfragen, die zu dem jeweiligen Projekt gehören, ist dies in Ordnung bzw. verständlich.
In einem Umfeld, in dem man aber mehrere verschiedene Projekte abhandelt, ist dies auf Dauer nicht tragfähig, da die anstehenden Projekte um die Zeit der Fehlerbehebung verlängert werden, oder über Mehrarbeit abgehandelt werden, was nicht wünschenswert ist.

Wie kann dies nun praktikabel gelöst werden? Verwendet man für die Problemlösung einen SixSigma Ansatz, also einen analytisch geprägten Ansatz, so benötigt man eine Ausgangssituation. In diesem Falle kann man sagen, dass das Support-Team keinerlei Anfragen bearbeitet und das Entwickler-Team alle Anfragen beantwortet. Nun ist die Aufgabe, dieses Verhältnis zu verschieben. Für einen guten Schnitt soll dieses Verhältnis auf 50/50 angehoben werden.

Was ist das grundsätzliche Problem für ein Support-Team? - Es kommen über die Zeit Anfragen der verschiedensten Art, die bearbeitet werden sollen. Diese können sich entweder auf die implementierte Lösung direkt oder das Umfeld dieser Lösung beziehen, um das Problem erstmal zu vereinfachen. Später kann es verkompliziert werden, indem auch Anfragen eher fachlicher Natur bearbeitet werden sollen.

Nachdem die Aufgabe der Definition abgeschlossen ist und damit auch der finanzielle bzw. zeitliche Impact klar ist - die unzweifelhafte Zeitersparnis für die Entwickler und die höhere Produktivität des Support-Teams - geht es daran die Informationen zu sammeln, auf Basis deren weiter Entscheidungen und konkrete Handlungsmassnahmen abgeleitet werden können.

Nun kommt die Aufgabe der Messung. In dieser müssen Daten erhoben werden, die zielführend sind und valide Aussagen darüber zulassen, welcher Art die Anfragen sind. Dazu kann ein evtl. bereits bestehendes Trouble-Ticket-System verwendet werden. Dazu ist eine Kategorisierung der Tickets notwendig. Diese sollte mehrfach vorgenommen werden, um die unterschiedlichen Dimensionen des Fehlers zu erfassen. Sinnvolle Dimensionen sind:

• Art des Fehlers - Datenfehler, techn. Fehler, Bedienungsfehler, Mappingfehler, Programmierfehler
• Tiefe des Fehlers - simpel, einfach, mittel, schwer
• Umfang des Fehlers - Komponente, Datenstrecke, Randsysteme, Benutzer
• betroffene Systeme - EAI, Randsysteme, Datenbanken

Typischerweise erhält man an dieser Stelle den Einwand, dass die ganze Datenerhebung keine Sinn macht und sowieso überflüssig ist. Man könnte meinen, dass dem so ist, stimmt aber nicht. Das Problem ist, dass man, methodisch betrachtet, etwas erreichen möchte, ohne Aufwände in Blindleistung zu investieren. Aus diesem Grunde sollte im ersten Schritt Daten erhoben werden, die Aussagen darüber zulassen, wieviel Anfragen überhaupt kommen und wie diese eingestuft werden können. Anschließend kann man für die Kategorien mit dem höchsten Aufkommen überlegen, wie diese behandelt werden können.

Und da ich jetzt keine Lust mehr habe, weiter zu schreiben, kommt morgen oder so der Rest zum Thema Analysieren und Verbessern.

Kommentare zum Bereich Definieren und Messen sind herzlich willkommen, gerade auch um andere Sichtweisen einzuarbeiten…

On his blog entry, Bill Miller states some of his thoughts of what an ESB is. This is something pretty interesting, as there seems to be a good amount of buzz around what something really is!

I’m working with Apache ServiceMix, an ESB product, implementing the JBI standard - Wow, what a lot of buzz around it! To my understanding, an Enterprise Service Bus is nothing concrete and it is neither something to be concrete ever.

Instead of being something a product can be, it’s more of a metaphor and a list of attributes a product may or may not deliver. The idea of an Enterprise Service Bus is to be a pattern, which can be implemented even without using a product delivering it.

What it’s all about is getting a clue of how separate building blocks can work together and how one get’s data and information from one point to another.

In designing enterprise applications, it’s important to focus on the logic of the application, on the side effects (locking, multi-user issues, etc.) and the overall picture. If one has many applications, offering certain distinct pieces of functionality, you need a standard’s based methodology to pass data around and get all things connected. This is the foundation of an enterprise service bus - a possibility to connect in a standardized way.

Getting back to software development, it’s nothing but “contract based development” and “object oriented programming” one step further. The contract is the message format, the contract is the interface. On top of which platform such things are implemented, if irrelevant. Products implementing the ESB idea typically deliver a runtime environment, tooling and convenience functionality (such as a messaging system, transactionality, etc.). This is pretty necessary and very very good - but the foundation is just an idea.

I hope, this idea got a bit clearer (considering the shortness of this post). I’d be glad to get any comments on this or your thinkings on it!

So und weiter geht’s im Text um eine sinnvolle und für die Wartung brauchbare Dokumentation. Diesmal wechsle ich den Themenbereich und wende mich direkt den Quelltexten zu, denn aus denen sind die meisten Anwendungen dieser Tage aufgebaut.

Wenn Fehler auftreten, äußert sich das im Falle von Java zumeist durch einen Stack Trace. Dieser gibt an, in welcher Java Klasse der Fehler aufgetreten ist und wie der Aufrufgraph dahin aussieht. Darüber lässt sich nachvollziehen, über welche anderen Java-Klassen hinweg zu dieser, möglicherweise fehlerhaften, Stelle im Code gelangt worden ist.

Was passiert nun, wenn an diesen Stellen keine Fehlerbehandlung durchgeführt wird? Richtig - es werden Java Exceptions geworfen, die genau das aussagen, was gerade passiert. Übliche Beispiele wären NullPointerException, ArrayIndexOutOfBoundsException oder auch RemoteException - sehr beliebt übrigens auch aufgrund ihrer hohen Aussagekraft in einem Applikationskontext

Was braucht nun der Support? Der Support oder auch die Wartungsmannschaft möchte möglichst schnell die Stelle in den Protokolldateien finden, die den Fehler erwähnt und anschließend möglichst schnell erkennen können, was der Fehler genau ist. Im Sinne einer möglichst niedrigen Ausfallzeit ist das auch Sinn der Ãœbung. Nun hilft aber eine Darstellung der Form “RemoteException in Klasse Blah, Zeile Blub” herzlich wenig.

Darum plädiere ich ganz massiv, wie dies eigentlich auch getan werden sollte, für sprechende Exceptions, die zumindest auf einen Cluster von Fehlern hinweisen.

Ein Beispiel wären ein paar Projekte aus meinem Umfeld. Diese verwenden eine andere Komponente zur Auflösung von Qualitätsgruppen. Tritt beim Zugriff auf diese ein Fehler auf, sieht man in den Protokolldateien eine lustige RemoteException (oder auch CORBA Exception) und mehr nicht - suboptimal. Wie könnte es besser aussehen? Geholfen wäre zum Beispiel durch eine QualityCodeCacheManagerUnavailableException!

Durch solche Fehlertexte ist zwar die Lösung noch nicht gefunden, eine weitere Analyse an dieser Stelle ist aber überflüssig, weil das Problem woanders liegt. Nun kann sich aber der Support direkt dieser Thematik zuwenden und nachschlagen, was bei einem solchen Fehler zu tun ist.

Eine weitere Alternative ist die Eskalation über eMails. Dadurch können die notwendigen Informationen direkt an die Zuständigen Personen übermittelt werden (idealerweise eine Verteilerliste), ohne direktes Eingreifen zu erfordern. Dies könnte z.B. wie folgt aussehen:

Bitte legen Sie für den Qualitätscode das Wertpapier XY fest. Es wurde keine Gruppe gefunden.
Im Anschluss daran ist der Betrieb über den Neustart der Komponente zu informieren.
Diese eMail wurde automatisch generiert, bitte antworten Sie nach Abschluss der Wartungstätigkeit.

Wird diese eMail so gestaltet, dass Sie einerseits an die Verteilerliste gelangt und andererseits dem Betrieb mitgegeben wird, erkennt dieser sofort, wann kein direktes manuelles Eingreifen notwendig ist. Steht der Betrieb zudem als “Reply-To” Empfängerkreis in der eMail, kann dieser direkt informiert werden, wenn der normale Betrieb weitergehen soll.

Was ist der Nachteil einer solchen Vorgehensweise? Das ist relativ leicht dargestellt:

• Die Java Quelltexte werden länger, da mehr “named” Exceptions geworfen werden
• Die Quelltexte erhalten eine höhere Komplexität, da mehr defensive Prüflogiken eingebaut werden
• Der Entwickler muss sich nicht nur darüber Gedanken machen, wie er sein Problem löst, sondern auch, wie er dem Wartungsproblem begegnet

Es gibt sicherlich noch eine Menge mehr, was an dieser Stelle aufgeführt werden kann, aber nun auch ein paar positive Anmerkungen:

• Die Entwickler werden entlastet, da mehr Aufgaben durch den Betrieb/Support gelöst werden können
• Die Entwickler sind nur noch dann einbezogen, wenn der Fehler nicht durch den 2nd Level gelöst werden kann. In diesem Fall handelt es sich aber um “sinnvolle” Fehler, die tatsächlich einen Entwickler erfordern. Dies ist meistens nicht der Fall
• Die Projekte werden automatisch robuster entwickelt. Da der Entwickler möglichst wenig Aufgaben im Wartungsumfeld wahrnehmen möchte, es ihm ein Anliegen, die möglichen Fehler möglichst umfassend zu dokumentieren (in Form von Exceptions und SDs)

Was ist das Ende vom Lied? Eine bessere Supportleistung ist möglich. Dies ist in diesem Falle mit einem Eingriff in den Quelltext verbunden, der den üblichen Rattenschwanz hinsichtlich Change, Deployment und Re-Test nach sich zieht, aber schlußendlich qualtitativ höheren Code hinterlässt.

Hier ein paar Links zum Thema JMX für alle, die sich näher damit beschäftigen möchten:

• J2EE Application Management - The Power of JMX
• Sun Java Management Extensions
• Superior App Management with JMX
• JMX - Wikipedia
• Java ist auch eine Insel - JMX
• JMX die Zweite - IT-Blogger.com
• JBoss Wiki JMX

Von den Seiten her empfehle ich für den Einstieg die Wikipedia Seite. Danach das JBoss Wiki JMX. Damit gibt es einerseits eine grobe Ãœbersicht zum Thema Management von Java Anwendungen und andererseits den eher praktisch orientierten Teil mit Fokus JBoss. Die anderen Seiten in der Liste nähern sich dem Thema eher entwicklungslastig, sollten aber dennoch nicht übergangen werden …

Ein Problem bei der Suche ist mir aufgefallen: Es gibt relativ wenig konsistente Informationen zu dem Thema, auch wenn sehr viel und sehr breit darüber publiziert wird. Insbesondere aus Betriebsanforderungssicht her, scheinen sich wenige Leute damit zu beschäftigen, was entweder für die unglaubliche Stabilität der Plattform spricht (wie gesagt: un-glaublich!), oder aber eher von untergeordnetem Interesse zu sein scheint.

Auf jeden Fall ein Thema, mit dem man sich auseinandersetzen sollte !

Aufgrund immer wieder aufkommender Diskussionen zum Thema Dokumentation in Softwareprojekten (Fokus EAI) hier mal meine Position zum Thema. Da kann man sich zwar immer gut an die eigene Nase fassen, aber notwendige Dinge werden nicht weniger notwendig, indem man nicht darüber spricht/schreibt.

Ziel einer Dokumentation ist es, eine Beschreibung für den Aufbau, die Funktionen und mögliche Fehlerquellen zu beschreiben und Gegenmassnahmen bzw. Vorgehen zu skizzieren.
Zudem sollte (evtl. mit Verweis auf entspr. Dokumente) mit aufgeführt werden, wie die Funktion aufgerufen werden muss. Das umfasst evtl. auch die Parametrisierung anderer Komponenten und externer Systeme.

Dies sollte nicht nur auf Projektebene erfolgen, sondern für jede einzelne techn. Komponente erfolgen. Neben der zentrierten Sicht auf das Projekt als solches muss dabei zwangsläufig auch die Sicht nach links bzw. rechts gewendet werden, da jede technische Komponente eingebettet ist in einen Applikationskontext.

Aus diesem Grunde sollte die Dokumentation folgermassen gegliedert sein:

• Projektumfeld (grob)
• betroffene Anwendungen (Beschreibung der Aufgabe, evtl. Verweis auf weitere Dokumente)
• Datenfluss
• Komponenten und deren Zusammenspiel untereinander

Für jede Komponente sollte eine separate Dokumentation erstellt werden. Ist dies nicht sinnvoll, sollte jeder Komponente ein separates Kapitel gewährt werden. Damit kann erreicht werden, den Stellenwert jeder einzelnen Komponente hervorzuheben und damit einen Anreiz zu bieten, mehr als nur die eben notwendigen Informationen dort abzulegen.
Es sollten folgende Fragestellungen mit einbezogen werden:

• Welche Aufgabe erfüllt die Komponente im Gesamtkontext
• Was für Daten werden in welchem Format (mit Abbildung) entgegengenommen
• Was für Daten werden als Ergebnis produziert. In welcher Form geschieht dies
• Welche Schritte vollführt die Komponente. In diesem Zusammenhang bieten sich UML Aktivitätsdiagramme an. Dieser Schritt sollte so detailliert aufgebaut sein, dass das Verhalten und die Verarbeitungslogik auch für nicht direkt im Projekt involvierte leicht nachvollziehbar ist
• Was für Fehlerquellen sind denkbar. Wie sind diese zu identifizieren (”named” Exceptions, Protokolldateien, etc.)
• Welche Schritte sind für Außenstehende notwendig, um Fehler zu finden und eine Lösung herbeizuführen

Ferner ist bei jeder Form von Dokumentation für Aktualität zu sorgen. Insofern ist vor jedem Deployment auf die Abnahme/Produktion zu prüfen, ob die Dokumentation angepasst werden muss und ob dies geschehen ist. Ist eine notwendige Änderung nicht durchgeführt worden, muss das Deployment verweigert werden, bis die Dokumentation aktualisiert worden ist. In notwendigen Fälle kann das Verfahren natürlich abgeändert werden.