Permanenter Link Gespeichert von Wolfgang Göbl (nicht überprüft) am Fr, 07/12/2019 - 09:29
Matthias, vielen Dank für den super Artikel. Mich beschäftigt das Thema schon länger und ich hatte dazu auch einen Vortrag am Wiener DDD Meetup wo ich Business Architektur/Capabilities präsentiert habe.
Capabilities, wenn "gut" modelliert sind für mich DER Schlüssel für erfolgreiche Architekturarbeit, aber nur wenn sie gut im Fachbereich bekannt sind und sie vom Development akzeptiert/mitgestaltet werden. Aus zweiterem Grund muss es gelingen die Brücke zwischen EAM/Development, Capabilities/DDD wie von Dir beschrieben zu bauen.
Was mir fehlt: Capabilities werden in Firmen höchst unterschiedlich verwendet. Ich sehe viele davon in meinen Beratungsprojekten und ich würde max. 10% als "gut" bezeichnen. Modellierungsrichtlinien für Capabilities existieren nicht - die Definition im BIZBOK und die Beispiele dort sind.... optimierbar. Ähnlich geht es mir nach Durchsicht der DDD Literatur. Die abstrakten Konzepte sind nachvollziehbar, konkrete Beispiele und Richtlinien für das Finden "guter" Contexts etc sind rar.
Für Capabilities erstellen wir gerade auf architectural-thinking.com Modellierungsrichtlinien - schau mal rein auf http://atf.architectural-thinking.com:8090/x/DYER und mache gerne dort Feedback.
Das Beispiel in Deinem Artikel hier ist gut, aber natürlich bräuchte es noch einiges Nachdenken um Modellierungsregeln für Contexts und das Mapping Capabilities->Contexts zu definieren. Falls Du/ihr Lust habt am Thema weiterzuarbeiten bitte melden!
Super Artikel, macht Lust am Thema noch tiefer zu tauchen
Matthias, vielen Dank für den super Artikel. Mich beschäftigt das Thema schon länger und ich hatte dazu auch einen Vortrag am Wiener DDD Meetup wo ich Business Architektur/Capabilities präsentiert habe.
Capabilities, wenn "gut" modelliert sind für mich DER Schlüssel für erfolgreiche Architekturarbeit, aber nur wenn sie gut im Fachbereich bekannt sind und sie vom Development akzeptiert/mitgestaltet werden. Aus zweiterem Grund muss es gelingen die Brücke zwischen EAM/Development, Capabilities/DDD wie von Dir beschrieben zu bauen.
Was mir fehlt: Capabilities werden in Firmen höchst unterschiedlich verwendet. Ich sehe viele davon in meinen Beratungsprojekten und ich würde max. 10% als "gut" bezeichnen. Modellierungsrichtlinien für Capabilities existieren nicht - die Definition im BIZBOK und die Beispiele dort sind.... optimierbar. Ähnlich geht es mir nach Durchsicht der DDD Literatur. Die abstrakten Konzepte sind nachvollziehbar, konkrete Beispiele und Richtlinien für das Finden "guter" Contexts etc sind rar.
Für Capabilities erstellen wir gerade auf architectural-thinking.com Modellierungsrichtlinien - schau mal rein auf http://atf.architectural-thinking.com:8090/x/DYER und mache gerne dort Feedback.
Das Beispiel in Deinem Artikel hier ist gut, aber natürlich bräuchte es noch einiges Nachdenken um Modellierungsregeln für Contexts und das Mapping Capabilities->Contexts zu definieren. Falls Du/ihr Lust habt am Thema weiterzuarbeiten bitte melden!