Entwicklung eines rationalen Entscheidungsprozesses für Architekturentscheidungen

AbstractIt is one of the critical tasks to make the right design- and architectural-decisions in huge and complex developing or reengineering projects. Such decisions have different types. On the one hand there are decisions with minimal effects on the architecture and the software system. On the other hand there are more strategic decisions which effect the architecture widely and change the central characteristics of the software system. Particularly the strategic decisions are very complex, risky and include many uncertain facts about hidden dependencies. The complexity and risks rise if such decisions have to be made in huge projects with 50 or more developers. The decisionmaker, mostly the project manager or the client, is confronted with various factors, assumptions and constraints. Typical examples are competing objectives, alternative solutions and incomplete information about external third-party systems. If such complex decisions have to be made in an unsystematic way, they will lead to uncalculatable risks with enormous bad consequences for the software system and the development project. Examples are changed or missed deadlines, risen development costs or monetary losses due to an outage of a business critical system.However, the specific characteristics of architectural decisions are not considered by existing methods and concepts to support decision making. They are too detailed, focussed on source code and require information in a formal quality and completeness. These information can not be gathered within such huge projects because of the high effort, time pressure and lacking resources. Therefore an architectural decision process is missing to structure the various information, assumptions and subjective estimations and so you can make such complex and risky decisions in a systematic and focussed way.The main objective of the following dissertation is to reduce the complexity, uncertainty and risks of architectural decisions in order to avoid additional changes and adjustments as well as to achieve the desired objectives. An architectural decision process with four phases is developed on the basis of the generic proceeding of the decision theory. This process includes methods and concepts in order to establish alternative solutions on the basis of the objectives, conditions and the model of the existing architecture. The various alternative solutions are evaluated through a systematic proceeding in order to identify and select the best solution. The developed process includes the specific characteristics of software architectures:Besides incomplete information and uncertainties, it is possible to observe hidden dependencies through scenario-based analysis methods, establishted by the concepts of the Architecture-Level-Modifiability-Analysis (ALMA).Due to the complexity and risks, huge architectural changes have to be separated into smaller tasks. This is supported by a stepped planning, from abtract analysis to more detailed planning.To achieve a reasonable relation between the analysis effort and the benefis from the analysis in terms of reduced risks, complexity and uncertainty, the depths of the analysis can be adjusted flexibly by clear objectives. Two practical applications show, how to make architectural decisions in a systematic way by using the decision process. Afterwards, the assumptions and expectations, which have been used for the decision making, are evaluated by comparing with the consequences of the real implementation. Due to the results of the comparison it can be described clearly, which advantages and disadvantages the application of the decision process has.In Softwareentwicklungsprozessen müssen permanent die richtigen Design- und Architekturentscheidungen getroffen werden, damit die mit dem Entwicklungs- oder Reengineeringprojekt verbundenen Ziele in vollem Umfang erfüllt werden können. Diese Entscheidungen können dabei von unterschiedlicher Natur sein. So werden einerseits Entscheidungen getroffen, die nur geringe Auswirkungen auf das Softwaresystem haben. Auf der anderen Seite existieren Entscheidungen mit strategischem Charakter, die sich auf große Teile der Architektur und auf zentrale Systemeigenschaften auswirken. Gerade die strategischen Architekturentscheidungen sind in Großprojekten mit 50 oder mehr Entwicklern von hoher kombinatorischer Komplexität und beinhalten große Unsicherheiten über versteckte Abhängigkeiten. Der Entscheidungsträger, meist der Architekt oder der Projektleiter, ist mit einer Vielzahl unterschiedlicher Faktoren und Bedingungen konfrontiert. Hierzu zählen konkurrierende Ziele oder alternative Lösungsansätze, für die meist nur unvollständige Informationen vorliegen. Unter diesen Voraussetzungen führen unsystematische Entscheidungen zu unkalkulierbaren Risiken mit gravierenden Folgen für das Softwaresystem und das Entwicklungsprojekt, wie z. B. eine deutliche Erhöhung der Entwicklungskosten oder zeitliche Verzögerungen. Die bereits existierenden Methoden zur Entscheidungsunterstützung berücksichtigen die spezifischen Eigenschaften von Softwarearchitekturen zu wenig. Sie sind zu feingranular, codeorientiert und benötigen Informationen in einer formalen Genauigkeit und Vollständigkeit, die bei Architekturentscheidungen in Großprojekten aus Aufwandsgründen nicht erhoben werden können. Somit fehlt eine Unterstützung des Entscheidungsträgers, um die Vielzahl an Einzelinformationen und subjektiven Einschätzungen zu strukturieren sowie die Entscheidungsfindung systematisch und fokussiert durchzuführen. Mit der vorliegenden Dissertation wird das Ziel verfolgt, die Komplexität, Unsicherheiten und Risiken bei Architekturentscheidungen zu reduzieren, um aufwandsintensive Korrekturen zu vermeiden und die Architekturziele in vollem Umfang zu erfüllen. Auf der Grundlage des in der Entscheidungstheorie beschriebenen generischen Vorgehens zur Entscheidungsfindung wird ein Vier-Phasen-Entscheidungsprozess entwickelt. Dieser Prozess beinhaltet Methoden und Konzepte, um ausgehend von den Zielen, Rahmenbedingungen und der existierenden Architektur systematisch alternative Lösungsansätze zu entwickeln. Im Anschluss werden die Lösungsansätze nach rationalen Gesichtspunkten im Hinblick auf die Zielerreichung bewertet, um eine ausgewogene Entscheidung zu treffen. Der entwickelte Entscheidungsprozess berücksichtigt dabei die speziellen Eigenschaften von Softwarearchitekturen: Trotz unvollständiger Informationen und Unsicherheiten können versteckte Abhängigkeiten mit einem szenariobasierten Analyse- und Bewertungsansatz, auf der Grundlage der Architecture-Level-Modifiability-Analysis (ALMA), sichtbar gemacht werden. Die systematische Aufteilung komplexer Entscheidungen in handhabbare Einzelentscheidungen wird durch die Anwendung eines gestuften Verfahrens mit Grob- und Feinplanung erreicht.Um ein ökonomisch sinnvolles Verhältnis zwischen dem Aufwand zur Entscheidungsfindung und dem Nutzen in Form von reduzierten Risiken, Unsicherheiten und einer geringeren Komplexität zu ermöglichen, kann die Detailtiefe der Analysen anhand eindeutiger Kriterien flexibel angepasst werden.Zwei praktische prototypische Anwendungen des Entscheidungsprozesses zeigen auf, wie eine Architekturentscheidung systematisch und nach rationalen Gesichtspunkten durchgeführt werden kann. Die während der Entscheidungsfindung getroffenen Annahmen und Erwartungen werden im Anschluss mit den Ergebnissen der realen Implementierung verglichen. Anhand des Vergleichs wird klar erkennbar, welche versteckten Abhängigkeiten durch den Einsatz des Entscheidungsprozesses bereits frühzeitig erkannt wurden sowie welche Vorteile die richtige Entscheidungsfindung für das Softwaresystem und das Entwicklungsprojekt hat

