Lösungen (ITIL, COBIT, agile Methoden, Wasserfall etc.). Wichtig ist, dass das Service-Release die Businesse-Erwartungen erfüllt und den Warranty-Anforderungen (Sicherheit, Verfügbarkeit, Performance etc.) entspricht.
Abb. 2–27 Aktivitäten der IT Value Chain Requirement to Deploy (in Anlehnung an IT4IT)
Request to Fulfill (R2F):Über diesen Wertstrom soll ein nachfrageorientiertes Engagement-Modell über einen integrierten, zielgruppengerechten Service-Katalog angeboten werden, das die IT im Sinne eines Service-Brokers bereitstellt. Zahlreiche Leistungen werden von unterschiedlichen externen Lieferanten für Produkte und Services integriert, was einer Multi-Sourcing-Steuerung bedarf.Die Services werden nach Anforderung für die Anwender zur Verfügung gestellt, und die Service-Nutzung wird gemanagt. Dazu gehören auch die Informationsbereitstellung (also Knowledge Management) zu den Services und die spätere Verrechnung der Service-Kosten auf Basis der gemessenen Service-Nutzung.Die Einträge im Service-Katalog sollten wertschöpfungsorientierte Services darstellen, die auf Service-Modellen beruhen, instanziiert und angeboten werden können. Sowohl die Anforderung über den Katalog (z.B. über ein Self-Service-Portal) als auch die Bereitstellung sollten konsistent erfolgen und so weit wie möglich automatisiert werden. Wichtig ist, dass der angeforderte und genutzte Service den Anforderungen entspricht.
Detect to Correct (D2C):Im Rahmen dieses Wertstroms erfolgen in der Produktion u.a. die Handhabung von Events, Störungen, Problemen, Changes sowie das Monitoring und das Configuration Management. Hier geht es auch um ihr Zusammenspiel im Betrieb und die Berücksichtigung der verschiedenen Stakeholder, um Probleme im Betrieb zu lösen. Zu den Stakeholdern gehören auch die verschiedenen Drittanbieter in einer Multi-Sourcing-Umgebung mit den unterschiedlichen Wechselwirkungen und Abhängigkeiten, die im Betrieb über Services, Technologien und Prozesse beteiligt sind.Im Fokus steht die Sicherung des kontinuierlichen Betriebs der IT Services für das Business.Der angestrebte Nutzen liegt in der Vermeidung von Betriebsunterbrechungen im Sinne einer Risiko-Reduzierung, der rechtzeitigen Entdeckung, Priorisierung und Lösung von Problemen zusammen mit den beteiligten Parteien. Auch die kontinuierliche Verbesserung hat einen Platz.
Die Referenzarchitektur (siehe Abb. 2–28) erlaubt es, die IT als »Business Innovation Center« zu positionieren und einen End-to-End-Business-Service-Lebenszyklus für bestehende und zukünftige Rahmenbedingungen zu bilden. Die Referenzarchitektur bildet die Aktivitäten der IT Value Chain auf vier Elemente ab: Service Model, Information Model, Functional Model und Integration Model. Dies macht den sogenannten präskriptiven Charakter des Standards aus.
Abb. 2–28IT4IT Reference Architecture – Level 1 in Verbindung mit dem IT4IT Service Model (IT4IT). Der Übersicht halber verweisen nicht alle Service-Status des Modells auf die Referenzarchitektur.
Die wesentlichen Informationen des IT-Management-Ökosystems sind in den Modellen der Referenzarchitektur abgebildet und beschrieben. Sie liefern konkrete und detaillierte Angaben, wie die Integration der einzelnen Funktionen und Daten zu erfolgen hat. Jeder IT Value Stream nimmt Bezug auf mindestens ein Element des Service Model und die jeweilige Konstellation der Datenobjekte (Information Model) und funktionalen Komponenten (Functional Model, »Building Blocks«), die dies unterstützen. Jeder Value Stream nutzt bzw. erzeugt Daten. Das Information Model berücksichtigt die Datenobjekte und ihre Beziehungen.
IT4IT beschreibt unterschiedliche Ebenen, die sich von der Referenzarchitektur der Ebene 1 über die Ebene 2 der einzelnen Value Streams erstreckt. Jede funktionale Komponente der Ebene 2 wird auch noch einmal mit ihren Eingangs- und Ausgangsobjekten separat dargestellt. Die Beschreibung reicht bis hin zu einer herstellerunabhängigen Architektur, die über eine andere Notation mit Hilfe von ArchiMate und UML die Datenobjekte und ihre Attribute auf einer tieferen Detailebene beschreiben (Level 3: Vendor-independent Architecture). Die Beschreibung von IT4IT endet mit Ebene 3.
Die darunterliegenden Ebenen stellen weitere spezifische Details bereit und eignen sich für die Entwicklung von Implementierungsplänen oder Produkt-Design (Level 4: Vendor-specific Refinement Architecture und Level 5: Solution Architecture); sie unterliegen nicht der Steuerung von IT4IT. Ebene 4 kann von den Herstellern herstellerspezifisch ergänzt werden. Eine beispielhafte und tatsächlich eingesetzte Architektur wird in Ebene 5 als Lösungsarchitektur beschrieben, IT4IT gibt hier allerdings nur noch die Notation vor.
Mit der Veröffentlichung »IT4IT for Managing the Business of IT – A Management Guide« stellt die Open Group einen Leitfaden für die Implementierung von IT4IT im Sinne einer Transition zur Verfügung.
Eine IT4IT-Personenzertifizierung wird über die von der Open Group akkreditierten Schulungsunternehmen angeboten. Die Lernziele der IT4IT-Foundation-Zertifizierung lauten: Wissen und Verständnis der Terminologie, Struktur und Konzepte der IT4IT-Referenzarchitektur sowie der grundlegenden Prinzipien der Referenzarchitektur und der IT Value Chain.
2.3.8Agile Skalierungsframeworks
Frameworks für die gesamte Organisation existieren mittlerweile auch für agile Ansätze in der Softwareentwicklung. Sogenannte agile Skalierungsframeworks unterstützen Organisationen dabei, agile Methoden organisationsweit zu nutzen und nicht auf einzelne Entwickler-Teams zu beschränken. Sie sind in der Regel auf Basis von Scrum oder weiteren agilen Methoden entwickelt worden. Aktuell häufig genannte Skalierungsframeworks in der Praxis sind Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), SCRUM@Scale von Jeff Sutherland, Nexus und Disciplined Agile Delivery (DAD) sowie ScALeD Principles, Spotify Engineering Culture oder Agile Scaling Cycle weniger als Framework denn als Vorgehen zur Entwicklung einer agilen Organisationsform für die jeweilige Umgebung.
Ich möchte an dieser Stelle beispielhaft die beiden Frameworks SAFe und LESS vorstellen.
2.3.8.1SAFe
Das Scaled Agile Framework (SAFe, https://www.scaledagileframework.com/) ist auf die agile Entwicklung von Software ausgelegt, wurde 2012 veröffentlicht, weiterentwickelt und liegt aktuell in der Version 4.6 vor (siehe Abb. 2–29).1 SAFe ist – in Abgrenzung zu Scrum – nicht für den Einsatz in einzelnen kleinen Teams gedacht, sondern soll große Organisationen dabei unterstützen, agiles Arbeiten nach »Lean«-Grundsätzen auf Team-, Programm- und Portfolio-Ebene zu etablieren.
Abb. 2–29 SAFe Big Picture (aus: SAFe 4.6 Introduction, A Scaled Agile, Inc. White Paper/November 2018)
Das Framework bietet für den Einsatz unter unterschiedlich komplexen Bedingungen vier verschiedene Konfigurationen u.a. mit Rollen, Artefakten und Aktivitäten (siehe Abb. 2–30). Diese bilden eine umfangreiche und detaillierte Unterstützung in unterschiedlichen Medienformaten mit Ansätzen aus Scrum, Kanban und Extreme Programming kombiniert mit Lean Thinking sowie Prinzipien zum Lean Product Development (aus
