Blog

Hammer und Sichel des Softwarearchitekten: Ende der Werkzeugdebatte![edit]

Werkzeuge werden gerne und oft diskutiert.
Oft bestimmen die Werkzeuge die Methoden und nicht umgekehrt.
Werkzeuge versprechen erhöhte Produktivität bewirken aber zu oft das Gegenteil.
Werkzeuge sind Machtmittel, wenn über Lizenzen oder Know-how der Zugang versperrt ist.

• Wie sehen heute Werkzeugketten für Softwarearchitekten aus?
• Wie erreichen Sie die Nachvollziehbarkeit der Ergebnisse von den Anforderungen

bis zur fertigen Software?

• Wie treffen Sie die richtige Wahl der Tools?

VHIT – die erste Werkzeugkette!

Solange Programmierer ihre eigenen Anforderungen umsetzen konnten, war VHIT- „Vom Hirn ins Terminal“ die Method der Wahl.
Es gab eine Ein-Hirn-Werkzeugkette.

Zweihirnwerkzeugkette

So bald zwei oder mehr Personen an der Softwareentwicklung beteiligt sind, ist nicht mehr sichergestellt, dass die Anforderungen so wie eigentlich gedacht umgesetzt werden. Es kommt das Dilemma der menschlichen Kommunikation zum Tragen.
„Das hab‘ ich nicht gesagt“ und „Du kannst mich einfach nicht verstehen“ sind nicht umsonst beliebte Buchtitel.
Ab der Zweihirnwerkzeugkette treten alle Probleme auf, die sich aus der Verteilung des Wissens ergeben. Der verbindliche Stand der Software ergibt sich noch immer nur aus dem erstellten Source-code.
Erst beim Wechsel des Programmierers zeigt sich, ob und wie dieser Ansatz langfristig trägt. Auftragssoftware entsteht noch heute sehr häufig nach dem Zweihirnverfahren.

Vollständiger Beitrag: Hammer und Sichel des Softwarearchitekten: Ende der Werkzeugdebatte!

Y-Prinzip[edit]

Auf den iSAQB Information Days 2011 stand das Y-Prinzip im Mittelpunkt der Frage, wie Separation of Concerns möglichst einfach und effizient erreicht werden kann. Es geht dabei um die Trennung von Fachlichkeit und Technik. Das Y-Prinzip ist sehr oft, aber nicht immer anwendbar – die Kriterien für die Anwendung des Y-Prinzips müssen bekannt sein und die Softwareprojekt können dann daraufhin geprüft werden, ob ein großes Einsparpotential vorliegt.

Mit diesem Wissen sollten Sie motiviert sein, Ihre eigenen Softwareprojekte darauf hin zu analysieren, wo sie bzgl. der Trennung von Fachlichkeit und Technik stehen und welches Gewicht Sie diesem Thema in Zukunft geben wollen.

Nehmen Sie Kontakt mit uns auf, um zu erfahren, wie mit zunehmender Größe und Komplexität der Vorteil des Trennungsvorgehens außerordentlich steigt. Sehen Sie, wie in konkreten Projektbeispielen die „Reverse-Y“-Analyse zeigt, wo der größte Nutzen liegt.

Reverse-Y bedeutet, das Y-Prinzip von einer bestehenden Implementierung her anzuwenden. Dabei werden wiederkehrende technische Themen wie z.B. Hilfesystem, Fehlerbehandlung, Datenhaltung und Benutzeroberfläche identifiziert und schrittweise von der Fachlichkeit entkoppelt (falls nicht idealerweise die Entkopplung schon gegeben ist und daher nur noch dokumentiert werden muss).