Synchronisation eingebetteter Architekturentscheidungen mit Architekturentscheidungsprogrammen

Diese Arbeit behandelt das Thema der Synchronisation von quellcode-intern und quellcodeextern dokumentierten Softwarearchitekturentscheidungen. Einerseits gibt eine Java-Annotation, welche es erlaubt Architekturentscheidungen im Java-Quellcode zu hinterlegen, andererseits können Architekturentscheidungen auch mit dem Modellierungswerkzeug AD-Mentor modelliert und in einem Versionierungsrepository hinterlegt werden. Da Architekturentscheidungen somit an verschiedenen Stellen dokumentiert werden können, ist es sinnvoll diese zu synchronisieren. In dieser Arbeit wird ein Konzept zur Synchronisation von eingebettete Architekturentscheidungen mit modellierten Architekturentscheidungen anhand eines Versionierungsrepository vorgestellt und implementiert. Zur Verifikation des erstellten Konzepts wurde eine Fallstudie anhand des implementierten Synchronisationsprogramms durchgeführt und ausgewertet

Nachvollziehbare Entscheidungsprozesse in der industriellen Softwareentwicklung durch Rationale Management - Ansätze zur Umsetzung bei der SAP AG

Das Software Engineering ist heute geprägt von schnelllebigen Technologien und Trends, verteilten, arbeitsteiligen Projekten mit vielen Interessenvertretern (Stakeholdern) und einem umkämpften globalen Markt. In diesem Umfeld wird es zur Herausforderung, gewonnene Erkenntnisse festzuhalten und daraus als gesamte Organisation zu lernen, um Fehler nicht zu wiederholen oder gar ganz zu vermeiden. Information und Wissen sowie Kommunikation und Wissenstransfer zusammen mit wohl reflektierten Entscheidungen werden daher immer mehr zum kritischen Erfolgsfaktor einer Organisation. Rationale Management (RM) (engl. Begründungsmanagement) ist ein Ansatz, um diese Erfolgsfaktoren auf allen Ebenen einer Organisation einzubeziehen. Durch das Aufzeigen der Gestaltungsalternativen (design space analysis) sollen die Entscheidungsträger (gegebenenfalls in einem kollaborativen Prozess) anhand von adäquaten Kriterien zu konsistenten und argumentativ begründeten Entscheidungen gelangen. Über eine geeignete Erfassung, Aufbereitung und Nutzung des Rationale soll eine Verbesserung der Entscheidungskommunikation, des Wissenstransfers und der Informationsgewinnung über individuelle, organisatorische und funktionale Grenzen der Organisation hinweg erreicht werden. In der vorliegenden Arbeit werden die im Kontext des Software Engineering diskutierten Ansätze für Rationale Management zusammengetragen. Sie werden strukturiert nach verschiedenen Wissensbereichen des Software Engineering aufbereitet und gegenübergestellt. Basierend darauf und am Beispiel der SAP AG wird untersucht wie Rationale Management in unterschiedlichen Bereichen eines Vorgehensmodells gewinnbringend integriert werden könnte. Hierzu werden konkrete Vorschläge im Umfeld der Kommunikation von Projektlenkungsentscheidungen oder der Erfassung von Rationale im Kontext von Anforderungspriorisierungen erarbeitet. Die dabei gewonnenen Erkenntnisse bei der Integration von Rationale Management in die Prozesse – auch in Bezug auf die Projektpolitik – werden abschließend festgehalten

