Beiträge

The Open Group Architecture Framework (TOGAF): To go... für Daten

TOGAF – To go… für Daten

The Open Group Architecture Framework (TOGAF)

 

In einer Zeit in der es gar nicht neu und hip genug zugehen kann möchte ich an dieser Stelle eine Lanze für ein Framework brechen, dass, bei aller Liebe zur Agilität, seit fast 25 Jahren den Enterprise-Architekten die Möglichkeit gibt Unternehmensstrukturen und daraus resultierende IT-Umsetzungen zu planen, umzusetzen und zu warten: The Open Group Architecture Framework (TOGAF). Wobei der Aspekt der Wartung einer der grössten Herausforderungen bei diesem Unterfangen ist. Das erfordert zum einen eine permanente Überprüfung der Konsistenz des involvierten Unternehmensausschnitts und zum anderen die Disziplin, die zugrunde liegende Dokumentation aktuell zu halten und vor allem so didaktisch aufzubereiten, dass auch jeder andere Leser versteht, was man geschrieben hat.

 

Nach weit mehr als zwei Dekaden Beratung im Qualitäts- und Test-Management lautet mein Credo:

„Alles was ich schreibe, schreibe ich für andere und das muss verständlich und lesbar sein. Dazu zählt auch didaktische Redundanz“.

Vergleicht man dieses Framework mit anderen Frameworks, so wird man feststellen, dass eine nicht unerhebliche Anzahl von Frameworks lediglich die Lieferobjekte aufzählen, die benötigt werden, um verschiedene Aspekte der Unternehmensarchitektur zu beschreiben. Hier sagt TOGAF nicht nur was beschrieben werden sollte, sondern geht mit der Achitecture Development Method einen Schritt weiter und schlägt einen methodischen Ansatz zur Umsetzung vor, der sicherlich entsprechend dem jeweiligen Unternehmen angepasst werden sollte.

 

Gerade in Bezug auf die wachsende Internationalisierung der Projekte ist es wichtig, dass verteilte Teams nicht nur hinsichtlich der technischen Konsistenz von Datenmodellen ein fundiertes Wissen haben, sondern auch die Validität von Daten im Griff haben. Nehmen wir das Beispiel synthetischer Daten. Hier reicht es nicht aus syntaktisch korrekten Daten zu produzieren. Diese Daten müssen auch entsprechend dem jeweils übergeordneten Businessmodell entsprechen.

 

The Open Group Architecture Framework (TOGAF): To go... für Daten

 

Hierbei macht es Sinn ein zentralisiertes Testdaten-Management einzuführen und die Generierung der Daten in Abstimmung mit den jeweiligen Fachbereichen und den technischen Teams so zu koordinieren, dass die Fachbereiche sinnvoll generierte Daten sehen und die technischen Teams ein tieferes Verständnis bezüglich der Verwendung dieser Daten während der Entwicklungsphase bekommen. Synthetische Daten werden heutzutage nicht nur für Regressionstests verwendet, sondern auch von externen Entwicklungsteams, die aus Gründen von regulatorischen Vorgaben keine echten Daten verwenden dürfen.

 

Hat man zum Beispiel Entwicklungsteams im Ausland stellt die Bereitstellung geeigneter Daten eine nicht unerhebliche Herausforderung dar. Die Teams müssen die Business-seitige Verwendung der synthetischen Daten kennen und verstehen. Darüber hinaus muss auch das Verständnis da sein welche Kombinationen von Daten sinnvoll und welche technisch möglich aber aus Sicht der jeweiligen Geschäftsprozess nicht vorkommen oder sich sogar widersprechen.

 

Mit Unterstützung der Applikations- und Business-Architektur gelangt man dann zu einem weiteren Aspekt warum TOGAF ein geeignetes Mittel zur Beschreibung der Unternehmensarchitektur ist: Migration.

 

Migration als Teil eines unternehmensorientierten Wartungsprozesses ist eines der herausforderndsten Unterfangen um Geschäftsprozesse und ihre IT in Teilen oder als Ganzes zu transformieren. The Open Group Architecture Framework (TOGAF) kann dabei helfen Geschäftsprozesse und IT während und nach der Migration konsistent zu halten und unnötigen Ballast in Form von nicht mehr benötigten Tabellen, oder sogar ganze fachliche Subdomains, so herauszutrennen, dass die Migration auf sicherem Fundament steht und die damit verbundene Wartung des Unternehmensmodells stabil beendet wird.

 