Je getrennter die Verfolgung der Pfade Fachlichkeit und Technik erfolgt desto mehr ist es erforderlich, die Verbindungen zwischen beiden Seiten zu klären und Schnittstellen zu vereinbaren. Dazu ist es hilfreich, wenn die fachliche Seite mit einer “pseudotechnischen Sicht” arbeitet, welche vereinfacht die technischen Annahmen und Schnittstellen darstellt und die technische Seite arbeitet mit einer “pseudofachlichen Sicht”, welche die fachlichen Annahmen und Schnittstellen darstellt. Im Detail brauchen beide Sichten gar nicht vollständig oder korrekt sein. Die pseudofachliche Sicht sollte jedoch die aus technischer Sicht architekturrelevanten Punkte, wie z.B. das Mengengerüst, die Komplexität bzgl. Datenstrukturen und GUI und ähnliche Punkte wiedergeben. Die pseudotechnische Sicht sollte die aus fachlicher Sicht notwendigen techischen Themen wie z.B. GUI, Datenbank, Netzwerk, Security usw. so wiedergeben, dass die vorgesehenen Schnittstellen einfach und klar sind.

Das Y-Prinzip ist im Jahr 2001 bei BITPlan entstanden und basiert auf der Objects 9000® Idee von Martin Rösch. Dieses Prinzip ist in einer Reihe von Projekten angewendet worden, die plattformübergreifende Lösungen erfordern.

Bei der Entwicklung von Softwarearchitekturen geht es darum, eine geeignete Zerlegung der zu entwickelnden Software zu finden. Die Trennung von Fachlichkeit und Technik ist ein wichtiges Zerlegungsprinzip. Das Kosten- und Nutzenpotential darf nicht außer acht gelassen werden, denn es macht keinen Sinn mit missionarischem Eifer als Prinzipienreiter aufzutreten, wenn eine spezielle Projektsituation nun doch nicht den höchstmöglichen Kosten- Nutzeneffekt bietet. Bei langfristig zu pflegenden Softwaresystemen ist es wichtig die gesamte Laufzeit in die Betracht zu ziehen. In Situationen in denen Produktfamilien entwickelt werden gilt grundsätzlicher, dass ein aspektorientierte Ansatz der sich von der Trennung von Fachlichkeit und Technik leiten lässt sinnvoll ist. Plattformübergreifende Entwicklung lässt sich deutlich leichter realisieren, wenn die technischen Aspekte gekapselt sind. Konsequenterweise sollte schon die Anforderungsaufnahme die technischen Aspekte möglichst getrennt berücksichtigen. Die konzeptionelle Durchgängigkeit von der Anforderungsaufnahme bis zur Implementierung unter Beibehaltung von Trennung von Fachlichkeit und Technik zu erreichen ist in der Praxis nicht einfach. Kompromisse sind kaum vermeidbar. Wichtig dabei ist möglichst den Vorteil der Systematisierung nicht zu verlieren. Denn Systematisierung ist die Voraussetzung von Automatisierung. Die nötigen Einigungsprozesse für die Systematisierung gehören an den Anfang. Dann erst kann auf dieser Basis automatisiert werden.

Vollständiger Beitrag: Y-Prinzip

Vom Sinn und Unsinn einer Zertifizierung von Software-Architekten[edit]

Da Softwarearchitekt keine geschützte Berufsbezeichnung ist, können in einem Projektkontext erworbene Fähigkeiten oder Erfahrungen vom nächsten Arbeit- oder Auftraggeber schlimmstenfalls als ungenügend betrachtet werden. Solche Überraschungen wünscht sich weder der Softwarearchitekt noch der Arbeitgeber.
Ein gemeinsames Verständnis würde helfen, dieses Risiko zu vermeiden. Um überprüfen zu können, ob jemand den Anforderungen an das Berufsbild Softwarearchitekt gerecht wird, gibt es verschiedene Zertifikate, die dies sicherstellen sollen.
Dieser Artikel skizziert den Nutzen einer Zertifizierung aus der Perspektive eines Softwarearchitekten sowie aus der Perspektive eines Auftraggebers. Darüber hinaus beschreiben wir am Beispiel der Zertifizierung zum CPSA (Certified Professional for Software Architecture), welche fachlichen, organisatorischen und sozialen Kenntnisse von einem Softwarearchitekten gefordert werden und welche Aussagen man aus einem solchen Zertifikat ableiten kann bzw. welche nicht.

Vollständiger Beitrag: Vom Sinn und Unsinn einer Zertifizierung von Software-Architekten