tag:blogger.com,1999:blog-80077343185662843142024-02-20T07:08:18.907-08:00OOP Conference BlogBlog im Rahmen der OOP Conference (München). Dieses Blog wird in einen Blog-Planeten eingebundenMichaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-8007734318566284314.post-50698960118143076302008-12-21T09:59:00.001-08:002008-12-21T10:19:10.876-08:00[OOP 2009] De ja vu<p>Neulich lief im Fernsehen eine Sendung zur Intelligenz von Tieren. Und in einem der Experimente waren die Versuchstiere vor die Aufgabe gestellt,  in einem Labyrinth den Ausgang zu finden. Während viele Tierarten das Problem durchaus mit Bravour meisterten, scheiterten andere kläglich, sehr zum Amüsement der Zuschauer. Wer als Informatiker an dieser Stelle zum Lachen neigt, für den habe ich eine schlechte Nachricht. Dieselbe Beobachtung  lässt sich nämlich auch machen, wenn wir von einem erhöhten Standpunkt das ein oder andere Softwareentwicklungsprojekt betrachten. Jeder weiss wie wichtig effektive Kommunikation ist. Dennoch scheitern gerade daran nicht wenige  Projekte.  Dass Testen und Refactoring essenzieller sind als Amok laufender Featurismus, erkennt jeder unbeteiligte Entwickler. Sobald man dieselben Personen auf ihre eigenen Projekte loslässt, erwacht der Spieltrieb sowie der innere Drang nach überbordernder Funktionalität. Täglich hören wir Lobesgesänge auf agile Prozesse und strukturiertes Vorgehen. Warum schaut die Praxis bisweilen so  wenig agil aus? Klar, es liegt am Management! Oder doch eher an den vielen Technologien, die allesamt so untauglich sind? Vielleicht aber auch an den vielen unfähigen Kollegen? Haben wir erst einmal ein Projekt erfolgreich versenkt, so decken wir den Mantel des Schweigens darüber anstatt uns der Ursachenforschung zu widmen. Warum tapsen so viele intelligente Humanoide immer wieder in dieselben Fallen, amüsieren sich aber gleichzeitig über andere weniger smarte Spezies? Warum haben wir Gedächtnisstützen wie die vom "reinvent the wheel", halten uns daran aber in der Praxis oft wenig. Douglas Adams hat einmal gesagt, dass es typisch sei für die Menschheit, dass die meisten die Wiederverwendung von Erfahrungen anderer ablehne. Natürlich, es gibt Hoffnungsschimmer wie etwa Softwaremuster. Insgesamt sehen wir hier aber nur die berüchtigen Tropfen auf dem heissen Stein. </p> <p>Für die Spezies der Consultants hat das alles einen positiven Effekt. Solange wir derart ungeschickt bei der Softwareentwicklung agieren, brauchen sich Berater keine Sorgen um ihre Zukunft zu machen. Vielleicht sollten wir demnächst eine neue Art von IT-Rolle erfinden: den IT Counseler, um zumindest die negativen weil demotivierenden Effekte abzumildern.</p> <p>So weit mein Wort zum Sonntag.</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-17507567394055164182008-12-19T08:39:00.001-08:002008-12-19T08:39:44.423-08:00[OOP 2009] Software by Big Bang<p>Sie sind Softwareentwickler und meinen, die Finanzkrise könnte Ihren Job gefährden?</p> <p>Dann sind Sie leider bereits einem grossen Irrtum zum Opfer gefallen. Der wahre Feind des Softwareentwicklers ist der latente Trend zu "Software by Big Bang". Statt Personenjahre über Personenjahre in aufwändige Eigenentwicklung zu stecken, nutzen Sie besser die Möglichkeiten der Automatisierung! Ein Knopfdruck genügt und die generierte Anwendung steht bereit. Warum "Urknall"? Wenn es möglich ist, aus dem Nichts alles zu schaffen, dürfte sich dies doch für unsere Disziplin nicht als unmöglich erweisen. Ist nicht, genau genommen, alles bereits mit dem Urknall inittiert worden, selbst das vorliegende Posting und auch Ihre Software? Wir alle und unsere Leistungen repräsentieren also eher Kollateralschäden als kreative Schöpfungen. </p> <p>Die Devise muss demzufolge heissen, mit der Welle zu schwimmen und nicht gegen sie. Ganz nach  dem Motto "Generierst Du schon oder entwickelst Du noch?" </p> <p>Die Lösung auf alle Probleme - und hier bitte in Ihrer Fantasie die Fanfaren erklingen lassen - heisst MDD (in Worten "Model Driven Development") in Kombination mit DSL (in Worten "Domain Specific Language"). </p> <p>Das Rezept für ein sorgenfreies Informatikerleben lautet also: Man nehme eine Prise Metamodellierung, erzeuge unter ständigem Umrühren einen Anforderungsteig, lege das Ganze in den Cookie Generator und schon ist alles angerichtet - natürlich im doppeldeutigen Sinne.</p> <p>Im richtigen Leben funktioniert das alles nicht so glatt, weil das Problem zwei Seiten hat. Zum einen ist der Ansatz nur für gut durchdrungene, kleine Domänen sinnvoll. Dass es durchaus schwierig sein kann, eine gemeinsame DSL zu definieren, dürfte jeder bestätigen, der das in einer Beziehung schon einmal versucht hat. Zum anderen muss man sich irgendwann die Frage stellen, wer denn den Generator baut, in dem letztendlich die ganze Komplexität steckt. Da bekommt das Sprichwort vom "unter den Teppich kehren" eine ganz neue Wendung.  Man sollte also auf dem Teppich bleiben und die Erwartungshaltung so mancher Entwickler oder Entscheidungsträger zügeln.  </p> <p>Gab es da nicht schon andere "silver bullets" ähnlichen Kalibers. Komponenten, Services, 4GL, UML, .... Jede Technologie wurde zunächst zum Allheilmittel stilisiert, um sich dann wenig später einen kräftigen Kater einzufangen.</p> <p>Das ganze IT-Buzzword-Bingo führt nämlich mitunter dazu, dass Manager die versprochenen Verheissungen tatsächlich ernst nehmen und diese von der eigenen Entwicklung einfordern. Mit der virtuellen, weil nicht existenten Silberkugel kann man also allerhöchstens wild gewordene ITler zur Strecke bringen, nicht aber die Menge aller Probleme des Software Engineering.</p> <p>Hat das was mit Soft Skills zu tun? Klar! Kleiner Tipp: studieren Sie einmal die Auswirkung von übertriebener Technikeuphorie  auf die Managementebenen. Wenn Sie positive Effekte wahrnehmen, sollten Sie sofort mit dem Lottospielen beginnen oder eine Karriere als Stuntman starten. Erwartungsmanagement gehört also zu den wichtigen Aufgaben des professionellen Softwareentwicklers.</p> <p> </p> <p>MDD, Komponenten, Services sind alles brauchbare Technologien, aber nur wenn man ihre Grenzen kennt und sie entsprechend einsetzt. Ansonsten heisst es dann: riez ne va plus.</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-3790806234609068332008-11-14T15:23:00.001-08:002008-11-14T15:23:47.212-08:00[OOP 2009] Der Softwareingenieur ist zu allem fähig<p>Sobald Sie für Ihr Projekt oder Organisation neue IT-Spitzenkräfte akquirieren wollen, sollten Sie sich zuvor eingehende Überlegungen zu deren wichtigsten Fähigkeiten und Eigenschaften machen. Aus nahezu unzähligen Projekten habe ich die folgenden Erfahrungswerte zusammengestellt. Scheuen Sie sich nicht, ohne schlechtes Gewissen davon Nutzen zu ziehen und Sie als Ihre eigenen Elaborate auszugeben:</p> <ul> <li>Die wichtigste Eigenschaft des Ingenieurs ist absolute Verschwiegenheit. Eine größere Konmunikationsfähigkeit des Bewerbers sollte Sie von Anfang an stutzig machen. Zum einen bezahlen Sie diese Leute fürs entwerfen und programmieren, nicht fürs reden, und zum anderen richten kommunikationswillige Neonbabies zu viel Schaden an, speziell wenn Kunden ins Spiel kommen.</li> <li>Gerade bei Softwarearchitekten dürften technische Kenntnisse eher kontraproduktiv wirken. Der wahre Experte nutzt UML-Werkzeuge wie Powerpoint und Visio, um unvoreingenommen Lösungen zu realisieren. Techniknähe hingegen führt zu experimentierfreudigen Entwicklern, die der Firma nur kostbare Arbeitszeit stehlen.</li> <li>Vorhergehende Projekterfahrungen führen zu demotivierten Mitarbeitern. Unerfahrene Fachleute können ihren Traum noch leben und in utopischen Visionen schwelgen. Nur dadurch lassen sich Überraschungen in den laufenden Entwicklungen gewährleisten. Aus demselben Grund gehört Lernen aus Fehlern zu den Grundübeln jeder Teamkultur. Erstens machen Softwareentwickler keine Fehler und zweitens wiederholen sie Fehler nicht, selbst wenn sie zuvor welche gemacht haben sollten. Und drittens lassen sich Fehler zu Feature umdefinieren wie große Hersteller beweisen.</li> <li>Entwicklungsprozesse und ganz besonders die agilen sollen nur gewissen Softwareherstellern eine kontinuierliche Integration grüner Scheine sicherstellen. Softwareexperten, die Prozesse für nötig halten, dürften eher an Provisionen von besagten Protagonisten interessiert sein. Das Wasserfallmodell ist das einzig selig machende, auch wenn uns verirrte Sektisten eines Besseren belehren wollen.</li> <li>Testen ist nur etwas für Verlierertypen und Bürokraten, nicht für unternehmerisch denkende IT-Experten. Wer sorgfältig agiert, braucht nicht zu testen. Oder gehören Sie zu jener pedantischen  Spezies, die Reinigungskräften auf der Suche nach übrig gebliebenen Schmutzresten hinterher schleicht. Testsucht ist also eher mit Waschzwang vergleichbar.</li> <li>Anforderungsanalyse ist nur was für richtige Männer, nichts für Weicheier aus der IT-Abteilung. Ein Softwareentwickler sollte also gar nicht erst versuchen, Anforderungen im Detail zu verstehen, sondern nur das umzusetzen, was sie oder er zu verstehen glaubt. Weil hinterher jeder Änderungswunsch von Kunden zu grossen  Aufwänden führt, sollten sie sich schon jetzt einen Tresor zulegen, um die daraus resultierenden zusätzlichen Gewinne sicher zu verwahren.</li> <li>Teamfähigkeit impliziert Geselligkeit und unterstützt revoluzerische Verhältnisse. Achten Sie daher auf uneigenständige, infantile Mitarbeiter, die stets  an Ihrem Rockzipfel hängen. Einzig Tyrannei und Diktatur in Softwareprojekten kann dafür sorgen, dass die Karwane erfolgreich weiterzieht. Wie ein ehemmaliger Bundeskanler doch so trefflich bemerkte: letztes Jahr befanden wir uns einen Schritt vor dem Abgrund und dieses Jahr sind wir schon einen Schritt weiter.</li> </ul> <p>Es gäbe noch viele weitere Fakten und Empfehlungen anzuführen, doch ist es für den Autor Zeit, seine nächtliche Ruhestätte aufzusuchen und zuvor noch dem Gott der Informatik zu fröhnen - dem Paulaner! </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-8070115969417529502008-11-13T09:48:00.001-08:002008-11-13T09:52:11.841-08:00[OOP 2009] Layers & Co<p>Ich weiss nicht ob Sie es schon wussten, aber in größeren Organisationen ist das Layers-Architekturmuster sehr verbreitet. Ganz oben in schwindelerregender Höhe thront das Management und delegiert Aufgaben gerne nach unten (absteigende Nahrungskette). Die unterste Schicht wiederum ist für die Umsetzung zuständig, versteht nur selten die Sprache der obersten Schicht, versteckt sich also in der Regel hinter einer Low-Level Perspektive. Wegen des zumeist strikten Layerings befinden sich dazwischen ganz viele weitere Ebenen. Gerade die Layers in der Mitte fühlen sich in ihrer Sandwich-Position nur selten wohl und neigen dazu, den Informationsfluß in beiden Richtungen zu misszuverstehen oder sogar zum Stillstand zu bringen, was zu Fehlinterpretationen in den obersten und untersten Hierarchien führt. Moral von der Geschicht: strikte Layers bringen's nicht.</p> <p>Daher ist es ratsam, Mediatoren in solche Organisationen einzuschleusen. Diese wissensdurstigen Mitmenschen saugen geradezu jede noch so unbedeutende Information in sich auf und geben sie auch an alle weiter, die sie hören wollen oder nicht. Dumm nur, wenn Mediatoren die Information vorverdauen oder gar verfälschen. Dann wird aus diesem Unterfangen so ziemlich schnell ein Eigentor. Wer kennt nicht die neuesten Gerüchte die eigenen Person betreffend, die sich als völlig realitätsfern erweisen. Nicht zu vergessen die unterschiedlichen Interzeptoren, die gerne interessante Neuigkeiten erhaschen, um sie dann gewinnbringend für eigene Zwecke zu adaptieren.</p> <p>Günstig ist in vielen Fällen des (IT-)Alltags das Strategiemuster, das eine einheitliche Fassade bietet, hinter der sich die Untiefen des eigenen Handelns verstecken lassen. </p> <p>Um einen bekannten Komödianten zu zitieren. Ich könnte noch viele Beispiele für solche soziointeraktive Muster nennen, wenn ich nur welche wüsste.</p> <p>Interessant ist auf jeden Fall, dass das soziale Zusammenspiel in Organisationen sich mit Mustern beschreiben lässt.</p> <p>Und da soll noch mal einer sagen, wir Informatiker hätten es nicht so mit den alltäglichen Dingen oder wären sogar soziale Underperformer.</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-19512235760275068072008-11-10T23:34:00.001-08:002008-11-10T23:34:36.061-08:00[OOP 2009] Design by Committee<p>Was kommt raus wenn ein paar Dutzend Vertreter einer affenähnlichen Spezies im Vollrausch Software entwickeln?</p> <p>C++ und MS-DOS!</p> <p>Für den angemessenen Umgang mit besagter Software bedarf es freilich wieder der Einnahme bewusstseinsverändernder Drogen. </p> <p>Frederick F. Brooks, der vor etlichen Jahen die besagte Silver Bullet auf uns Informatiker  abgefeuert hat, vertritt die Ansicht, dass die meisten guten Entwürfe in der Geschichte der Menschheit unter der  Federführung exzellenter Einzelpersonen (also known as Exzentriker) entstanden sind. Er erwähnt in diesem Zusammenhang Kathedralen, den Apple Mac und die Programmiersprache Java.</p> <p>"So what?", denkt sich der  jetzt der deutschsprachige Leser. Offensichtlich bedarf es Teams, um größere Bauwerke zu entwerfen, aber auch Einzelpersonen, um diese Teams ins Ziel zu lenken. Teams ohne Führung neigen zu "suboptimalen" Entwürfen, was wir auch in Politik und Finanzwirtschaft jüngst miterleben durften. q.e.d.</p> <p>Es bedarf also auch in der erfolgreichen Softwareentwicklung Teams und geeigneter Führungspersönlichkeiten. Fähigkeiten wie Mut, Führungsstärke, Kommunikation oder Teamfähigkeit sind also nicht nur Faktoren, die bei Sonntagsreden weidlich breit getreten werden, sondern in der IT-Realität sich als unabdingbar erweisen.</p> <p>Aber Achtung! Führung braucht Kontrolle, wenn nicht Produkte Golem-scher Prägung das Licht der Welt erblicken sollen. </p> <p>Der Blick auf Technologie und Werkzeuge vermittelt zwar ein angenehmes Gefühl, aber Softwareentwicklung bleibt nicht zuletzt  zu gut hochdeutsch ein "Collaborative Game". </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-43013164973717910332008-11-04T06:10:00.001-08:002008-11-10T15:29:47.468-08:00[OOP 2009] Ja mei, ist denn schon wieder OOP?Wie Weihnachten kommt auch die OOP jedes Jahr völlig überraschend. Wie Weihnachten, weist auch die OOP immer nette Überraschungen auf. Und wie immer, darf ich selbst als aktiver Teilnehmer partizipieren. Ob das eine gute oder schlechte Nachricht ist, müssen die Teilnehmer freilich selbst entscheiden. <br /> <br />Auf jeden Fall finde ich das Motto der Konferenz ganz besonders spannend. "Skills" sind schließlich der Schlüssel für erfolgreiche Projekte. Für die Spezies der Softwarearchitekten reicht es eben nicht aus, technologische Fähigkeiten zu haben. Gerade der Bereich Soft Skills und ein grundlegendes Verständnis über Wirtschaftlichkeit sind unentbehrlich. Ein Architekt braucht Führungsstärke, Mut, Leidenschaft und Leidensfähigkeit - gerade um andere Rollen im Projekt von der Architektur zu überzeugen. Nur werden diese Skills zu selten in Ausbildung und Beruf vermittelt. <br /> <br />Da kommen dann mitunter folgende Varianten zum Vorschein: <br /> <br />Papiertiger haben gute Ideen, bringen diese zu Papier, sind aber nicht in der Lage, andere zu motivieren oder zu überzeugen <br /> <br />Stubenhocker erstellen in ihrem dunklen Kämmerlein die besten Konzepte, wundern sich aber, dass die bösen Entwickler da draussen fast nichts davon umsetzen. <br /> <br />Danger Seekers trauen sich alles zu. Nur leider ist ihnen auch alles zuzutrauen. Oft führen sie Architekturen ein, die sich im nachhinein als großes Risiko erweisen. <br /> <br />Und das nur als Auswahl aus der Artenvielfalt. Der Geist war willig, aber ... den Rest kennen Sie schon. <br /> <br />Interessanterweise scheitern die meisten Projekte eben nicht an technologischen Aspekten sondern an architektonischen Runinen, Politik, Mißverständnissen, Organisationshürden, ungeeigneten Entwicklungsprozessen. Und hinter all dem stecken Personen und Rollen, die für erfolgreiche Projektarbeit entsprechende Skills benötigen. <br /> <br />Kennen Sie da auch noch ein paar typische Variationen von Architekten oder anderen Spezies aus dem Software Engineering? Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-62392584748304901802008-02-09T04:16:00.001-08:002008-02-09T04:16:01.978-08:00[OOP 2008] New Kids on the Blog<p>Blogs sind eine der bekannten Ausprägungen des Web 2.0. Nun gibt es eine Vielzahl von Blogs, von Themen wie Herzschmerz über Politik bis Technik. Von Belanglosem bis Weltbewegendem. Auch im Bereich Softwareentwicklung haben sich inzwischen einige Blogs etabliert. Das gilt natürlich auch für Podcasts, aus meiner Sicht eine eher audiovisuelle Form des Blogging. Ich selbst betreibe z.B. einen Blog über <a href="http://stal.blogspot.com/">Softwarearchitekturen</a>. Meine Frage: Was sind empfehelnswerte Podcasts und Blogs aus dem Gebiet Software Engineering. Was muss man hören oder lesen, was sollte man lieber ignorieren? Natürlich darf an dieser Stelle das exzellente  <a href="http://www.se-radio.net/">SE Radio</a> nicht fehlen. Vorschläge?</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com1tag:blogger.com,1999:blog-8007734318566284314.post-40578192464588995692008-02-08T13:05:00.001-08:002008-02-08T13:05:42.313-08:00[OOP 2008] Ultra Large Scale Systems<p>Ein Thema hat dann doch gefehlt auf der OOP. Das Thema ULS (Ultra-Large-Scale-Systems), welches das amerikanische DoD vor 2 Jahren in Form einer Studie beleuchtet hat. "Ja, was ist denn das?", werden Sie sich jetzt möglicherweise fragen. ULS-Protagonisten wie Linda Northrop vom CMU SEI würden höchstwahrscheinlich einen metaphorischen Vergleich anstellen. Während bisherige Softwareentwicklung grosser Systeme eher mit dem Bau von einzelnen Infrastrukturen oder Gebäuden zu vergleichen ist, stellt ULS den Bau ganzer Städte dar.  Es geht also nicht um Systeme, sondern um Systeme von Systemen. Es geht um Netze, in denen Menschen selbst zu Netzknoten werden. Es geht darum, dass statt einer zentralistischen Kontrollinstanz Dezentralität dominiert. Das sind Systeme, die ungebremste Evolution aufweisen. Klar, dass darin emergentes Verhalten eine wichtige Rolle spielt, ebenso wie die Tatsache, dass Anforderungen durchaus kollidieren können. Es geht also um Ameisenstaaten.  Riesige Gesundheitsinfrastrukturen integriert im Internet, ergänzt um Telemedizin oder integrierte Telematiksysteme stellen potenzielle Anwendungsgebiete dar. Welche Fragen stellen ich dabei der Softwareentwicklung? Viele, die wir heute nur bedingt lösen können. Und darüber hinaus, genügt Informatik nicht. Hier sind verschiedene Fachrichtungen notwendig. SOA-Systeme "denken" dabei schon ein wenig in eine ähnliche Richtung. Das Internet stellt gewissermassen ein kleines ULS dar. Das ist doch nur für grosse Infrastrukturen relevant! Falsch, denn die gleichen Konzepte lassen sich auch im kleinen nutzen. Insofern stellt Rxploration der ULS-Ansätze ein interessantes Forschungsgebiet dar, gerade für zivile Anwendungen.</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-42630611274094818612008-02-08T10:30:00.001-08:002008-02-08T10:30:25.989-08:00[OOP 2008] Nach der OOP ist vor der OOP<p>Zwei Wochen sind bereits vergangen seitdem die OOP 2008 ihre Pforten geschlossen hat. Mit einem gewissen Abstand fällt es leichter, ein Fazit zu ziehen. Was waren dieses Jahr die thematischen Schwerpunkte, wie lautet also die Hitparade der Themen? Wenn man alles Revue passieren läßt, gehört sicherlich SOA zu den Topthemen der Konferenz und dies in allen möglichen Facetten. Aber auch das alte aber immer hochaktuelle Thema Softwarearchitekturen nahm neben Agilen Prozessen einen breiten Raum ein. Insgesamt habe ich den Eindruck, dass sich dieses Jahr die Techie-Themen der Art "Neue coole Technologie X" eher im Hintergrund hielten, während die tatsächlichen Praxisprobleme beim Software Engineering im Vordergrund standen. Ein bisschen gegen den Strom schwamm allerdings die durchaus intensive Thematisierung dynamischer Sprachen. Die gehören in den Firmen noch nicht unbedingt zum Mainstream, könnten aber bald größeren Einfluß gewinnen. Schließlich sind Sprachen wie C++, C# oder Java zwar mächtig, für einige Probleme aber viel zu unproduktiv. Was mir sehr gut geafllen hat, ist der Blick über den Tellerrand, in Form von Keynotes und Vorträgen, die sich auch Aspekten jenseits der Technik widmeten. Seien wir ehrlich, in den meisten Projekten stellt das Beherrschen von Technologien zwar eine Herausforderung dar, aber die meisten Probleme resultieren eher aus Fehlleistungen anderer Art. Insgesamt hat die OOP den Spagat geschafft, zwischen technischen und nicht-technischen Themen ein breites Spektrum abzudecken, ohne aber den roten Faden zu verlieren. Dadurch hebt sich die Veranstaltung wohltuend von den sonstigen Hardcore-Technik-Events ab.   </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-77319890816875140252008-01-25T10:58:00.001-08:002008-01-25T10:58:59.288-08:00[OOP 2008] Back to the Future - Forward to the Past<p>Die OOP 2008 vorbei und schon steht die OOP 2009 vor der Tür. Was waren die Highlights der diesjährigen Veranstaltung? Eigentlich lassen sich diesmal gar nicht so richtig einzelne Themen identifizieren. War es Scrum? Oder SOA? Oder Agilität? Mir fällt die Antwort schwer, zumal die OOP eine ganze Reige spannender Themen zu bieten hatte.</p> <p>Was aber noch viel spannender sein dürfte: welche kommenden Trends erwarten uns für die OOP 2009 und später? Alles nur nicht SOA oder Agilität, würde man fast sagen. Aber im Ernst wie lauten die Trendthemen für die nächste Zukunft?</p> <p>Sind es dynamische  Sprachen?</p> <p>Oder neue Middlewareansätze?</p> <p>Oder Produktlinien?</p> <p>Oder ganz was anderes?</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-58171370270335681062008-01-18T03:07:00.001-08:002008-01-18T03:07:34.914-08:00[OOP 2008] Languages are a Programmer's Best Friends<p>Wer das berühmte Buch der Pragmatic Programmers kennt, dürfte sich an die Empfehlung erinnern, der Informatiker solle sich jedes Jahr eine neue Programmiersprache aneignen - wer das Buch übrigens nicht kennt, sollte es sich unbedingt anschaffen.</p> <p>An diese Empfehlung habe ich mich gehalten und in den letzten Jahren Ruby, D, ein wenig Groovy sowie Lisp gelernt und mich neuerdings mit Scala beschäftigt. Nicht, dass ich jetzt täglich Projekte in unterschiedlichen Programmiersprachen anstreben würde. Jede dieser Sprachen integriert innovative Konzepte, die zu einer neuen Sicht auf die Dinge verhelfen und nicht zuletzt zu einer intellektuellen Herausforderung. Allerdings muss ich gestehen, dass ich ursprünglich vom Sprachdesign und Compilerbau komme, und dadurch zum Sprachen-Junkie mutiert bin. </p> <p>Was aber könnte ich mir für 2008 vornehmen? Ein heisser Kandidat könnte Erlang sein, eine Sprache, die sich speziell für verteilte und parallele Systeme eignet. Kein Wunder, stammt Erlang doch aus den Federn vom Telekommunikationserfahrenen Joe Armstrong. Von Klaus Rohe wurde mir F# ans Herz gelegt, eine funktionale Sprache für .NET. </p> <p>Gibt es noch weitere Kandidaten? Was bringt interessante Konzepte mit und was könnte in Zukunft etablierten Sprachen das Fürchten lernen? Vielleicht bekomme ich hier ja ein paar gute Tipps. </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com1tag:blogger.com,1999:blog-8007734318566284314.post-31034248963195897472007-12-28T03:55:00.001-08:002007-12-28T03:57:02.037-08:00[OOP 2008] Re-use sucks - sometimes!<p>In dem <a href="http://ralfw.blogspot.com/2007/12/oop-2008-wider-die-wiederverwendbarkeit.html">Blogpost</a> adressiert Ralf eines meiner Lieblingsthemen, "W-I-E-D-E-R-V-E-R-W-E-N-D-U-N-G". Da kann ich natürlich nicht widerstehen. </p> <p>Vor einigen Jahren hatte ich mal bei Siemens einen Workshop zum Thema "Komponenten-basierte Entwicklung" organisiert. Da stellte sich heraus, dass in der Tat nicht (nur) Wiederverwendung sondern Adaptierbarkeit als wichtiges Thema erachtet wurde. Einer der Experten ging sogar so weit, sich darüber lustig zu machen, dass einige Firmen sich damals  intensiv mit der Bereitstellung von Wiederverwendungs-Repositories beschäftigten. Dummerweise sollte sich schon bald herausstellen, dass die "Füllung" dieser Repositories sehr zu wünschen ließ. gab es doch nicht allzu viele wiederverwendbare Bausteine, außer in einigen "ablegenen Randdomänen". Und sogar die wiederverwendbaren Komponenten zeitigten einige Probleme. Man denke an das 95%-Problem - die wiederverwendbare Komponente erfüllt fast alle Wünsche, nur einen klitzekleinen Teil hätte man gerne geändert. Vorstellungen wie die von Brad Cox Anfang der Neunziger Jahre, es gäbe irgendwann eine komplette weltweite Wiederverwendungsinfrastruktur, lösten sich schon bald wie Seifenblasen auf - Plopp! </p> <p>Lustig wie sich das Thema Wiederverwendung dennoch wie ein roter Faden durch die Infomatikgeschichte zieht. Beim Erscheinen jedes neuen Paradigmas (etwa Komponenten oder neuerdings Services) verlassen die Wiederverwendungsjünger ihre Verstecke und setzen ihre Missionierungsbemühungen fort.</p> <p>Ist also Wiederverwendung eine Sackgasse oder ein unerreichbares Ziel? Leider erachten viele Ingenieure Wiederverwendung als singulären, rein funktionalen Ansatz oder geben sich mit punktueller Wiederverwendung zufrieden.  Ein systematisches Vorgehen hingegen muss alle Aspekte berücksichtigen, technische, architektonische, organisatorische, prozeßspezifische. Re-use funktioniert immer dann, wenn es einen solchen holistischen Ansatz gibt. Wir sind beim Thema "Product Line Engineering" (PLE) angelangt, bei dem es um Programmfamilien geht, die auf gemeinsamen Artefakten beruhen (Wiederverwendung), aber auch teilweise unterschiedliche Anforderungen berücksichtigen (Adaptierbarkeit). In PLE gibt es eine strenge Unterscheidung zwischen den Plattformentwicklern (die für die wiederverwendbaren Artefakte verantwortlich sind) und den Anwendungsentwicklern, die auf Basis der Plattform eigene Software entwickeln. Im Prozeß werden dafür spezielle Aktivitäten integriert wie Scoping. Domain Engineering, Commonality/Variability-Analysen und Feature Modelling. Wichtige Themen wie Plattformevolution finden ebenfalls ausreichend Berücksichtigung: was zum Beispiel passiert wenn eine wiederverwendbare Komponente erweitert oder verändert wird, zumal etliche Anwendungen von diesen Komponenten abhängen? </p> <p>Aus meiner Sicht bietet gerade Product Line Engineering einen vielversprechenden Ansatz, um Wiederverwendung auf stabile Beine zu stellen. Es zeigt sich aber auch sehr deutlich: Wiederverwendung ist nicht umsonst zu haben, weshalb es durchaus Szenarien gibt, in denen der Entwickler die Finger davon lassen sollte. </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com1tag:blogger.com,1999:blog-8007734318566284314.post-47112474165964824022007-12-24T04:58:00.001-08:002007-12-24T05:03:07.560-08:00[OOP 2008] Gödel läßt grüßen<p>In seinem <a href="http://ralfw.blogspot.com/2007/12/oop-2008-innovation-braucht.html">Blog</a>-Posting hat Ralf mein letztes Posting zu Innovation aufgegriffen. Zum Thema Wettbewerb und Innovation möchte ich noch ein kleines Argument hinzufügen:  Meine langjährige Erfahrung als Mitarbeiter  in der industriellen F&E zeigt: in Märkten mit geringem Wettbewerb ergeben sich wenige, in Märkten mit größerem Wettbewerb dagegen viele Innovationen.</p> <p>Heute ein weiteres philosophisches Thema, gewissermaßen eine harte Nuß für Nußknacker. Laut Gödel's Unvollständigkeitssatz für Prädikatenlogik höherer Stufen gibt es Wahrheiten, die sich nicht formal beweisen lassen. Douglas Hofstadter hat sich diesem Thema 1989 in seinem weltberühmten Buch "Gödel, Escher, Bach" eingehend gewidmet - im Übrigen ein exzellentes Elaborat, das seltsamerweise fast in Vergessenheit geraten ist.  </p> <p>Was aber folgt aus diesem Satz für Informatiker. Ich versuche einmal, ein wenig die daraus resultierenden Implikationen zu beleuchten. Zum einen natürlich, dass formales Beweisen seine Grenzen besitzt. Demnach lassen sich Softwaresysteme nicht in ihrer Vollständigkeit auf qualitative Eigenschaften überprüfen. Das gilt natürlich auch für potenzielle Fehler, Sicherheitslücken oder Nebenläufigkeitseigenschaften. Zum anderen bedeutet es, dass emergentes Verhalten in IT-Systemen durchaus unvorhergesehene Eigenschaften zeitigen kann- späte Hoffnung für KI-Freunde also? Natürlich folgt als eine weitere Konsequenz, dass sich durch schrittweise Programmtransformation auf Basis von "Axiomensystemen" (z.B. Patterns) nicht alle (semantisch) denkbaren Anwendungen erzeugen lassen. Auch modellbasierte Ansätze haben daher Grenzen.  </p> <p>Informatiker hantieren täglich mit Werkzeugen, die in Form von Programmierumgebungen oder Generatoren unterschiedlichster Coleur in Erscheinung treten.  Letztendlich verbergen sich dahinter aber syntaktische Textersetzungssysteme, denen eine (operative) Semantik zugrunde liegt. Leider, oder besser gottseidank, verdecken unzählige Abstraktionsschichten diese Tatsache. Es bleibt das Resüme: Der Allmacht von Werkzeugen und damit ihren Nutzern sind laut Gödel Grenzen gesetzt. </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-79553848481056292952007-12-22T14:52:00.001-08:002007-12-22T14:59:20.084-08:00[OOP 2008] Eine Frage der Innovation<p>Heute eine eher philosophische Frage: Wie entstehen Innovationen im Software Engineering?</p> <p>These: Durch Evolution im Sinne von Thomas Kuhn. Aus Paradigmen resultieren Mutationen, von denen durch Selektion (Wettbewerb) diejenigen überleben, die den veränderten Randbedingungen am besten standhalten.</p> <p>Antithese: Neuerungen resultieren durch Diktatur. Denn nur Monopolisten und Trendsetter haben die Voraussetzungen, um Platz für Innovatives zu schaffen statt sich in ständigem Konkurrenzkampf zu zermürben.</p> <p>Synthese: Es bedarf des Wettbewerbs der Ideen (Evolutionen) um Anzeize für Innovation zu schaffen, aber auch Leitfiguren, um Revolutionen zu bewirken und durchzusetzen. Allerdings sollte das Pendel weder zum einen noch zum anderen Extrem schwingen. </p> <p>Lemma 1 ist natürlich dass sich nicht immer sofort die technologisch besten Lösungen etablieren, sondern die ökonomisch reizvollsten (Shareholder Value).</p> <p>Lemma 2 besteht darin, dass sich dennoch auf Dauer die technologisch besseren Lösungen etablieren und bewähren müssen.</p> <p>Contradictio: Dummerweise haben wir es an dieser Stelle nicht nur mit einer singulären Technologie zu tun, sondern mit einer ganzen Reihe von komplementären Technologien. Wie die Natur und speziell die Entwicklung des Homo Informaticus zeigt, funktionieren "Best-of-Breed" Ansätze aber nicht. Ein perfektes Zusammenspiel mittelmäßiger Komponenten ist also einem mittelmäßigem Zusammenspiel exzellenter Einzelteile in der Regel überlegen. Stichwort: Swarm Intelligence.</p> <p>Die heutige Informatik hat leider zu überbordender Entropie geführt. Der Softwareengineer verliert sich daher heute in einem Netz unzähliger Technologien (SOA, BI, OO, Java, .NET, UML, DSL, AOSD... ). Jede für sich durchaus ausgereift, aber in der Summe nicht mehr vernünftig nutzbar und beherrschbar.</p> <p>Es ist an der Zeit, inne zu halten. Es ist Zeit für einen holistischen Ansatz, der die Einzeltechnologien vernünftig integriert.  Es ist Zeit abseits von Konferenzen, Wettbewerb und dem dort gehuldigten Expertentum einen Schritt zurückzutreten, um zu reflektieren und zusammen wachsen zu lassen was zusammen gehört.  Auch bloße Integration kann Innovation bedeuten, ganz im Sinne der kollektiven Intelligenz.  Das bedeutet aber auch, dass eine Gruppe von Team-Playern einem Team aus Individualisten überlegen ist.  Für erfolgreiches Softwareengineering bedarf es daher beide Arten der Integration, die auf technologischer Ebene aber auch die soziale.</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-16492393988155869582007-12-16T09:30:00.001-08:002007-12-16T09:30:44.628-08:00[OOP 2008] Bubbles don't crash<p>Auf manchen Powerpoint-Folien erscheint SOA als allmächtiges Wunderwerkzeug für Jedi-Ritter. Zu enge Kopplung? Da hilft nur SOA! Integrationsprobleme in heterogenen Umgebungen? Natürlich nur mit SOA zu beseitigen. Das erinnert mich doch bedenklich an Alchimistenträume. Bisweilen ziehen dann die selbsternannten SOA-Experten und andere Abenteurer durch die Management-Etagen und verkünden ihre Heilsbotschaft. Nur gelegentlich kommen kritische Stimmen an die Oberfläche und berichten über Fallstricke und Probleme - wobei mir da gerade in den Sinn kommt, dass "Probleme" heutzutage  "Herausforderungen" heissen. Es ist ja so simpel: man nehme den bisherigen Entwicklungsprozess, die bisherige Organisation, adaptiere lediglich Applikationsstellen durch Service-Schnittstellen, und lasse einen SOA-Sturm durch alle Abteilungen fegen - "resistance is futile".  Schon ist alles angerichtet! Dummerweise lecken bereits so manche Organisationen gegenwärtig ihre Wunden, nachdem sie allzu leichtfertig auf die SOA-Karte gesetzt haben. Es ist wie immer im Leben: keine Technologie kann uns das Nachdenken abnehmen, aber bei jeder neuen Technologie ignorieren wir diese Tatsache von neuem. Was Grady Booch dereinst zum Thema Werkzeuge geäußert hat ("a fool with a tool is still a fool") hat nach wie vor Gültigkeit und dürfte sich als Naturgesetz qualifizieren. Da fällt mir auch der gute alte Witz ein: Treffen sich mehrere Wissenschaftler und diskutieren ob Gott ein Biologe, Physiker oder SAO-Experte ist. Da meint der Biologe, es sei ja wohl offensichtlich, dass Gott Biologe sei, denn immerhin habe er den Menschen als Krone der Schöpfung erschaffen. Daraufhin entgegnet der Physiker, dass das ja alles sein möge, aber am Anfang hätte Gott doch aus dem Chaos die Natur kreiert. Worauf der SOA-Experte nur süffisant lächelt und sagt "Und woher, glaubt ihr, stammt das Chaos?". Zum Entwickeln umd Umsetzen einer erfolgreichen SOA-Strategie bedarf es mehr als nur Powerpoint-Folien und warmer Worte. Fallstricke lauern in den verschiedensten Bereichen, seien es organisatorische, prozessbedingte, technische, architektonische, oder herstellerspezifische. Dem Chaos lässt sich nur mit einem systematischen Vorgehen begegnen. Und wie von mir bereits des öfteren in den Raum gestellt: SOA = Product Line Engineering.   Mit anderen Worten: SOAP und Co mögen jedes für sich einfach sein, aber das lässt sich nicht auf das SOA-Paradigma als holistischer Ansatz übertragen, dessen Implikationen bis in die IT-Strategie von Unternehmen reicht. In meinem SOA/Microsofttechnologien-Tutorial auf der OOP werde ich daher nicht nur die netten neuen Spielzeuge vorstellen, sondern auch ein paar Pitfalls und Guidelines adressieren. Wie gesagt: bubbles don't crash!</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-57884834082613861752007-11-26T11:19:00.001-08:002007-11-26T11:27:34.235-08:00[OOP 2008] SOA-Transformer<p>In einem sehr gelungenen Posting zu <a href="http://http://ralfw.blogspot.com/2007/11/oop-2008-transformers-to-rescue.html">SOA</a> hat Ralf Westphal auf mein Posting zu SOA-Leichtgläubigkeit Bezug genommen.</p> <p>Der Punkt Flexibilität ist tatsächlich einer der problematischen Aspekte bei der Softwareentwicklung. Gerade das Erreichen einer guten Balance erweist sich als äußerst diffizil. Etwa bei real existierenden Architekturen, die allenfalls von Strategy-Patterns zusammen gehalten werden. Ein Strategy-Pattern gleicht aber der Aussage, dass sich der Architekt an der Anwendungsstelle noch nicht festlegen konnte oder wollte. Eine Häufung des Strategy-Patterns heißt demzufolge, dass er sich an vielen Stellen nicht festlegen wollte oder konnte. Weiss dieser Architekt denn überhaupt was er entwerfen möchte? Oder anders ausgedrückt: Würden sie ihm Ihre Kreditkarte anvertrauen? Ein anderer typischer Fall ist das Mediator-Pattern. Göttergleich thront der Mediator im Zentrum des Softwareuniversums. Keiner kommt an ihm vorbei, denn es kann schließlich nur einen geben. Man denke an die vielen Hub-and-Spoke Ansätze, die bei vielen Unternehmen als lebendige Leichen im Keller lauern. </p> <p>Flexibilität muss geplant aber auch kontrolliert und gezielt beschränkt werden. Das Open/Close-Principle leistet hier gute Dienste. Flexible Architekturen, die sich nur an wenigen Stellen offen und damit verwundbar zeigen, zählen heute noch als seltene Spezies. Positive Ausnahmen: Eclipse und das Plug-In-Konzept, WCF und die konfigurierbaren Channels.</p> <p>Da gerade SOA dem Produktliniengedanken sehr eng folgt, sind entsprechende Mechanismen um mit Variabilität systematisch umzugehen zum einen Feature Modeling und zum anderen Commonality/Variability-Analyse. Auf der Architekturebene erleichtern Patterns das systematische Behandeln der Variabilität. Und nicht zuletzt existieren Mechamismen auf der Plattformebene, wie z.B. Workflows, Rules Engines,  Plattforminterzeptoren. </p> <p>Die Wahl der Mechanismen und Architekturkonzepte sollte aber mit Bedacht erfolgen. Nicht selten  experimentieren Softwareentwickler gerne mit den verschiedensten Ansätzen, die sich dann in den fertigen Systemen wieder finden.</p> <p>Insofern gleicht SOA tatsächlich eher den cineastischen Transformern als ihren organischen Pendants, den Formwandlern. Soll die Architektur in Form bleiben und nicht alsbald unter Alterserscheinungen kollabieren, ist ihre vorausschauende Trans-Form-ationsfähigkeit essenziell. Minority Report läßt grüßen. </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-1357111695278890452007-11-18T01:28:00.001-08:002007-11-18T01:28:00.140-08:00[OOP 2008] Moderne Zeiten<p>Kann sich noch jemand an die gute alte Zeit des Schwarz-Weiss-Fernsehens erinnern?  Damals, als die ersten Farbfernseher zu saftigen Preisen die Läden erreichten und mit neidischen Blicken betrachtet wurden? Da gab es eine Werbeanzeige in diversen Zeitschriften, die für lau eine Farbfolie offerierte, um aus dem heimischen Schwarz-Weiss-Fernseher einen Farbfernseher zu machen. Das funktionierte tatsächlich, wenn freilich die Farbzuordnung rein zufällig war und bisweilen zu grünen Gesichtern oder braunem Himmel führte.   Waren schon leichtgläubige Zeitgenossen!</p> <p>Wenn ich freilich die jetzige Zeit betrachte, welcher Unterschied zu damals! Da gibt es doch glatt die neue, unwiderstehliche Welt von SOA, SaaS und ESBs. Nur leider sind die alten Anwendungen dazu noch nicht kompatibel. Voller Neid blicken Techniker und Manager daher auf das Land der unbegrenzten SOA-Möglichkeiten. Ist doch alles einfach! Man nehme eine beliebige  Anwendung und füge Web-Service-Schnittstellen hinzu. Schon ist alles angerichtet - wortwörtlich!</p> <p>Die Zeiten ändern sich offensichtlich, nicht aber die menschliche Neigung, an Wunder zu glauben. Leider ist die Modernisierung von existierenden Landschaften alles andere als trivial. Es gilt, Anwendungen neu aufzubrechen und zu strukturieren, um sie an den richtigen Stellen zu integrieren. Und Integration heisst eben nicht nur Kommunikation, sondern Datenintegration, Geschäftsprozesse, Organisations- und Prozeßänderungen. Stichwort: Dominoeffekt durch inhärente Komplexität.</p> <p>Das impliziert natürlich, dass ein systematisches Vorgehen essenziell ist, ebenso technisches Knowhow und Architekturkompetenz. Insgesamt sind die Anforderungen also entsprechend hoch. Kein Wunder, dass viele Modernisierungsprojekte kläglich scheitern.  </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-775126552155300762007-11-15T11:37:00.000-08:002007-11-15T12:36:14.187-08:00[OOP 2008] Die Zukunft von OO ist FunktionalSprachen wie Ruby oder C# haben sich bereits in die Richtung bewegt, Neuentwicklungen wie Scala das Ziel bereits erreicht. Die Zukunft objektorientierter Sprachen heisst .... Lisp. Kompletter Unsinn? Dann lassen Sie mich ins Detail gehen. Schon lange (über 60 Jahre) existieren zwei grundlegende Paradigmen der Programmierung. Auf der einen Seite das funktionale Lambda-Kalkül und auf der anderen die prozedurale Turing-Maschine. Beide sind in der Lage, alle denkbaren und berechenbaren Funktionalitäten zu beschreiben und verarbeiten. Während die Turing-Maschine hierfür einen unendlichen Variablenspeicher nutzt, basiert das Lambda-Kalkül ganz symbolzentriert auf Funktionskompositionen und Funktionsaufruf. Nun sind die OO-Sprachen einmal, lax ausgedrückt, nichts anderes als Turing-artige Maschinen höherer Abstraktion. Funktionale Sprachen wie Lisp, ML oder Haskell hingegen beruhen im wesentlichen auf dem Lambda-Kalkül. Vorteil der funktionalen Programmierung ist zum Beispiel dessen symbolorientierter Ansatz und dessen Gleichbehandlung von Daten und Funktionen. Nachteil beispielsweise die geringere Performanz - und bisweilen das ungewohnte Programmierparadigma. In neu entwickelten Sprachen wie Scala (das im übrigen auf Java VMs läuft) lassen sich nun beide Ansätze, OO und funktionale Programmierung, miteinander kombinieren. C# 3.0 hat bewiesen, dass auch "traditionelle" OO-Sprachen sich sinnvoll um funktionale Ansätze wie Lambda-Ausdrücke ergänzen lassen. Dass dies viele Vorteile in sich birgt, beweisen die Brüder im Geiste Ruby, Scala, C# 3.0 oder Smalltalk. Natürlich werden Programmierer jetzt nicht auf Common Lisp oder Scheme umschwenken. Wohl aber dürften sie in Zukunft mit den aus diesen "Ursprachen" kommenden Konzepten konfrontiert werden. Ruby und C# 3.0 sind nur der bescheidene Anfang. Insofern kann eine Beschäftigung mit "good old Lisp" nicht schaden. Ganz nach dem Motto: Das Lamda-Kalkül ruft. Folgen wir ihm!Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com1tag:blogger.com,1999:blog-8007734318566284314.post-72690196922576342182007-11-11T03:19:00.001-08:002007-11-11T03:19:33.378-08:00[OOP 2008] Architektur mit Schleife :-)<p>Gernot berichtet in seinem Blog-Posting über eine realistische Vorgehensweise bei der Architekturerstellung. Dem Ansatz kann ich aufgrund meiner täglichen Praxis nur zustimmen. Wobei das Bild den Eindruck erweckt, als würde man/frau zunächst eine komplette Architekturvision erstellen und dann erst in der nächsten Iteration aufgrund von Feedback die Architektur überarbeiten. </p> <p>Nach meiner Ansicht funktioniert Architektur iterativ in zwei Stufen. Ausgehend von den "Requirements" und deren Klärung erfolgt zunächst inkrementell die Erstellung einer Architekturvision respektive Grobarchitektur. Jedes Inkrement umfasst zum einen Verfeinerung und zum anderen architektonisches Refactoring. Die Inkremente fangen mit den höchst prioren Anforderungen an und betten die fachliche Logik in die für nicht-funktionale Eigenschaften benötigte Infrastruktur ein. Das erfolgt schrittweise, Requirement für Requirement, bis eine Grobarchitektur bereitsteht, die einfach genug ist, um sie zu kommunizieren, aber auch stabil genug, um in die nächste Phase einzutreten, nämlich zur inkrementellen Erstellung der Feinarchitektur.    </p> <p>Wichtige Richtlinien dabei sind z.B.:</p> <ul> <li>Learning from Failure</li> <li>Strategisches Design vor fachlichem Design</li> </ul> <p>Die beiden Phasen der Architekturerstellung verfallen also nicht der Versuchung des "Big-Bang"-Ansatzes.</p> <p>Wichtig ist aber genauso die Vorgabe von Leitlinien am Anfang. Nicht umsonst definieren Booch, Jacobsen, Rumbaugh, dass Architektur die Definition der Subsysteme und ihrer Zusammenarbeit umfasse, aber aauh die dabei zugrunde gelegten Design-Richtlinien (guiding principles). </p> <p>Schwieriger gestaltet sich allerdings die Architekturerstellung beim Product Line Engineering, bei dem im Domain Engineering die Plattformdefinition erfolgt, und erst im Application Engineering die Produkterstellung. Hier werden auf einmal ehemals taktische Aspekte wie Variabilität zu strategischen Aspekten, die gründlicher Maßnahmen bedürfen. Etwa Scoping, C/V-Analyse, Domain Driven Design und Feature Modelling.</p> <p>Ich bin gespannt wie Gernot das Thema Product Line Engineering sieht. </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-6699360715132264572007-11-10T05:21:00.001-08:002007-11-10T05:41:56.414-08:00[OOP 2008] SOA ist nicht (nur) Technologie<p>Ralf hat auf meine Gedanken zu SOA mit einigen guten Gedanken geantwortet und empfiehlt Systemtheorie und systemisches Denken. Er gibt zu bedenken, dass SOA nicht nur Denken im Großen bedeuten kann. Nachdenken hat natürlich noch nie geschadet, auch nicht beim Programmieren :-) Mein Beobachtungen suggerieren, dass die Probleme auch woanders liegen, weil zum Beispiel SOA oft nur als weitere Middleware begriffen wird, nicht als Paradigma. Ist SOA eine schlichte Evolution von OO? Reicht es, existierende Applikationen durch Service-Wrapper zu SOA-enablen? </p> <p>Aus meiner Sicht ist SOA eine Vielzahl von Dingen:</p> <ul> <li>Es ist keine Technologie, sondern ein Architekturparadigma.</li> <li>SOA ist nicht gleich WS-*.</li> <li>SOA erfordert Änderungen in Organisationen und Prozessen. Stichwort: Governance. Im Prinzip sind SOA-Entwicklungen Produktlinien.</li> <li>SOA ist keine Middleware, die bisherige OO Middleware ersetzt. Es ist eine Fortentwicklung von Message-Oriented Middleware.</li> <li>SOA ist eine Integrationstechnologie.</li> </ul> <p>SOA lässt sich daher auch im Kleinen nutzen, betrachtet man es als Paradigma.</p> <p>Sobald ESBs, SOA Frameworks und WS-* in den Mittelpunkt rücken, ist es ein Ansatz für grosse Systeme. Allein schon deshalb, weil die Komplexität von ESB-Lösungen und SOA Frameworks den Rahmen von Kleinprojekten sprengt.</p> <p>Zur Umsetzung des SOA-Gedankens ist ein holistischer Ansatz gebracht, der auf folgenden Säulen beruht:</p> <ul> <li>Standardisierung: Es solte möglichst auf Standards gesetzt werden, nicht auf Eigengewächse. Es sei denn, ein proprietärer Ansatz wird angestrebt.</li> <li>Markt und Hersteller: Zu beachten ist der volatile SOA-Markt, der ständigen Änderungen unterworfen ist. Welche Standards unterstützen die Hersteller. Welche Produkte sind reif und welche noch nicht?</li> <li>Architektur und Domäne: Welche Anforderungen ergeben sich hinsichtlich der Domäne? Welche Technologien mappen am besten auf diese Anforderungen. In einem top-down Ansatz müssen grobgranulare Dienste aus den Geschäftsanforderungen abgeleitet werden. Feingranulare Dienste sollten nicht direkt für Clients zugreifbar sein. Service-Aufrufketten sind zu vermeiden, Versionierungsaspekte und verschiedene Service-Versionen zu berücksichtigen. Best Practice Ansätze (Patterns) bieten grosse Hilfe. Für die Integration von Legacy Software ist ein geplantes Vorgehen notwendig. </li> <li>Prozeß und Organisation: Die Organisation ist dem SOA-Paradigma entsprechend zu ändern, etwa Einteilung in Anwendungs- und Serviceentwicklung. Governance-Aspekte müssen durch eigene Teams abgedeckt werden, speziell bei SOA im Grossen. SOA fängt oben an bei den Anforderungen. Ein bottom-up-Ansatz ist lediglich für Integrationsaspekte zulässig. Jegliche Art von Big-Bang-Ansatz ist kontraproduktiv. Eine schrittweise Transition ist hingegen empfehlenswert.</li> <li>Technologie: Herstelleraussagen hinsichtlich SLAs und NFRs sind gründlich zu verifizieren, etwa durch Prototyping. SOA darf nicht als Middleware betrachtet werden. Den Fehler, in Point-to-Point Kommunikation zu verfallen, sollte man vermeiden, schon wegen der höheren Komplexität.</li> </ul> <p>Das sind natürlich nur einige Punkte. Wir sehen, ein systemisches Vorgehen ist durchaus vorteilhaft. Dabei ist aber nicht nur die IT-Abteilung involviert sondern alle Stakeholder. SOA ist nicht einfach sondern sehr komplex, weil es schon heute Ansätze des Ultra Large Scale Computing vorweg nimmt, sich aber auch im Kleinen umsetzen läßt. Gerade diese Mischung sorgt für Sprengkraft.</p> <p>Wer also sein Projekt unter Garantie gegen die Wand fahren will, greife jetzt zu einem SOA Toolkit nach Wahl und fange einfach an, darauf loszuprogrammieren. </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-42505071587521053902007-11-03T03:13:00.001-07:002007-11-03T03:29:43.701-07:00[OOP 2008] Das GaGa Prinzip<p>Garbage-in-Garbage-out lautet eine der universellen Prinzipien der Softwareentwickung. Auf Basis schlechter Anforderungen lassen sich nun mal keine anforderungsgerechten Qualitätssysteme erstellen. Ein Compiler, dem der Entwickler ein unstrukturiertes, fehlerhaftes Softwaresystem übergibt, kann daraus nur selten ein strukturiertes, fehlerfreies System  konstruieren. Aus einer unvollständigen UML-Beschreibung, lassen sich schwerlich gute Softwareartifakte ableiten. Und hier haben wir genau das Problem der modellbasierten Softwareentwicklung. Neulich auf der ooPSLA 2007 gab es ein hochrangig besetztes Panel zum Thema OO-Sprachen nach Simula 67. Eine der Befürchtungen der Programmiersprachen-Koryphäen besteht darin, dass unbedarfte Softwareingenieure die Schaffung domänenspezifischer Sprachen als ihr Steckenpferd entdecken könnten. In diesem Fall bekämen wir ein echtes Problem. Sprachentwicklung ist beileibe nicht simpel, speziell wenn es sich um DSLs für einigermaßen nicht-triviale Domänen handelt. Insofern bleibt zu hoffen, dass mächtige MDSD-Waffen und Analyse-Methoden nicht in die falschen Hände geraten.   Wie gesagt: Garbage-in-Garbage-out!</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-2772929199889582412007-11-02T13:14:00.001-07:002007-11-03T02:54:03.355-07:00[OOP 2008] Agile Architekturen<p>Eines der Kernaufgaben bei Softwareprojekten stellt die Erstellung der Architektur dar. Wie sich diese Aufgabe in den Entwicklungsprozeß einbettet, darin scheiden sich die Geister. Manche agile Methoden (z.B. xP)  schlagen eine Art "Design and Ownership by Committee" vor. Jeder Projektbeteiligte partizipiert an der Architekturerstellung. Im anderen Extrem ist eine Gruppe weniger dedizierter Architekten für diese Aufgabe zuständig. Laut Frederick P. Brooks (Keynote auf der ooPSLA 2007) zeichnen sich gerade die etwas "schlechteren" Softwaresysteme dadurch aus, dass sie von vielen Köchen erstellt wurden, während die richtig guten Softwaresysteme die Handschrift eines oder weniger Architekten tragen. Wie also verhält sich Agilität zu Architektur? Meiner Meinung nach lässt sich in einem agilen Prozeß beides kombinieren. Zunächst erfolgt die Bereitstellung einer architektonischen Vision durch einen oder wenige Architekten. Danach deren Verfeinerung durch einen inkrementellen Prozeß, der Top-Down Elemente (Verfeinerung) mit Bottom-Up Gardening (Refactoring) koppelt. Dass es in einem extreme Programming Prozeß gute Architekturen gibt, wenn nicht alle Beteiligten entsprechende Erfahrung mitbringen, bezweifle ich. Wie lautet also die Lösung für Agilität + Architekturen = ?</p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-79777178720493867142007-10-29T11:21:00.001-07:002007-10-29T11:22:41.058-07:00[OOP 2008] En vogue mit SOA<p>Mittlerweile dreht sich ein allzu grosser Teil der Informatikwelt um das Thema SOA.  Das Kochrezept in mancher Fachzeitschrift klingt geradezu verführerisch: man nehme eine Prise SOAP, dazu noch etwas WSDL, füge unter ständigem Rühren BPEL hinzu und würze das Ganze mit einigen weiteren WS-Standards, ganz nach dem persönlichem Gusto. Schon ist alles angerichtet - das ganze Unglück zumindest. Und führende Chefköche empfehlen als Dessert ESB, WEB 2.0, BPMN, BAM und BPM. Da natürlich alle am Kuchen teilhaben wollen, findet sich in dieser modernen  Cuisine ein bunter Eintopf aus Paradiesvögeln, vom Enterprise-Architekten bis zum C++-Experten. Selbstredend singen Marktanalysten mit Entzücken die "Ode an der SOA-Freude" - Orakel liessen sich schließlich schon immer gut honorieren.  Es könnte doch alles so schön sein. Leider schaut die Realität etwas anders aus als Technologieprovider uns glauben machen wollen. In der Praxis bekommen doch auffallend viele SOA-Projekte Probleme, teils wegen der unrealistischen und oft überzogenen Erwartungen, teils aber auch wegen der Komplexität, Technologieunreife oder fehlender Systematik. DAs erinnert mich auffallend an die Anfangszeit von CORBA, dem damals ähnlicher Kultstatus bescheinigt wurde. Und es gibt noch viele weitere auffallende Parallelen, speziell was das Thema Standardisierung betrifft. Wenn der leuchtende SOA-Stern weiterhin derart überfrachtet werden wollte, dürfte er bald implodieren und alles mit sich reissen.   Bin ich ein Advocatus Diaboli oder etwa ein Schwarzmaler? Angeblich soll es irgendwo in dieser Galaxie schon erfolgreiche SOA-Projekte geben. Bühne frei für die Gladiatoren und Missionare, die SOA auf ihre Fahnen geschrieben haben und mich nun eines Besseren belehren!   </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-56274723666712584582007-10-29T11:01:00.001-07:002007-10-29T11:02:19.491-07:00[OOP 2008] Countdown<p>Für die kommende OOP 2008 haben wir wieder mittels Terraforming einen Blog-Planeten geschaffen. Auf dessen Orbit kreisen mehrere Monde. Darunter so veritable wie</p> <li>SOA </li> <li>Software Architektur </li> <li>Agile Entwicklungsprozesse </li> <li>Modernisierung bestehender Systeme </li> <li>Analysis & Design (inkl. Model-driven-Development) </li> <li>Ruby on Rails</li> <p> </p> <p>Zu jedem dieser OOP-Satelliten erwarten Sie spannende Blog-Casts und hoffentlich kontroverse, aber unterhaltsame Diskussionen.</p> <p>Dadurch erhalten OOP-Besucher und solche, die es werden wollen, einen Vorgeschmack auf die Ingredienzen der kommenden OOP. Dazu noch von so prominenten Chefköchen (beziehungsweise Trackchairs). </p> <p>Für Kommentare und Feedback bitte ich um Öffnen eines Nachrichtenkanals zu <a href="mailto:michael.stal@sigs-datacom.de">michael.stal@sigs-datacom.de</a></p> <p> </p> <p>Bon Voyage! </p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0tag:blogger.com,1999:blog-8007734318566284314.post-62873416668332155742007-10-14T13:19:00.001-07:002007-10-14T13:19:26.485-07:00OOP Conference 2008<p>Ich werde diesen Blog nutzen, um den Planeten OOP ein wenig anzutreiben. Sobald die Trackchairs bereit sind, geht es los</p> <p><a href="http://lh3.google.com/michael.stal/RxJ5yMesJZI/AAAAAAAAAB0/LuYCAegGtYk/micha_foto%5B4%5D.jpg"><img id="id" style="border-top-width: 0px; border-left-width: 0px; border-bottom-width: 0px; border-right-width: 0px" height="108" alt="micha_foto" src="http://lh3.google.com/michael.stal/RxJ5zMesJaI/AAAAAAAAAB8/jAjd5Ebc7zs/micha_foto_thumb%5B2%5D.jpg" width="86" border="0" /></a></p> Michaelhttp://www.blogger.com/profile/11984599832785431031noreply@blogger.com0