Überblick im Technologie-Dschungel: Technologie-Management bei OPITZ CONSULTING

War vor 10 Jahren die Welt für ein mittelständisches IT-Beratungshaus oder eine IT-Abteilung noch relativ überschaubar, so ist die Anzahl der Technologien, mit denen man in IT-Projekten heute in Berührung kommt, sehr stark angewachsen.

Wir wollen euch in diesem Blog-Post einmal einen Einblick geben, wie wir bei OC unser Technologieportfolio managen.

Autoren dieses Beitrags:
Richard Attermeyer (Chief Architect)
Sven Bernhardt (Chief Architect)
Jens Bleiholder (Chief Architect)
Torsten Winterberg (Director Technology)

Wichtig für uns ist, dass die Tätigkeiten von Projektmitarbeitenden, Accountteams, Zentralbereichen und Management optimal ineinandergreifen, damit wir die gewohnt hohe OC-Qualität beim Kunden dauerhaft und über die ganze Mannschaft leisten können.

Dazu haben wir einen schlanken Technologie-Management-Prozess festgelegt, der durch verschiedene Systeme unterstützt wird:

• TLMT: The Lifecycle Management Tool. Unser Tech-Radar.
• Blueboard: Verwaltung von Tickets zur Durchführung einer Technologieevaluierung.
• OCEH: OC Engineering Handbook. Dokumentation der Technologiebewertungen, Standardarchitekturen und Beratungshandreichungen.
• Oscar: Skillbewertung durch die Mitarbeiter.
• Susy: Vorschlagswesen für Oscar und TLMT zur Erfassung neuer Tech-Items (Funktion in TLMT).

Das Blueboard ist als Jira-Projekt realisiert, die anderen Systeme sind kleine Anwendungen.

Über diesen Systeme liegt ein schlanker Prozess, welcher vom Corporate Development Team und dem OC-Architekturboard bespielt wird.

Abb. 1: Technologie-Management: Zusammenspiel der Werkzeuge

TLMT

Das „The Lifecycle Management Tool“ (kurz TLMT) nutzen wir bei OPITZ CONSULTING, um uns die Vielfalt der Werkzeuge, Technologien und Methoden am IT-Markt zu erschließen und auf die für uns strategischen Technologien zu fokussieren.

Gemäß unserer Strategie #zukunftswirksam, hilft uns das TLMT dabei, proaktiv zu bewerten, welche Technologien unseren Leitthemen (Modern, Automatisiert, Integriert, Sicher) entsprechen, worauf wir unsere Kompetenzen perspektivisch ausrichten sollten und welche Technologien wir unseren Kunden empfehlen (wenn wir die freie Wahl haben).

Zusätzlich erhalten wir durch die Verknüpfung zu unserem Skill Management Tool OSCAR eine einfache Übersicht über die Anzahl unserer Mitarbeiter und deren Tiefe der Qualifizierung pro Technologie. So können wir Rückschlüsse für unsere Wissensdomänen zur Personalentwicklung ziehen, sowie einschätzen, wie gut Kundenanfragen zu unserem Knowhow passen.

Kurzum, das TLMT schafft Transparenz darüber:

1. Was wir für Technologien, Methoden und Standards einsetzen
2. Wie gut wir die Technologien, Methoden und Standards beherrschen
3. Worauf wir uns in der Weiterbildung fokussieren
4. Wie gut Technologien, Methoden und Standards in unser Portfolio passen

Blueboard

Blueboard steht für eine Innovationsmethode, die Transparenz und Nachhaltigkeit im Ideen-Management fördern soll. Wir haben uns daran angelehnt und unser eigenes, elektronisches Blueboard gebaut. Hierfür haben wir die Möglichkeiten von Jira genutzt, um Ideen und deren Status visualisieren zu können. Ziel ist es, Transparenz über Aktivitäten bei OC zu erzeugen, um nicht Dinge doppelt zu machen und auch um zu wissen, wer sich gerade mit welchem Thema beschäftigt.

