Kollaboratives Architekturmanagement

Transkript

1 Kristia E. Florea ist seit 2008 bei der IBM Software Group Ratioal als Cliet Techical Professioal im Bereich Architecture Maagemet tätig. Sie uterstützt Kude i uterschiedliche Idustrie ud Geschäftsfelder bei der Eiführug vo Werkzeuge für Model-Drive Architecture ud Collaborative Desig ad Applicatio Developmet. Dr. Eiar Karlse (eiar.karlse@de.ibm.com) beschäftigt sich seit mehr als 25 Jahre als Etwickler, Projektleiter, Berater ud Architekt mit Softwareetwicklugs-Tools ud Methode. Seie Dissertatio (Uiversität Breme) hat die Itegratio vo Etwicklugswerkzeuge als Thema. Seit 1998 ist er für Ratioal Software zuächst als IT-Spezialist u. a. für Architektur Maagemet ud derzeit als Solutio Architekt für Applicatio Lifecycle Maagemet tätig. Kollaboratives Architekturmaagemet Wichtige Artefakte im Architekturmaagemet sid ud bleibe Modelle. Die Modellierug umfasst ei breites Spektrum vo Disziplie ud wird häufig durch eie Reihe eigestädiger Modellierugstools uterstützt. Gleichzeitig beötige Uterehme Tools, die es de Teammitglieder ermögliche, gemeisam Desigs zu erstelle, zu überprüfe ud a Aforderuge ud Testfälle zu verküpfe. Eie Rückverfolgbarkeit uterstützt das Äderugsmaagemet ud die Wirkugsaalyse ud ermöglicht außerdem das Erstelle compliace-relevater Dokumetatioe. All diese Aktivitäte setze im Prizip itegrierte Tools voraus, we die Teams effiziet ud koordiiert zusammearbeite solle. I diesem Beitrag werde wir aufzeige, wie Itegratio ud besseres Teamwork auf der Basis der Kollaboratio- ud Itegratiosplattform IBM Ratioal Jazz erreicht werde köe. Eiführug Die Modellierug schließt heutzutage ei breites Spektrum vo Disziplie, Fuktioe ud Tools ei. Bei Uterehmesarchitekture liegt der Schwerpukt beispielsweise auf der Modellierug vo Ziele, Fuktioalität, Systeme, Geschäftsprozesse ud Services. Die Geschäftsprozessmodellierug, ausgedrückt z. B. durch die Busiess Process Modelig Notatio (BPMN), wird verwedet, um sowohl vorhadee als auch geplate Prozesse zu defiiere, die i Kombiatio mit Simulatios- ud Aalysefeatures geutzt werde köe, um festzustelle, ob Prozessäderuge die gewüschte Wirkug für das Uterehme hätte. Diese Geschäftsprozessmodelle köe als Iput für die Erstellug erster Servicemodelle diee. Komplexe IT-Aweduge, z. B. für SOA, köe mithilfe der Uified Modelig Laguage (UML) defiiert werde, idem komplexe Services i eizele Teilservices zerlegt ud dere Modelle aschließed i Web Service Defiitio Laguage (WSDL) oder Service Compoet Architecture (SCA) trasformiert werde. Etwickler vo eigebettete Systeme gehe oft bei der Modellierug och eie Schritt weiter, idem sie vollstädig ausführbare Modelle defiiere, die i ausführbare C-, C++- oder Java-Code trasformiert werde köe. Für Datebakmodellieruge sid wiederum adere Istrumete otwedig, um beispielsweise das kozeptuelle, logische ud physische Datemodell darzustelle ud es durch Modell-zu-Modell- Trasformatioe umzuwadel. Für eizele Projekte, die ur selte alle Modellierugsvariate eibeziehe, reiche eizele oder eie begrezte Azahl a Modellierugstools, die vo alle Rolle ud Aufgabebereiche verwedet werde, ormalerweise vollstädig aus. I größere Orgaisatioe mit eier Vielzahl uterschiedlicher ud stärker spezialisierter Rolle ist es wahrscheilicher, dass ei gazer Satz vo Spezialtools zum Eisatz kommt. I beide Fälle müsse die zustädige Teams zusammearbeite, ud zwar teamiter als auch exter mit adere Teams, Stakeholder, Prüfer usw. Die erarbeitete Modelle müsse geprüft werde uter Umstäde durch Stakeholder, die weder über Zugriff auf die fragliche Modellierugstools och über das Kowhow zu dere sachgerechter Nutzug verfüge. Die Aufgabe der Teammitglieder müsse defiiert, geplat, zugewiese, ausgeführt ud überwacht werde. Die Rückverfolgbarkeit zwische Aforderuge, Modellelemete, Code ud Testfälle muss sichergestellt sei, um ei eiwadfreies Äderugsmaagemet ud die Wirkugsaalyse zu uterstütze. I Orgaisatioe, die im Kotext vo Norme ud Compliacevorgabe agiere, müsse außerdem Dokumete geeriert werde, die de Liefergegestad für bestimmte Meilesteie darstelle. I de folgede Abschitte dieses Artikel möchte wir zeige, wie Zusammearbeit im Kotext eies Satzes verschiedeartiger Modellierugstools erreicht werde ka, idem eie Itegratiosplattform für das Kollaborative Awedugslebeszyklus-Maagemet (Colla- 1

2 Olie Themespecial Architekture 2012 advertorial borative Applicatio Lifecycle-Maagemet, CALM) ametlich die Itegratios- ud Kollaboratioplattform IBM Jazz verwedet wird. Die Itegratios- ud Kollaboratioplattform Jazz Jazz [IBM08] ist eie offee Tool-Plattform, die Tools aus alle Phase des Awedugslebeszyklus die gemeisame Nutzug vo Iformatioe ermöglicht. Die Jazz Foudatio wurde vo Afag a daraufhi ausgelegt, die Probleme der Itegratio vo Tools i eier komplexe Plaugs- ud Etwicklugsumgebug zu löse. Sie bietet zudem eie Sammlug allgemeier Services für Sicherheit, Zusammearbeit, Ereigisbeachrichtigug, Beutzerverwaltug, Dashboards ud Ab - frage. Auf der Grudlage dieser Plattform ist es möglich, vorhadee Tools, beispielsweise IBM Ratioal DOORS, für das Aforderugsmaagemet zu itegriere. IBM Ratioal bietet darüber hiaus eie Satz vo CALM-Lösuge, die direkt auf der Jazz- Plattform aufsetze. Hierzu zähle: IBM Ratioal Requiremet Composer für das Aforderugsmaagemet, IBM Ratioal Team Cocert für die Teamzusammearbeit ud das Softwarekofiguratiosmaagemet, IBM Ratioal Quality Maager für das Testmaagemet ud IBM Ratioal Software Architect Desig Maager ud IBM Ratioal Rhapsody Desig Maager für das Modellmaagemet. Abb. 1: Jazz-Architektur* Das Herzstück der Jazz Foudatio ist ei eu erarbeiteter Satz aus Schittstellestadards, Ope Services for Lifecycle Kollaboratio (OSLC) geat, mit dem das Ziel verfolgt wird, gemeisame Toolschittstelledefiitioe für zetrale Aufgabebereiche im Awedugslebeszyklus eizuführe. Die OSLC-Iitiative [OSLC12] zählt derzeit 16 Gruppe, die sich u. a. mit der Stadardisierug vo Schittstelle für das Architekturmaagemet sowie für verwadte Disziplie, wie Äderugsmaagemet, Qualitätsmaagemet, Aforderugsmaagemet, Soft - warekofiguratiosmaagemet, Architekturmaagemet ud Berichtswese, befasse. Eies der wichtigste Prizipie der Jazz-Itegratiosplattform ist das Prizip der verküpfte Date. Jede mit de Tools verwaltete Ressource wird durch eie eideutige Uiform Resource Locator (URL) idetifiziert ud Traces zwische Elemete werde ahad dieser URL defiiert. Die Itegratio wird mittels loser Koppelug zwische de Tools erreicht ud Iteraktioe erfolge über techologieeutrale REST-Services ( Represetatioal State Trasfer ). Die REST-Services stelle die ötige CRUD-Operatioe (Create, Read, Update ud Delete; Erstelle, Lese, Aktualisiere ud Lösche) des Elemets bereit, uabhägig davo, ob es sich um eie Aforderug, ei Modellelemet, ei Work Item, eie Testfall oder eie Fehler hadelt. Dak dieser offee Itegratiosarchitektur köe vorhadee Aweduge i die Jazz Foudatio itegriert werde, währed gleichzeitig Kudeivestitioe i bestehede Techologie geschützt werde. Die OSLC-gestützte Itegratio vo Modellierugstools i eie größere Kotext ierhalb der Jazz-Plattform bietet zahlreiche Vorteile. Die Teammitglieder köe de Grad der Zusammearbeit erfolgreich erhöhe, idem sie Work Itemud Projektmaagemetfuktioalität utze, um ihre Arbeit zu plae ud de Fortschritt zu überwache. Das Äderugsmaagemet ka wirkugsvoll uterstützt werde, idem beispielsweise Work Items mit zugehörige Modellelemete ud Aforderuge verküpft werde, auf die sich eie Äderug auswirkt. Ei itegrierter Asatz hisichtlich des Aforderugsmaagemets ud der Modellierug, der die Defiitio vo Traces zwische Elemete i de beide Bereiche ermöglicht, bietet erhebliche Vorteile für beide Teams: Aforderugsetwickler köe eie Abdeckugsaalyse durchführe (werde alle Aforderuge durch das Modell abgedeckt?) ud Mitglieder des Desigteams habe direkte Zugriff auf die für ihre Arbeit relevate Aforderuge. Darüber hiaus wird die Übergabe a Testteams uterstützt, idem die Verküpfug vo Modellelemete mit Testfälle ermöglicht wird ud idem Architekte ud Testmaager das abgestimmte Arbeite uter Nutzug des gleiche (itegrierte) Work Item-Maagemetsystems ermöglicht wird. Klassischerweise erfolge solche Übergabe, idem Iformatioe ausgetauscht ud sychroisiert werde. BPMN- oder UML-Modelle köe aus eiem Modellierugstool exportiert ud i ei aderes Tool importiert werde. Ebeso köe Aforderuge verwedet werde, um ei Aforderugsmodell im Modellierugstool zu erstelle. Alterativ dazu ist es auch möglich, Modellelemete zu Aforderuge zurückzuverfolge, idem Modellstellvertreter im Aforderugsmaagemettool erstellt werde. Jede dieser Vorgehesweise impliziert jedoch, dass Iformatioe kopiert werde, was die aschließede Sychroisatio dieser beide Welte otwedig macht. Mit adere Worte: Bei der fuktiosübergreifede Zusammearbeit gibt es Hiderisse, die überwude werde müsse. Die Fuktiosweise vo OSLC uterscheidet sich dahigehed, dass die Date Olie Themespecial Architekture

