Einleitung

Zielgruppe

Dieses Dokument richtet sich an Unternehmensarchitekten, Technische Projektleiter, Projektleiter, Produktmanager, Projektauftraggeber und Projektarchitekten, die sich über die Möglichkeiten der Qualitätsbewertung im Rahmen frühzeitiger Reviews informieren möchten.

Zweck des Dokuments

Sie erfahren in diesem Whitepaper, wie Kunden der innoQ in unterschiedlichen Projektphasen von der Umsetzungs- und Architektur-Expertise von innoQ profitiert haben. Sie lernen die notwendigen Voraussetzungen für erfolgreiche Review-Projekte kennen.

Ansprechpartner

Für Fragen und Anmerkungen stehen wir Ihnen jederzeit gern zur Verfügung:

Einführung

Es gibt einige zentrale Fragen, die Sie sich regelmäßig während der Projektarbeit beantworten müssen:

Die Informationsflut, der die Beteiligten gegenüberstehen, wird zum Teil durch Detaillisten und zum anderen Teil durch geeignete Abstraktionen adressiert. Details schlummern in einer für das Projekt passenden Repräsentation und fristen ein Schattendasein.

Sporadisch oder regelmäßig werden einzelne Details hervorgeholt und betrachtet, um Risiken zu erkennen, bevor sie eintreten und den Projekterfolg gefährden. Reviews dienen dazu, ausgewählte bzw. auszuwählende Details in einem definierten Kontext zu bewerten. Die Bewertungskriterien können sich auf funktionale, fachliche oder qualitative Aspekte des Review-Gegenstands beziehen – oder sogar auf das Projekt selbst.

Der Review-Gegenstand kann unterschiedliche Ausprägungen haben, zum Beispiel:

Ein Review eignet sich dazu eine Menge von Fragestellungen zu beantworten, die auf die Qualität des Review-Gegenstands abzielen. Mögliche Kandidaten für solche Fragestellungen sind:

Dazu verwenden Reviewer verschiedene Techniken je nach Zielsetzung und Kontext in beliebiger Reihenfolge und Gewichtung – zum Beispiel:

Im Folgenden möchten wir Ihnen die Grundlagen und den Nutzen von Reviews in den verschiedenen Projektphasen demonstrieren und Ihnen Hinweise geben, wie Sie Review-Ergebnisse sinnvoll in Ihre Projekte einbetten können.

Review-Ansätze

Eine grundlegende Technik ist die szenariobasierte Analyse des Review-Gegenstands. Unter einem Szenario versteht man dabei die Interaktion mit einem System innerhalb eines definierten Kontexts.

Erheben der Architekturtreiber

Sie sind sich sicher, dass die Qualitätsziele und die Anforderungen perfekt beherrscht und von allen gleich verstanden sind? Dann genügt es dem Review-Team diese Anforderungen zu erläutern.

Sollte aber nicht sichergestellt sein, dass alle Beteiligten über das gleiche Verständnis verfügen, sollte der Review-Auftrag die Erhebung der Qualitätsziele mit beinhalten.

Abwägungen von Entwurfsentscheidungen

Sie möchten die Konsequenzen ihrer Entscheidung analysieren und verstehen? Sie möchten sicherstellen, dass Ihr Entwurf keine unerwünschten Nebeneffekte mit sich bringt? Sie möchten eine taktische Entscheidung treffen, die Ihnen möglichst viele strategische Optionen offen hält?

Hier können mithilfe eines Reviews Schwachstellen und Konsequenzen szenariobasiert aufgedeckt werden. Sowohl die Erfahrung des Review-Teams als auch ihr neutraler Blick liefert Rückmeldungen und eine Überprüfung der bisherigen Annahmen.

Steuerung der technischen Pflege

Sie möchten unter Berücksichtigung der bisherigen Strukturen und Implementierung eine technische Renovierung durchführen und sicherstellen, dass der Aufwand die Software umzubauen minimal ist? Mit entsprechend qualifizierten Sparringspartnern können Sie die Vor- und Nachteile im Hinblick auf die Architekturmigration, auf die erreichbare Qualität und auf die zukünftige Pflege bewerten.

Dokumentation

Orientierung an der Zielgruppe

Die Ausarbeitung eines Review-Berichts kann beliebig aufwendig sein. Deshalb sollten Sie im Vorfeld des Auftrags prüfen, was Sie tatsächlich benötigen um das Projekt weiter zu steuern. Das Spektrum ist dabei sehr groß:

Sie können davon ausgehen, dass das Ergebnisprotokoll eines eintägigen Workshops innerhalb von 0,5 bis 2 Stunden erstellt ist, wenn es sich ausschließlich an die Teilnehmer richtet. Die Ausarbeitung eines für alle Projektbeteiligten geeigneten Ergebnisprotokolls ist unvergleichlich viel aufwendiger und muss individuell abgeschätzt werden.

Dokumentationsarten

Üblicherweise können Sie von einem Review ein Ergebnis erwarten, das folgende Aussagen beinhaltet:

Abhängig von der Review-Art können weitere optionale Elemente des Ergebnisberichts hinzukommen:

Einbettung von Reviews ins Projekt

Ein Review ist eine zeitlich begrenzte Aktivität. Bei externer Vergabe können Prüfungen des Review-Gegenstands parallel zur Projektarbeit erfolgen. Dennoch erfordert ein Review die Zeit des Projektteams für die Interviews bzw. Rückfragen sowie für die Vor- und Nachbereitung.

Vorbereitung eines Reviews

Der Auftraggeber sollte die mit dem Review verbundene Zielsetzung definieren und sicherstellen, dass alle nötigen Voraussetzungen geschaffen sind. In Zusammenarbeit mit dem Review-Team wird eine Übersicht über die wichtigsten Interessenvertreter diskutiert und eine Kommunikationsstrategie für das Review abgestimmt. Bei der Vorbereitung kann das Review-Team maßgeblich unterstützen. Die letztendliche Definition der Zielsetzung obliegt aber dem Auftraggeber.

Nachbereitung des Reviews

Das Projektteam erhält einen Review-Bericht, der Maßnahmen enthält, die teilweise im Rahmen des Projekts umgesetzt werden sollten. Im Nachgang zum Review werden also zentrale Fragen besser beantwortet werden können.

Fallbeispiele für Architektur-Reviews

Quartalsweises, aktives Design-Review

Auftraggeber

Ein internationaler Spezialist für Information Retrieval stellt mit Hilfe von sehr frühen und regelmäßigen Designreviews sicher, dass die Produktvision umgesetzt wird. Die zyklische Diskussion von architekturrelevanten Änderungsanforderungen erlaubt die risikoarme Weiterentwicklung des Systems.

Umfang

1 Senior-Architekt als Reviewer, 2–3 PT je Quartal

Art der Durchführung

Zusammenhängende Workshops mit dem Team Szenariobasierte Bewertung der Entwürfe Separate Zusammenfassung der Workshop-Ergebnisse

Art der Dokumentation

Review-Bericht, etwa 4–6 DIN A4-Seiten Struktur stark an Review-Inhalten ausgerichtet Gliederung auf Level 1:

Nutzen

Neben dem kontinuierlichen Risikomanagement und dem Zielabgleich konnte der Kunde so das kritische Projekt-Knowhow auf verschiedene zueinander im Wettbewerb stehende Dienstleister verteilen und dadurch eine einseitige Abhängigkeit zu einem einzelnen Anbieter verhindern.

Architektur-Review eines Bestandsführungssystems in einer Versicherung

Auftraggeber

Für das DACH-Geschäft eines internationalen Versicherungskonzerns wurde das zentrale Bestandsführungssystem evaluiert, um zu beurteilen, inwiefern Architekturaspekte die Ursache für sehr lange Time-to-Market, hohe Aufwände und nicht zufrieden stellende Qualität sein könnten.

Umfang

Review-Team bestehend aus 2 Senior-Architekten, 1 Domänenexperten und 1 Technologie-Spezialisten, insgesamt 1 PJ im Zeitraum von 6 Monaten

Art der Durchführung

Workshop-Reihe mit verschiedenen Workshops zu Spezialthemen mit unterschiedlichsten Interessenvertretern Begleitet durch Spezialist der Versicherungsbranche Regelmäßige Abstimmung im Vorstandsgremium

Art der Dokumentation

Detaillierter Review-Bericht mit Empfehlungen für die fachliche Definition und die technische Umsetzung Bericht an den Vorstand Gliederung auf Level 1:

Nutzen

Der Kunde konnte eine Reihe von kurz-, mittel- und langfristigen Architekturmaßnahmen konzipieren und eine mehrjährige Roadmap für deren Umsetzung erstellen, erste „Quick Wins“ konnten sehr zeitnah umgesetzt werden.

