Welche Artefakte muss ein IT-Unternehmensarchitekt erstellen?

Langsam komme ich echt in die Bredouille. Eigentlich will ich doch über Enterprise Architecture schreiben, aber der korrekte deutsche Begriff ist IT-Unternehmensarchitektur. Und da mein Blog nun mal vorerst auf Deutsch ist, bleibe ich wohl beim deutschen Wort. Irgendwie gefällt mir aber Enterprise Architecture auch und der Begriff IT-Unternehmensarchitektur ist auch nicht gerade der kürzeste. Vielleicht hört man ihn deswegen so wenig…

Hier eine Liste der wichtigsten Artefakte, die ein IT-Unternehmensarchitekt erstellen muss. Ich habe eigentlich die Hoffnung, das alles mal auswendig zu können, bis dahin werde ich aber mit dem Blogeintrag vorlieb nehmen. Und für ein bisschen Inspiration ist die Liste niemals schlecht.

Ich werde die einzelnen Artefakte später noch im Detail beschreiben und besonders auch mit einem Beispiel versehen. Oftmals hat man nämlich keine Ahnung, wie man vorgehen will, und wenn man aber ein Beispiel eines vergangenen Projektes hervorholt denkt man sich „Ah ja klar, eigentlich logisch“.

Mir ist bewusst, dass die folgende Liste so nicht viel bringt, aber haben Sie bitte Geduld mit mir. Jetzt weint nämlich gerade mein 5 Monate altes Mädchen und darum muss ich jetzt aufhören zu schreiben.

Die drei wichtigsten Artefakte

Baustein-Diagramm / Bausteindiagramm
Englisch: Application Architecture / „IT architecture components mapped to business capabilities“

Informationsflüsse / Laufzeitsicht
Englisch: Information flow diagram

Verteilungssicht
Englisch: Deployment diagram / „Infrastructure landscape“

Weitere Artefakte

Kontextabgrenzung
Englisch: Environment footprint

Qualitätssicherung Prozesse und Kontrolle
Englisch: Quality Assurance Processes and Controls

Verwendete Tools für das Continuous Delivery und Release Management
Englisch: Continuous Delivery Model and Release Management

Verwendete Tools für die Code Versionsverwaltung
Englisch: Code Management Standard

Verwendete Tools für die Entwicklung und Testing
Englisch: Toolchain used for application development and testing

Datenmanagement Prozesse und Kontrolle
Englisch: Data Management Processes and Controls

Informationssicherheit Prozesse und Kontrolle
Englisch: Information Security Processes and Controls

Security Architektur
Englisch: Security architecture

Technologiestacks
Englisch: „System Level Description of development stack and system components“

Infrastrukturlandschaft
Englisch: Infrastructure landscape / „Deployment architecture of applications and middleware“

Netzwerklandschaft / Netzwerkarchitektur
Englisch: Network Landscape / Network Architecture

Zusätzliche Hinweise

Denken Sie daran, dass zu Beginn eines Projektes alle Artefakte aus einer grossen Höhe gemacht werden müssen (high level). Sprich: Lassen Sie alle Details weg! Fangen Sie klein an. Beim Informationsfluss-Diagramm könnte man zum Beispiel verschiedene Pfeile nehmen für Service Call, Daten duplizieren oder einen manuellen Prozess. Wenn man diese Information aber gar nicht hat, sollte man all die Details einfach weglassen und einen einzigen Pfeil für alle Informationsflüsse verwenden.

Wenn man ein hübsches Diagramm erstellt, etwa für die Bausteine, sollte man diese im Nachfolgenden in einer Tabelle auflisten und kurz beschreiben.

Zu jedem Diagramm braucht man während des Projektes zusätzlich eine Tabelle mit offenen Punkten, die man abklären muss. Beispiel: „Welcher Baustein ist für das Laden der Pinguindaten zuständig?“

