Nutzen einer dokumentierten Unternehmensarchitektur

Eine UA zu erstellen ist eine aufwändige Sache und macht Sinn, wenn mehr als ein Projekt und/oder mehr als eine Anwendung über mehrere Fachdomänen verteilt werden. Für kleine KMU u. Startups macht diese evtl. nicht gleichviel Sinn, wie für ein grosses und komplexes Unternehmen.

Den Idealen Zeitpunkt zur Erschaffung einer UA zu finden ist ebenfalls nicht ganz einfach. Beginnt man zu früh, so besteht das Risiko einer "Überorganisation" - verpasst man den Zeitpunkt und das Unternehmen wächst zu schnell, so kann ein unkoordinierter und ineffizienter "Hühnerhaufen" resultieren.

Leider wird der Sinn und Wert einer UA vom "typischen" Management nicht gesehen. Somit ist der persönliche Effort, den ein Unternehmensarchitekt erbringen muss, enorm. Ohne "Sponsoren" und Lobby kann diese Aufgabe nur schwer gelöst werden - eine Ausnahme bilden hier vermutlich reine Software-Unternehmen, da dort der Stellenwert der IT naturgemäss viel höher ist.

Weiter ...

Integrationsarchitektur

Wozu dient Integrationsarchitektur?

Integrationsarchitektur dient dem "Zusammenspiel" von unterschiedlichen Lösungen/Systemen.

Sie definiert die Kommunikation und die Verteilung von Systemen und lässt Schnittstellen entstehen.

Man kann Integrationsarchitektur mit Brückenbau vergleichen.

zum Artikel

Einsatz von Integrations-Middleware

Eine Integrations-Middleware ist die konkrete Umsetzung eines abstrakten Integrationsprinzip. Abhängig von einer der drei Haupt-Integrations-Muster:

• Datenintegration
• Businesslogik-Integration
• Oberflächen-Integration

und der Anforderung and die Technologie, kommt eine einfache oder komplexere Middleware zum Einsatz.

zum Artikel

Vorgehen bei der Entwicklung einer Architektur

Fassen wir die einzelnen Schritte zur Erstellung einer Architektur zusammen, so kommen wir auf lediglich 8 Stichworte. Bis zur Abgabe des fertigen Produktes wird dieser Vorgang iterativ durchgeführt.

1. Anforderungen sammeln
2. Risiken abschätzen
3. Konzept und Struktur erstellen
4. Dokumentation/en erstellen
5. Dokumentationen kommunizieren
6. Umsetzung überwachen
7. Architektur Bewerten
8. Anpassen / Erweitern

Bild 1 dient uns als Gedächtnisstütze, da sich vermutlich die meisten von uns Bilder eher einprägen können als einfachen Text.

Bild 1 - Entstehung der Architektur

Führen wir nun diese 8 Stichworte weiter aus, so sieht man allerhand Arbeit, die auf einen Software Architekten zukommt. Allerdings ist auch nicht verlangt, dass wir als Software Architekten die ganze Abeit alleine erledigen, sondern - im gegenteil - die Architektur im Team und nicht isoliert (fernab der Realität) entstehen lassen. Auch soll die Aufgabe nicht verkrampft angegangen werden mit dem Ziel von Anfang an alles richtig zu machen, denn eine Architektur soll an sich und am Produkt mitwachsen.

Anforderungen sammeln

Ideal wäre es, wenn der Kunde bereits zu 100% wüsste was er eigentlich genau möchte. Das Problem ist hier jedoch, dass der Kunde dies nicht immer wissen kann und einfach eine grobe Idee, von dem was er sich ungefähr wünscht, hat. Die Aufgabe des Architekten ist es nun (unter anderem) die Idee zu erfassen und zusammen mit dem Kunden die Idee zu verfeiner. Betrifft die Idee oder der Wunsch ein bestehendes Produkt, so kann man beratend Einfluss auf die Anforderungen nehmen. Der Kunde kann in diesem Falle noch nicht wissen, was das System so alles kann und welche seiner Wünsche und Anforderungen überhaupt umgesetzt werden können - oder allenfalls bereits abgedeckt sind.

