Anwendungsportfoliomanagement

Einführung

Application Portfolio Management (APM) schafft Transparenz darüber, welche Anwendungen existieren, wofür sie genutzt werden, wer sie besitzt, welche Daten sie verarbeiten und von welchen Technologien sie abhängen.

Dieses Pattern beschreibt einen pragmatischen Ansatz zum Anwendungsportfoliomanagement mit ArchiMate, abgestimmt auf das ADOIT Lean Profile for Enterprise Architecture.

Der Fokus liegt auf Klarheit, Vergleichbarkeit und analytischer Nutzbarkeit statt auf erschöpfenden technischen Details.

Designprinzip

Business First, Technology Second

Anwendungen werden aus Geschäftssicht und nicht aus technischer Sicht definiert.

Es gibt keine allgemein anerkannte Regel dafür, was eine Anwendung ausmacht. Dieses Pattern empfiehlt, Anwendungen aus Geschäftssicht und nicht aus technischer Sicht zu definieren.

Das Portfolio konzentriert sich auf den Wert, den eine Anwendung für das Geschäft liefert, und darauf, wer dafür verantwortlich ist. Implementierungsdetails werden separat in der Technologiearchitektur dokumentiert.

Diese Trennung verbessert die Portfolio-Transparenz, vermeidet unnötige technische Komplexität und unterstützt Anwendungsportfoliomanagement und Architekturplanung besser.

Was ist eine Anwendung?

Bevor im Anwendungsportfolio modelliert wird, muss klar sein, was als Anwendung gilt.

• In der Praxis werden viele Komponenten als „Anwendung“ bezeichnet, obwohl es sich um Folgendes handelt:

  • generische Plattformen,
  • gemeinsam genutzte Technologieprodukte,
  • oder Infrastrukturdienste.

Um Mehrdeutigkeit zu vermeiden und das Portfolio schlank zu halten, wird der folgende Fragebogen zur Anwendungsidentifikation verwendet.

Fragebogen zur Anwendungsidentifikation

Der Fragebogen hilft zu bestimmen, ob eine Komponente als Applikationskomponente oder eher als Systemsoftware modelliert werden sollte.

Die Fragen sind bewusst geschäftsorientiert und unabhängig von Implementierungsdetails.

1. Enthält die Komponente Geschäftslogik?

   • Unterstützt sie konkrete Geschäftsfunktionalität?

     Wenn eine Softwarekomponente in erster Linie dafür verantwortlich ist, Anwendungen zu hosten oder zu realisieren, anstatt Geschäftsfunktionalität bereitzustellen, sollte sie als Systemsoftware und nicht als Anwendung modelliert werden.

2. Kann die Komponente spezifischen Fähigkeiten zugeordnet werden?

   • Realisiert sie klar eine definierte Menge von Geschäftsfähigkeiten?

   • Ist ihr Beitrag zum Geschäft verständlich und erklärbar?

     Wenn die Zuordnung zu Fähigkeiten vage oder extrem breit ist, ist dies ein starker Hinweis darauf, dass die Komponente keine Anwendung ist.

3. Ist die Komponente geschäftsspezifisch oder allgemein einsetzbar?

   • Ist sie auf spezifische Geschäftsanforderungen zugeschnitten?

   • Oder bietet sie generische Funktionalität über viele Domänen hinweg?

     Allgemein einsetzbare Komponenten sind typischerweise Systemsoftware.

4. Hat die Komponente eine klare geschäftliche Verantwortung?

   • Gibt es einen identifizierbaren Anwendungsverantwortlichen?

     Wenn eine Softwarekomponente vollständig von der IT besessen und verwaltet wird und keine Geschäftsfunktionalität direkt bereitstellt, ist sie typischerweise Systemsoftware und gehört nicht in das Anwendungsportfolio.

5. Kann die Komponente unabhängig verwaltet werden?

   • Hat sie eine eigene Roadmap oder Investitionsplanung?

   • Kann sie unabhängig von anderer Software bereitgestellt, aktualisiert, ersetzt oder außer Betrieb genommen werden?

   • Würde sich ihr Lebenszyklus von dem der umgebenden Lösung unterscheiden?

     Wenn ein Teil einer Lösung mit eigenem Lebenszyklus verwaltet werden kann, ist er oft ein guter Kandidat für eine separate Applikationskomponente. Unabhängige Lebenszyklen sind ein starker Hinweis darauf, dass mehrere Applikationskomponenten statt einer einzelnen modelliert werden sollten.