Zu jedem Diagramm braucht man während des Projektes zusätzlich eine Tabelle mit Annahmen, die man während der Erstellung des Artefakts trifft. Diese Annahmen können anschliessend bestätigt oder verworfen werden (Confirmed/not confirmed). Beispiel: „Der Zoo liefert jeden Tag eine Datei mit den Namen der Schlangen, die im Zoo leben“.

Werbeanzeigen

Consultant Tagebuch 3 Der Verrat an König Arthur

Wer wissen will, wie das Leben eines Informatik-Consultants, also eines „Beraters“, aussieht, ist hier richtig.

Hier gehts zum Consultant Tagebuch 2: Selbstbeschäftigung
Hier gehts zum ersten Eintrag
Consultant Tagebuch 1

Ich krieche auf allen vieren auf dem Boden, König Arthur steht drohend über mir.

Ich: „Aber mein König… das wollte ich nicht… ich habe nur…“

König Arthur: „Schweigt! Du hast mich hintergangen! Warst du einst mein treuester Gehilfe, musste ich nun mit ansehen, wie du hinter meinem Rücken mit dem Feind angebandelt hast! Und nun kommst du dahergekrochen wie ein dreckiger Wurm! Wegen dir können wir den Sieg im Kampf um das Vaterland vergessen! Verrotten sollst du im tiefsten Kerker! Wachen! Packt diesen reudigen Hund und werft ihn in das tiefste Loch, das wir haben! Hiermit verurteile ich ihn zu dreissig Jahren Haft in Ketten!

Ich: „NEEEEEIIIIIIINNNNNNN!!!!!!!!!!!!“

Licht am Ende des Tunnels

Letzten Donnerstag war ich wirklich wütend. Immer noch wütend wegen diesem doofen Interview, und dann konnte ich keinen Arbeitsplatz im Büro finden, also musste ich mich irgendwo hinquetschen, um wenigstens an meinem Laptop arbeiten zu können.

Wir haben wirklich nur begrenzt Platz in unserem Büro, weil wir ja eigentlich beim Kunden Projekte durchführen müssen. Und theoretisch kann man einen Platz im unserem Büro reservieren – Leider sind alle Plätze bereits auf Wochen von Leuten ausgebucht, die bereits wissen, dass sie im Büro sein müssen. So passierte es, dass König Arthur auf der Klimaanlage des Meeting-Raumes gearbeitet hat, so eine tischhohe kleine Seitenleiste im Raum, wo kalte Luft rauskommt. Und ich durfte es mir auf dem Sofa neben der Kaffeemaschine bequem machen, was nicht so schlimm war bezüglich dem Komfort, aber auf einem Sofa kann man halt zum Beispiel keine Maus richtig bedienen und kann die gewünschte Arbeit nur halb so schnell erledigen.

Und dann habe ich an dem Donnerstag noch eine Mail bekommen, dass mein Projekt Hasenstall, bei dem ich ausgeholfen habe, per heute meine Buchung gestoppt hat. Heisst, ich werde ab Morgen Freitag tatsächlich hundertprozentig ohne Projekt sein. Ach menno! 😡

So wusste ich mir nicht weiter zu helfen als Deryck Whibley anzuschreiben, den wir in Teil 2 des Consulting Tagebuchs schon kennengelernt haben.

„Hallo lieber Deryck. Per heute ist meine Buchung auf dem Projekt zu Ende. Was soll ich nur tun? Gruss, verzweifelter Consultant-Kollege“

Die Anwort von Deryck kam sofort: „Komm doch um 16 Uhr bei mir vorbei, dann gehen wir einen Kaffee trinken“ 😉

Der Zwinkersmiley machte mir ein bisschen Sorgen… und sowieso, was könnte Deryck schon ausrichten?

Ein Kaffe in Nöten

So ging ich mit Deryck Kaffee trinken. Deryck arbeitet schon sehr lange in der Firma. Er meinte, ich hätte mich beim Erstellen der technischen Architektur für Projekt Hasenstall gar nicht mal so doof angestellt. Und er fragte mich, ob ich mir vorstellen könnte, das weiterhin zu tun.