In diesem Schritt können erste Abklärungen mit anderen Stakeholdern (Lieferanten Fremdsysteme, Betrieb, Kundendienst, Entwickler etc.) ebenfalls initiiert und getätigt werden.

Nichtfunktionale Anforderungen sollten ebenfalls bereits zu diesem Zeitpunkt definiert werden. In Summe erhalten wir dadruch die Qualität des Produktes. Nicht vergessen sollte man hier zu jedem Punkt die Messbarkeit zu definieren. Nur so kann man dem Kunden (und auch den anderen Stakeholdern) beweisen, dass die Qualität des Systemes genau so ist wie man sich das vorgestellt hat. 

Beispiele für solche NFA's sind:

• Performance (Effizienz)
• • Performance muss messbar gemacht werden, indem wir Szenarien und Messwerte (Duchsatz, Antwortzeit etc.) definieren.
• Verfügbarkeit
• • Die Verfügbarkeit von Systemen kann genau berechnet werden. 
  • Die beiden Hauptmesserte werden MTBF (Mean Time Between Failure) und MTTR (Mean Time To Repair) genannt.
  • Idealerweise können wir uns mit dem Kunden auf Betriebszeiten zu einigen. Dadurch mindern wir die Zeit wo das System unbedingt vergübar sein muss.
  • Unrealistische Verfügbarkeiten wie 99.999% und höher machen keinen Sinn und sollten dem fantasierenden Stakeholder direkt vorgerechnet werden. Hierzu stehen uns zwei Formel zur verfügung:
  • • Serielle verkettung von Komponenten: A = A1 * A2 * An; hierbei gilt, dass A immer kleiner ist als das "schächste" glied.
    • Parallele verkettung von Komponenten A = 1-((1-A1)*(1-A2)*(1-A3)); daraus folgt, dass A immer grösser ist als das stärkste Glied der "Kette".
  • hierzu mehr in einem späteren Kapitel; es werden auch Berechnungsbeispiele folgen, welche aufzeigen was für fantastische Anforderungen zu diesem Thema gestellt werden können.
• Korrektheit
• Bedienbarkeit
• Wartbarkeit
• Änderbarkeit
• Stabilität
• Testbarkeit
• Betriebbarkeit
• weitere Attribute mit "...barkeit" am Wortende

Generell gilt bei den NFA's, dass man sich mit den Stakeholdern auf 4-5 einigen sollte, welche auch messbar gemacht werden. Achtung: jeder Stakeholder hat seine eigenen Anforderungen!

Risiken abschätzen

Hier haben wir oft einen fliessenden Übergang zwischen Sammeln der Anforderungen und abschätzen der Risiken. Unter "Risiken" verstehen wir z. Bsp. 

• fehlendes Knowhow
• grosse Datenmengen
• komplizierter Use Case, der nicht mehr vereinfacht werden kann
• begrenzte physikalische Verbindungen
• eingeschränkte Hardware Ausstattung
• schlechte Testbarkeit aufgrund sehr teurer oder komplexer Umsystem, wo keine Testsysteme vorhanden sind
• Organisatorische Mängel oder Restriktionen
• unrealistischer Zeitplan/Budget
• ...

Diese Liste könnte fast endlos weitergeführt werden. Fast jede Zielbranche eines Systems kennt seine eigenen Risiken - die einen mehr, die anderen weniger. 

Konzept und Struktur erstellen

Dieser Schritt wird in vielen Lehrbüchern zusammen mit dem Erstellen der Dokumentation beschrieben. Ich bin jedoch der Ansicht, dass die ersten Konzepte und Strukturen im Kopf (bei einem Spaziergang, während einer langweiligen TV-Sendung, beim Autofahren, auf der Toilette, bei einem Glas Wein etc.) entstehen. Daher trenne ich diese beiden Schritte gerne. 