6. Verarbeitet die Komponente Geschäftsdaten?

   • Erstellt, aktualisiert oder löscht sie Geschäftsobjekte?

   • Ist sie ein System of Record oder System of Engagement?

     Komponenten, die Daten nur transportieren oder technisch verarbeiten, sind in der Regel keine Anwendungen.

7. Würde das Entfernen der Komponente eine Geschäftsfähigkeit entfernen?

   Eine einfache, aber wirksame Kontrollfrage: Würde die Organisation bei Entfernung dieser Komponente eine Geschäftsfähigkeit verlieren — oder nur eine technische Plattform?

   • Verlust einer Geschäftsfähigkeit → Applikationskomponente
   • Nur technischer Ersatz erforderlich → Systemsoftware

Praktische Orientierung

Der Fragebogen ist ein Entscheidungshilfsmittel, keine starre Checkliste.

• In den meisten Fällen gilt:

  • Wenn alle oder die meisten Fragen mit Ja beantwortet werden können, sollte die Komponente als Applikationskomponente modelliert werden.
  • Wenn nur wenige zutreffen, handelt es sich typischerweise um Systemsoftware oder ein anderes technisches Element.

So bleibt das Anwendungsportfolio auf Geschäftswert fokussiert.

Modellierungsstruktur

• Applikationskomponenten - Kern des Portfolios

  Jede Anwendung wird als Applikationskomponente modelliert.

  • Applikationskomponenten repräsentieren:

    • geschäftliche Verantwortung,
    • funktionalen Umfang,
    • portfolio-relevante Planungseinheiten.

• Verknüpfung von Anwendungen mit Fähigkeiten

  Um zu verstehen, warum eine Anwendung existiert, wird sie mit Geschäftsfähigkeiten verknüpft.

  Applikationskomponente → Realisierung → Fähigkeit

• Technologieabhängigkeiten über Systemsoftware

  Zugrunde liegende Technologieprodukte werden als Systemsoftware modelliert.

  Systemsoftware → Dienen → Applikationskomponente

  • Dies macht sichtbar:

    • Technologieabhängigkeiten,
    • Standardplattformen,
    • Modernisierungsbeschränkungen.

• Informationsflüsse über Applikationsschnittstellen

  APIs und Schnittstellen werden explizit mit Applikationsschnittstellen modelliert.

  • Anwendungen komponieren die Schnittstellen, die sie bereitstellen.

    Applikationskomponente → Komposition → Applikationsschnittstelle

  • Anwendungen werden von den Schnittstellen bedient, die sie konsumieren.

    Applikationsschnittstelle → Dienen → Applikationskomponente

• Datennutzung über Geschäftsobjekte

  Um zu verstehen, welche Daten eine Anwendung verarbeitet, werden Geschäftsobjekte verwendet.

  Applikationskomponente → Zugriff → Geschäftsobjekt

• Geschäftliche Verantwortung über Geschäftsakteure

  Eigentum und Nutzungsverantwortung werden explizit modelliert.

  • Anwendungsverantwortlicher

    Applikationskomponente → Verantwortlich → Geschäftsakteur (Hinweis: ADOIT-spezifische Relation)

  • Benutzerorganisation / Kunde

    Applikationskomponente → Informiert → Geschäftsakteur (Hinweis: ADOIT-spezifische Relation)

Modellierungsmuster

Do / Don't - Anwendungsportfoliomodellierung

• Do

  • Anwendungen als Applikationskomponenten modellieren.
  • Anwendungen mit Fähigkeiten verknüpfen.
  • Anwendungen von Systemsoftware trennen.
  • Eigentum und Nutzung explizit machen.
  • Große Monolithen sinnvoll zerlegen.

• Don't

  • Keine generischen Plattformen als Anwendungen modellieren.
  • Keine Anwendungen ohne klare Verantwortlichkeit modellieren.
  • Anwendungen nicht direkt ohne Schnittstellen verbinden.
  • Monolithen nicht als unteilbare Einheiten behandeln.

Umfang und Zielsetzung

• Dieses Pattern unterstützt:

  • Anwendungsinventar und Transparenz,
  • Portfolioanalyse und Rationalisierung,
  • Modernisierungs- und Ersatzplanung,
  • Abstimmung zwischen Geschäfts-, Anwendungs- und Technologiesicht.

• Es ist nicht vorgesehen für:

  • den Ersatz technischer Systemdokumentation,
  • die Modellierung von Deployment- oder Laufzeitarchitektur,
  • die Beschreibung von Anwendungsinterna.