HOPEX Handbuch Technologie-Managementfeedback

1. Zweck und Geltungsbereichfeedback

Dieses Handbuch beschreibt das systematische Management von Technologie-Standards und IT-Lösungen in HOPEX V6. Es regelt die Pflege von Technologie-Lifecycles basierend auf End-of-Life-Daten aus IT-Pedia und definiert die Governance-Prozesse für Soll- und Ist-Technologien.

Das Dokument regelt:

• Technologie-Lifecycle-Management mit automatisierter EoL-Integration
• Standardisierungsphasen und Unternehmensnormen für Technologieentscheidungen
• Unterscheidung zwischen Soll-Technologien (Anwendungsebene) und Ist-Technologien (Installationsebene)
• Reporting und Governance-Prozesse für AppOwner und Technologie-Portfolio-Owner
• Compliance-Management bei Ausnahme- und Verbotsstatus

Geltungsbereich: Alle Technologie-Entscheidungen, Standardisierungsprozesse und IT-Lösungsbewertungen in HOPEX V6.

2. Technologie-Lifecycle-Modellfeedback

2.1 Lifecycle-Phasenfeedback

Das Technologie-Lifecycle-Modell definiert fünf Standardphasen, die den Lebenszyklus einer Technologie von der ersten Evaluierung bis zur Ablösung abbilden:

Phase	Beschreibung	Ziel	Dauer
Erprobung	Technologie wird in Pilotprojekten getestet und evaluiert	Machbarkeit und Eignung prüfen	6-12 Monate
Einführung	Schrittweise Einführung in produktive Umgebungen	Erfahrungen sammeln, Kompetenzen aufbauen	12-18 Monate
Standard	Technologie ist etabliert und wird für neue Projekte empfohlen	Standardisierung und Skalierung	3-7 Jahre
Ausnahme	Technologie wird nur noch in begründeten Ausnahmefällen eingesetzt	Kontrollierte Nutzung, Migrationsvorbereitung	1-2 Jahre
Verboten	Technologie darf nicht mehr verwendet werden	Vollständige Ablösung	Sofortig

2.2 Unternehmensnorm-Ausprägungenfeedback

Zusätzlich zu den Standardphasen definiert die Unternehmensnorm eine erweiterte Kategorisierung:

Ausprägung	Definition	Handlungsempfehlung
Zurückgestellt	Technologie wird zurzeit nicht weiterverfolgt	Monitoring fortsetzen, erneute Bewertung in 12 Monaten
Erprobung	Aktive Pilotierung und Evaluierung	Ressourcen für Tests bereitstellen
Einführung	Kontrollierte produktive Nutzung	Schulungen und Kompetenzen aufbauen
Standard	Empfohlene Technologie für neue Projekte	Bevorzugte Verwendung in allen Neuprojekten
Ausnahme	Nur bei fundierten Geschäftsgründen	Begründung und Genehmigung erforderlich
Verboten	Keine Verwendung gestattet	Sofortige Migrationspläne erstellen

3. EoL-Integration mit IT-Pediafeedback

3.1 Datenquelle und Automatisierungfeedback

HOPEX V6 integriert automatisch End-of-Life-Daten aus IT-Pedia, um technologie-bezogene Entscheidungen datengestützt zu treffen.

Integration-Pipeline:

IT-Pedia API → HOPEX Import Service → Technologie-Objekt (EoL-Attribut) → Lifecycle-Status Aktualisierung

3.2 EoL-basierte Lifecycle-Übergängefeedback

EoL-Status in IT-Pedia	Verbleibende Zeit	Automatischer HOPEX-Status	Handlungsauslösung
Aktuell	> 24 Monate	Standard (unverändert)	-
Bald auslaufend	12-24 Monate	Ausnahme (automatisch)	Migration-Roadmap erstellen
Kurz vor EoL	3-12 Monate	Verboten (automatisch)	Sofortige Migrationsprojekte
EoL erreicht	< 3 Monate	Verboten	Notfallmigration, Ausnahmen nur mit CTO-Genehmigung

