Mein persönlicher Hintergrund

Ich bin der tiefen Überzeugung, dass einerseits Anforderungsmanagement und andererseits eine gut durchdachte Architektur die Schlüsselfaktoren für eine erfolgreiche Softwareentwicklung sind.

Im Jahre 2015 wurde bei meir ein Gehirnanorisma entdeckt, und ich wusste dass Ich sehr stark Schlaganfall gefährdet war. Die Ärzte der Uniklinik von Grosshadern rieten mir aufgrund der Gefärlichkeit von einer Operation ab, und warnten mich, dass selbst bei einer erfolgreichen Operation mir die Arbeitsunfähigkeit droht.

Dies bestärkte mich, meine Projekte immer so zu gestalten, dass Ich jederzeit ersetzbar bin. Ich war immer auf der Suche nach der einfachsten und verständlichsten Lösung.

Im Herbst 2018, kam es dann zu dem befürchteten Schlaganfall.Die Operation, von der mir die Ärzte abgeraten hatten, musste in einer Notoperation erfolgen. Während die Mitpatienten in der Reha ihren Unfall oder Krankheit als Schicksalschlag empfanden, überwog bei mir die Dankbarkeit, es überstanden zu haben. Ich hatte meinen Schlaganfall als eine Befreiung empfunden, und damit die Therapeuthen und Betreuer überrascht. Dankbar sind nicht die Glücklichen, sondern glücklich sind die Dankbaren. Der Spruch entstand ursprünglich von Francis Bacon (1561 - 1621), und trifft inzwischen voll auf mich zu.

Ich bin zu einem für den Kunden extrem ungünstigen Zeitpunkt ausgeschieden. Gleichzeitig hat sich mein Partner, mit dem Ich mich beraten hatte, einer anderen Aufgabe gewidmet.Es musste ein Mitarbeiter reaktiviert werden, der ein paar Jahre zuvor kurz in das Projekt eingebunden war.

Ohne die Leistung meines Nachfolgers schmälern zu wollen, so war es auch die eine saubere Architektur, die es ermöglichte dass dieses Projekt trotz Ausfall beider technologisch Verantwortlicher ohne Verzögerung ablief

Mein Berufsethos

Ich sehe mich als eine Art Arzt für Geschäftsprozesse. So wie das Ziel jedes Arztes sein sollte, dass der Pateient möglichst gesund, und nicht im Sarg, das Krankenhaus verlässt - sollte ein Informatiker alles tun, damit der Kunde sich nun allein um die Fachlichkeit kümmern kann.

Die Anforderungen müssen vom Kunden kommen. Häufig glauben Informatiker besser als der Kunde die Fachlichkeit zu verstehen. Eine gute Softwarearchitektur trennt aber technische von fachlicher Infrastruktur. D.h. der Erfolg eines Informatikers ist es falls der Kunde sich um das alleine kümmern kann, was er am besten beherrscht - und dies ist die Konzentration auf die Fachlichkeit.

Wer Software schreibt, ist der primäre Stakeholder für diese Software. Es ist seine Aufgabe vom Management die Ressourcen einzufordern, die notwendig sind - um die Software in einem sauberen Zustand zu halten.

Als Softwareentwickler ist das Studium von Entwurfs- und Architekturmuster wichtig. Muster sind typische Lösungen, für Probleme, die immer wieder auftauchen.Die Orientierung an solche Muster, hilft schnell vernünftige Lösungen zu finden - umd typische Fehler direkt zu vermeiden.

Viele Informatiker streben nach der möglichst modernsten und neuesten Technologie. Firmen versuchen Kunden in die technologische Abhängigkeit zu treiben.

Mir persönlich hat wahrscheinlich der Chef Neurologe des Elisabethnklinikum in Ravensburg indirekt das Leben gerettet, weil er zugab die notwendige Operation sich nicht zutraut. Für mich ist dieser Arzt ein Vorbild in Kommunikation, denn er hat meine persönliche Gesundheit vor den kommerziellen Interessen des Krankenhauses gesetzt

Ich sehe Konflikte als etwas Positives an. Nur an Konflikten wächst man. Wichtig ist dass diese Konflikte mit Empahie und gegenseitiger Wertschätzung zu verbinden. Notwendig ist dazu eine gute gelebte Fehlerkultur.Jeder der arbeitet macht Fehler. Diese sind notwendig um sich zu perfektionieren