Formelle Designentscheidungen

Das klassische Arbeiten in Unternehmen unterliegt einer Transformation – dies ist seit der im Frühjahr 2020 in Deutschland angekommenen Corona-Pandemie für die breite Bevölkerung spürbar. Aus einer oftmals vorhandenen Möglichkeit des Arbeitens von Zuhause wird plötzlich eine verbindliche Phase des Rückzugs ins Homeoffice. Aus dieser Situation heraus stellt sich vermehrt die Frage, wie sich diese Lage während und nach der Pandemie weiter entwickeln wird. Um die Innovationskraft in Unternehmen zu erhalten und zu steigern, ist eine effiziente Zusammenarbeit unterschiedlicher Disziplinen essentiell. Das im folgenden Artikel vorgestellte Forschungsvorhaben entsteht im Rahmen des globalen Innovationsmanagements der Robert Bosch GmbH am Campus für Forschung und Vorausentwicklung in Renningen. Ziel ist die Übersetzung eines regulären Coworking Space in einen sogenannten Corporate Coworking Space innerhalb eines Unternehmens. Durch eine ganzheitliche Gestaltung und Bewertung soll aufgezeigt werden, ob ein solches Vorhaben die disziplinübergreifende Zusammenarbeit unterstützen kann

Das Spannungsfeld zwischen EAM und agilen Teams im Kontext von agilen Skalierungsframeworks