Architektur-Review eines Versicherungsproduktes

Auftraggeber

Ein Rückversicherer stellt seinen Kunden, den Versicherungen, ein Webbasiertes Produkt zur Risikobewertung zur Verfügung, das die Versicherungen wiederum ihren Interessenten und Kunden anbieten können. Aufgrund von unterschiedlichen Erwartungen von Auftraggeber und Entwicklung wurden im Rahmen eines Reviews Schwachstellen identifiziert.

Umfang

30 PT, Review-Team besteht aus 1 Senior-Architekt + 1 Architekt

Art der Durchführung

Workshops mit den Interessenvertretern gemeinsam Danach jeweils Einzelinterviews mit Vertretern aus Architektur, Entwicklungsteam, Fachbereich und Betrieb

Art der Dokumentation

Review-Bericht (34 Seiten) Abschluss-Präsentation (Management Summary) für den fachlichen Auftraggeber Gliederung auf Level 1:

Nutzen

Der Kunde hat sein Projektportfolio gemäß der Risiko-Einschätzung ausgerichtet und beschränkt sich im aktuellen Projekt auf die identifizierten Quick-Wins. Die im Review festgestellten Mängel werden bei der Definition der Zielarchitektur für ein Nachfolger-System im Rahmen eines separaten Projekts berücksichtigt und beseitigt.

Architektur-Review einer webbasierten Lernplattform

Auftraggeber

Der Hersteller einer führenden Lernplattform für Unternehmen unterzieht die Plattform und die Entwürfe für eine Neu-Implementierung einem Review, um im Vorfeld Implementierungsrisiken auszumerzen.

Umfang

1 Senior-Architekt als Reviewer, 5 PT

Art der Durchführung

Workshop mit Entwicklungsleiter, Architekt, Entwicklern, Betreiber und Produktmanager

Art der Dokumentation

Review-Bericht (ca. 30 DIN A4-Seiten) für Entwicklungsteam, Vorstand und Aufsichtsrat Vorstandspräsentation Gliederung auf Level 1:

Nutzen

Mit Hilfe der im Review-Bericht vorgeschlagenen Zielarchitektur wurde ein langfristiger Umsetzungsplan aufgestellt und ein kultureller Wandel innerhalb der Produktentwicklung initiiert.

Review einer Zielarchitektur für ein Behördeninformationssystem

Auftraggeber

Ein Softwarelieferant lässt die Tragfähigkeit und Zukunftsfähigkeit seiner Produkte vor dem Hintergrund eines geplanten bzw. bereits begonnenen Technologiewechsels von VB6 und Delphi auf Microsoft .NET überprüfen. Review-Gegenstand sind die Entwürfe der Zielarchitektur der neuen Produktpalette und der Migrationspfad von der bestehenden Architektur zum neuen Entwurf.

Umfang

Review-Team, bestehend aus Senior-Architekt und Architekt, ca. 3 PM

Art der Durchführung

Workshops und Einzelinterviews SWOT-Analyse

Art der Dokumentation

Review-Bericht (ca. 40 DIN A4-Seiten) inkl. Ausarbeitung der Dokumentation des Zielarchitektur Ergebnis-Präsentation Gliederung auf Level 1:

Nutzen

Die transparente Bewertung verbesserte die Detailplanung des zukünftigen Produktsegments und führte zur konkreten Umsetzung des Vorhabens.

Über innoQ

Seit 1999 bietet innoQ Beratungsleistungen im Umfeld unternehmenskritischer IT- Systeme an. Der Hauptfokus liegt dabei auf serviceorientierten Architekturen, Ansätzen zur Effizienzsteigerung in der Softwareproduktion (zum Beispiel mit modellgetriebener Entwicklung mit und ohne UML) und der Entwicklung von Lösungen mit Java/J2EE/Java EE und Ruby on Rails.

Agile Entwicklungsmethoden