Dokumentation/en erstellen

Zur Dokumentation stehen uns diverse Werkzeuge zur Verfügung. Grundsätzlich sind diese bereits mehr oder weniger standardisiert. Doch viele grosse Unternehmen interpretieren Standards individuelle. Dazu rate ich jedoch nicht, da man sich gerade bei Diagrammen noch um Legenden kümmern muss. Da bedient man sich lieber der UML. Diese Modelliersprache deckt bereits vieles ab. 

Das zentrale Dokument, welches ein Software Architekt erstellt, ist das sogenannte "Software Architektur Dokument" (SAD). In diesem sind Punkte enthalten wie

• Zweck des Systems
• Art des Systems
• Stakeholder
• Entscheidungsmatrixen
• Use Cases
• Risiken
• NFA's
• • Messbarkeit
• FA's
• Sichten
• • Die "Baupläne" des Produktes; hierzu später mehr
• ...

Es gibt bereits sehr gute Vorlagen und Beispiele im Netz. Ich persönlich verwende gerne die Vorlagen von Gernot Starke auf arc42.de. Wichtig ist, dass das Dokument leben darf und soll. Es sollten hingegen keine Kapitel oder Seiten entfernt werden. Ist ein Thema nicht relevant oder dazu noch Fragen offen, so soll dies festgehalten werden - es geht in einem SAD um Transparenz und am Ende muss jeder Stakeholder mehr oder weniger hinter dem Dokument stehen. Der Kunde muss seine Idee wiedererkennen und der Entwickler muss wissen wir er das Produkt umzusetzen hat.

Dokumentationen kommunizieren

Je nach Kunde gestaltet sich das Kommunizieren der Dokumentation, sprich des technischen Konzeptes eher formell, familiär, freundschaftlich oder es wird eine regelrechte Show erwartet. Für die gröberen Fällen steht uns die "Übersichtspräsentation" zur Verfügung. Dokumente, die das SAD vereinfacht zusammenfassen und durch eine Präsentation abgerundet werden - so dass auch Nicht-Techniker den Sinn und Vorteil der Arbeit eines Architekten verstehen.

Will man schwer Eindruck schinden, so erarbeitet man hübsche Diagramme, druckt diese gross (A0 oder noch grösser!) aus und "tapeziert" damit das Büro. In diesem Falle reden wir von "Architekturtapeten".

Weitere Dokumente sind "Handbuch zur Architekturdokumentation" - wie lese ich die ganzen Dokumente, was beinhalten sie und wo liegt die jeweilige Abgrenzung.

"Architekturüberblick" - eine Kompakte Version des SAD (maximal 30 Seiten).

"Technische Informationen" zum Entwicklungsprozess - regeln die Prozesse rund um die Entwicklung, Testing, Deplpoyment, Build, Betrieb.

Richtig - jetzt haben wir erfolgreich einiges an Dokumentationen erstellt und niemand hat mehr den Überblick. Da lässt sich doch gleich noch eine "Dokumentationsübersicht" verkaufen! Nein, im Ernst - es sollen nur die nötigen Dokumente erstellt werden. Nicht vergessen darf man, dass Architektur ja "lebt" und sich weiterentwickelt. Mit jedem Dokument, das wir haben, erhöht sich der Wartungsaufwand. Und es gibt ja den Grundsatz: "Architect also implements" - unser Hauptwerkzeug soll eine IDE sein und nicht eine Textverarbeitungssoftware.

Umsetzung überwachen

Bei der Überwachung geht es an sich nur darum, regelmässig das eigene Tun zu überprüfen. Es geht nicht nur darum zu überprüfen ob die Architektur per se korrekt ist, sondern viel mehr darum um zu prüfen ob

