Agile Software-Entwicklung hat uns von einigen Zwängen der phasen-orientierten Prozesse befreit.

  • Wir müssen nicht mehr alles zu Beginn des Projektes wissen. Wir dürfen miteinander und voneinander lernen.
  • Wir haben keine getrennten Teams für Analyse, Entwicklung und Test. Wir lieben selbstorganisierte cross-funktionale Teams.
  • Niemand muss in einer Software-Fabrik arbeiten. Wir reden miteinander und entwickeln das unserer Meinung beste Produkt.

Trotzdem gibt es in agilen Prozessen den Bedarf für Anforderungsanalyse, Stakeholder-, Architektur- und Lizenzmanagent, auf jeden Fall in großen Unternehmen. Eine agile Projektorganisation bewegt sich immer in einem Spannungsfeld zwischen Selbstorganisation der Entwickler, verbunden mit der vollständigen Kontrolle über die Implementierung ihrer Komponenten, und der Einschränkung der Vielfalt der Lösung aufgrund übergreifender Ziele, internationaler Normen oder unternehmensweiter Vorgaben. Immer kontrovers!

Motivation

Mit praktisch jedem Baustein der Systemstruktur sind Entscheidungen verknüpft. Im Baustein Service wird im Steckbrief festgelegt, mit welchen Technologien die Komponente realisiert wird. Mit den Bausteinen Entity und Event werden Datenstrukturen fixiert. Der Baustein Domain wird genutzt, um ein Service einem Code-Repository zuzuordnen. Das sind alles einzelne Entscheidungen, die bei agiler Entwicklung im verantwortlichen Team getroffen werden. Manchmal ist es sinnvoll, dass eine einmal getroffene Entscheidung auch für eine andere Komponente richtig ist. Oder Events sollen einer einheitlichen Grundstruktur folgen. Das Prinzip DRY verbietet es, diese Entscheidung immer wieder zu wiederholen.

Der Baustein Spec ist das “missing link” im Kanon der Bausteine der Methode CARDS+. Dort wird allein durch die Existenz einer Spec festgehalten, dass es ein übergreifendes Konzept gibt. Die Beschreibung wird genutzt, um die Grenzen der Anwendbarkeit des Konzeptes zu definieren.

Wiederkehrende Muster

Für welche Themen wiederkehrende Muster übergreifende Konzepte notwendig sind, hängt ganz wesentlich vom Produkt ab. Aber auch das Projekt, die Projektorganisation und das Unternehmen sind Einflussfaktoren.

Insbesondere Schnittstellenkomponenten folgen wiederkehrenden Mustern. Schnittstellen realisieren sehr häufig auf technischer Ebene gleichartige Datenverarbeitung mit wechselnden fachlichen Inhalten. Treiber sind internationale Normen oder unternehmensweite Vorgaben. Der Baustein Spec beschreibt eine Implementierungsvorlage, vergleichbar mit Generics (Java) oder Templates (C++) beim Programmieren, nur auf wesentlich höherer Abstraktionsebene.

Betriebskonzepte

In praktisch jedem nicht trivialem Software-Produkt gibt es den Bedarf an übergreifenden Konzepten für den Betrieb des IT-Systems. Themen wie Logging, Monitoring, Sicherheit, Nachvollziehbarkeit, Robustheit, Skalierbarkeit können ganz einfach nicht individuell entschieden werden. Bei den Themen Sicherheit oder Skalierbarkeit gilt der Satz «Die Kette bricht an der schwächsten Stelle». Jede Komponente muss sicher sein. Keine Komponente darf ein Flaschenhals (englisch: bottle neck) werden. Monitoring im Betrieb ist eine Aufgabe für Personen der Betriebsorganisation und in der Regel außerhalb der Teams. Eine einheitliche Präsentation des Zustandes von Komponenten ist ein wesentlicher Erfolgsfaktor für eine schnelle Identifizierung und Behebung von Störungen.

Der Baustein Spec definiert Betriebskonzepte zur Erreichung dieser wichtigen übergreifenden Ziele, mit einer Beschreibung der Randbedingungen und Qualitätsmerkmale. Sie können bei agiler Entwicklung auch als Konkretisierung einer DoD verwendet werden.

Fremdprodukte

Moderne Software-Entwicklung basiert auf der Wiederverwendung von Software. Insbesondere Open-Source-Software ist mittlerweile ein unverzichtbarer Bestandteil vieler erfolgreicher kommerzieller Software-Produkte. Programmbibliotheken lösen viele alltägliche Probleme der Entwickler: Bildmanipulation, Datenkonvertierung, Datenaustausch, um nur ganz wenige Einsatzbereiche zu nennen. Die Umsetzung der Testpyramide wäre undenkbar ohne JUnit, TestNG, Fitnesse, Cucumber, Jenkins, Mockito, u.n.s.v.m. Viele Open-Software-Projekte sind Teil der Infrastruktur für den skalierbaren, leistungsfähigen und robusten Betrieb eines Software-Produktes. Die Apache Software Foundation hat ein ganzes Universum unverzichtbarer Produkte: Kafka, Storm, Flink, das Hadoop-Ökosystem, diverse Datenbanken. Auch erfolgreiche Unternehmen wie Google, Netflix oder Microsoft stellen gut funktionierende Produkte frei zur Verfügung. Eine cloud-basierte Infrastruktur mit PaaS, IaaS oder SaaS wäre ohne Docker, Kubernetes, Rancher wohl nicht machbar.

Ganz schnell verliert ein Team den Überblick über nicht selbst entwickelte Produkte. Der Baustein Spec ist eine einfache Möglichkeit, einen Katalog der benutzten Software zu erstellen. Und gleichzeitig eine Voraussetzung für effizientes Architekturmanagement.

  • Welche Versionen sind im Einsatz?
  • Gibt es professionellen Support?
  • Wer leistet den Support?
  • Welche Einschränkungen gibt es?
  • Gibt es bekannte Probleme?