Ich sagte ihm, dass es mir wirklich Spass gemacht hat, und ich überhaupt nicht traurig bin, wenn mein nächstes Projekt kein Java Projekt sei, obwohl ich gerne Java entwickle. Immerhin wurde ich auch als technischer Architekt eingestellt und das Projekt Hasenstall ist momentan recht am anfang, also !!!>>> DIE <<<!!! Gelegenheit, unglaublich viel über Enterprise Architektur beziehungsweise Unternehmensarchitektur zu lernen.

„Na gut“ meinte Deryck. „Ich habe heute Abend ein Meeting mit dem Oberprojektleiter. Ich schau mal, was ich machen kann“.

Am nächsten Morgen kam dann prompt der Oberprojektleiter zu mir mit der Nachricht, dass sie mich gerne weiterhin in Projekt Hasenstall dabeihätten und ich mit dem Rest des Teams am Montag zum Kunden gehen könne!

Ich war natürlich völlig von den Socken!

Natürlich habe ich zugesagt und sehe mich jetzt in der vorteilhaften Situation, am Montag zum Kunden und somit in mein allererstes echtes (bezahltes) Projekt einzusteigen!

Das Leben ist schön!

Der Verrat

Ach was, hör schon auf! Es ist überhaupt kein Verrat! Ich kann über-haupt-nichts dafür!

Kurz nachdem der Oberprojektleiter nämlich mit mir gesprochen hatte, ging er noch mit König Arthur in ein Meetingraum. Und als dieser zurückkam, musste ich ihm die frohe Botschaft von meinem Projekt natürlich gleich übermitteln.

Und was war seine Botschaft? Er war eigentlich ebenfalls für das Projekt Hasenstall geplant, nun haben sie ihn aber rausgenommen! Verdammt!

Also habe ich ihm quasi den Platz geklaut? (Witziges Detail am Rande: König Arthur darf jetzt an das von mir verpatzte Java Interview gehen – Immerhin hat er jetzt eine Ahnung, was der Kunde von ihm wissen will…)

Neeeeee ich glaube, König Arthur nimmt das ganze recht locker, er arbeitet ebenfalls schon lange bei der Firma und das gehört einfach dazu, dass man unglaublich flexibel sein muss. Dass es jederzeit heissen kann „Oh wegen XY bist du nicht mehr auf dem Projekt, bye!“ Er meinte auch, dass man das überhaupt nicht persönlich nehmen muss, genausowenig, wie wenn man etwa ein Java Interview verpatzt. Man ist dadurch nicht weniger wert! Nein, wirklich nicht! (Ich probiere, mich selbst davon zu überzeugen…)

Ich habe König Arthur gesagt, dass es mir leid tut, beziehungsweise dass ich es super schade finde, dass wir nicht zusammen weiterhin diese hübschen Architekturdiagramme zeichnen können. Er war mir ein guter Berater in meinen ersten Tagen in der Firma, aber jetzt muss ich erwachsen werden und meinen eigenen Weg gehen… sniff 😥

Und so verlässt König Arthur mit wehenden Fahnen die Bühne. Eventuell wird er später wieder zu uns stossen, wenn es um die eigentliche Implementation des Projektes geht, aber das wird wohl noch einige Zeit dauern.

Die Firma ist auch flexibel

Und so kann ich mit den heutigen Tagebucheintrag mit einer kleinen Anekdote beenden: Grundsätzlich haben König Arthur und ich jeden Tag um 12 Uhr einen Status-Telefon-Call mit den Oberarchitekten, etwa Deryck. (12 Uhr, weil die Oberarchitekten zu allen anderen Zeiten bereits ausgebucht sind, ausser vielleicht noch Morgens oder Abends um 7) Am Freitag hatte dieser aber überhaupt keine Zeit und hat das Statusmeeting deswegen auf 16:30 Uhr verschoben.