3.3 Konfiguration in HOPEX V6feedback

Setup-Schritte:

1. IT-Pedia-Connector aktivieren: Administration > Data Integration > IT-Pedia Connector
2. Mapping konfigurieren: Technology Objects > Attribute Mapping > EoL Date Field
3. Automatische Rules einrichten: Governance > Lifecycle Rules > EoL-based Status Transition
4. Notification Setup: Alerts > Technology EoL Warnings → Portfolio Owner

4. Soll- vs. Ist-Technologienfeedback

4.1 Technologie-Hierarchie in HOPEXfeedback

Enterprise
├── Technologie-Portfolio
    ├── Soll-Technologien (Application Level)
    │   ├── Anwendung A → verwendet Technologie X (Soll)
    │   └── Anwendung B → verwendet Technologie Y (Soll)
    └── Ist-Technologien (Infrastructure Level)
        ├── Server 1 → Installation von Technologie X v2.1 (Ist)
        ├── Server 2 → Installation von Technologie X v1.9 (Ist, veraltet)
        └── Server 3 → Installation von Technologie Z (Ist, nicht Soll-konform)

4.2 Soll-Technologien (Application Level)feedback

Definition: Technologien, die für Anwendungen/IT-Lösungen als Standard definiert sind.

HOPEX-Modellierung:

• Objekt: Application → Technology (Relation: "uses standardized technology")
• Attribut: Technology.StandardizationStatus = {Standard, Einführung, Erprobung, Ausnahme, Verboten}
• Governance: Durch Solution Architect und Technologie-Portfolio-Owner festgelegt

4.3 Ist-Technologien (Infrastructure Level)feedback

Definition: Konkret installierte Technologie-Versionen auf physischen/virtuellen Servern.

HOPEX-Modellierung:

• Objekt: Server → Deployed Application → Technology (Relation: "runs on technology version")
• Attribut: Technology.Version, Technology.InstallationDate, Technology.EoL-Date
• Governance: Durch Operations und Infrastructure-Team verwaltet

5. Reporting und Governancefeedback

5.1 AppOwner-Report: Non-Standard Technologie-Nutzungfeedback

Zweck: Zeigt dem Application Owner alle Installationen seiner Anwendungen, die nicht den Soll-Technologien entsprechen.

Report-Struktur:

Application Owner: [Name]
================================

Anwendung: Customer Portal
┌─────────────────────────────────────────────────────────────┐
│ Server: PROD-WEB-01                                         │
│ ├── Java Runtime v8.0.231 (Status: Verboten, EoL: 2023)   │
│ ├── Solr v7.1 (Status: Ausnahme, Standard wäre v9.0)      │
│ └── ❌ 2 Non-Standard Technologies detected                │
└─────────────────────────────────────────────────────────────┘

Anwendung: Document Management
┌─────────────────────────────────────────────────────────────┐
│ Server: PROD-DOC-02                                         │
│ ├── .NET Framework v4.8 (Status: Standard ✓)              │
│ ├── SQL Server 2019 (Status: Standard ✓)                  │
│ └── ✅ All technologies compliant                          │
└─────────────────────────────────────────────────────────────┘

Action Required:
- Java Runtime v8.0: Migration to OpenJDK 17 required by Q3/2024
- Solr v7.1: Upgrade to v9.0 planned in next maintenance window

HOPEX-Konfiguration:

Report: ApplicationOwner_TechCompliance
DataSource: 
  - Applications (Owner filter)
  - Deployed Applications 
  - Server
  - Technology (with EoL and Standard status)
Filter: 
  - "Technology.Status IN ('Ausnahme', 'Verboten') OR Technology.Version != Soll_Technology.Version"

5.2 Portfolio-Owner-Report: Ausnahme- und Verboten-Status Kontrollefeedback