• sie zum Ziel führt
• alle beteiligten noch vom Gleichen reden?
• sich die Implementation daran hält?
• die Dokumentation sich deckt mit der Implementierung?
• Dokumentationsanpassungen ausstehende sind?

Die hohe Kunst besteht hier vermutlich darin, den Stakeholdern zu vermitteln, dass nicht sie überwacht werden sondern wirklich nur die Umsetzung.

Architektur Bewerten

Die regelmässige Bewertung führt dazu, dass die Architektur stetig wächst und korrigiert wird - oder zumindest optimiert werden kann. Nicht selten kann man im Laufe eines Projektes Dinge vereinfachen und somit Komplexität "wegoptimieren".

Anpassen / Erweitern

Für Anpassungen darf man sich nie zu schade sein. Gerade zu Beginn eines Pojektet ist es häufig so, das sie das Ziel noch stark bewegt. Das heisst, auch unsere Architektur muss sich bewegen - man nennt dies "auf bewegende Ziele schiessen".

Die Herausforderung liegt hier darin, ein wenig Einfluss auf die Bewegungen des Zieles nehmen zu können.

Grundsätzliches zur Software Architektur

Was ist Softwarearchitektur?

Definition gemäss Wikipedia:

Eine Definition von Helmut Balzert beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement genau einer Architekturkomponente zugeordnet ist.

Paul Clements beschreibt Softwarearchitektur als „Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen“.

Die Softwarearchitektur ist Teil des Softwareentwurfs (siehe SWEBOK), innerhalb dessen sie als Grobgliederung der Komponenten entsteht. Während der Softwareentwurf sich auch auf lokale Aspekte innerhalb des architektonischen Rahmens der Software bezieht und deshalb sehr detailliert sein kann, ist die Softwarearchitektur eine globale Eigenschaft des Gesamtsystems.

Die Rolle des Architekten

Grundsätzlich füllt der Architekt eine Dienstleister Rolle aus. Er erhält von einem Stakeholder (z. Bsp. Kunde) Anforderungen - im Idealfall (in gefühlten 2% aller Fälle) weiss der Kunde bereits genau was er will.

Die Aufgabe des Architekten besteht nun darin, zu Analysieren, wie diese Anforderungen umzusetzen sind. Er berücksichtigt dabei das bestehende Umfeld und vorhandene Werkzeuge (in einem Brownfield Projekt - was vermutlich der Regel entspricht) oder aber evaluiert neue Werkzeuge, mögliche Umsysteme etc. und schafft (bei Greenfield Projekten - was wohl einem Lottogewinn gleich kommt) ein komplett neues Umfeld (Organisation, Guidelines, Prozesse etc.).

Bild 1 veranschaulicht welche Stakeholder den Architekten "benutzen" und dass die Architektur das zentrale Produkt des Architekten darstellt. Der Architekt ist im Entwicklungsteam angegliedert. Es ist nicht ausgeschlossen (ich behaupte sogar: es ist sogar von Vorteil!), dass der Architekt mit dem Rest des Teams das System implementiert - sprich "Der Architekt arbeitet mit am Code!".

Bild 1 - Rolle des Architekten

Der Architekt kümmert sich um Themen wie:

• Strukturen
• • Bausteine und deren Zusammenhänge
  • Systemabläufe
  • Schnittstellen nach Aussen
  • interne Schnittstellen
  • Abhängigkeiten
  • Verteilung (Deployment)
  • ...
• Dokumentation und Kommunikation
• • Aufbau des Wissens und Erhaltung
  • "Verkauf" der Architektur
  • ...
• Technische Konzepte
• • User Expirience (UX)
  • Datenspeicherung
  • Ablaufsteuerung
  • Impl. sog. Businessrules
  • Exceptionhandling
  • Monitoring- & Healthmanagement
  • Verteilung
  • Konfigurierbarkeit
  • Lokalisierung (Internationalisierung)
  • Deployment
  • ...