Seit vielen Jahren entwickeln wir nach agilen Methoden, insbesondere Scrum, und verfügen über Erfahrungen mit dem Einsatz in kleinen und großen Projekten, auch unter widrigen Umständen und in Fällen, in denen organisatorische Herausforderungen das Vorgehen schwierig machen. Wir sind nicht dogmatisch, sondern legen wert auf eine pragmatische, lösungsorientierte Vorgehensweise. Neben der aktiven, agilen Projektarbeit verfügt innoQ auch über Know-how in dem notwendigen Transformationsprozess – sprich: wie ein Konzern mit seinen ganzen Bereichen, Abteilungen, Projeken und seiner langen Entwicklungshistorie am besten damit anfängt, von einer relativ statischen Entwicklung mit wenigen Releases pro Jahr auf ein agiles Vorgehen umzustellen.

Moderne Web-Entwicklung

Durch unsere Tätigkeit für Fortune 500-Unternehmen auf der einen und „reine“ Web-Unternehmen auf der anderen Seite sind wir sowohl mit den Herausforderungen in der Unternehmens-IT als auch mit der Dynamik moderner Web-Angebote vertraut. Über besondere Erfahrung verfügen wir dabei in den Bereichen modularer Benutzeroberflächen, Responsive Design, dem angemessenen und architektonisch sauberen Einsatz von modernen Web-Technologien sowie der Skalierung von Web-Anwendungen mit Hilfe von Caching-Servern und anderen Proxies. Mit den von uns favorisierten Ansätzen erhalten Web-Anwendungen eine integrierte Rolle in der Gesamtarchitektur, unabhängig von der Nutzergruppe (intern, Partner oder Endkunden) und den verwendeten Geräten (Desktop oder mobil), anstatt ein separates Dasein im Marketing-Kontext zu fristen.

Continuous Delivery, Cloud-Computing und DevOps

Wir bieten Unterstützung bei der Realisierung von privaten ebenso wie bei der Nutzung öffentlicher Cloud-Dienste an. Mit Public Clouds (insbesondere Amazon AWS) haben wir vor allem mit dem Einsatz im Entwicklungs- und Testumfeld sehr gute Erfahrungen sammeln können. Wir sehen dabei insbesondere Vorteile in der Kombination mit der vollständigen Automatisierung von Release- und Deployment-Prozessen. Dazu werden virtuelle Maschinen bei Bedarf provisioniert, ohne dass dazu ein manueller Eingriff notwendig ist. Die Behandlung von Infrastrukturthemen mit derselben Rigidität wie den Entwicklungsprozess hilft dabei, agile Prozesse auch in der betrieblichen Praxis zu etablieren.

Service-orientierte Architekturen (SOA)

Wir unterstützen Sie bei der Einführung serviceorientierter Architekturen (SOA) in Ihrem Unternehmen. Dabei decken wir sowohl strategische Aspekte (Evaluation des Ansatzes, Business Cases, Prozesse und Organisationsstrukturen, Gremien usw.) wie auch technische Querschnittsthemen und die Entwicklung individueller Services ab. Wir beraten Sie unabhängig von den Interessen einzelner Produktanbieter bei der pragmatischen Umsetzung des serviceorientierten Ansatzes, sowohl auf Basis von Web Services (SOAP/WSDL/WS-*) als auch mit Hilfe von REST/RESTful HTTP.

Architekturausbildung mit iSAQB-Zertifizierung

innoQ unterstützt erfahrene Software-Entwickler und Architekten durch eine fundierte Ausbildung, die mit der Zertifizierung zum iSAQB Certified Professional for Software Architecture (Foundation Level) – CPSA-F – abschließt. Darüber hinaus bietet innoQ Module im Rahmen des CPSA-A – des modularen Advanced Level-Programm des iSAQB an. innoQ ist Gründungsmitglied des iSAQB (www.isaqb.org). Informationen zu den Trainings-Aktivitäten sind über die Website erreichbar.

Unsere Expertise

Unser Hauptinteresse gilt der Konstruktion von Softwaresystemen – insbesondere von Architekturen für unternehmenskritischerche, verteilte Systeme. Wir haben tragfähige Systeme in verschiedenen Projekten aus Handel, dem Banken- und Versicherungswesen, Logistik-, Marketing-, Energie- sowie dem TK-Sektor geplant, konstruiert und in den Produktivbetrieb gebracht. Entwicklungsprojekte begleiten wir häufig als Entwickler, Softwarearchitekten, Systemarchitekten oder technische Projektleiter sowohl in den Konstruktions- als auch in den Einführungs- und Wartungsphasen. Zu unseren Beratungsschwerpunkten zählen neben der Umsetzung von Projekten insbesondere Architektur-Entwicklung, -Coaching, -Trainings und -Reviews.

TAGS