cards+
Der Baustein Concept
Moti­vation

Der Bau­stein Concept ist das Arte­fakt für den Archi­tektur­entw­urf, mit dem Autoren pro­dukt­spezifi­sche Kon­zepte fest­halten. Er gibt einem Konzept einen ein­deutigen Namen. Der Überblick im Bau­stein muss jeden Leser in die Lage ver­setzen, das Kon­zept und seine Konse­quenzen zu ver­stehen.

Für welche Themen über­haupt Kon­zepte not­wendig sind, hängt ganz wesent­lich vom Archi­tektur­stil ab, aber auch das Pro­jekt­umfeld, die Pro­jekt­organi­sation und die Anwen­dungs­domäne sind Ein­fluss­fak­toren.

Pro­jekt­manage­ment

In prak­tisch jedem nicht trivi­alen IT-System gibt es den Bedarf an über­grei­fenden Betriebs­kon­zep­ten. Themen wie Log­ging, Moni­toring, Sicher­heit, Robust­heit, Ska­lier­bar­keit müssen in der Regel über­greifend betrach­tet werden. Bei der Sicher­heit oder Ska­lier­bar­keit gilt der Satz «Die Kette bricht an der schwäch­sten Stelle». Ein Team muss viele Qua­litäts­merk­male berück­sich­ti­gen. Jeder ein­zelne Dienst muss sicher sein und die ge­speicher­ten Daten ange­mes­sen schüt­zen. Kein Dienst darf zum Flaschen­hals (engl. bottleneck) für das IT-System wer­den. Zuver­lässi­ges Moni­toring ist eine Vor­aus­setzung für den rei­bungs­losen Betrieb in einer kom­ple­xen IT-Land­schaft. Mit dem Bau­stein Concept werden Kon­zepte doku­mentiert und kom­muni­ziert, um sol­che Qua­litäts­ziele zu erreichen. Mit der Frei­gabe wird das Kon­zept zur ver­bind­lichen Vor­gabe für das Team. Ab­weichun­gen vom Kon­zept sind weiter­hin zu­lässig. Sie müssen aber be­grün­det wer­den. Änderun­gen am Kon­zept sind natür­lich auch mög­lich. Die Kon­sequen­zen soll­ten dann aber sehr gründ­lich unter­sucht wer­den.

Anfor­derungs­analyse

Kon­zepte für wieder­kehrende Muster sind ein sehr wich­tiges Ein­satz­gebiet für den Bau­stein Concept. Ent­wick­ler kennen viele Ent­wurf­smuster (engl. design patterns), z.B. Single­ton, Obser­ver oder Dele­gate. Es gibt unzäh­lige Bücher dazu, z.B.

  • Design Patterns (1997) von Gamma/Helm/Johnson/Vlissides
  • Pattern-orientierte Software-Architektur (1998) von Buschmann/Meunier/Rohnert/Sommerlad/Stal
  • Refactoring, (1999) von Fowler
  • J2EE Best Practices (2002) von Broemmer
  • Patterns of Enterprise Application Architecture (2002) von Fowler/Rice/Foemmel
  • Server Component Patterns (2002) von Völter/Schmid/Wolff
  • Core J2EE Patterns (2003) von Alur/Crupi/Malks

In der Regel werden die Muster auf eine ganz bestimmte Art und Weise für das Pro­dukt ange­wendet. Im Bau­stein Concept hal­ten Autoren diese Beson­der­heiten fest.

Pro­dukt­entwick­lung

Ver­treter des Teams nutzen den Bau­stein Concept, um für das Team wich­tige Kon­zepte beschrei­ben. Er ist hilf­reich bei der Formu­lierung eines gemein­samen Ver­ständ­nisses nicht funktio­naler Aspekte, die von «gleich­artigen» Diensten berück­sich­tigt wer­den. Mit dem Titel der Seite im Wiki bekommt jedes Kon­zept einen ein­deutigen Namen. Der Bau­stein Concept wird in den Bau­steinen des System­struk­tur mit einer kurzen Begrün­dung als Ver­knüpfung einge­tra­gen. Der Bau­stein Concept wird auch gewählt, um eine sehr kom­plexe Lösung zu beschrei­ben, wenn mehr als ein Dienst betrof­fen ist.

Moderne Pro­dukt­ent­wick­lung basiert auf der Wieder­verwen­dung von Soft­ware. Open-Source-Soft­ware ist mittler­weile ein unver­zicht­barer Bestand­teil vieler erfolg­reicher kommer­zieller Pro­dukte. Programm­biblio­theken lösen viele all­tägliche Prob­leme der Ent­wick­ler: Bild­manipu­lation, Daten­konver­tierung, Daten­aus­tausch, um nur einige Ein­satz­bereiche zu nennen. Die Umsetzung einer Test­pyramide wäre undenk­bar ohne JUnit, TestNG, Spock, Fitnesse, Cucumber, Jenkins, Mockito und noch viele weitere mehr. Open-Source-Soft­ware ist Teil der Infra­struk­tur für den ska­lier­baren, leis­tungs­fähigen und robus­ten Betrieb eines Pro­duktes. Die Apache Software Foundation hat ein ganzes Uni­versum unver­zicht­barer Produkte: Kafka, Storm, Flink, das Hadoop-Öko­system und viele ver­schie­dene Daten­banken. Auch erfolg­reiche Unter­nehmen wie Google, Netflix oder Microsoft stellen gut funk­tionie­rende Pro­dukte zur freien Nutzung zur Ver­fügung. Eine cloud-basierte Infra­struktur mit Konzepten wie PaaS, IaaS oder SaaS wäre ohne Docker, Kubernetes, Terraform, Packer oder Rancher wohl nicht mach­bar.

Eine Bedien­ober­fläche ver­folgt immer ein bestimm­tes Bedien­kon­zept. Die Größe des Bild­schirmes (z.B. Watch, Smart­phone, Tablet, Moni­tor, UHD-TV) und die Mög­lich­keiten der Ein­gabe (z.B. Maus, Tasta­tur, Stift, Berüh­rung) beein­flus­sen die Gestal­tung der Bedien­ober­fläche. Ein Bedien­kon­zept ver­folgt auch das Ziel einer Stan­dardi­sierung der Ele­mente der Bedien­ober­fläche durch eine Gestal­tungs­richt­linie (engl. style guide). Jedes Bedien­kon­zept wird mit dem Bau­stein Concept erfasst und bekommt durch den Titel der Seite im Wiki einen ein­deutigen Namen.

Das Wiki.

Ein Erfolgsfaktor.