• Qualität
• • Definiert diese nichfunktionale Anforderungen (NFA) mit Stakeholders
  • • Performance
    • Verfügbarkeit
    • Robustheit
    • Security
    • Flexibilität/Anpassbarkeit
    • Skalierbarkeit
    • Testbarkeit
    • Verständlichkeit
    • Betriebbarkeit
    • ...
  • Definiert Messbarkeit dieser NFA's
  • ...
• Anforderungen
• • Verwaltet die Anforderungen
  • • Verhandelt mit Stakeholden
  • ...
• Entscheidungen treffen
• • zur Struktur
  • zum technischen Konzept
  • Überwacht die Einhaltung und nimmt Korrekturen vor
  • ...

Entstehung der Architektur

Es ist keinesfalls so, dass der Architekt Anforderungen aufnimmt, Abklärungen trifft, Dokumente erstellt und "fertig ist die Architektur". Auch wenn gewisse Projektleiter es gerne sehen würden, dass der Task "Erstellen der Architektur" abgehakt werden kann - aber ist deren Unwissen oder "Beratungsresistenz" unser Problem? Nein! Architektur ist lebendig und wird iterativ (und auch agil) erschaffen - sie begleitet ein Projekt und definiert die Rahmenbedingungen, an welche sich Entwickler zu halten haben. Dem Auftraggeber dient sie als Bestätigung, dass sein Anliegen verstanden wurde. Zugegeben: es gibt Bereiche welche den Auftraggeber vermutlich eher verwirren, als bestätigen. Aber ein bisschen "Magie" darf sein.

In den meisten Fällen - nein, in der Regel - ist es so, dass der Kunde selber nicht genau weiss was er genau möchte. Das liegt zum einen in der Natur der Sache und zum Anderen darin, dass der Kunde sich ja von einem Fachmann (was ein Architekt sein sollte) beraten lassen will und muss und nicht im Stande ist, zu wissen was ein bestehendes System bereits kann. Daher hat man zu Beginn eines Projektes eine gewisse Unschärfe. Diese Unschärfe deckt der Architekt im Laufe seiner Arbeit auf und kann mit Fragen, Verhandlungen, Abklärungen usw. dem Projekt eine gewisse Schärfe verleihen - er "schiesst" auf ein sogenanntes "Moving target". Dadurch erfährt auch die Architektur immer wieder kleine Anpassungen und wächst mit. Im Idealfall stimmen am Ende des Projektes die Architektur mit dem System UND den Kundenanforderungen überein. 25% aller Projekte erfahren gemäss einer internationalen Statistik jedoch nie ein Ende, weil entweder die Anforderungen nie klar werden, das Budget gestrichen wird oder der Aufwand zu gross wird. Es wird auch der Verlust von Motivation als Grund erwähnt (ja das kommt anscheinend wirklich vor!).

Rolle der Architektur

Bild 2 macht deutlich, dass die Architektur wie auch das fertige Produkt (System) Einfluss auf deren Umfeld hat. Was jetzt abstrakt klingen mag bedeutet in der Realität, dass z. Bsp. die Windows Store App "SLUITEN" Einfluss haben wird auf deren Benutzer resp. die Organisationen und Sportvereine, welche diese App einsetzen. Organisationen, welche aufgrund hoher Investitionskosten und technischem Aufwand komplett auf Statistiken verzichten mussten, können mit SLUITEN  und den damit verbundenen sehr kleinen Einstiegshürden, von einem professionellen Werkzeug profitieren. Was dazu führen wird, dass auch im Amateursport vermehrt Ersatzspieler eine spannende und wichtige Aufgabe während eines Spieles erhalten werden.