Die Einführung von agilen Skalierungsframeworks birgt Herausforderungen bezüglich der Integration in ein bestehendes Enterprise Architecture Management (EAM). Das EAM behält in der Regel Elemente seiner Wasserfallnatur, während den agilen Teams durch die Einführung der agilen Arbeitsweise mehr Autonomie gewährt wird. Entsprechend wird die Steuerung der agilen Teams im Vergleich zum Wasserfallvorgehen schwieriger. Die agilen Teams streben die schnelle Wertlieferung an, während das EAM die Erreichung der strategischen Ziele durch das Verwirklichen der Soll-Architektur anstrebt. Die Prinzipien der agilen Arbeitsweise, die durch die agilen Teams ausgelebt werden, resultieren in Abweichungen von bewilligter Architektur und den EAM-Vorgaben, was die Erreichung des Soll-Zustands der IT-Landschaft hindert. Die verschiedenen Ziele und Prioritäten der zwei Parteien führen zu einem Spannungsfeld, das die Zusammenarbeit beeinträchtigt. Mit dieser Problemstellung befasst sich auch die Zürich Versicherungs- Gesellschaft AG (Zurich), die das agile Skalierungsframework ‹SAFe› (Scaled Agile Framework) im Einsatz hat und wo das Spannungsfeld zwischen der EAM-Einheit ‹CrEAM› (Collaborative EAM) und agilen Teams beobachtet werden kann. In dieser Masterarbeit wird untersucht, wie das Spannungsfeld zwischen EAM und agilen Teams im Kontext von agilen Skalierungsframeworks aufgelöst oder verbessert werden könnte. Dafür wurden aus der Literatur Aspekte des Spannungsfeldes abgeleitet: 1) unzufriedenstellende Kommunikation, 2) Mangel an Einbindung der agilen Teams in die Architekturprozesse, 3) unpassende Ebene der Steuerung durch EAM, 4) Konflikt zwischen EAM-Governance und Team-Autonomie, 5) Mangel an technischen Kenntnissen der Enterprise Architekten und 6) Mangel an Bewusstsein und Akzeptanz von EAM seitens der agilen Teams. Diese Aspekte wurden im Rahmen der Einzelfallstudie bei der Zurich angewendet, um durch Interviews mit Enterprise Architekten und Product Ownern aus den agilen Teams Daten zu den jeweiligen Aspekten zu erheben. Durch die qualitative Analyse der Interviews wurden drei Ausprägungen des Spannungsfeldes identifiziert, die bei Zurich am stärksten das Spannungsfeld bilden. Die Abweichungen der agilen Teams von der bewilligten Architektur sind zentrale Auslöser des Spannungsfeldes. Um die Lage zu verbessern, werden Veränderungen bezüglich der Zuständigkeiten der Rollen der Product Owner und der Enterprise Architekten empfohlen. Die Product Owner sollten sicherstellen, dass die agilen Teams sich an die bewilligte Architektur halten. Ebenfalls sollten die Product Owner den Enterprise Architekten transparent melden, wenn die agilen Teams von der bewilligten Architektur abweichen möchten. Die Enterprise Architekten sollten zusammen mit den agilen Teams die Abweichung entwerfen und dabei sicherstellen, dass diese den EAM-Vorgaben entspricht. Ein weiterer Auslöser des Spannungsfeldes ist der Mangel an Bewusstsein bezüglich der Rolle von CrEAM und über die EAM-Prozesse seitens der agilen Teams. Hier wird empfohlen, dass die Enterprise Architekten sich regelmässig mit den Product Ownern austauschen, sie transparent informieren, sie in EAM-Prozessen begleiten und ihr Feedback einholen. Der dritte Auslöser des Spannungsfeldes ist der Mangel an Einbeziehung der agilen Teams in die Definition von Standards und die Bestimmung von strategischen Tools. Um das Spannungsfeld diesbezüglich aufzulösen, sollen die Enterprise Architekten aktiv die Vorschläge der agilen Teams entgegennehmen und deren Expertise in den Prozess einfliessen lassen. Durch die Erweiterung der Rollen um die vorgeschlagenen Zuständigkeiten kann die Spannung zwischen EAM und agilen Teams reduziert oder sogar aufgelöst werden, da die aktuellen Rollenprofile der Enterprise Architekten und Product Owner nicht auf die effektive Zusammenarbeit der zwei Parteien ausgerichtet sind

Parametrisierung der Spezifikation von Qualitätsannotationen in Software-Architekturmodellen

Um qualitativ hochwertige Softwaresysteme zu entwickeln, muss in einem Softwareentwicklungsprozess eine Vielzahl von Qualitätsattributen berücksichtigt werden. Je höher die Komplexität von Softwaresystemen wird, desto wichtiger wird es, die zu erwartende Qualität im Vorfeld zu beurteilen. Jedoch existiert eine Reihe von Qualitätsattributen für Softwaresysteme, welche erst aus den strukturellen Eigenschaften der Softwarekomponenten in diesem Softwaresystem bestimmt werden können. Diese Qualitätsattribute werden in strukturierten und formalisierten Entscheidungsunterstützungsprozessen zur Optimierung der Softwarearchitektur oft nicht genutzt. Einer der Gründe dafür ist, dass dieses Wissen um die Qualitätsattribute einer Softwarekomponente in der Regel nur mit diesen Softwarekomponenten verknüpft ist und nicht mit den strukturellen Eigenschaften eines komponentenbasierten Softwaresystems. So bleibt ein Großteil dieses Wissens unberücksichtigt und kann daher nicht für Kompromissentscheidungen in automatisierten Softwarearchitektur-Optimierungsansätzen genutzt werden. In dieser Masterarbeit wird ein Rahmenwerk definiert, um Regeln zu spezifizieren zum Transformieren der Qualitätsattribute einer Softwarekomponente in Relation zu ihren strukturellen Eigenschaften in ihrem komponentenbasierten Softwaresystem. Mit diesem Ansatz kann architekturdefiniertes Wissen in Abhängigkeit der Systemarchitektur parametrisiert werden. Hierdurch können die Qualitätsattribute einer Softwarekomponente, welche erst aus den spezifischen Eigenschaften einer konkreten Softwarearchitektur abgeleitet werden können, spezifiziert und so auch ausgewertet werden. Durch diese verbesserten Auswertungen von strukturellen Eigenschaften sollen die Werkzeuge für Softwarearchitekten verbessert werden, sodass diese bessere Entscheidungen in einem Softwareentwicklungsprozess treffen können. Für die Validierung des Ansatzes werden zwei voneinander unabhängige Fallstudien durchgeführt, um dessen Anwendbarkeit und Nutzen zu zeigen. Zu diesem Zweck wird der Ansatz dieser Masterarbeit sowohl auf eine wissenschaftliche Fallstudie angewandt wie auch auf ein Beispiel, welches sich auf ein reales Industriesystem bezieht. Hiermit wird gezeigt, wie der Ansatz helfen kann, Kompromissentscheidungen über die Softwarearchitektur zwischen mehreren Qualitätsmerkmalen unter der Berücksichtigung der strukturellen Eigenschaften des Softwaresystems zu treffen

