EA-CAPABILITY-MODEL-001

Enterprise-Capability-Model#

Zweck#

Das Enterprise ⌘CapabilityEine Capability beschreibt ein dauerhaft benötigtes fachliches Leistungsvermögen, nicht dessen technische Umsetzung. Model beschreibt Capability als universelles ⌘MeaningBedeutung beschreibt den fachlichen Sinn eines Elements und seine Relevanz für Menschen und Organisationen. und als semantischen Übergang vom Begründungsraum zur Realisierung. Es übernimmt die tragfähige Theorie des historischen CON-014 – Capability Model, ohne solution-spezifische Kataloge oder technische Implementierungsentscheidungen nach Enterprise zu verschieben.

Definition#

Eine Capability ist ein Meaning, das ein fachlich bedeutsames Leistungsvermögen beschreibt.

Eine Capability beschreibt, was grundsätzlich möglich sein soll und welches Leistungsversprechen relevant ist. Sie gibt weder eine konkrete technische noch eine organisatorische oder prozessuale Realisierung vor.

Capability ist insbesondere:

• kein ⌘Building BlockEin Building Block ist ein abgegrenzter Baustein mit stabiler Verantwortung zur Realisierung von Capabilities.,
• keine Component,
• kein ⌘ServiceEin Service ist eine abgegrenzte bereitgestellte technische oder fachliche Leistung mit klarer Verantwortung.,
• keine API,
• keine Rolle,
• keine Permission,
• kein Deployment-Objekt.

Artifacts können zu einer Capability beitragen oder sie gemeinsam realisieren. Sie werden dadurch nicht selbst zu dieser Capability.

Fachliche Herkunft#

Jede Capability muss aus mindestens einem Meaning ableitbar sein. Dieses Meaning muss nicht zwingend eine ausdrücklich dokumentierte ⌘VisionEine Vision beschreibt eine langfristig gewünschte Wirkung und gibt der Weiterentwicklung eine gemeinsame Richtung. sein.

Mögliche fachliche Quellen sind unter anderem:

• Vision,
• Requirement,
• Principle,
• Decision,
• Risk,
• Gap,
• Learning,
• Strategy,
• gesetzliche oder regulatorische Vorgabe,
• fachlicher Zweck.

Meaning bildet dabei kein starres Stufenmodell, sondern ein Begründungsnetz.

Meaning-zu-Capability-Relationships#

Eine generische ⌘BeziehungEine Beziehung beschreibt eine nachvollziehbare Verbindung zwischen Bedeutungen, Artefakten und ihrem Kontext. wie relates-to reicht für die Begründung einer Capability nicht aus. Mindestens folgende Bedeutungen müssen unterscheidbar sein:

Die Relationship trägt den konkreten Zusammenhang. Er darf nicht in unstrukturiertem Begleittext verborgen werden.

Capability-zu-Capability-Relationships#

Capabilities können untereinander mindestens:

• specializes – ein allgemeineres Leistungsvermögen spezialisieren,
• depends-on – ein anderes Leistungsvermögen voraussetzen,
• consists-of – fachlich aus mehreren Teilfähigkeiten bestehen.

Eine Spezialisierung besitzt kleineren und konkreteren Scope, ohne die Bedeutung der übergeordneten Capability neu zu definieren.

Übergang zur Realisierung#

Capabilities entstehen häufig durch das Zusammenspiel mehrerer Artifacts. Viele-zu-viele ist der Normalfall.

Meaning
                    justifies / requires / constrains
                Capability
                    is realized by
                Artifacts and Relationships

Für die Verbindung eines einzelnen Artifacts zur Capability ist contributes-to regelmäßig präziser als implements. In Gegenrichtung kann is-realized-by verwendet werden.

Ownership ist kein Bestandteil der Capability-Identität. Verantwortung wird durch eine Relationship ausgedrückt, beispielsweise responsible-for.

Scope und Spezialisierung#

Capability ist auf mehreren Architekturebenen dieselbe semantische Kategorie mit unterschiedlichem Scope:

Enterprise Capability
                    specializes into
                Solution Capability
                    specializes into
                Design-near Capability

Enterprise Capabilities sind organisations- und lösungsunabhängig. Solutions dürfen sie für ihren Lösungsraum spezialisieren. Design darf sie weiter konkretisieren. Keine Ebene darf die übergeordnete Bedeutung stillschweigend umdefinieren.

Konsistenzregeln#

1. Jede Capability besitzt nachvollziehbare fachliche ⌘HerkunftProvenienz beschreibt die nachvollziehbare Herkunft eines Wissenselements, einer Aussage oder einer abgeleiteten Darstellung..
2. Jede Capability ist als Meaning modelliert.
3. Jede Realisierung ist über typisierte Relationships nachvollziehbar.
4. Viele Artifacts dürfen gemeinsam zu einer Capability beitragen.
5. Ein ⌘ArtifactEin Artefakt ist jede eindeutig identifizierbare fachliche, technische, organisatorische oder reale Einheit, die in der Engineering-Landschaft modelliert wird. darf zu mehreren Capabilities beitragen.
6. Capability-Begründung ist keine Ownership.
7. Capability Coverage, Reifegrad, KPI und Runtime-Verfügbarkeit sind eigene Bewertungsmodelle und nicht Teil der Capability-Identität.
8. Eine neue Capability entsteht nur bei einem eigenständigen, fachlich bewertbaren Leistungsvermögen.

Abgrenzung#

Dieses Modell definiert keine solution-spezifischen Capability-IDs, keine MVP-Auswahl, keine technische Realisierung und kein Deployment-Mapping. Solche Materialisierungen gehören in Vision-Materialisierungen, Solution Architecture oder Design.