The Spoken Word

InfoHesive is a product of 2BrightSparks and is a personal information management application. It is meant to organize Files, URLs, Articles, eBooks and whatever can be structurized within a single application.

Overview

The application aims at organizing informations of all kinds into a structured view. For that, the main window is splitted vertically to have a outline view of the information structure on the left side and the editor view on the right side.

The structure from 2BrightSparks is as follows:

Every aspect put into InfoHesive is managed as a project, which is stored in a proprietary file format. There are three types of projects which can be created:

• Project - Here, all generic information can be archived and structured
• eBook - This is a project only with Topics and Articles. No File or URL links can be inserted. This is the preferred format for people writing eBooks they want to publish. InfoHesive offers the ability to publish written eBooks as an executable using the proprietary InfoHesive viewer.
• Help File - This is  a project pretty much comparable to the eBook style.

Features

The application offers the following benefits:

• Easily creatable structure with topics and subtopics
• A topic can consist of topics, articles, URL links, File links
• Each entry can be annotated/described and also be linked to other pages within InfoHesive

Personal Experience

I’m a fairly ew user to InfoHesive, though the concept to store very different things is quite appealling. What I, up to now, dislike is the necessity to keep files on the file system and not being able to embed it directly into the InfoHesive "project".

Since that, I use a central folder where all information is loosely organized. Any files in this folder are linked to at least one InfoHesive entry, so that I don’t pollute the folder with uninteresting information or non-organized information.

This section will be expanded as my usage improves (and with it my understanding on how to work with this application).

Any critics/comments are highly welcome!

Das Thema "personal development" oder auch "personal growth" ist etwas, dass uns wie ein Hype verfolgt. Getrieben durch omnipräsenten Vorreiter "Amerika" werden unzählige Bücher veröffentlicht, Seminare zu allen möglichen Themen angeboten, um die Menschen "weiter zu entwickeln". Darunter fallen solche Dinge wie

• Zeitmanagement (time management)
• Ziele setzen und erreichen (goal setting)
• emotionale Intelligenz oder auch Einfühlungsvermögen (emotional intelligence)
• ….

Die Lüge des Patentrezept’s

Angeblich gibt es die Methodik schlechthin für jedes dieser Gebiete und wenn man diese Methodik anwendet, funktioniert der Rest quasi "von alleine". Das das ziemlich einfach gedacht ist, dürfte jedem klar sein. Schließlich gibt es nicht DAS Patentrezept für jeden Menschen - was für den einen vielleicht wunderbar funktioniert, klappt bei dem anderen überhaupt nicht. Aber das ist auch gut so, denn jeder Mensch ist individuell verschieden und funktioniert nach anderen Prinzipien.

Es gibt kein Patentrezept für individuelle Probleme. Alles im Bereich der persönlichen Entwicklung funktioniert nur sehr individuell.

Die angebotenen Möglichkeiten sollte man sich anschauen, aber was funktioniert, sagt einem nicht die Methode, sondern die Resultate, wenn man eine Methode ausprobiert.

Und falls eine Methode nicht passt: Abändern bzw. austauschen - findet etwas, dass für euch funktioniert! 

Eine relativ einfache Möglichkeit, diesen ganzen Seminar- und Buchzauber zu "unterwandern" ist aber das naheliegende zu versuchen: Beobachtung! Dabei geht es nicht darum, willkürlich seine Umwelt zu betrachten und zu schauen, wie diese funktioniert, sondern diejenigen Personen zu beobachten, die etwas besser machen, als man selbst!

Beobachten und daraus Lernen ist universell - auch für die persönliche Entwicklung

Die Evolution ist ein kontinuierlicher Prozess der zwar auch viel mit ausprobieren zu tun hat (Gen-Mutation lässt grüßen), aber eine Entwicklung in der Breite funktioniert am besten durch Imitation - Nachahmung. Jeder weiß, in welchen Bereichen er sich verbessern kann, wenn man eine Woche einmal rückblickend Revue passieren lässt und sich die Frage stellt: Was hätte besser funktionieren können? Hier geht es darum, Problemfelder zu identifizieren:

• chaotische Termine
• unstrukturiertes, "sprunghaftes" Arbeiten (vom einen Problem zum Anderen und wieder zurück)
• Zerstreutheit
• …

Da wird sich vermutlich jeder wiederfinden. Sobald wir diese Punkte kennen, können wir sie angehen - vorher nicht! Wenn man jetzt über ein einzelnes Problemfeld nachdenkt - wirklich nur eines! - dann fallen einem in aller Regel sofort Personen ein, die es besser machen, als man selbst:

Kollege XY ist da viel besser - der bekommt das einfach hin.

Hier klappt etwas überhaupt nicht, hätte das XZ gemacht, wäre das schon durch

Falls einem niemand solches einfällt - denkt einfach mal etwas stärker "out-of-the-box"! Welche Person in eurer Umgebung kommt mit euren Problembereichen besser klar, als ihr selber? Ich bin mir sicher, dass sich da jemand finden lässt!

Wenn ihr eine solche Person identifiziert habt:: beobachtet! Wie arbeitet derjenige/diejenige, wie agiert er/sie. Nimmt er Arbeiten an oder wiegelt er ab, sagt er zu, bereitet er sich auf Besprechungen vor, kritisiert er sehr schnell oder nicht?

Andere Menschen, die man als "Vorbilder" betrachtet, zu beobachten, ist der einfachste und effektivste Weg, Vorschläge und Ideen für persönliche Verbesserungen zu bekommen!

Sobald ihr ein Gefühl dafür gewonnen habt, wie euer Vorbild agiert, überlegt euch, wie ihr dieses Verhalten, was ja offenbar funktioniert, adaptieren könnt. Es geht nicht darum, das Verhalten 1:1 zu übernehmen und damit, quasi, die Person zu kopieren! Ziel dieses Schrittes ist es zu entscheiden, wie ihr die Vorzüge des Verhaltens in euer eigenes Leben integrieren könnt. Was bedeutet das praktisch:

Wenn ihr neuen Aufgaben immer sehr schnell zustimmt (einfach weil ihr sie erfüllen möchtet, oder aber weil ihr euch bedrängt fühlt), euer Vorbild jedoch sehr zurückhaltend ist - übernehmt das Verhalten. Kommt jemand auf euch zu und möchte, dass ihr eine Aufgabe erledigt: vertröstet ihn auf später. Behaltet euch die Antwort vor und denkt erst in Ruhe darüber nach. Prüft euren Kalender, ob ihr überhaupt Zeit dafür habt und erklärt dies auch offen - nichts ist schlimmer, als Erwartungen, die ihr durch Zusagen schürt, zu enttäuschen.

Es gibt hunderte Beispiele, die ich hier gar nicht alle aufführen möchte (bei konkreten Fragen: schreibt eine Mail oder hängt einen Kommentar an!), aber versucht aus dem Verhalten anderer Muster abzuleiten. Diese Muster können unterschiedlich umgesetzt werden und ihr müsst den Weg finden, der für Euch am besten funktioniert!

Der stete Tropfen höhlt den Stein

Eine Sache, die bei alle dem sehr sehr wichtig ist und meist vergessen wird: Nehmt euch nicht zuviel vor! Fangt klein an und steigert euch. Es gibt mit Sicherheit eine Unmenge an Dingen, die ihr an euch verbessern wollt - verzettelt euch dabei nicht. Macht eine Liste (oder Mind-Map, oder was auch immer), in der ihr all die Punkte aufnehmt, die auch an euch stören und die andere besser machen. Und dann fangt an einem Punkt an und versucht, für diesen eine Verbesserung herbeizuführen.

Eine Verbesserung muss nicht sofort die Lösung aller Probleme darstellen, sondern ein kleiner Schritt in die richtige Richtung.

Ein kleiner Schritt in die richtige Richtung, der aber tatsächlich gemacht und nicht nur versprochen wird, ist mehr Wert, als 100 Versprechungen, die nicht gehalten werden (können).

Auf diese Weise kann man sich iterativ, also in stetigen Wiederholungen und Verbesserungen, langsam an des Übels’ Wurzel heran arbeiten.

Literatur - weiterführend oder weitführend?

Ich möchte an dieser Stelle natürlich nicht all die Seminar und Bücher verteufeln, die es gibt! Diese sind nützlich und sinnvoll für neue Ideen und Anregungen oder auch den Austausch mit anderen. Es sind aber nicht die Allheilmittel und sicherlich in vielen Belangen auch unbrauchbar. Bücher sind gut, um Anregungen zu bekommen oder zu sehen (und zu er-lesen), wie andere Menschen mit Problemen umgehen. Schlussendlich werden aber auch dort nur Beispiele und Möglichkeiten aufgezeigt. Vieles davon wird in dieser Form nicht umsetzbar sein, einfach weil das individuelle Umfeld ein anderes ist. Dies gilt es zu erkennen und entsprechend zu bewerten. Folgende Bücher kann ich allerdings empfehlen, weil ich sie persönlich sehr gut finde und sehr viele Ideen darin gut umsetzbar sind:

Wie in jedem Bereich gibt es auch hier eine Myriade von Büchern, die alle möglichen Dinge beleuchten. Die wirklich guten Bücher zeichnen sich allerdings dadurch aus, dass dort Prinzipien vermittelt werden. Konzepte, die immer wieder funktionieren, einfach weil Sie universell sind. Bücher, deren Inhalt sich an einem Hype orientiert, sind überflüssig. Dort werden Ratschläge mitgegeben und aufgeführt, die nur eine kurze Halbwertszeit haben.

Bücher die universelle Prinzipien und immerwährende Konzepte und Strategien vermitteln, sind eine Investition in die persönliche Entwicklung.

Wie ich gestern im MEDION Onlineshop (http://www.medionshop.de) gesehen habe, sind die größeren Akkus mit 5200mAh demnächst verfügbar.

Da ich den 2200mAh Akku tatsächlich etwas klein finde, habe ich mir direkt den größeren geordnet. Noch soll dieser am 17.07 geliefert werden - man darf gespannt bleiben.

Da der Medion akoya mini mit dem MSI Wind baugleich ist, besteht hoffentlich auch die Chance, das asiatische Hersteller (ähnlich wie beim Auss eeePC) richtig große Akkus anbieten werden - schließlich ist die Netbook Klasse auf Mobilität ausgelegt .. und Mobilität ohne Saft ist schlecht

Update 14.07.2008: Okay, eine Prüfung gerade im MEDION Onlineshop hat ergeben, dass der Liefertermin mittlerweile der 21.07 sein soll/wird. Mal schauen, ob sich das noch weiter nach hinten verschiebt :-/

Update 20.09.2008: Heute ist tatsächlich mein großer Akku angekommen. Es geschehen offenbar noch Zeichen und Wunder

Taugt ein Netbook als Ersatz für einen PDA?

Die Frage ist sicherlich berechtigt! Die Aufgabe eines PDAs liegt in der mobilen Verfügbarkeit von Daten und Informationen. Die Geräte speichern Office-Dokumente und verwalten Termine, Aufgaben und vieles mehr. Zudem können sie als Leseplattform für eBooks dienen oder als Abspielplattform für Musik, wodurch auch die Unterhaltung nicht zu kurz kommt.

Allerdings haben die Geräte auch einen gewaltigen Nachteil: die Größe. So ist die Bearbeitung von Office-Dokumente durch die Bildschirmgröße und die Tastatur nur schwer möglich und zudem langsam. Ein gewohntes Arbeiten ist damit nicht drin.

Demgegenüber bieten Netbooks die wunderbare Möglichkeit, mit einer (fast) normalen Tastatur arbeiten zu können und damit fast das Gefühl einen Notebooks zu bekommen. Die aktuellen Displaygrößen bieten (fast) normales Arbeiten ebenso an wie eine vernünftige CPU-Geschwindigkeit, um tatsächlich mehr arbeiten zu können, als zu warten.

Mobilität

Für einen sinvollen Vergleich darf aber der Aspekt der “Tragbarkeit” oder Mobilität nicht außer acht gelassen werden. Einen PDA kann ich sehr einfach in die Jackentasche stecken. Dort fällt das Gerät nicht auf, da es klein und leicht ist. Ein Netbook schlägt mit immerhin doch 1kg zu Buche und ist, bei einem 10″ Display, definitiv zu groß für die meisten Jackentaschen. Selbst die Pioniere eee PC 4G (701er Modell) mit seinen nur 7″ Displaygröße sind hier außen vor, da das Gewicht trotz allem bei gut 1kg liegt. Hier muß man daher Abstriche machen.

Robustheit und “Instant-On”

TODO

Fazit

Ob ein Netbook als Ersatz für einen PDA taugt, muß jeder selber entscheiden. Wenn man üblicherweise mit einer Aktentasche unterwegs ist, oder einen Rucksack, können die Geräte sicherlich eine Überlegung wert sein, da hier die Transportmöglichkeit gegeben ist. Wer eigentlich nur mit Handy und PDA “bewaffnet” ist und ansonsten nichts dabei hat (oder auch haben will), für den sind die Geräte eher nicht zu empfehlen. Dadurch das man es trotz allem tragen muß, hat man entweder eine Tasche in der Hand oder das Gerät auf dem Rücken - beides eine Einschränkung im Vergleich zu “vorher”.

So … am 03.07.2008 war es soweit: In den Filialen von Aldi Süd und Aldi Nord wurde das erste Netbook mit Intel Atom Prozesser verkauft: das Medion akoya mini.

Formfaktor entscheidet: eee oder akoya mini
Wie so viele andere auch, habe auch ich eines erstanden. Zwar bin ich Besitzer eines eee 701 der ersten Stunde (Markteinführung Deutschland am 26.01.2008), aber es mich dennoch gereizt. Warum habe ich dem eee abgeschworen? Für mich war und ist überwiegend der Formfaktor und das Einsatzgebiet ausschlaggebend. Der eee ist ein super Reisebegleiter, wenn es darum geht, Netbook-Funktionalität auf kleinstem Raum zu ermöglichen. Durch das kleine Display von nur 7″ konnte ein sehr kleines Gehäuse konstruiert werden, wodurch das Gerät in jede (Damen-)Handtasche passt.

Das Display: bigger is better
Durch das geringe Display ist aber leider auch so, dass längere Arbeiten schon etwas mühselig sind, da oftmals gescrolled werden muß. Wo wir bei den Einsatzgebieten ankommen. Ich verwende das Netbook (sei es eee oder akoya mini) für folgende Aufgaben:

• Surfen im Netz
• Schreiben von Einträgen für mein Weblog
• Schreiben von Konzepten (für den Beruf)
• kleinere Softwareentwicklungen mit eclipse oder NetBeans

An den Aufgaben ist schon sehr leicht zu erkennen, wo der Haken beim eee liegt. Der Display ist für längere Arbeiten einfach zu klein. Um Abends auf der Couch ein paar Webseiten zu besuchen oder eMails zu lesen, ist überhaupt kein Problem. Spätestens seit Firefox 3.0, der Webseiten als Ganzes verkleinern kann (inkl. Schriften, Layout und Bildern) kann man jede Seite für das 7″ Display “optimeren”. Allerdings ist damit einer Textverarbeitung nohc nicht geholfen :-/

Bei Dingen, die etwas mehr Auflösung benötigen, kann der akoya mini seine Vorteile ausspielen. Das 10″ Display bietet für den unterwegs-Faktor mehr als ausreichend Größe - auch Softwareentwicklungen sind mit fast keinen Einschränkungen machbar. Von daher sprich viel für das Gerät aus dem Hause Medion, der baugleich ist mit dem MSI Wind U100.

Drawbacks
Bei den guten Argumenten für den akoya mini - was spricht dagegen? Da wäre einerseits der Akku. Diesem kann man bedenkenlos ankreiden, das er zu klein dimensioniert ist. Der 3-Zellen-Akku hält (je nach Tätigkeit) um die zwei Stunden. Das ist eindeutig zu wenig für ein Netbook, bei dem Mobilität groß geschrieben werden sollte. Eigentlich war wohl angedacht, dem Kleinen den Großen zu spendieren, allerdings aufgrund gestiener Einkaufspreise für Akkuzellen hat das leider nicht funktioniert. Hier gibt es demnächst einen großen 6-Zellen-Akku der Laufzeiten von vier bis fünf Stunden ermöglich dürfte - man darf gespannt sein. Neben der größeren Akkuleistung muß dabei aber leider auch der größere Preis berücksichtigt werden: der Akku wird mit 99 EUR zu Buche schlagen (MEDIONshop). Man darf gespannt sein, was ggf. als Alternativen auf den Markt kommt, sobald auch der MSI Wind in freier Wildbahn gesichtet werden kann!

Fazit
Ein Netbook ist ein Kompromißgerät. Es ersetzt keinen Desktop-Arbeitsplatz und für viele Erledigungen unterwegs reicht einfach die vorhandene CPU-Leistung nicht aus. Das ist aber auch nicht das Ziel. Das Ziel eines Netbooks ist es, auf kleinem Raum Mobilität und Konnektivität bereit zu stellen. Das ganze verpackt in ein komfortabel zu bedienendes Gerät verpackt und schon wird ein Verkaufsschlager draus. Die Leistungsklasse hat auf jeden Fall das Zeug dazu, vor allem, wenn man etwas kreativ in den Anwendungen für solch ein Gerät ist.
Auch wenn das Ziel der Verkäufer eigentlich: “viel Internet” heißt, auch die Softwareentwicklung im Kleinen oder das erstellen von Dokumenten mit den gängigen Büroanwendungen ist kein Problem. Von daher eignen sich die Geräte der zweiten Generation sicherlich für alle mobilen Nomanden, die immer und überall in der Lage sein wollen, etwas zu tun.

In der Software-Entwicklung kommt es immer wieder zur Anschuldigung, die verwendeten Prozesse wären schwergewichtigt und zäh - eine Anschuldigung die zum guten Teil richtig ist.Viele Teams verkomplizieren sich die Arbeit massiv, indem Dokumentationen erstellt werden, Meetings anberaumt werden, Entscheidungsträger definiert werden - nur “geschafft” wird wenig.

Um aus dieser Falle zu gelangen, kann Pragmatik helfen. Die schlichte Fragestellung: “Wie kann ich mein Problem am einfachsten lösen?” verhilft hierbei zur Lösung. Es geht bei einfach pragmatischem Vorgehen nicht darum, möglichst elegante Lösungsszenarien zu entwerfen oder komplexe Patterns anzuwenden - sondern einfach nur das Problem zu lösen.

Ein pragmatisches Vorgehen ist gerade im Projektgeschäft außerordentlich hilfreich, da es zumeist positiv von den Kunden aufgenommen wird, wenn man sich nicht verkünstelt, sondern schlicht das Problem auf den Punkt bringt und dazu eine Lösung anbietet.

Andererseits ist pragmatisches Vorgehen aber auch eine Gefahr! Durch die “Möglichkeit”, Änderungen schnell umzusetzen und evtl. die erste (aber nicht unbedingt beste Lösung) zu verwenden, können schnell Kurzschlußhandlungen entstehen, die einem im späteren Projektverlauf massiv das Leben schwer machen oder aber wieder Änderungen nach sich ziehen.

Den Spagat zwischen Pragmatik einerseits und der Vermeidung von Schnellschüssen andererseits stellt die “konsequente Umsetzung” dar.

Was ist darunter zu verstehen?

Ganz einfach - tritt ein Problem auf, wird pragmatisch analysiert, wie das Problem gelöst werden kann. Die gefundene Lösung wird dann aber konsequent auf ihre Tragfähigkeit analysiert. Dabei müssen alle relevanten Aspekte mit einbezogen werden (funktional wie auch nicht-funktional). Nur durch eine solche Vorgehensweise kann sichergestellt werden, dass die bestehenden Probleme einerseits gelöst werden, andererseits aber eine “Zukunftssicherung” mit einfließt.

Auf Prozessthemen angewendet bedeutet dies, dass im Rahmen einer pragmatischen Lösungsfindung die Entscheidung getroffen werden kann, eine zusätzliche Entscheidungsinstanz einzuführen. Konsequenterweise bedeutet dies aber auch Zeitaufwand, der mit eingeplant werden muss. Dabei bedeutet Planung in diesem Fall auch, dass es nicht nur eine Kostenstelle gibt, sondern im Zeitplan tatsächlich eingetragen werden muss.

Diese Konsequenz in der Umsetzung ist gerade zu Anfang, oder aber in eingeschliffenen Teams, außerordentlich schwierig. Da dort überwiegend gelebte Prozesse vorhanden sind, ist die Umsetzung natürlich ein Problem, da es hier um Veränderung bestehenden Verhaltens geht. Diese Veränderung kann nur durch stete Kontrolle und Erinnerung (nicht aber Ermahnung) einhergehen.

Insgesamt löst “konsequente Pragmatik” diverse Probleme, die vielen schwergewichtigen Prozessen zugeschrieben werden. Im Kern kommt es, wie immer, darauf an, dass kein Thema überbewertet wird, aber auch nicht vernachlässigt wird. Eine pragmatische Lösungsfindung, aber konsequente Umsetzung kann auch die Verwendung von schwergewichtigen Prozessen vereinfachen.

P.S.: Was ich natürlich nicht erwähnt habe, wenngleich es mindestens den gleichen Stellenwert hat, ist die Seite der “Betroffenen”. Diese sind verständlicherweise auch gehalten, Prozesse zu leben und dies wechselseitig zu forcieren - sprich genau das Verhalten auch von Kollegen einzufordern. Verwendet man keine konsequente wechselseitige “Ermahnung”, verwässern die Strukturen. Andererseits: Wenn Prozesse und damit möglicherweise einhergehende Verbesserungen nicht von allen Beteiligten gewollt werden, kann man sich natürlich wunderbar die Zähne daran ausbeißen, diese einzuführen/umzusetzen

Der Kleine ist ja nun schon eine Weile (prinzipiell) im Lande, wenngleich immer noch relativ schwer zu bekommen.

Dafür hab ich mit meinem Modell schon einen neuen Anwendungsfall gefunden (neben dem Schreiben von Weblog Artikeln) - das Lesen von PDFs. Die Auflösung von 800×480 ist absolut ausreichend um die meisten DIN A4 Seiten, zwar leicht verkleinert, aber immer noch lesbar darzustellen.
Zudem bekommt man im “Lesemodus” des Acrobat (oder alternativ auch Vollildmodus) genug von der Seite auf die 480 Bildpunkte Vertikale, um nicht permanent am Scrollen zu sein.

Damit habe ich eine mobile Weblog-Mschine und einen mobilen eBook Reader - was will man mehr? Da kann Amazon mit seinem Kindle doch glatt einpacken, wenngleich die speziellen Geräte natürlich ihre Vorteile haben.

Wenn ich mir den Iliad anschaue, dann ist die Größe natürlich hübsch und die Möglichkeiten, Notizen zu hinterlegen. Aber bei einem Preis von 700 EUR, bei dem ich dann auch nur eBooks lesen kann, ist es relativ fraglich wie gut das tatsächlich kommt. Schließlich kann ich mit dem eee daneben noch einiges mehr (z.B. JBoss AS und NetBeans betreiben, wenn ich mal kurz etwas durchprüfen möchte).
Das geht auf keinem Kindle :-))