König Arthur und ich haben deshalb nach dem Mittagessen beschlossen, (jeder zu sich) nach Hause zu gehen und dort weiterzuarbeiten. Auch das ist in meiner Firma völlig legitim und niemand wird Dich komisch ansehen, wenn du um 12:30 nach Hause gehst (natürlich solltest Du am Nachmittag kein wichtiges Meeting mehr haben, bei dem Du vor Ort sein musst).

Um 16:30 Uhr hatte Deryck zwar immer noch keine Zeit, ich habe aber einen neuen Mitstreiter kennengelernt, der mich ab nächster Woche unterstützen wird. Ich brauche noch einen passenden Namen für ihn. Wie es scheint, kommt er aus Frankreich, weshalb ich dachte, Monsieur Baguette sei passend. Was meinen Sie?

So sitze ich also hier, schreibe diese Zeilen und bin gespannt, was nächste Woche bei Kunden passieren wird. Spannend!

Hier gehts zum Consultant Tagebuch 4: Eine Woche in der Hölle

Consultant Tagebuch 2: Selbstbeschäftigung

Wer wissen will, wie das Leben eines Informatik-Consultants, also eines „Beraters“, aussieht, ist hier richtig.

Hier gehts zum Consultant Tagebuch 1: das verpatzte Interview

Seit dem verpatzten Java Interview hat sich einiges getan. Ich habe das gesamte Wochenende Java Basics gebüffelt – Quasi back to the roots.

Also nein wirklich, das kann mein Stolz nicht auf sich beruhen lassen, dass ich mich als Java Entwickler betitle, aber nicht weiss, wieviele Collections intern erstellt bei einem Stream erstellt werden, wenn man 5 Verarbeitungsschritte macht (Antwort: Pro Schritt wird eine neue Collection erstellt). Oder warum HashSet’s so enorm viel schneller sind als ArrayLists (Antwort: Weil man bei HashSet zuerst das Objekt mittels Methode hashCode() aus Object hasht und erst dann quasi in er richtigen von unzähligen Schubladen mittels equals() nachschaut, welches Objekt man sucht. Das ist auch der Grund, warum hashCode() und equals() so eng verknüpft sind… Puh!).

Was ich mich aber auch gefragt habe ist folgendes: Was wäre, wenn diese eine Person, der Java Enthusiast, der einige Mensch auf Erden ist, der mir jemals in meinem ganzen Leben diese Java fragen stellen wird? Müsste ich dann jetzt die Antworten auf diese Fragen tatsächlich lernen?

Wie auch immer, jetzt habe ich diese Themen in meinem Gehirn wieder aufgefrischt, fühle mich besser, und könnte im Notfall immer noch ein Selbstversuch starten, ob Frauen im Ausgang heiss werden, wenn man ihnen in langen Erläuterungen den Unterschied zwischen ArrayList und LinkedList erklärt (Spoiler: Ja, sie werden heiss!!!).

Rein ins kalte Nass!

Das alles ist jetzt schon gar nicht mehr wichtig. (Sehr ihr? So schnell wechseln in meinem Leben die Themen, und da soll ich mir all die Dinge noch merken können…)

Momentan helfe ich meinem neu gefundenen Arbeitskollegen an einer Offerte – Nennen wir ihn König Arthur. Dabei geht es um ein ziemlich grosses Projekt, nennen wir es Projekt Hasenstall. Ja, ich weiss, in meinem letzten Tagebucheintrag habe ich geschrieben, dass ich ein Projekt suche. Dabei hatte ich aber immer Projekt Hasenstall als „Backup Projekt„.

Aber vielleicht beginne ich von Anfang an. Als ich bei meiner neuen Firma angefangen habe, war ich zuerst einmal zwei Wochen auf der Ersatzbank, da Projekt Hasenstall noch nicht bereit war für meine unerschöpfliche Weisheit. Dann endlich habe ich von König Arthur die Nachricht erhalten, dass ich ins Büro kommen kann, um am Projekt mitzuhelfen.

Und schon wurde ich mitten ins kalte Wasser geschmissen!