Das hier angeschnittene Thema „TOGAF als mögliches Kommunikations- und Verständnismodell für dezentrale Teams“ und als Basis zur Herleitung von synthetischen Daten und Validierungsmodell im Bereich der Migration sind nur einige Beispiel wie man Quick Wins produzieren könnte. Wer mehr zur Anwendung von The Open Group Architecture Framework (TOGAF) wissen möchte sollte unseren Spezialisten Felix Isensee kontaktieren.

 

Kontaktinformationen

 

Consultant: Harald Schmidt
E-Mail: harald.schmidt@spf-consulting.ch

 

Harald Schmidt

 

Consultant: Felix Isensee
E-Mail: felix.isensee@spf-consulting.ch

Felix Isensee

SPF Consulting AG - Blog - Agil, aber mit Menschen

Agil, …aber mit Menschen

Eine erfolgreiche Umsetzung agiler Strategien ohne Menschen geht nicht

 

Schaut man sich heute die Programme zur agilen Transformation an, so wird man in einem nicht unerheblichen Masse feststellen, dass es zugeht wie bei den Technikern:  Wenn man etwas effizienter und effektiver zukünftig gestalten möchte, dann nimmt man am besten ein neues Tool. Eine neue Entwicklungsumgebung oder ein neues Ablagesystem für Dokumente, dass man noch besser konfigurieren kann. Das dadurch die von den Mitarbeitern erstellten Dokumente nicht besser werden Bedarf an dieser Stelle nicht wirklich einer Diskussion.

So in etwa verhält es sich mit der Einführung neuer Prozesse und den damit verbundenen Tools. Wo bleibt hier der Faktor Mensch oder genauer gesagt der Mitarbeiter? Es sind nicht die agilen Prozesse, die innovative Produkte designen oder Lösungen für Kunden entwickeln. Es sind auch nicht die täglichen agilen Meetings, die Probleme lösen. Es sind die Menschen innerhalb und ausserhalb einer Organisation, die an den täglichen Herausforderungen direkt beteiligt sind.

Wie also transformiert man die Mitarbeiter? Was macht man mit einem unverzichtbaren C++ Entwickler, der über 20 Jahre Berufserfahrung hat und sagt, dass er mit alle dem nichts zu tun haben möchte und nur seinen Job machen will?

Jetzt werden einige sagen, dass jeder ersetzbar ist. Das stimmt nur bedingt. Langfristig eventuell, kurz- bis mittelfristig sicherlich nicht. Es sei denn man möchte direkt oder indirekt die Liste der Projektrisiken erheblich erweitern. Gerade in diesen Zeiten, in der man froh sein kann, dass man engagierte und kompetente Mitarbeiter in seinem Team hat, die noch dazu ein hohes Mass an Erfahrungen mitbringen. Denn mit zunehmender Komplexität der Anforderungen, steigt auch die Komplexität der geforderten Lösung.

Weiter sollte man sich vor Augen halten, dass nicht nur geeignete Mitarbeiter hierfür notwendig sind, sondern auch, dass die technische Umsetzung der Anforderung immer auf fehlerhaften Tools basiert, dessen Ergebnis Fehlerfreiheit fordert. Dies ohne erfahrende Mitarbeiter zu machen ist fast unmöglich. Wie also begeistert man z.B. Wasserfall-Mitarbeiter für die agile Welt?

 

SPF Consulting AG - Blog - Agil, aber mit Menschen

 

Ich empfehle, dass mit der Transformation eines Unternehmens oder meistens auch nur der IT, in eine agile Organisation auch ein Change-Management-Projekt für die Mitarbeiter einher gehen sollte. Immer noch ist die Kluft zwischen denjenigen, die diese agilen Prozesse definieren und denen die sie letztendlich leben sollen immer noch zu gross. Die Teams sollten stärkeren Einfluss auf die Gestaltung des agilen Prozesses haben.