Optimierung von Verfahren zur Lösung rechtsrelevanter Wissensprobleme in kritischen Infrastrukturen : Befunde im Smart Grid und technikrechtliche Empfehlungen

Die Arbeit befasst sich mit dem vielschichtigen Interessenausgleich sowie der technikrechtlichen Regulierung an der Schnittstelle von Energiewirtschaftsrecht und Datenschutzrecht. Im Smart Grid wird für die Optimierung von Regulierungswissen ein Verfahren der Bundesnetzagentur vorgeschlagen. Durch dessen Anreicherung um Aspekte der datenschutzkonformen Technikgestaltung kann eine Komplexitätsreduzierung auch durch Visualisierung - angelehnt an das Bau- und Planungsrecht - erreicht werden

Design Research 2020: Kolloquium Technisches Design: Technische Universität Dresden

Der vorliegend Band 14 der Reihe Technisches Design schlägt nach Tagungsbänden und Dissertationsschriften – dem Charakter nach eher abgeschlossene Werke – eine Brücke in die Zukunft der Forschung im Technischen Design, indem es die Textfassungen von acht Beiträgen des ersten öffentlichen Kolloquiums Technisches Design vom September 2020 beinhaltet, die allesamt aus dem Prozess laufender Promotionsvorhaben verfasst wurden. Diese acht Arbeiten stehen damit auch stellvertretend für ganz individuelle Forschungsperspektiven und Schwerpunktsetzungen innerhalb des weiten Möglichkeitsraums aktueller Designforschung. Die Design-Promovierenden stellen ihre jeweiligen aktuellen Stände und besonderen Aspekte ihrer Forschungsarbeiten zur Diskussion und erlauben damit einen Einblick in verschiedenste Phasen ebenso wie sichere und noch offene Passagen ihrer Auseinandersetzung. Die Bandbreite reicht von ausgearbeiteten Exposees der Promotionsvorhaben über die Ergebnisse systematischer Literaturanalysen bis hin zur Darstellung konkreter Untersuchungsplanungen. Alle Beiträge eint die Auseinandersetzung mit dem menschlichen Erleben und Interagieren mit gestalteten Artefakten. Innerhalb dieses Felds decken die Artefakte ein sehr breites Spektrum von nachhaltigen Materialien oder Fertigungsverfahren über vorwettbewerbliche Technologiedemonstratoren bis hin zu kollaborativen Arbeitsplätzen ab. Innerhalb der Arbeiten werden Bezüge und Fragestellungen zu Menschen und Umgebungen in interdisziplinären Entwicklungsprozessen sowie zur Beurteilung und Kommunikation von Neuem durch Expert:innen und Laien entwickelt. Mit der Bandbreite dieser acht Beiträge wird das thematische Spektrum von Promotionsvorhaben an der Professur für Technisches Design gut ausgeleuchtet und entsprechend stolz sind wir auf diesen ersten Band, der ausschließlich Arbeiten unserer Promovend:innen zeigt. Band 14 der Reihe Technisches Design gibt einen aktuellen Einblick in die Forschung an einer der größeren Designforschungseinrichtungen im deutschsprachigen Raum und lässt Sie teilhaben an empirischer Forschung zur erlebenszentrierten Entwicklung vielfältiger Mensch-Technik-Interaktion

Architekturbasierte Bewertung und Planung von Änderungsanfragen

Die Software-Architektur umfasst die technische Organisation eines Software-Systems und die Prinzipien, die den Entwurf und die Evolution des Systems bestimmen. Die Problemstellung ergibt sich aus der Software-Evolution, wenn das System angepasst werden muss. Der Beitrag dieser Arbeit ist ein Verfahren zur Änderungsanfragenanalyse im Architekturmodell, welches die Ableitung von Tätigkeiten in nachgelagerten Tätigkeitsfeldern und Lebenszyklusphasen ermöglicht