Bild 2 - Rolle der Architektur (in Anlehnung an

Eine weitere Rolle nimmt die Architektur bei den Entwicklern ein: Sie bildet das Grundgerüst und trägt dazu bei, dass das komplette Team in EINE gemeinsame Richtung arbeitet und dient als Diskussionsgrundlage. 

Wie bereits erwähnt, darf und soll die Architektur sich stetig verändern - das Produkt und die Anforderungen tun dies ja auch. Allerdings soll auch darauf geachtet werden, dass eine Änderung immer aus einer fundierten Motivation entsteht und nicht aus einem Hype heraus oder nur weil ein Entwickler (oder auch der Kunde!) eine "Tischbomben-Idee" hat ... Ebensowenig darf eine Architektur isoliert entstehen und soll keine emotionale Effekthascherei enthalten.

Kontext

Bild 3 zeigt mögliche Einflüsse einer Software Architektur auf die Entwicklung einer Software.

 Natürlich können diese Einflüsse je nach Umfeld, Organisation oder Anforderungen stark varieren. Das zeigt wieder einmal mehr, dass es keine "richtige" oder "falsche" Architektur gibt sondern höchstens "gute" und "schlechte" - und "schlecht" ist sie dann, wenn die Entwickler nicht verstehen was sie tun sollen, der Kunde seine Anforderungen nicht wiedererkennt oder aber viele Fragen offen bleiben.

Fazit

Der Architekt vermittelt mit Hilfe seiner Architektur zwischen Kunde und Entwicklung und stellt sicher, dass sich die Anforderungen in einem tollen Produkt wiederfinden!

Programmieren in der Grundschule

Was in England bereits zum Schulstoff der Grundschule gehört, könnte auch in Deutschland schon bald die Kreativität der Kinder und Jugendliche fördern. Als Nebeneffekt erhalten die Kids bereits in einem sehr frühen Stadium die Möglichkeit Ihre Berufliche Laufbahn massgebend mit zu gestalten.

Grundsätzlich bin ich der Auffassung, dass man Kindern in erster Linie Kinder sein lassen sollte und nicht schon - kaum können sie Lesen und Schreiben - mit dem Ernst des Lebens unter Druck zu setzen. Doch wie fest "Ernst des Lebens" ist Programmieren? Einverstanden - geht es um die unternehmensrelevante Software Entwicklung kann man die Ernsthaftigkeit des Programmierens nicht abstreiten. Jedoch kann Programmieren ein Hobby sein, welches jeden Tag absoluten Fun bietet. Wer kennt aus seinen jungen Jahren nicht die Lego-Bausteine?! Programmieren ist im Grunde genommen nichts anderes als mit Lego-Bausteinen ein Haus, Auto, Raumschiff oder ein komplett sinnfreies "Gebilde" zu bauen. Man setzt Bausteine zu was zusammen, was man sich vorher gut oder weniger gut vorgestellt hat. 

Die Handarbeit- u. Malstunden sind bereits an jeder Schule ein fester Bestandteil - da wird allerhand praktisches für das Leben gelernt, es wird gebastelt und gezeichnet ... Warum nicht mal einem Roboter in einer Gruppenarbeit zum Leben erwecken? Oder in einer Einzelarbeit einem virtuellen Hündchen das Gehorchen beibringen? Viel schwieriger als Nähen, Sägen, Bohren, eine Blume zeichnen o.ä. ist das nämlich nicht. Und macht bestimmt so viel Spass.

OK, ich gebe zu, dass bis in absehbarer Zeit die Lehrer dazu fehlen werden. Die Tatsache, dass Menschen mit den nötigen technischen und pädagogischen Skills bereits in der privaten Wirtschaft Mangelware sind, macht es nicht einfacher Lehrstühle zu besetzen. 

Fakt ist, dass in Zukunft Kompetenzen in der Entwicklung von Software immer wichtiger werden. Erkennen diesen Trend alle Länder um die Schweiz herum, werden wir früher oder Später ein Problem haben. Zumal die Rekrutierung im Ausland ja seit Anfang dieses Jahres nicht einfacher wurde.

  

Verweise

• http://t3n.de/news/programmieren-ab-grundschule-internetbotschafterin-gesche-joost-536352/
• http://code.org/learn