3 Abb. 2: Mit OSLC verküpfte Lebeszyklusdate köe sie kei Feedback zu de vo ihe erstellte Modelle erhalte. Eie derartige Vorgehesweise führt uweigerlich zu kostspielige Nachbesseruge i spätere Phase des Etwicklugszyklus. Die Abkoppelug der Modelle vo adere Artefakte des Lebeszyklus (Code, Aforderuge, Testfälle usw.) macht es darüber hiaus so gut wie umöglich, die tatsächliche Auswirkuge eier Äderug zu verstehe. Dies führt etweder zu riskate Zusage oder dazu, dass Äderugsafrage auf Widerstäde stoße ud das i eier Zeit, i der Agilität ud Risikomaagemet uverzichtbar sid. Die Lösug ist der IBM Ratioal Desig Maager, der ermöglicht, Ratioal Software Architect- ud Ratioal Rhapsody- Modelle i ei Jazz-basiertes Modellrepository zu importiere. Nach dem Import ist es de Desigteams möglich, Modelle zu prüfe, Rückverfolgbarkeitsverküpa ihrem ursprügliche Ort verbleibe ud stattdesse Verküpfuge zwische zwei Fuktiosbereiche erstellt werde. Diese Art der Verküpfug mittels OSLC wurde jügst verwedet, um zwei Modellierugstools i usere Lebeszyklusmaagemetlösuge zu itegriere ud auf diese Weise die Zusammearbeit zu verbesser. Die Rede ist vo IBM Busiess Process Maagemet [Pac12], das OSLC-Verküpfuge uterstützt ud hierdurch die Verküpfug vo Geschäftsprozesselemete, beispielsweise zu Aforderuge, Äderugsafrage ud Testfälle, ermöglicht sowie vo IBM System Architect, das die Verküpfug vo Uterehmesarchitekturelemete zu beispielsweise Äderugsafrage ud Aforderuge ermöglicht. Im Kotext der Jazz-Plattform ka jedoch ei och höherer Grad a Zusammearbeit erreicht werde ei Pukt, auf de wir im ächste Abschitt eigehe möchte. fuge zu defiiere, die Auswirkuge vo Äderuge zu aalysiere ud Lebeszyklus-Desigdokumete zu veröffetliche. Durch IBM Ratioal Desig Maager wird das Desig i die Plaugs- ud Etwicklugszykle vo Aweduge ud Systeme itegriert ud die Teams werde i die Lage versetzt, i Echtzeit ud orgaisatios-, diszipli- ud bereichsübergreifed zusammezuarbeite. Eie Aalyse des Desigprozesses zeigt, dass er sich als ei aus zwei Phase besteheder Vorgag beschreibe lässt: 1. Kozipiere der Architektur (Evisio the architecture) ud 2. Optimiere der Architektur (Re fie the architecture). Das Kozipiere der Architektur ist eie zetrale Phase im Rahme der Softwareetwicklug, die i herkömmliche Desiglösuge bereits hireiched Berücksichtigug fidet. I dieser Phase werde die Modelle erstmalig umrisse. Dies erfolgt ormalerweise durch die Architekte, wie das Beispiel i Abbildug 3 zeigt. I der zweite Phase, beim Optimiere der Architektur, geht es darum, das ursprügliche Desig mit dem Iput der Stakeholder abzustimme, um die Qualität zu verbesser ud sicherzustelle, dass es eie gemeisame Vorstellug vo der Lösug gibt. I dieser Phase werde die Modelle vo alle beteiligte Fuktioe (Etwickler, leitede Architekte, Softwareigeieure ud -techiker) überprüft ud mit Kommetare versehe. Obwohl diese Phase sehr wichtig ist, um die Komplexität im Griff zu behalte, Risike zu miimiere ud die Gesamtqualität zu verbesser, erfolgt sie oft sofer sie überhaupt stattfidet auf ustrukturierte Kollaboratives Desigmaagemet Nach der Überahme vo Telelogic stad IBM vor der Aufgabe, IBM Ratioal Software Architect für das Desig vo IT-Aweduge ud Telelogic Rhapsody (jetzt IBM Ratioal Rhapsody) für das Desig eigebetteter Aweduge miteiader zu verküpfe. Eie Neuetwicklug eies dieser beide Produkte wäre icht praktikabel ud die Weiterführug vo zwei eigestädige Lösuge icht zufriedestelled gewese. We Desigteams getret voeiader arbeite (was fast immer der Fall ist, we separate Tools verwedet werde), Abb. 3: Fuktioe ud Aktivitäte beim kollaborative Architekturmaagemet 3