Manchmal ist es sinnvoll einwöchige Sprints zu haben. Manchmal, bedingt durch die zugrundeliegende Komplexität, machen auch Sprints von fünf Wochen Sinn. Das gleiche gilt für die Daily Standup-Meetings. Täglich ist nicht immer sinnvoll und eine Vorgabe von aussen schon gar nicht. Es sollte innerhalb des Teams entschieden werden, auch ob es wirklich sinnvoll ist, dass jeder alles macht. Es heisst nicht umsonst, dass man seine Stärken ausbauen und nicht an seinen Schwächen zugrunde gehen sollte.

Auch auf Prozess-Level gilt:  A fool with a tool, is still a fool. Um das maximale Committent seitens der Mitarbeiter gegenüber einer neuen agilen Organisationsstruktur zu erlangen, sollten auch Change-Programme für Mitarbeiter durchgeführt werden und die agile Transformation begleiten. Ich empfehle einen Blick in das Umfeld von Soziokratie 3.0 zu werfen, die ein geeignetes Mittel zur Integration von Mitarbeitern in neue Organisationsstrukturen bieten könnten. Letztendlich bildet die Grundlage einer jeden erfolgreichen Änderung die Motivation und Bereitschaft dies auch zu wollen. Dies funktioniert meiner Meinung nach nur mit gegenseitigem Vertrauen und Respekt. Tägliche Kontrolle ist eher ein Demotivator.

Dieser Beitrag löst sicherlich nicht die hier beschriebene Probleme mit den damit verbundenen Herausforderungen. Vielmehr sollte dieser Beitrag verdeutlichen warum das Thema agile Methoden und Organisationen an der Basis immer noch skeptisch betrachtet wird und dass das Problem nicht die Strategie und ihre Methoden selbst sind, sondern vielmehr die Integration der Mitarbeiter.

Mit über 20 Jahren Erfahrung im Bereich Stakeholder-Management als Consultant ist alles was man tut erstens immer für andere und zweitens immer eine vertrauensbildende Massnahme. Den Mitarbeitern muss gezeigt werden, dass der agile Weg der bessere ist; sowohl auf der persönlichen Ebene wie auch auf Ebene der Organisation. Das Stichwort ist hier Balanced Scorecard und Strategic Maps. Hierzu wird es von mir sicherlich nicht nur ein Follow-Up geben.

Kontakt

Consultant: Harald Schmidt
E-Mail: harald.schmidt@spf-consulting.ch

 

Harald Schmidt

Resistance to Change

Das Einführen und Leben von agilen Werten in einer Organisation ist eine wichtige Säule, um Business Agilität zu etablieren. Jedoch gibt es für Organisationen immer wieder die Herausforderung, dass agile Werte nicht von allen Mitarbeitern gelebt werden. Woran liegt das? Und warum will sie nicht jeder leben? Liegt es am Alter, an Verlustängsten oder sozialen Verpflichtungen? Können nur 26- bis 45- jährige agil sein? Können Transparenz und Partizipation in einem von Konkurrenz geprägtem Umfeld überhaupt praktiziert werden?

Die Änderungsresistenz entsteht oft anstelle eines agilen Umfeldes. Es ist wichtig, den Mitarbeitern in einer Organisation klar zu vermitteln, dass Änderung Chancen bietet. Dabei hat die Änderungsresistenz gute und schlechte Seiten, so wie es gute und schlechte Gewohnheiten gibt. Gute Gewohnheiten anzutrainieren befähigt uns, effizient zu sein. Andererseits können kreative Prozesse durch alte Gewohnheiten behindert werden. Jedoch gerade in der Softwareentwicklung ist jede Arbeit eine Änderung und bei bereits ritualisierten Vorgängen stellt das Entwöhnen eine echte Herausforderung dar. Welche Gewohnheiten wie zu werten sind, ist in komplexen Systemen schwierig zu beurteilen. Es braucht regelmässige Momente für Abstraktion, Reflexion und Dialog. Die Zusammenarbeit ist dabei stets die Grundlage von agilem und qualitätsbewusstem Handeln.

Im unserem heutigen Video zum Thema, geht unser Agile & Quality Professional Danilo Biella auf das Thema ein und veranschaulicht die Herausforderung, inklusive möglichen Lösungsansätzen.

Video: Resistance to Change - Danilo Biella - Agile & Quality Professional - SPF Consulting AG

Video: Business Agility & Resistance to Change

Kontakt

Consultant: Danilo Biella
E-Mail: danilo.biella@spf-consulting.ch

SPF Consulting AG - Daniello Biella - Agile & Quality Professional