Auf der Ersatzbank hatte ich es gemütlich – Ich war zuhause und habe mir Tutorials über Blockchain reingezogen. Und plötzlich sass ich in einem Meeting nach dem anderen mit unglaublich vielen Leuten die mit sehr vielen Fachausdrücken um sich warfen!

Und dabei hat meine neue Firma eine ganz eigene Meeting-Kultur (dazu mal in einem späteren Tagebucheintrag mehr). Immerhin habe ich gut ausgeschaut in meinem hübschen Anzug, den ich mir für die neue Stelle extra gekauft hatte.

Bei meinem dritten Meeting waren bereits etwa 20 Kollegen dabei von allen möglichen Disziplinen (Strategie-Menschen, Architekten, Projektleiter etc.). König Arthur sass neben mir, und so haben wir zwei Stunden damit verbracht, herauszufinden, was die werten Kollegen so diskutieren. Für König Arthur ist das alles auch noch relativ neu, er ist wie ich ein Java Entwickler, der sich jetzt in der neuen Rolle als Enterprise Architekt wiederfindet.

Wir haben alles versucht, um der Lage Herr zu werden, aber ich sage Ihnen eines, geehrter Leser. Wenn Sie es nicht kennen, können Sie es sich nicht vorstellen, wieviele Fremdwörter in solch kurzer Zeit hören kann!

Erschwerend dazu kommt, dass meistens mehrere der anwesenden Personen gleichzeitig geredet haben. Und die Person neben mir hat ständig zu allem Fragen gestellt. Der Oberarchitekt hat dann auf einem Flip-Chart die Zielarchitektur der gewünschten Software Lösung skizziert und beschriftet, aber leider konnte ich seine Schrift nicht entziffern, was die Sache nicht gerade einfacher machte. So habe ich verzweifelt versucht, die wichtigsten Aussagen in einem Protokoll zu sammeln, während wir gleichzeitig eine Audioaufnahme des Geschehens machten, welche König Arthur nach dem Meeting nochmals durchhört hat.

Natürlich war das gesamte Meeting auf Englisch, und die geschätzten Kollegen, welche Englisch als Muttersprache sprechen, sind dabei besonders schwer zu verstehen, da sie meistens sehr schnell sprechen. Eine echte Herausforderung!

Vielleicht kann ich Ihnen folgendermassen klar machen, wie chaotisch das ganze Meeting war: Bei meiner Anstellung in die Firma hatte ich ein zweistündiges Telefoninterview über Software Architektur mit einem mir damals unbekannten Kollegen namens Deryck Whibley. Vor diesem Riesenmeeting habe ich in der Teilnehmerliste gesehen, dass Deryck auch an dem Meeting teilnehmen wird – also habe ich mich schon gefreut, ihn kennenzulernen. Leider habe ich ihn während des Meetings nicht gesehen (gut wie gesagt, 98% aller Leute kannte ich noch nicht). Deshalb ging ich zum Oberarchitekten und sagte ihm „Schade, dass Deryck nicht gekommen ist, ich hätte ihm gerne die Hand geschüttelt!“

Und was war die Antwort vom Oberarchitekten? „Deryck war die erste Hälfte des Meetings hier! Er sass gleich neben mir!“

Wie sich also herausstellte, sass Deryck, den ich so gerne mal gesehen hätte, nur zwei Meter von mir entfernt und ist dann aber in der Hälfte des Meetings aufgestanden und gegangen (völlig normal in meiner Firma). Zuerst hat es bei mir nicht geklickt, aber plötzlich erinnerte ich mich: Da war so ein Mann, der den anderen ständig Fragen gestellt hat… Das war Deryck!!! Oje… Anhang des Profilbildes im System habe ich ihn mir ganz anders vorgestellt…

So ging es dann die nächsten Tage weiter: Meeting über Meeting mit immer wieder wechselnden Teilnehmern. Was ich aber zugeben muss: Ich habe in diesen wenigen Tagen unglaublich viel gelernt – Zum einen über Unternehmensarchitektur, zum andern auch über das ganze Thema Finanzen. Und während man zu Beginn glaubt, ein Meeting erinnert an einen Stall voller aufgescheuchter Hühner, erkennt man nach einigen Meetings bereits, dass durchaus eine Ordnung dahinter zu finden ist…. (oder auch nicht…?)

