Is there a Description of an Interface of SAF to Enterprise Frameworks?

[haarer]

From a mail to safsupport
"
Sehr geehrte SAF Arbeitsgruppe,

leider war mir aus Ihren Beschreibungen zum System Architecture Framework in github, die Schnittstelle zu denn Enterprise Frameworks wie NAF oder ADMBw nicht klar ersichtlich.

Ist hier im SAF ein separater Übergabepunkt von Informationen aus der Enterprise Architecture definiert oder ist diese über die Überschneidung durch die „Operational Domain SOV“ Ebene im Viewpoint Grid realisiert?
"

[haarer]

Die Anbindung von SAF an Enterprise Frameworks ist so gedacht, daß man die SAF Operational Domain wegläßt und statt der Relationen zur OD dann Relationen zu den analogen Elementen in UAF / NAF / ADMBw herstellt.
Da in Modellen der o.g. Enterprise Frameworks i.d.R. schon eine "Idee" der zu beschaffenden Systeme vorliegt, sollten diese auch über Relationen mit den entsprechenden konzeptionellen Systeme aus der FD in SAF verbunden werden.
Die Vorgehensweise und die Relationen wären noch im Detail zu beschreiben.

[parkaneric]

Aus SAF Sicht könnten folgende SAF Stereotypen zu operationellen Stereotypen in Enterprise Frameworks verknüpft werden: SAF_SystemUseCase (SFV01a), 2. SAF_SystemCapability (SFV02b), SAF_SystemRequirement (SFV06a).

Das würde bspw. für ADMBw@NAF folgende Traceability bedeuten:

1. SAF_SystemUseCase enables OperationalArchitecture (L2)
2. SAF_SystemCapability mapping to Capability (C1)
3. SAF_SystemRequirement derived from Requirement (R2)

Würde man in den Werkzeugen dann einem Element zwei Stereotypen (SAF + NAF) vergeben, um z.B. Verlinkungsregeln zu genügen?

[parkaneric]

So in etwa ... falls die Metatypen nicht passen (Use Case vs Class), muss wohl ein Platzhalter auf SAF Basis erstellt werden?

[haarer]

Ich würde ungern das Enterprise Architektur (EA)Modell verändern um darauf tracen zu können.
Auch wenn es eine einfache Möglichkeit ist.
Lieber würde ich den SAF Tracing Relationen erlauben, auch auf Elemente des EA Modells zu verweisen.
Also statt in einem UAF Modell den UAF::Capability elementen auch den SAF_OperationalCapability stereotypen zu verpassen, lieber mit SAF_SystemCapabilityMapping direkt auf UAF:: Capability Elemente verweisen.

Ich würde bei einem EA Modell allerdings eher erwarten, dass es bis auf die resource Ebene runter geht, und man aus der SAF FD auf die Resource Ebene tracen sollte.

Es wird da verschiedene Anwendungsfälle geben.

[odungern]

Aus meiner Perspektive: Bitte niemals einem Element zwei Stereotypen geben, weil automatische Modelltransformation in vielen Fällen unmöglich wird. Oskar

[parkaneric]

Danke für die Antworten.
Die Verlinkung funktioniert dann bspw. wie unten angezeigt. Im Enterprise Architect (ich nehme mal stark an der Anfragensteller hat den Sparx EA im Einsatz?) darf man dann nicht die SAF Views nutzen, damit man die SAF Elemente mit ADMBw Elementen verknüpfen kann, da in den Views die Verlinkungsregeln hinterlegt sind.

Generell gesprochen: brauchen wir irgendwo eine Art How-To?

[haarer]

Am 25. Oktober 2023 08:18:23 MESZ schrieb Eric Parkan ***@***.***>:

Danke für die Antworten. Die Verlinkung funktioniert dann bspw. wie unten angezeigt. Im Enterprise Architect (ich nehme mal stark an der Anfragensteller hat den Sparx EA im Einsatz?) darf man dann nicht die SAF Views nutzen, damit man die SAF Elemente mit ADMBw Elementen verknüpfen kann, da in den Views die Verlinkungsregeln hinterlegt sind. Generell gesprochen: brauchen wir irgendwo eine Art How-To?  -- Reply to this email directly or view it on GitHub: #31 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