Des Weiteren ist das Blueboard ein Hilfsmittel bei der Fokussierung und Bündelung unserer Schlagkraft. Klar ist, dass wir nicht alle Themen gleichzeitig bearbeiten können. Doch welche Themen sind gerade wichtig für die Entwicklung von OC und was wollen und wünschen die Kunden? In verschiedenen Gremien werden die einzelnen Ideen diskutiert und die Auswirkungen auf den Markt und OC betrachtet. Darauf basierend wird dann entschieden, was mit der Idee passieren soll, also geht sie in die Umsetzung, wird sie erstmal zurückgestellt oder liegt sie nicht im Fokus von OC.

Alle Mitarbeiter sind aktiv aufgerufen Ideen, die unsere Kunden, OC oder sich selbst weiterbringen, ins Blueboard einzutragen.

Je mehr Informationen initial gefüllt sind, umso einfacher ist es für das passende Gremium, die Entscheidung zu treffen. Sofern Kollegen gerade nicht voll durch Projekte ausgelastet sind, finden sie hier Ideen, bei denen sie unterstützen können.

Die einzelnen Bereiche des Blueboard sind über Swimlanes abgebildet. Hinter jeder Swimlane steht ein eigenes Gremium, das sich um die Tickets kümmert:

• F&E: Technologie-Themen und Technologie-Evaluierungen
• (Technologie-) Partnerschaften
• Business Development (neue Themen mit Markteintrittsziel)
• (Technologie-) Communities
• Interne Systeme
• Delivery Process & Knowledge (Optimierung und Weiterbildung)
• Allgemeine Verbesserungsvorschläge

OCEH

Das OC Engineering Handbuch (OCEH) entwickelt sich zu DER Wissensquelle für alle OC’ler. Damit OC die in der Strategie definierten Ziele erreicht, werden im OCEH die verschiedenen Bereiche adressiert, die für die Erstellung und den Betrieb von Lösungen notwendig sind.

Die Art der Leistungserbringung beim Kunden definiert den notwendigen „OC-Way“, also die OC-bewährte Herangehensweise.

Und dies verstehen wir unter dem „OC-Way“:

• Wie wir das Problem des Kunden analysieren (Auftragsklärung, Business Problem Understanding, Early Solution Design)
• Wie wir eine Lösung entwerfen (Lösungsarchitektur + Design)
• Wie wir Teile einer Lösung umsetzen (Service Design und Development)
• Wie wir eine Lösung produzieren (Local Development, Continuous Integration and Deployment, Staging, Test und Verifikation)
• Wie wir eine Lösung übergeben (Service Transition)
• Wie wir eine Lösung betreiben (Operations und Support)
• Wie wir eine Lösung weiterentwickeln (Application Maintenance)

Damit ist das OCEH in folgenden Situationen hilfreich:

• Eine Begründung für einen bestimmten Technologiestatus finden (über die zugehörige Technologieevaluierung)
• Beantwortung der Frage, welche Technologien bei der Erstellung einer Lösungsarchitektur verwendet werden sollten
• Welche Erfahrungen haben wir bei OC mit einer bestimmten Technologie?
• Was soll ich beim Einsatz einer bestimmten Technologie / Methode beachten?

Das OCEH gliedert sich in diese inhaltlichen Bestandteile, die in den folgenden Abschnitten genauer beschrieben werden:

• Beratungshandreichungen
• Engineering Guidelines
• Lösungs-Architekturen (konkret)
• Architekturschablonen und Standardarchitekturen
• Technologie-Evaluierungen

Generell gilt: Das OCEH ist ein lebendes Dokument, das redaktionell vom OC-Architekturboard betreut wird. Es lebt aber davon, dass jeder seine Erfahrungen beisteuern kann. Dazu nutzen wir das aus Open Source Projekten bekannte „Fork and Pull Request“-Prinzip. Dies gilt auch für schon bestehende Teile, die OC‘ler genutzt und vielleicht um eigene Aspekte ergänzt haben.

Wenn ihr im Rahmen von Projekten eine Evaluierung oder eine Architekturentscheidung getroffen habt, dann kann diese auch anderen OC-Kollegen über das OCEH zur Verfügung gestellt werden.

Unsere Kunden erwarten zu Recht, dass wir sie aufgrund der Erfahrung bei anderen Kunden beraten können. Eine solche Austauschplattform zu haben, ist ebenfalls ein Mittel, um Kopfmonopole aufzubrechen.