Aber eigentlich wollte ich nicht über Meetings schreiben, sondern über Offerten.

Wie funktioniert eine Offerte in einem kleinem Unternehmen?

Die letzten zwei Jahre, die ich in einem kleinen Unternehmen gearbeitet hatte, gab es auch ab und an eine Offerte zu bearbeiten. Das funktioniert jeweils so: Irgendeine Firma, nehmen wir zum Beispiel die Deutsche Bahn, hat irgendeine gute Idee, die sie gerne umsetzen möchte. Sie möchte zum Beispiel durch Gesichtserkennung im Handy den Gemütszustand des Kunden mittels Machine Learning herausfinden. Macht der Kunde einen zufriedenen Eindruck, schlägt die Deutsche Bahn-App eher Züge vor, die wahrscheinlich überfüllt sein werden. Falls der Kunde einen Lätsch 😡 macht, schickt man ihn eher auf einen leeren Zug in den Randzeiten. Und sieht der Kunde hungrig aus, schickt man ihn in den Speisewagen. Dort wäre dann auch König Arthur ständig anzutreffen 🙂

Die Deutsche Bahn sammelt also alle Anforderungen zu dieser neuen Funktion möglichst genau in einem Dokument und veröffentlicht dieses.

Nun können beliebige Firmen die Offerte nehmen, studieren, und dazu einen Lösungsvorschlag abgeben, natürlich mit einem Vorschlag, wie viel Aufwand Lösung braucht und wieviel die Deutsche Bahn dafür zahlen muss. Die Deutsche Bahn sammelt dann alle Vorschläge der Firmen und entscheidet sich anschliessend nicht für heimische deutsche Entwickler sondern für die um einige hundert Euros günstigeren Konkurrenten aus Polen. 😉

Wie auch immer, wichtig bei dieser ganzen Offertensache ist: Der Aufwand für den Lösungsvorschlag wird dabei nicht bezahlt! Erst wenn die Deutsche Bahn sich für eine Firma entscheidet hat, bekommt diese Firma Geld und alle anderen Teilnehmer gehen leer aus.

Hatte in der kleinen Firma also ein Mitarbeiter ein bis zwei Wochen Zeit, bekam er die Möglichkeit, eine möglichst gute Lösung auf das Problem der offerierenden Firma zu finden und diese zu beschreiben.

Wie aber sieht das bei einem grösseren Projekt aus?

Eine Offerte in einem grossen Unternehmen

Grundsätzlich funktioniert eine Offerte genau gleich. Gut, Blogeintrag fertig, bis zum nächsten Mal! ❤

Nein, eine Offerte funktioniert zwar prinzipiell gleich, aber in völlig anderen Dimensionen, welche erst einmal beherrscht werden müssen. Nehmen wir an, die Deutsche Bahn will keine App erstellen, sondern ihre gesamte IT-Infrastruktur erneuern, quasi Deutsche Bahn 2. Die alte IT-Infrastruktur soll nicht weiter verwendet werden, stattdessen baut man alles neu, mit dem neuesten Technologiestack (Ein Stack zeigt auf, welche Technologien für ein Informatikproblem beziehungsweise deren Lösung verwendet werden. Welches Betriebssystem, welche Programme etc.).

Ja, da wird es natürlich interessant. Können Sie sich vorstellen, wieviel eine Deutsche Bahn 2 kostet? Nein? Ich auch nicht!

Nein, das benötigt zuerst einmal jede Menge Strategieleute, die sich mit dem Geschäftsfall oder Business Case auseinandersetzen.

Und was ist mit den Geschäftsprozessen? Die werden ja wahrscheinlich auch ändern, oder? Dann benötigt es Spezialisten, welche die heutigen Prozesse analysieren und die neue Lösung, die sogenannte Business Architektur konzipieren können.