In diesem Sinne: probiert es einfach aus - nach spätestens fünf Minuten hat man sich an das Format sehr gut gewöhnt und kommt ziemlich flott durch die Seiten durch!

In diesem Artikel geht es um die Entwicklung von Komponenten für den ESB. In diesem Falle konkret für einen JBI-basierten ESB. Dabei soll erläutert werden, wie Komponenten geschnitten/abgegrenzt werden können und was bei der Entwicklung zu beachten ist. Dem Fehlerhandling wird ebenfalls ein eigener Absatz gewidmet.

Durch den ESB wird eine Architektur beschrieben, die die komponentenorientierte Entwicklung von Integrationsarchitekturen fördert. Dabei werden von einem ESB bestimmte Eigenschaften erwartet, die von den Herstellern in unterschiedlicher Weise umgesetzt werden können.

Im Rahmen des JCP (=Java Community Process) wurde für die Java Plattform eine ESB-konforme Spezifikation erstellt, die unter dem Namen JBI (=Java Business Integration) firmiert. Darin wird eine Kompontenarchitektur beschrieben, die den Lebenszyklus sowie die Interaktion von Komponenten beschreibt, die für die Java Plattform entwickelt werden.

Bei der Entwicklung von Konnektoren kommt es darauf an zu klären, was konkret geleistet werden soll und wie diese Funktion allgemein umgesetzt werden kann.