4 Olie Themespecial Architekture 2012 advertorial Abb. 4: Modellauszeichug ud -prüfug Weise ud icht im Kotext des Etwicklugszyklus. I dieser Phase kommt es häufig vor, dass Prüfer ud Stakeholder weder über eie Zugriff auf das fragliche Modellierugstool och über das Kow-how zu desse sachgerechter Nutzug verfüge. Dies führt dazu, dass Prüfuge üblicherweise ahad vo Papierdokumete oder HTML-Exporte durchgeführt werde. Die sich daraus ergebede Äderugsafrage werde oft uorgaisiert per oder auf aderem Wege übermittelt, was eie strukturierte Prüfprozess schwierig ud zeitaufwedig macht. Für verteilte Teams ist die gemeisame Arbeit a Modelle och schwieriger. Dieses Problem wird i IBM Ratioal Desig Maager durch die Verwedug eies zetrale Modellrepositorys gelöst. Mit IBM Ratioal Desig Maager köe Architekte, Aalytiker, Stakeholder ud adere Mitglieder des erweiterte Teams icht ur Suchoperatioe ud Wirkugsaalyse durchführe ud vo der Wiederverwedbarkeit vo Modelle profitiere, soder, wie i Abbildug 4 gezeigt, Modelle über eie Web-Browser direkt kommetiere ud ergäze. Die Kommetare (rechts) ud Modellauszeichuge (i der Mitte) werde veröffetlicht ud sid i Echtzeit sowohl über de Web-Cliet als auch über de Ratioal Software Architect/Rhapsody-Desktop- Cliet zugäglich. Darüber hiaus bietet IBM Ratioal Desig Maager Stakeholder die Möglichkeit, olie- ud kotextbasierte formale Prüfuge durchzuführe. Eie Prüfug fidet ormalerweise statt, we ei bestimmter Meilestei erreicht ist, ud ka uterschiedliche Zwecke diee (beispielsweise als Dokumetatio im Rahme eier vertragliche Vereibarug usw.). Sie folgt eiem defiierte Ablauf ud ka die Beteiligug vo Teammitglieder mit uterschiedliche Fuktioe vorsehe. Der Verfasser/Besitzer der Prüfug begit, idem er eie Prüfug alegt, de Umfag der Prüfug defiiert, das oder die zu prüfede Artefakte auswählt, die Beteiligte (Teilehmer oder Prüfer) auswählt ud ggf. de Fälligkeitstermi der Prüfug festlegt. Sobald die Prüfug begoe wurde, werde die Beteiligte iformiert, die daraufhi ihre Kommetare abgebe ud die Ressource als geprüft kezeiche köe. Der gesamte Prüfprozess ka über de Desig Maager- Web-Cliet ausgeführt werde. Als Teil der auf Jazz basierede CALM- Lösug verwedet Ratioal Desig Maager OSLC-basierte Verküpfuge, um Desigartefakte mit Aforderuge i Ratioal Requiremet Composer, mit Äderugsafrage oder Aufgabe i Ratioal Team Cocert ud mit Testfälle i Ratioal Quality Maager zu verbide. Die (i Abbildug 5 dargestellte) Asicht für die Rückverfolgbarkeit im Lebeszyklus ermöglicht es Etwicklugsteams, die Artefakte währed des gesamte Lebeszyklus azuzeige, i ihe zu avigiere ud die Auswirkuge vo Äderuge zu aalysiere ud zu kotrolliere. Auf diese Weise lasse sich Risike miimiere ud die Qualität etwickelter Aweduge steiger. Desig Maager uterstützt die Wirkugsaalyse außerdem durch Erstellug eies Diagramms, das alle Modellelemete aufzeigt, die vo eier Äderug eies bestimmte Modellelemets betroffe wäre. Für Orgaisatioe ka es weiterhi otwedig sei, Iformatioe zu Model- Abb. 5: Rückverfolgbarkeit im Lebeszyklus uter Eibeziehug vo Modellelemete Olie Themespecial Architekture