SAF Viewpoints spezifizieren was in Views drin sein soll, damit die concerns erfüllt sind. Das heißt nicht, das man da nicht auch weitere Elemente rein tun darf. Ich könnte mir vorstellen, das man in eine n SAF View auch admbw Elemente aufnimmt und die concerns so erfüllt. Das (Luxus) Problem hierbei könnte sein, das 1. eine Metrik/Validierung die man für SAF gemacht hat, nicht erkennt das der VP OK ist, weil die Regeln die SAF fremden Elemente nicht kennen. 2. Viewpoints die von solchen hybrid befüllten VP abhängen, möglicherweise nicht funktionieren, weil dort nicht echte SAF Elemente drin sind. Beides sind Fragen die in erster Linie das Profildesign betreffen. Allerdings könnte man überlegen, ob man die Anbindung an EA Fw. auf eine formal sichere Basis stellt, indem man z.B. spezifiziert, welche stereotypen äquivalent sind. Btw. Admb:: OperationalArchitekture ist nicht äquivalent zum Usecase. Das ist eher wie der operational context.

…

-- Gruß, Alexander

[hugoormo]

Je nach dem was man als Enterprise Framework versteht. Z.B. im Fall TOGAF geht es um zwei unterschiedliche Anwendungsperspektive: bei SAF geht es um alle Arten von Systemen und bei TOGAF speziell um IT-Systeme.

[haarer]

SAF ist in dem Sinne kein EA Framework, weil es nicht primär für die Beschreibung von Enterprise Architekturen gedacht ist.
Es ist für die Systementwicklung gedacht. Es hat eine OD, um den Informationsbedarf der sonst typischerweise von EA Fw befriedigt wird, aus Sicht der Systementwicklung zu befriedigen.

EA Frameworks wie NAF,ADMBw, UAF, DoDAF, TOGAF sind nicht primär für die Systementwickung (IT oder andere) gedacht, sondern für die Beschreibung von Enterprises. Sie haben jeweils eine Ebene die technische Systeme beschreibt, mit dem Ziel ihre Beschaffung zu planen. (aber nicht mit dem Ziel sie mittels des Frameworks zu entwickeln)

Dass in der Praxis Auftraggeber hier oft über das Ziel hinaus schießen und versuchen "in die Systeme hinein zu designen"- traurig aber wahr.

[parkaneric]

Danke für die Rückmeldungen. Die im Paper vorgestellten Konzepte wurden initial untersucht. Folgende Einschätzung:

1. Wenn im Projektkontext zwei organisatorische Entitäten miteinander bspw. im AG/AN Verhältnis stehen, sollten die Enterprise Architektur (EA) und Systemarchitektur (SA) Modelle getrennt bleiben.
2. Eine Verlinkung zwischen EA-SA Elementen ist empfehlenswert. Enge oder lose Kopplung ist abhängig vom Projektkontext.
3. Neben einer Verlinkung von SA-Elementen auf EA-Elemente können auch zusätzliche aus Bottom-Up-Sicht SAF basierte Elemente hinzugefügt werden, welche inhaltlich nicht zum EA-Modell gehören (bspw. zusätzliche Operational Stories als alternative operationelle Anwendung)
4. Solution 1 aus „Linking UAF and SysML Models“ ist Out of Scope bzw. Ist auch nicht empfehlenswert.
5. Solution 2 aus nachtweilhaft, wenn im Projektkontext ein organisatorischer Bruch existiert (AG/AN) – Need-to-know-Prinzip wird verletzt.
6. Solution 3 ist zweckmäßig und sollte weiter untersucht werden.
7. Solution 4 ist häufig beobachtete Praxis in Projekten, folgt aber keinem übergeordneten Architekturziel und etabliert keine zusammenhängende EA-SA.