Das OCEH wird in AsciiDoc geschrieben, arbeitet mit einfachen Git Fork und Merge Workflows und wird mittels Antora als Webseite veröffentlicht.

Beratungshandreichungen

In diesem Sub-Kapitel im OCEH sammeln wir Dinge, die sich beim Kunden bewährt haben und im Beratungskontext helfen können.

Es stellt dar, wie sich OC auf Basis von Projekterfahrungen zu einem bestimmten Themenbereich positioniert, etwa zum Einsatz von Kubernetes in unterschiedlichen Einsatzszenarien.

Engineering Guidelines

Sich auf Spielregeln und Best Practices im Einsatz von Technologien festzulegen, ist in jedem Projekt hilfreich. In diesem Sub-Kapitel sammeln wir bewährte Guidelines aus der OC-Praxis, etwa:

• Angular Guidelines
• REST Guidelines
• Apache Camel Guidelines
• Database Development Guidelines
• Git Guidelines
• usf.

Diese Guidelines werden in unseren Projekten verwendet, um eine Einheitlichkeit bei der Projektumsetzung, bezogen auf die entsprechenden Aspekte, gewährleisten zu können. Zudem wird die Delivery hierdurch effizienter, da man sich keine eigenen Gedanken zu immer wiederkehrenden Fragestellungen machen muss.

Neue Erkenntnisse aus den Projekten fließen hier immer wieder zurück, wenn sich Vorgaben als nicht praktikabel erweisen.

Lösungs-Architekturen (konkret)

In diesem Sub-Kapitel findet ihr beispielhafte, anonymisierte Lösungsarchitekturen, die wir im Rahmen von Angeboten für Kunden ausgearbeitet haben. Sie sind ggf. nachträglich aufbereitet und ihr findet entsprechende Hinweise, falls wir bei einem Review festgestellt haben, dass wir in der Zwischenzeit etwas anders machen würden.

Beispielhafte Inhalte:

• Moderne Integrationsarchitektur für Ablösung eines alten Enterprise Service Bus (ESB)
• API-Management Konzept für Open Data, Partner-Data, Internal-Data
• Integration vorhandener Daten über API Gateway und Integrationsmuster, um neue Use-Cases zu unterstützen.
• Ansteuerung von verschiedenen Backend-Diensten über eine cloud-native Integration mittels Camel und Priorisierung der Anfragen über priorty based messaging.
• Aufbau einer hybriden, Multi-Cloud API Plattform auf der Basis von Kong

Architekturschablonen und Standardarchitekturen

Wenn wir uns über Architekturschablonen und Standardarchitekturen unterhalten, dann müssen wir erst einmal ein paar Begriffe definieren.

Architekturstil: Ein Architekturstil bezeichnet eine abstrakte Sammlung, die von konkreten Elementen und Aspekten einer Architektur abstrahiert. Sie besteht daher aus einer Menge an gemeinsamen Annahmen und Randbedingung, die über alle konkreten Architekturen gleich ist. Es werden damit eine Menge an konkreten Designentscheidungen schon vorweggenommen und bestimmte Aspekte werden isoliert betrachtet. Beispiele für einen Architekturstil sind

• Microservices Architektur
• Monolithische Architektur
• Schichtenarchitektur
• Datenbank-zentrische Architektur
• Event getriebene Architektur
• REST
• SOA

Architekturschablone: Eine Architekturschablone kombiniert unter Umständen mehrere Architekturstile zu einer abstrakten Architektur. Wir gehen davon aus, dass diese Art der Architekturschablonen für eine gewisse Klasse an Anwendungstypen passt, ohne dass dort konkrete Technologien genannt sind. Beispiele

• Cloud Native Systems
• Integrationsarchitekturen
• Analytische Architekturen

Wir beschreiben Schablonen durch die zu realisierenden Technischen Capabilities. Dabei kann eine solche Capability auch Aspekte eines Architekturstils enthalten, etwa „event-based communication“.

Standardarchitekturen: Standardarchitekturen konkretisieren die Schablonen durch eine Auswahl von konkreten Technologiebausteinen. Diesen Standardarchitekturen liegen weitere Glaubenssätze und Randbedingungen zugrunde. Glaubenssätze und Randbedingungen schränken den möglichen Lösungsraum ein. Wir sprechen auch von „Flavors“. Beispiele können sein:

• Mixed Flavor (bspw. für Hybride Architekturen)
• AWS Flavor
• Azure Flavor
• Oracle Flavor

Lösungsarchitektur: Eine konkrete Lösungsarchitektur entwickeln wir für ein konkretes Kundenproblem. Da Probleme so unterschiedlich sind, wie unsere Kunden, können wir in der Regel nicht einfach mit der Präsentation einer Standardarchitektur antworten. Wir müssen die Architekturtreiber erheben und eine passende Antwort entwickeln. Dabei können Standardarchitekturen und Architekturschablonen eine gute Hilfestellung sein. Die definierten Standardarchitekturen sind in diesem Zusammenhang als eine Art Baukasten zu verstehen, aus dem wir uns bedienen können, um eine passgenaue Lösungsarchitektur für ein Kundenproblem zu definieren. So können wir bspw. mit Hilfe der Standardarchitekturen für „Cloud Native Systems“ und für „Integration“ eine Lösungsarchitektur für eine Cloud-native Integrationsplattform entwerfen, die On-premises, in der Cloud oder auch hybrid und Multi-Cloud deployed und betrieben werden kann.

Die Schablonen helfen durch die Auflistung von häufig notwendigen technischen Capabilities, dass wir an alles denken, was im konkreten Kontext wichtig ist; also dienen die Schablonen als eine Art Checkliste. Dabei ist nicht immer die Adressierung aller Capabilities notwendig. Wir treffen die Entscheidung aber bewusst (und dokumentieren diese), damit wir z.B. im Projektverlauf nicht unliebsame Überraschungen erleben, weil wir vergessen haben einen wichtigen Teil zu schätzen.

Gleichzeitig helfen uns Standardarchitekturen in Pre-Sales Situationen in eine Diskussion mit Kunden einzusteigen: Wenn wir die Wahl haben, dann würden wir ihr Problem wie in unserer Standardarchitektur beschrieben lösen. Sehen Sie auch alle Elemente für notwendig? Worauf wollen Sie verzichten? Das hat aber folgende Auswirkungen. Wir können auch eine andere Technologie verwenden, aber das ist mit größerem Risiko oder Aufwand verbunden.

Technologie-Evaluierungen und ADRs

Wird eine für OC neue Technologie zur Aufnahme ins OC-Technologie-Portfolio vorgeschlagen, geschieht dies über einen Vorschlagseintrag im TLMT. Das OC-Architekturboard (OCAB) bewertet den konkreten Vorschlag. Soll eine Verprobung stattfinden, wird ein Evaluierungsticket im Blueboard erzeugt und die Ergebnisse werden in Form einer Technologieevaluierung im entsprechenden Sub-Kapitel im OCEH dokumentiert.

Beispiele:

• Pyramid Analytics
• Confluent Cloud
• Ionos Cloud
• Service Meshes
• Go
• …

Allgemeinere Architekturentscheidungen werden in Form von bewährten ADRs (Architecture Decision Records) dokumentiert. Des Weiteren werden ADRs geschrieben, wenn es für die Umsetzung von Capabilities mehrere Technologiebausteine gibt. Der ADR definiert dann den zu präferierenden Baustein und begründet, warum das so ist.

Beispiele für ADRs:

• Rancher Desktop als Docker Desktop Umgebung
• Nutzung eines Key-Value-Stores zur Speicherung einer Service Konfiguration im mixed Flavour
• Nutzung von Prometheus für cloud-natives Service Monitoring
• Nutzung von Kong als API Gateway im mixed Flavour
• Nutzung von Caching Reverse Proxies im Mostly-AWS Flavour

Wissensdomänen

Das Management von Technologien auf Ebene der einzelnen Tech-Items ist wichtig, aufgrund der hohen Anzahl von Tech-Items jedoch sehr schnell unübersichtlich und schwer handhabbar.

Aus diesem Grund verwenden wir zur Komplexitätsreduktion eine Bündelung vieler Tech-Items. Wir sprechen von den sogenannten Wissensdomänen:

Abb. 3: Die OC-Wissensdomänen

Auf Basis dieser Wissensdomänen planen wir Aus- und Weiterbildungen im Kontext des Technologie-Managements.

Das Trend-Scouting, also das Auffinden neuer technischer Strömungen, neuer Technologien, Frameworks oder Lösungsansätze wird so ebenfalls handhabbarer.

Das OC-Architekturboard (OCAB)

Das OCAB erweitert das Corporate Development Tech-Team und ist zentrales Instrument für #zukunftswirksame OC-Lösungen. Es stellt die technologische sowie methodische Kompetenz von OC für unsere #zukunftswirksamen IT-Lösungen sicher.

Dort Wirkung erzeugen, wo Bedarf ist: In Kundenszenarien, in den Communities, vor Ort. Immer enablend für andere.

Hauptaufgaben des OCAB:

• Tech-Portfoliomanagement und Bereitstellung eines klar kommunizierten Tech-Stacks: Wir helfen unseren Projekten durch eine Standardisierung der technologischen Basis
• Wissensdrehscheibe für Projekterfahrungen: Aus laufenden Projekten lernen und laufende Projekte besser machen. Wiederverwendbarkeit von bereits gelösten Themen. Deliveryfähigkeit verbessern (Qualität).
• Support beim Gewinnen von „modernen“ Projekten (Akquise & Ausschreibungen; im Enablement-Modus für Andere; „mehr Lösungsarchitekten haben“; mehr moderne Technologien, mehr Projekte, Attraktivität als Arbeitgeber)
• Kommunikation über Technologien sicherstellen nach innen und außen (u.a. OC Engineering Handbook, OC TechTalks, Tech-Blog, Fachartikel, Konferenzen)

Das OCAB-Leistungsangebot gliedert sich in drei Bereiche:

1. Technologie-Management / Wissensmanagement (Basis für Akquise und Umsetzung)
2. Unterstützung bei Akquise
3. Unterstützung bei Projekt / Produkt / Service

Das OC-Forum

Unser Forum ist ein Ort zum technischen Austausch und Quell für wichtige Wissensfundstücke im Projektalltag.

Es ist wichtig, wenn man nicht nur Kollegen eines Teams ansprechen will, sondern das gesamte Wissen aller Kollegen anzapfen möchte.

Wir hatten schon vor Jahren ein Forum und haben es bei der Einführung von Microsoft Teams zunächst abgeschafft. Aus heutiger Sicht lässt sich sagen: das war eine grenzwertig gute Idee. Teams hat viele Vorteile, die Funktionalität der Abbildung eines Forums gehört leider nicht dazu.

Wir haben gelernt und daher ein neues Forum aufgesetzt. Bei der Struktur haben wir uns bewusst an unseren Wissensdomänen orientiert, um dieses Denkmodell in der täglichen Praxis zu verankern.

Die OC Communities

Neben den Werkzeugen gibt es auch die Möglichkeit des Netzwerkens in Communities.

Jede Community richtet sich an den strategischen Zielen von OC aus. In den Communities tauschen wir uns mit anderen am Thema interessierten Mitarbeiter:innen aus und vergrößern so unser OC-Netzwerk. Die Communities treiben aus ihrer Sicht relevante Aufgaben und gestalten so aktiv die Zukunft von OC mit.

In den Communities wird gelernt, neue Technologien werden ausprobiert, evaluiert und angewendet. Hieraus ergeben sich viele Synergien zum Technologie-Management in den Kategorien der Wissensdomänen.

Beispiele für OC-Communities:

• Next Level Analytics (C42)
• Data Engineering
• DevOps Infrastructure- & Container-Experts (DICE)
• Software-Development-Architektur
• Low Code
• PostgreSQL
• Agile Softwareentwicklung
• Projekt Management
• Team Management

Schlussbemerkung

Wir hoffen, euch hiermit einen guten Überblick über das Technologie Management gegeben zu haben, das aus unserer Sicht auf diesem Niveau für einen professional arbeitenden IT-Lösungsexperten wie OC absolut unabdingbar ist. Hat es euch gefallen? Sind Fragen aufgetaucht? Wir freuen uns über euer Feedback!

Richard, Sven, Jens und Torsten