Wird ein Problem mit einem Open-Source-Produkt bekannt, kann durch Verlinkung der Fremdprodukte mit den individuell entwickelten Komponenten schnell geprüft werden, ob und welche Komponenten auf Schwachstellen überprüft werden müssen. Soll ein Fremdprodukt durch ein anderes ersetzt werden, kann sehr einfach der grobe Umfang für das Refactoring bestimmt werden.

Frei verfügbare Software ist nicht gleichzusetzen mit lizenzfreier Software. Im Gegenteil: Open-Source-Software kann nur entsprechend ihrer Lizenz verwendet werden. Und Lizenzen gibt es wie Sand am Meer. Auf https://opensource.org/licenses gibt es einen sehr guten Überblick über Lizenzen für Open-Source-Produkte. Auf https://tldrlegal.com/ können je nach Lizenz in einem vereinfachten Format Pflichten bei der Verwendung von Open-Source-Produkten eingesehen werden. Ein wichtiges Ziel des Bausteins Spec ist daher die Erfassung der Lizenz benutzter Software und Grundlage für ein zuverlässiges Lizenzmanagement.

Weitere Quellen

Es gibt eine Reihe von Ansätzen, die Software-Architektur quasi als wissenschaftliche Disziplin betrachten, Kernaufgaben des Architekturentwurfs definieren und Vorlagen für die Dokumentation zur Verfügung stellen.

Das Kapitel 36 mit dem Titel “Architectural Deliveries” beschäftigt sich mit konkreten Ergebnissen aus dem iterativen ADM-Kreislauf. Speziell die Kapitel “Architecture Contract” und “Architecture Principles” definieren Dokumententypen, die geeignet sind wiederkehrende Muster und Strukturen zu beschreiben.

Quelle: TOGAF9 online documentation

Querschnittliche Konzepte sind geeignet, um wiederkehrende Muster und Strukturen zu beschreiben. Oftmals projekt- oder systemübergreifende Einsatzanleitung für Technologien helfen bei der Bewältigung komplexer Software.

Quelle: ARC42 online documentation

Definition

Beschreibung

Der Baustein Spec beschreibt ein fachliches oder technisches Konzept und gibt ihm einen eindeutigen Namen.

Der Baustein Spec ist hilfreich bei der Formulierung von Vorgaben für eine einheitliche Implementierung. Insbesondere geht es um ein gemeinsames Verständnis nicht funktionaler Aspekte, die von «gleichartigen» Komponenten berücksichtigt werden. In der Regel helfen diese Vorgaben, andere übergreifende Konzepte zu realisieren.

Der Baustein Spec wird gewählt, um sehr komplexe oder übergreifende Lösung zu beschreiben, wenn mehr als eine Komponente betroffen ist.

Der Baustein Spec beschreibt Module. Unter dem Begriff Modul versammeln sich Software-Produkte, die beim Aufbau eines individuellen Produktes genutzt werden. Dazu zählen Verzeichnisdienste (z.B. git, LDAP) Datenbanken, Message-Broker, Caches, Web-Server, Proxy-Server. Module können aber auch Werkzeuge und Bibliotheken sein, die in Komponenten des individuellen Produktes genutzt werden, z.B. Spring Boot, Docker, Gradle.

Der Baustein Spec wird für Entwickler geschrieben.

Struktur

Abschnitt Steckbrief

Der Abschnitt enthält eine Tabelle mit Zeilen für eine Kurzbeschreibung des Dienstes und eine Liste der eingesetzten Technologien.

ktip Der Steckbrief sollte so gestaltet werden, dass sich aus dem Namen, der Kurzbeschreibung und der eingesetzten Technologien sehr leicht ein Katalog erstellen lässt. In Confluence nutzen wir das Makro Seiteneigenschaften für den Steckbrief. Der Katalog wird mit dem Makro Seiteneigenschaftsbericht erstellt.
Abschnitt Dynamische Sicht

Der Abschnitt enthält einen Überblick über die Schnittstellen dieses Dienstes. Wichtig ist, dass wir hier vor allem die Sicht von außen beschreiben. Abläufe im Inneren beschreiben wir nur ergänzend zum lesbaren Code. Dazu zählen insbesondere Beschreibungen von Algorithmen und Geschäftsregeln.

ktip Der Abschnitt ist frei gestaltbar. Diagramme sind hilfreich, sollten aber immer definiert werden, z.B. durch eine Symbolbeschreibung. Das Einbetten von externen Ressourcen aus dem Code-Repository benötigt ein gutes Management für Versionen.
ABSCHNITT statische SICHT

Der Abschnitt enthält einen Überblick über die Strukturen dieses Dienstes. Wichtig ist, dass wir hier vor allem die Sicht von außen beschreiben. Strukturen im Inneren beschreiben wir nur ergänzend zum lesbaren Code.

ktip Der Abschnitt ist frei gestaltbar. Diagramme sind hilfreich, sollten aber immer definiert werden, z.B. durch eine Symbolbeschreibung. Das Einbetten von externen Ressourcen aus dem Code-Repository benötigt ein gutes Management für Versionen.
Abschnitt nicht funktionale Aspekte

Der Abschnitt beschreibt den Lösungsansatz für nicht funktionale Aspekte in dem vorliegenden Konzept. Die Aspekte ergeben sich aus den Anforderungen durch Qualitätsmerkmale wie Sicherheit, Skalierbarkeit, Robustheit, Leistungsfähigkeit oder Betriebsführbarkeit.