Zweck: Dem Technologie-Portfolio-Owner Überblick über alle Anwendungen (Soll) und Server (Ist) geben, die Technologien im Status "Ausnahme" oder "Verboten" verwenden.

Report-Struktur:

Technologie-Portfolio Owner: [Name]
====================================

Technologie: Java Runtime v8.0 (Status: Verboten, EoL: 2023-12-31)
┌─────────────────────────────────────────────────────────────┐
│ SOLL-Anwendungen (noch Standard definiert):                │
│ ├── Customer Portal (Owner: Max Mustermann)                │
│ ├── Legacy Billing System (Owner: Anna Schmidt)           │
│ └── 📊 2 Applications still using as standard             │
├─────────────────────────────────────────────────────────────┤
│ IST-Installationen (Server):                              │
│ ├── PROD-WEB-01 (Customer Portal v2.1)                   │
│ ├── PROD-BILL-01 (Billing System v3.2)                   │
│ ├── TEST-ENV-05 (Development Environment)                 │
│ └── 📊 3 Active installations detected                    │
└─────────────────────────────────────────────────────────────┘

Action Items:
- Customer Portal: Migration project required (Priority: HIGH)
- Legacy Billing: Decommissioning scheduled Q4/2024 (Priority: MEDIUM)
- Test Environment: Can be updated immediately (Priority: LOW)

HOPEX-Governance-Dashboard:

• Filter: Technology.Status = 'Ausnahme' OR 'Verboten'
• Soll-View: Applications → uses Technology (with non-standard status)
• Ist-View: Server → Deployed Applications → Technology (with non-standard status)
• Actions: Automatic task creation for responsible owners

6. Governance-Prozessefeedback

6.1 Technologie-Standardisierungsprozessfeedback

Phase	Aktivität	Verantwortlich	Dauer	Deliverable
Antrag	Technology Request einreichen	Requestor	1 Woche	Technology Assessment Request
Evaluierung	Technische und strategische Bewertung	Portfolio Owner + Architecture Board	4 Wochen	Technology Evaluation Report
Pilotierung	Proof of Concept in Testumgebung	Solution Architect + Dev Team	8-12 Wochen	Pilot Results + Recommendation
Standard-Entscheidung	Aufnahme in Technologie-Katalog	Architecture Review Board	2 Wochen	Technology Standard Decision
Rollout	Kommunikation und Schulung	Portfolio Owner	4 Wochen	Rollout Plan

6.2 Ausnahme-Managementfeedback

Ausnahme-Antragsprozess:

1. Antrag: AppOwner reicht begründeten Ausnahme-Antrag ein
2. Bewertung: Portfolio Owner prüft Business Case und technische Risiken
3. Entscheidung: Architecture Review Board entscheidet über Genehmigung
4. Monitoring: Regelmäßige Reviews der genehmigten Ausnahmen
5. Exit-Strategie: Definierter Migrationspfad für Ausnahme-Technologien

Genehmigungskriterien:

• Business Criticality: Geschäftskritische Anforderungen ohne Alternative
• Technical Constraints: Technische Zwänge oder Legacy-Abhängigkeiten
• Timeline: Befristete Ausnahme mit definiertem Ende-Datum
• Risk Mitigation: Ausreichende Sicherheits- und Compliance-Maßnahmen

6.3 Verbots-Managementfeedback

Sofortmaßnahmen bei "Verboten"-Status:

1. Immediate Stop: Keine neuen Projekte mit der Technologie
2. Assessment: Bestandsaufnahme aller Anwendungen und Installationen
3. Migration Plan: 90-Tage-Plan für kritische Systeme, 180-Tage-Plan für andere
4. Risk Management: Notfall-Support und Sicherheits-Patches organisieren
5. Executive Reporting: Wöchentliche Status-Reports an CTO

7. HOPEX V6 Implementierungfeedback

7.1 Objekt-Konfigurationfeedback

Technologie-Objekt erweitern:

Technology:
  Standard_Attributes:
    - Name
    - Version
    - Vendor
    - Category
  Extended_Attributes:
    - StandardizationStatus: [Zurückgestellt, Erprobung, Einführung, Standard, Ausnahme, Verboten]
    - EoL_Date: Date (from IT-Pedia)
    - LastEoL_Check: Date
    - Portfolio_Owner: Person
    - Business_Criticality: [Low, Medium, High, Critical]
  Relationships:
    - used_by_Application: Application
    - installed_on_Server: Server
    - governed_by: Technology_Portfolio_Owner

7.2 Automation Rulesfeedback

EoL-basierte Status-Updates:

# HOPEX Automation Script
def update_technology_status_based_on_eol():
    for technology in Technology.objects.all():
        days_to_eol = calculate_days_to_eol(technology.eol_date)
        
        if days_to_eol <= 90:  # 3 Monate
            technology.status = 'Verboten'
            create_urgent_migration_task(technology)
        elif days_to_eol <= 365:  # 12 Monate
            technology.status = 'Ausnahme' 
            create_migration_roadmap(technology)
        
        technology.save()
        notify_portfolio_owner(technology)

7.3 Dashboard-Konfigurationfeedback

Technologie-Portfolio-Dashboard:

• Status Distribution: Pie Chart der Technologie-Status
• EoL Timeline: Gantt Chart mit EoL-Daten und Migrationsplänen
• Compliance Heatmap: Matrix Anwendungen vs. Standard-Technologien
• Action Items: Liste offener Migrationen und Ausnahme-Reviews

8. Best Practicesfeedback

8.1 Technologie-Lebenszyklusperiodenfeedback

• Evaluationszeit einplanen: Mindestens 3 Monate vor produktivem Einsatz
• Graduelle Migration: Phased Rollout statt Big Bang-Ansätze
• Backward Compatibility: Sicherstellen bei Major Version Updates
• Documentation First: Vollständige Dokumentation vor Standardisierung

8.2 Stakeholder-Managementfeedback

• Early Involvement: AppOwner in Standardisierungsentscheidungen einbeziehen
• Regular Communication: Quartalsweise Technology Briefings
• Clear Escalation: Definierte Eskalationspfade bei Konflikten
• Training Programs: Kontinuierliche Weiterbildung zu neuen Standards

8.3 Monitoring und Alertingfeedback

• Proactive EoL Management: 18 Monate vor EoL mit Planung beginnen
• Automated Compliance Checks: Wöchentliche Reports über Standard-Abweichungen
• Exception Tracking: Monatliche Reviews aller Ausnahme-Genehmigungen
• Risk Assessment: Quartalsweise Bewertung aller "Verboten"-Technologien

9. Integration mit TOGAF ADMfeedback

Dieses Technologie-Management-Framework unterstützt alle TOGAF ADM-Phasen:

Phase A: Architecture Visionfeedback

• Technologie-Prinzipien und Standards definieren
• Portfolio-Owner-Mandats festlegen

Phase D: Technology Architecturefeedback

• Soll-Technologien pro Anwendung spezifizieren
• EoL-Roadmaps in Architecture Vision integrieren

Phase E: Opportunities & Solutionsfeedback

• Migrationsprojekte für Ausnahme/Verboten-Technologien identifizieren
• Business Cases für Technologie-Upgrades entwickeln

Phase F: Migration Planningfeedback

• Detaillierte Migrationspläne basierend auf EoL-Daten
• Abhängigkeiten zwischen Technologie-Updates berücksichtigen

Phase H: Architecture Change Managementfeedback

• Kontinuierliche Überwachung der Technologie-Lifecycle
• Anpassung der Standards bei neuen Technologien

---

Dieses Handbuch wird vierteljährlich überprüft und bei Bedarf aktualisiert. Für Fragen und Anregungen wenden Sie sich an den Technologie-Portfolio-Owner.