Das Ziel der Entwicklung von JBI/ESB Komponenten ist es, wiederverwendbare Komponenten zu schaffen, um damit zukünftige Probleme lösen zu können, ohne das Rad buchstäblich neu zu erfinden.

Aus diesem Grunde sollte bei der Umsetzung von Anforderungen in zwei Stufen vorgegangen werden:

1. Beschreibung des konkreten Lösungsvorschlags

2. Zerlegung der speziellen Lösung in eine allg. Lösung und eine spezifischen Anteil (Dekomposition)

Sollen beispielsweise Datensätze aus einer Datenbanktabelle gelesen werden, zu denen es einen Steuersatz in einer anderen Datenbanktabelle gibt, so kann man dieses Problem in einer JBI-Komponente kapseln, die genau dieses Szenario beschreibt. Schafft man jedoch eine wiederverwendbare Komponte, so könnte diese allg. eine Spalte aus einer Tabelle auslesen und anhand dessen weitere Datensätze aus einer anderen Tabelle lesen, wobei die Spalte als Einschränkung verwendet wird. Die Tabellen bzw. die entsprechende(n) Spalte(n) können dabei parametrisiert werden. Auf diesem Wege erreicht man eine Lösung, die nicht nur für ein konkretes und spezifisches Problem anwendbar ist, sondern für eine ganze Klasse von Problemstellungen verwendet werden kann.