Meine Erfahrung zeigt mir dass Unternehmen aufgrund von Ja-Sagern scheitern.Auch das obere und mittlere Management braucht Feedback. Auch das obere Management hat das Recht schlechte Nachrichten zu erfahren. Verantwortungsvolle Eltern geben Ihren Kindern auch nicht immer Gummibärchen, damit diese zufrieden sind. Jetzt ist das obere Managemen natürlich keine Kinder, aber selten sind diese Fachexperten, und häufig fehlt es an Menschen, die dem Chef sagen, dass seine Wünsche nicht oder nur sehr schwer realisierbar sind. Verantwortung ist etwas, was man nicht nach oben delegieren kann. Als verantwortungsvoller Mitarbeiter, hat man auch die Fürsorgepflicht gegenüber dem Unternehmen, in dem man arbeitet.

Ich habe schon einige Unternehmen hin zur Insolvenz oder am Rande der Insolvenz begleitet. Fast immer sah ich das Muster, dass das obere Management ihre Entscheidungen traf, die auf Daten basierten, die das mittlere Management in ihrem Sinne aufbereitet hatten. Das Problem tritt häufig auf, sobald die Daten die das mittlere Management liefert, zu deren Bewertung und Karriereförderung verwendet wird.

Aufbau der Seiten

Problem der Testfragen

Von vorherigen Zertifizierung hatte Ich die Erfahrung gemacht, dass die beste Vorbereitung ist, durch Mock Engines bestehende Prüfungen zu simulieren. Da es schwieriger ist deutsche Testfragen zu finden, sollte man sich überlegen, die Prüfung direkt in Englisch zu machen

WWirklich viele Testfragen habe Ich leider nicht, und damit habe Ich leider eine grosse Unsicherheit, mich selbst einschäzen zu können, ob Ich auch gut vorbereitet bin.

Die einzige kommerzielle Lösung habe Ich unter it-pruefungen.de gefunden. Aber 43 Testfragen sind eigentlich viel zu wenig. Es gibt zusätzlich im Downloadbereich der isaqb Homepage ein paar Beispiele, allerdings für die vorherige Version. Ausserdem gibt es einige Lernkontrollfragen im schon vorgestellen Lehrbuch Basiswissen für Softwarearchitekten

Der Mangel an Testfragen, erschwert es zu entscheiden in welcher Tiefe man lernen muss um die Zertifizierung zu bestehen. Aber wie fast immer im Leben, ist der Weg das eigentliche Ziel. Ob man das Zertifikat besteht oder nicht besteht ist in meinen Augen zweitrangig. Entscheidend ist das Wissen darüber, und ob man es im Alltag anwenden kann. Die Zertifizierung selbst gibt den Weg vor, den man gehen sollte. Und genau aus diesem Grund halte Ich Zertifizierungen für sinnvoll. Die Zertifizierung selbst ist nur eine Urkunde, mit relativ geringer Aussagekraft.Es ist besser den Weg zu gehen und nicht zu bestehen, als mit extrem geringen Aufwand oder Bulimie Lernen die Zertifizierung zu bestehen

Verwendete Literatur

Das wichtigste Buch ist das Buch Basiswissen für Softwarearchitekten. Es ist die optimale Grundlage zur Vorbereitung auf die Zertifikation.

Ich selbst empfinde aber das Buch Effektive Softwarearchitekturen von Gernot Starke als besserer Einstieg in die Thematik. Da habe Ich noch die achte Auflage, die noch auf den alten Lehrplan aufbaut gelesen. Ein weiteres Problem ist dass diese Bücher dem aktuellen Lehrplan nachjagen. Die neunte Auflage zu Effektive Softwarearchitekur ist gerade erst erschienen. Aber Ich habe aber mit der achten Auflage gelernt

Ein weiteres Buch aus dem ich kopiert hatte, ist das Buch Software Architektur kompakt

Sinnvoll scheint mir das Buch von Stefan Zörner zu sein, das sich auf die Dokumentation und Kommunikation konzentriert. Softwarearchitekturen kommentieren und dokumentieren 2. Auflage

Kategorisierung der Lernziele