5 le i Form vo Dokumete a extere Stakeholder zu übermittel, beispielsweise, we das Modell vo eier extere Vertragsfirma oder eier Prüfstelle wie dem TÜV geehmigt werde muss. Derartige Dokumete ethalte üblicherweise Iformatioe zu de Diagramme ud Modellelemete sowie Iformatioe zu verfolgte Elemete, beispielsweise Aforderuge. I der Jazz-Plattform wird dies uterstützt, idem ei Tool zur Geerierug vo Dokumete auf der Basis mehrerer Quelle zum Eisatz kommt, das Date aus berichtsfähige REST-Services extrahiert ud diese Iformatioe ahad vo kudespezifische Vorlage zu hochwertige Dokumete, beispielsweise im PDFoder Microsoft Word-Format, zusammestellt. I der Artikelreihe [Kar11] fide Sie ausführliche Iformatioe zu diesem Aspekt. Fazit Nicht ur die Nutzug vo verschiedeartige Modellierugstools, soder auch die Zusammearbeit uterschiedlicher Rolle ud Teams im Bereich des Architekturmaagemets stellt für viele Uterehme eie große Herausforderug dar. Eie Kollaboratios- ud Itegratiosplattform wie Jazz, die OSLC-Schittstelle ud OSLC-basierte Verküpfuge als zetrales Kozept utzt, ermöglicht die Itegratio vo lose gekoppelte Modellierugs-Tools mit Lebeszyklusmaagemet-Lösuge. Dies erlaubt ei kollaboratives Architekturmaagemet, das icht ur Modellerstellug, soder auch die Itegratio vo Projektplaug, Äderugsmaagemet, Aforderugsmaagemet ud Testmaagemetaktivitäte rud um Modelle im Fokus hat. Der auf Jazz basierte IBM Refereze Ratioal Desig Maager brigt darüber hiaus ei höheres Maß a Itegratio ud Iteraktio zwische die relevate Rolle im Bereich Architekturmaagemet, idem er eie webbasierte Veröffetlichug, Prüfug, Verfolgug ud Verwaltug vo Modelle durch de Eisatz eies gemeisame Jazz-basierte Model- Repositories realisiert. Dieser Asatz wurde bereits verwedet, um kollaboratives Desigmaagemet für zwei uterschiedliche Modellierugswerkzeuge (Ratioal Software Architekt ud Ratioal Rhapsody) zu uterstütze. [IBM08] IBM: Jazz Itegratio Architecture Overview, Jazz.et, [IBM12] IBM: Ratioal Software Architect Desig Maager & Ratioal Rhapsody Desig Ma-ager, jazz.et, [Kar11] Eiar W. Karlse: Geeratig compliace documetatio usig IBM Ratioal Publishig Egie, developerworks, November [OSLC12] OSLC-Commuity: Ope Services for Lifecycle Kollaboratio, [Pac12] P. Pacholsky: What s ew i IBM Busiess Process Maager V8, Developer Works, Jui *IBM ud das IBM Logo sid eigetragee Marke der IBM Corporatio. Weitere Logos, Uterehmes-, Produkt- oder Serviceame köe Marke aderer Hersteller sei. 5