Auch bei der Weiterverarbeitun kann man grundsätzliche Abläufe von speziellen Eigenheiten versuchen zu trennen, um damit die Nutzbarkeit der Investition (leverage) zu maximieren und für die Zukunft geringere Aufwände zu produzieren.

Über unterschiedliche Projekte hinweg kann sich somit und dadurch ein Unternehmen eine ganze Sammlung von Komponenten erarbeiten, die für Folgeprojekte zu Verfügung stehen und in diesen genutzt werden können (technical business assets). Durch die konsequente Verwendung von Standards ist dabei eine langfristige Investitionssicherheit gegeben.

Ebenfalls ergeben sich aus den Komponenten Anwendungsmuster, die in die weiteren Architektuplanung einbezogen werden können, um auch Fremdsysteme entsprechend der vorhandenen Pattern zu steuern - auch hier kann weitergehend die Investition genutzt werden.

In einer flexiblen Systemarchitektur, die nach service-orientierten Gesichtspunkten aufgesetzt ist, stellt die Überwachung eine besondere Herausforderung dar.Durch die sowohl technische wie auch fachliche Überwachung lassen sich während des Betriebs Trendlinien für die operative Gestaltung ableiten, aber auch Geschäftschancen ableiten.

Unter technischem Monitoring kann man dabei die folgenden Aktivitäten zusammenfassen:

• Überwachung des Systemzustands von deployten Komponenten (gestartet, gestoppt, etc.)
• Überwachen der Randsysteme (Zustand von DB-Tabellen, die ausgelesen werden, etc., Nachrichtenmengen in Queues)
• Überprüfung mögl. vereinbarter Service-Level-Agreements mit dem Ziel eines Frühwarnsystems

Unter fachlichem Monitoring kann man hingegen die folgenden Aktivitäten zusammenfassen:

• Überwachung des Auftragseingangs/Std.
• Überwachung von Auswirkungen durch fachl. getriebene Werbekampagnen
• Messung der Wartezeiten von Anrufern in Call-Centern

Dabei lassen sich viele Aufgabenstellungen im Umfeld BAM auf wenige, sehr gleichartige Prinzipien zusammenfassen:

• Bewertung von Daten anhand konfigurierter Kritierien
• Messung von Zeit, Anzahl, abgeleiteten Werten (z.B. Durchsatz)
• Eskalation bei Überschreitung von Schwellwerten (Trend-Breaks, etc.)

Wie konkret die einzelnen Aufgaben konkret realisiert werden, ist eigentlich gleich - von Bedeutung ist, dass diese gleichartig sind und damit auf die gleiche Art und Weise realisiert werden können.

Implementiert man abstrakte/generische Komponenten, die diese Aufgaben erledigen, meistens auf Basis von XML, erhält man eine investitionssichernde Applikation, die auch späteren Änderungen standhalten kann.

Eine mögliche Architektur für eine solche Komponente kann wie folgt aussehen:

• Erstellung von Adaptern für die einzelnen Zielsysteme. Diese greifen auf die Randsysteme zu und extrahieren die relevanten Daten. Diese liegen entweder in einem allg. Format vor, dass für die BAM Komponente allgemeingültig ist, oder in einem applikationsspezifischen Format auf Basis von XML. Sofern man für ein applikationsspezifisches Format votiert, hat das den Vorteil, das weniger Anpassungen an den betroffenen Randsystemen erforderlich sind. Dafür muss die Integration dann “vor” der BAM Komponente erfolgen.
• Erstellung einer Vorverarbeitung. Diese extrahiert die für den Trigger relevanten Informationen und stellt diese der BAM Komponente in kanonischer Form bereit. Kanonisch bedeutet, dass alle relevanten Informationen wie eindeutige Zuordnungs-ID, relevante Zeitstempel, etc. vorhanden sind
• Erstellung einer Integration. Diese nimmt die extrahierten, kanonischen Daten entgegen und integriert diese zu einer Gesamtsicht. Dabei bleiben alle Daten erhalten, werden aber für Zugriffe zur Verfügung gestellt. Diese Komponente ist ebenfalls in der Lage, Anfragen bzw. Bewertungsqueries zu beantworten, hinsichtlich der Anzahl von Datensätzen zu einem Schlüssel, Zeitstempel, Mittelwerte/Durchsätze. Durch die Verwendung einer zentralen Komponente, die alle Daten verwaltet, können Erweiteurngen in Bezug auf neue Abfragen/Operationen einfach (z.B. über eine Plugin-Architektur) hinzugefügt werden.

Das Hauptaugenmerk liegt sicherlich auf der BAM Komponente selber. Diese muss in der Lage sein, Konfigurationen einzulesen und diese zu verarbeiten. In diesen Konfigurationen wird für jeden Schlüssel hinterlegt, welche Operationen aufgerufen werden und welche Schwellwerte, welche Aktionen auslösen.

Durch diese nicht-monolithische Architektur wird sichergestellt, dass es keinen development-lock-in gibt, sondern kontinuierliche Erweiterbarkeit sichergestellt ist.

Die BAM Kompenten kann dabei über diverse Wege selber Statistiken bereitstellen (Hit/Miss Ratio, Trends, etc.), die Aussagen über die Intensität und den “Erfolg” der implementierten Regeln geben.

Die Aktionen, die eine BAM Komponente ausführen kann, sollte wiederum in Form von Plugins vorhanden sein. Dadurch ist maximale Flexibilität gewährleistet und jede Aktion für sich kann über das kanonische Datenmodell alle relevanten Informationen abgreifen.