Und irgendwo muss das neue System ja auch laufen, richtig? Wieviele Server muss man kaufen, damit die neue Software darauf laufen kann? Oder lässt man alles in der Cloud laufen? Aber in welcher Cloud? Und was sind das überhaupt Programme? Wir benötigen eine Technologie Architektur! (Und die sollte sich möglichst nicht zu weit von der Business Architektur entfernen – Leichter gesagt als getan!)

König Arthur’s Schlachtzug ins ungewisse Land

Und genau in dieser schönen Situation befinden König Arthur und ich uns jetzt. Bereits an meinem zweiten Arbeitstag im Büro habe ich nämlich erfahren, dass ich mit König Arthur zusammen die Technologie Architektur für dieses grosse Projekt konzipieren darf.

Das wirklich wirklich schöne ist, dass man in so einem riesigen Unternehmen niemals alleine ist. Und die Mitarbeiter sind wirklich enorm hilfsbereit und auch motiviert, dieses Projekt über die Bühne zu bringen!

Und was man machen muss, das wird uns auch schnell erklärt: Man braucht eine Übersicht über die heutige IT-Infrastruktur. Nicht im Detail, sondern aus grosser Höhe, ein Big Picture von den heutigen Prozessen, welche Applikationen dahinter stehen und wie diese miteinander Arbeiten. Zusätzlich muss man herausfinden, welche Daten die Deutsche Bahn wo gespeichert hat und welche man davon wiederverwenden oder migrieren kann (Stichwort: Make or Buy von Software).

Das Problem, ähm ich meine die Herausforderung ist aber: König Arthur und ich haben keinen Zugriff auf die Deutsche Bahn! Wir haben zwar bereits eine Handvoll Mitarbeiter welche dort stationiert sind, der Grossteil des Projekts befindet sich aber noch in den heimischen Büros und hat keine Möglichkeit, entweder mit den Deutsche Bahn-Mitarbeitern zu sprechen oder deren Dokumente zu inspizieren. Klingt spassig? Ist es auch!

Es ist quasi ein wenig wie das Huhn-Ei Problem: Wir möchten gerne zu der Deutschen Bahn, um deren Prozesse zu studieren, damit wir ihnen eine möglichst gute Lösung für ihr Problem anbieten können. Gleichzeitig sind wir aber in der Offertenphase und die Deutsche Bahn hat noch keinen Vertrag unterschrieben, was uns daran hindert, zu ihnen zu gehen und das aktuelle System zu studieren.

Selbstbeschäftigung

Eine unmögliche Aufgabe? Nein, tatsächlich können wir uns sehr gut selber beschäftigen, indem wir alle Artefakte soweit vorbereiten, wie wir es können. Ich denke aber, das sollte ich auch in einem eigenen Tagebucheintrag beschreiben, was es heisst, eine Technologie Architektur zu konzipieren.

Sehen Sie, dieser Blogeintrag ist ist typisch für ein Projekt dieser Grössenordnung. Ich wollte gar nicht soviel über Offerten oder Meetings schreiben! Da denkt man, man schreibt kurz, wie man in einem Projekt am effektivsten voranschreitet, merkt aber dann, dass man noch zuerst A und B und C braucht, bevor man sich mit seinem D selbst beschäftigen kann.

Nichtsdestotrotz muss man aber immer optimistisch bleiben und dran glauben, dass am Ende des Regenbogens ein Topf voll Gold steht, auch wenn anfangs das Gefühl hat, die aufgescheuten Hühner werden den Weg dorthin niemals finden. Ich persönlich bin sehr gespannt, wie sich das Projekt weiterentwickeln wird.

Und wenn Sie jemand fragt, woher Sie wissen, dass die Deutsche Bahn ihre IT-Infrastruktur erneuern will und dass das Projekt firmenintern Projekt Hasenstall genannt wird – Das haben Sie nicht von mir!

(PS bezüglich Huhn-Ei-Problem: Das Ei war zuerst da, ist ja logisch! )

Hier gehts zum Consultant Tagebuch 3: Der Verrat an König Arthur