Die Implementierung kann beispielsweise auf Basis eines ESB erfolgen, indem über eine Registry die vorhandenen Plugins registriert werden (je nach Kategorie (Aktion, Operation)). Die BAM Komponente kann über die Registry dynamisch abfragen, welche Operationen zu Verfügung stehen und damit autonom entscheiden, welche Trigger überhaupt aktiviert werden. Diese wiederum greifen über das zentrale Datenmodell auf die Faktenbasis zu und lösen über ihre Ergebnisse ggf. Aktionen in der BAM Komponente aus.

Über diese enge aber trotzdem loose Verzahnung von einzelnen Komponente lässt sich Flexiblität und schnelle Änderbarkeit zentral und verteilt realisieren - eine service-orientierte Architektur auf Basis (eventuell) eines ESB.

Im Rahmen dieser kurzen Ausführungen habe ich vorgestellt, wie auf Basis eines konkreten Geschäftsnutzens eine service-orientierte Architektur verwendet werden kann, um dynamisches Business Activity Monitoring zu implementieren. Als Standardarchitektur kann dabei ein Enterprise-Service Bus eingesetzt werden, der das kanonische Aufrufen von Komponenten ermöglicht und sicherstellt. Im Rahmen einer service-orientierten Architektur kann somit eine “SOA in Klein” etabliert werden, die genau die benötigten Anforderungen umsetzt.

Im Rahmen des SOA Expertenrats der Computerwoche hat Rolf Schumann einen Artikel über Mashups veröffentlicht.

Ich gehe eigentlich nicht davon aus, dass sich in nennenswerter Weise Mashups in näherer Zeit etablieren werden. Die Idee hinter einem Mashup ist, Daten aus unterschiedlichen Quellen zu rekombinieren, um darüber Mehrwert zu erzeugen.
Dazu bedarf es aber einiger Voraussetzungen:

• Die Daten müssen vorhanden und entsprechend zugreifbar sein
• Die Verknüpfung sollte einfach und schnell erfolgen

Das Vorhandensein von Daten ist dabei in den wenigsten Fällen ein Problem, aber allein das hoch-integrative Beispiel von Kartenmaterial zeigt auf, dass es um die Datenverknüpfung von internen wie externen Daten geht. Aus Datenschutzgründen ist es für Unternehmen sicherlich schwierig zu akzeptieren, dass Daten von außen den Daten “im Inneren” beigemischt werden. Der Mehrwert von Mashups kann schließlich in den wenigsten Fällen komplett im Unternehmen selber geleistet werden.

Vielmehr ist der Datenbestand im Unternehmen der Ausgangspunkt für ein Mashup. Darauf aufbauend können anschließend Daten “von extern” dazugezogen werden, um diese Informationen zu visualisieren oder wie-auch-immer anzureichern. Zumal die meisten Datentöpfe für diese Art der Verwendung auch nicht vorbereitet sind.

Neben diesen Problemen sind auch Aspekte des Zugriffs noch ungeklärt. Zugriffsschutz auf interne Daten muss auch bei Verwendung von Mashups erhalten bleiben. Dazu gibt es AFAIK in der “Szene” noch keine Antworten.

Die einfache Bereitstellung ist sicherlich auch noch ein riesiges Problem. Yahoo hat gezeigt, wie es “vereinfacht” gehen kann, aber ob dies das Ende der Fahnenstange ist, darf bezweifelt werden. Auch Google arbeitet in diesem Gebiet mit, auch hier dürften Innovationen noch zu erwarten sein. Das Credo muss auch hier sein, dass das Mashup

• einfach und
• für den Fachbereich verständlich

erstellt werden kann. Nur dann ist die Akzeptanz da, diese neue Möglichkeit aufzugreifen und Lösungen “mal eben so” zu erstellen und zu nutzen.

Aber auch wie Wiki’s oder Weblogs nach einer ganzen Weile Einzug ins Unternehmen halten, wird auch das Mashup seinen Platz in der Unternehmenswelt finden - und sei es nur als leichtgewichtige Möglichkeit, die Unzulänglichkeiten der im Einsatz befindlichen Applikationen “einfach” zu überspielen, indem dynamische Datenverknüpfungen  “on demand” geschaffen werden, um Fragen zu beantworten.

Nicht umsonst ist die statische Verknüpfung von an sich dynamischem Inhalt der große Vorteil. Diesen für die Geschäftswelt sichtbar zu machen und durch die IT in geordneten Bahnen umzusetzen ist sicherlich eine Herausforderung, die kommen wird. Nur wann - wie immer schwer abzusehen