Der Abschlussbericht zum Guided Project GP SS16_B9 „Microservice-Architektur für webbasierte Enterprise-Anwendungen“ ist verfügbar:
In der Fachgruppe ArchiLab setzen wir unsere Guided Projects in aller Regel als agile Projekte um. Der agile Ansatz erfordert, dass das Team zeitlich und räumlich („co-located“) eng zusammenarbeitet. Das kollidiert mit der Wirklichkeit vieler Hochschulprojekte, bei denen die Studierenden zwischen vielen verschiedenen Aufgaben hin- und herwechseln („Task Switching“ als Form des „Muda“ in der Lean Software Development). Darüber hinaus arbeiten Studierende in Hochschulprojekten oft isoliert voneinander, als pragmatische Reaktion auf die komplexe Zeitplanung (viele parallele Projekte mit jeweils anderen Teamstrukturen).
Für die Durchführung agiler Projekte mit Fokus auf Software-Engineering-Themen wurde daher ein Lehrkonzept erarbeitet, das einen Prozessrahmen nach Scrum und XP auf die Möglichkeiten eines GP anpasst. Die Herausforderungen sind hier beispielsweise:
- Wie kann in der typischen studentischen „Teilzeitallokation“ trotzdem eine agile Taktung und ein agiles Teamgefühl erzeugt werden?
- Wie muss man die Standrollen nach Scrum ggfs. umdefinieren, damit sie in dem Rahmen eines studentischen Projekts funktionieren?
- Wie können den Studierenden professionelle Arbeitsbedingungen (agile Tools, Räumlichkeiten, …) zur Verfügung gestellt werden?
In einem solchen Projekt gehen wir beispielsweise von einer Sprintstruktur von vier Wochen aus. Teams haben die Verpflichtung, einen gemeinsamen Arbeitstag zu definieren, an dem sie physisch präsent sind und in einem Raum (der von uns bereitgestellt wird) gemeinsam an ihrem Projekt arbeiten können
Eine Einführung in agile Prozesse nach Scrum mitsamt Beschreibung des agilen Lehrkonzepts findet sich hier: Agile Project Management with Scrum und XP.
Das agile Vorgehensmodell eignet sich besonders gut, Teamprozesse und die eigene Rolle darin zu analysieren und einzuüben. Daher ist es das Ziel, speziell für den Projekttyp GP-A das Lehrkonzept so zu erweitern, das das von Prof. Stumpf betreute Prozessbegleitungs-Modul sich mit der agilen Methodik verzahnt. Das ist aktuell „Work in Progress“.
Die Überlegungen zu dem Lehrkonzept sind auch in Teilen in eine von mir betreute Masterarbeit eingeflossen.
Am 31.05.2016 wurde in der AM-Veranstaltung durch Mitarbeiterinnen des Hochschulreferats Qualitätsmanagement ein Teaching Analysis Poll (TAP) durchgeführt. Die Resultate habe ich in der darauffolgenden Woche mit den Studierenden diskutiert. Die Ergebnisse finden Sie hier:
Die Ergebnisse der Feedback-Umfrage in ST2 liegen vor. An einer Online-Umfrage nahmen ca. 75% der Hörer teil. Die Ergebnisse wurden dann am 7.6. in der Vorlesung diskutiert. Das Ergebnis ist hier nachzulesen:
Gemeinsam mit Kornelius Fuhrer habe ich im aktuellen CIO-Handbuch den Beitrag „Lean EAM – IT-Landschaften schlank gestalten, Transformationen vernetzt steuern“ veröffentlicht. Die Vorschau auf das das CIO-Handbuch finden Sie hier: Buchinfo CIO Band 4.
Abstract unseres Kapitels
Enterprise-Architektur-Management (EAM) dient der strategischen Planung und Steuerung der IT. Aber welchen Wirkungsgrad hat EAM eigentlich in der Praxis? Lean EAM mit einem schlanken »3 × 3 × 3«-Ansatz ermöglicht es CIOs, ihre Ziele schnell, konsistent und nachhaltig zu operationalisieren.
In diesem Beitrag erfahren Sie:
- wie Sie durch die Vernetzung der Managementfähigkeiten die Effizienz in der IT-Planung erhöhen,
- wie Sie durch ein wertschöpfungsorientiertes EAM-Metamodell den Nutzen maximieren,
- wie Sie durch Geschäftsfähigkeiten Ihre Transformationen effektiv managen.
Es gab mehrere Anfragen zu dem Thema, in welcher Weise frühere Softwaretechnik-Praktikumsleistungen bei Prof. Dr. Jochum angerechnet werden können. Hierzu gilt folgende Regelung:
- Wenn Sie die Prüfung bei Prof. Dr. Jochum wiederholen wollen, so ist dies grundsätzlich möglich, solange er an der Hochschule lehrt. Bitte nehmen Sie dazu direkt mit ihm Kontakt auf.
- Wenn Sie die Prüfung bei mir machen möchten:
- Wenn Sie aus früheren ST-Praktika nur eine Teilnahmebestätigung, aber keine Note erhalten haben (z.B. aus früheren ST1-Praktika, WS14/15 und früher), dann müssen Sie für das entsprechende ST-Praktikum bei mir die Praktikumsleistung erbringen (normalerweise eine im Team erstellte Architekturspezifikation) und sich benoten lassen. Wir können Ihnen die reine Teilnahme am Praktikum erlassen. Aber vermutlich nutzt Ihnen das nicht viel, weil Sie ohne die physische Präsenz beim Praktikum kaum in der Lage sein werden, sinnvoll an einer Gruppenarbeit mitzuwirken.
- Wenn Sie aus früheren ST-Praktika bereits eine Note haben (z.B. ST2 im SS 14 oder 15) und diese behalten möchten: In diesem Fall können Sie einfach die Vorlesung bei mir hören und dann die Prüfung machen. Am Praktikum und der Erstellung der Gruppenleistung brauchen Sie nicht teilzunehmen. Ich empfehle Ihnen das aber trotzdem dringend, weil Vorlesung und Praktikum eng miteinander verzahnt sind, und Sie von der Vorlesung deutlich mehr mitnehmen, wenn Sie auch am Praktikum teilnehmen.
- Wenn Sie Ihre „alte“ Note behalten wollen, aber trotzdem am Praktikum teilnehmen wollen, so ist das möglich. Sie können dann in eine Praktikumsgruppe als zusätzlicher Teilnehmer (also bei 5er Gruppen als sechster) gehen und so am Praktikum teilnehmen. Dadurch kommen Sie wieder besser in den Stoff. Bedingung ist meinerseits nur, dass Sie sich zu Beginn entscheiden, ob Sie benotet oder nur hospitierend teilnehmen wollen (sonst gibt es möglicherweise Konflikte, Mitnahmeeffekte, Unklarheiten). Diese Entscheidung würde ich dann spätestens nach dem ersten Praktikumstermin als irreversibel ansehen. Und Sie müssen sich selbst ein Team suchen, für das Ihr „hospitierender“ Status ok ist. (Suche sollte über ILIAS einfach sein.)
- Wenn Sie aus früheren ST-Praktika noch keine Note haben (oder Ihnen die „alte“ Praktikumsnote nicht genügt), dann können Sie einfach ganz normal am Praktikum teilnehmen.
Das nachfolgende Guided Project wird im SS16 stattfinden.
Problembeschreibung
Eine Microservice-Architektur verfolgt den Ansatz, ein IT-System (in der Regel eine webbasierte Anwendung) als Suite von weitgehend unabhängigen vertikalen Modulen aufzubauen. Diese können (weitgehend) unabhängig voneinander deployed und betrieben werden und benötigen nur ein Minimum an zentraler Kommunikationsinfrastruktur. Kommunikation zwischen Front- und Backend erfolgt über leichtgewichtige Protokolle wie etwa REST.
Dieser Architekturstil erlaubt es, Anwendungen nach Geschäftsfähigkeiten zu segmentieren, die jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können. Das ist insbesondere bei Webportalen mit seinen schnellen Update-Zyklen ein deutlicher Vorteil. Beispielsweise kann so der Produktkatalog eines Webshops und die Zahlungsabwicklung durch unabhängige Microservices realisiert sein, so dass eine explorative Weiterentwicklung des Produktkatalogs den operativen Zahlungsverkehr nur minimal gefährden kann.
Projektbeschreibung
Ziel des Projekts ist es, für eine existierende Showcase-Webanwendung (Restaurantmanagement-System) eine Microservice-Architektur zu konzipieren und umzusetzen. Dabei sollen die Stärken, Schwächen, Risiken und Grenzen dieses Ansatzes im Projektreport evaluiert werden.
Die Entwicklung erfolgt mittels des Open-Source-Projekts Open Application Standard Platform (OASP). OASP hat es sich zur Aufgabe gemacht, bewährte Open-Source-Frameworks zu einem „Best-of-Breed“-Anwendungspaket zu bündeln. Mit Hilfe von OASP können Softwareprojekte für kostensensitive Kunden (z.B. öffentliche Auftraggeber) ohne Zeitverlust durch die sonst übliche „Technologie-Findungsphase“ realisiert werden. Außerdem vermeidet man technologischen Wildwuchs, da OASP eine in sich konsistente Basisarchitektur darstellt. Zufallsarchitektur (Accidental Architecture) wird so zumindest bei der Technologieplattform vermieden.
Zusätzlich zum Basis-Stack in OASP (http://oasp.github.io/) existiert auch eine JavaScript-Variante OASP for JavaScript (OASP4JS, http://oasp.github.io/oasp4js/), die auf dem Google-Framework AngularJS basiert. OASP4JS ist als Plattform für Open-Source-basierte Webanwendungen konzipiert. Die existierende Showcase-Anwendung wurde mit OASP in einem früheren Guided Project erstellt und kann jetzt entsprechend weiterentwickelt werden.
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik erfolgen. Die agilen Teams wählen jeweils einen Scrum Master und einen Product Owner. Das Projekt wird in (vermutlich dreiwöchige) Sprints gegliedert. Ein Vertreter des Projektpartners (Capgemini) wird bei den Entwicklungs-Demos am jeden Sprints als Kunde zugegen sein.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen und deren Umsetzung in webbasierter Software-Entwicklung
- Methodik zur systematischen Evaluierung eines Architekturstils
- Erfahrungen mit Erstellung von AngularJS-basierten Webanwendungen
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Interesse an der Softwarearchitektur sowie Gestaltung von Nutzeroberflächen
- Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
- Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
Externe Projektpartner
Capgemini
Problem Description
Enterprise Architecture Management (EAM) is a strategic management discipline. EAM facilitates the alignment of an enterprise’s strategic goals, business capabilities, and management processes with its IT landscape.
Focus of an EAM initiative can greatly vary, depending on the specific nature of the enterprise, its core business domain, and its process maturity. Therefore, mapping out the scope and target of an EAM initiative with appropriate assessment tools is key to a successful EAM consulting project.
Project Definition
The Guided Project will be divided in two subteams, working each on a specific case study (see below). As a starting point, each team will create an EAM metamodel for their case. Depending on the case, further assessment methods (e.g. expert interviews, maturity assessments, etc.) will come into the picture.
Case Study 1: A leading European intercity bus service company
The intercity bus market has been recently deregulated in Germany and Europe. As a low-fare competitor to rail and air travel, companies in the intercity bus sector face a 2-digit annual growth as well as fierce competition for market dominance.
The recently kicked off EAM initiative in this long-distance bus service company is supposed to establish certain standards and to maintain strategic alignment in a startup, growth-oriented IT environment. Main challenges are:
- Automation of core business processes
- Assessment of the overall EAM approach, and recommendations for improvements
Case Study 2: A large federal IT provider in Germany
This public IT provider is one of three large public IT organizations in Germany, rendering IT services to governmental agencies and ministries. All three currently in the process of being merged into one huge, unified federal IT provider in Germany.
The EAM group in the agency exists for several years. It focuses mainly on the application and technology architecture, and works towards establishing mandatory EAM standards in a very inhomogeneous, fragmented, and historically grown IT landscape. Main challenges are:
- Identification of success factors and blockers for establishing standards
- Defining Good Practices for establishing sustainable, mutually accepted processes for EAM data collection and standards monitoring
In a joint project report, both subteams will sum up their assessment results and recommendations, and evaluate which assessment tools have proven useful for what purpose.
Project goal is to present basic recommendations for both analyzed cases, as well as an evaluation of the strength and weaknesses of the assessment tools used in the process.
Learning Outcomes
- Knowledge of typical EAM goals, methods, success factors, and challenges
- Practical consulting experience, e.g. usage of typical consulting methods like expert interviews
- Creation of an analysis report plus recommendations
- Usage of metamodels as a tool for focus and goal assessment of a strategic management discipline
Requirements
- Basic EAM knowledge
- Interest in analyzing the specific context, goals, and challenges of an EAM initiative
- Willingness to talk to experts (under professor’s guidance)
- Quick mind and good analysis capabilities
- Basic interest in consulting work
External Project Partner
See case studies above
Der Abschlussbericht des Guided Project „Agiler PoC OASP4JS“ ist jetzt verfügbar: Evaluationsbericht OASP / OASP4JS.
Der Bericht beschreibt sowohl die Architektur von OASP und OASP4JS, wie auch den Proof-of-Concept und die aus ihm gewonnenen Bewertungen.
The final report of Guided Project „A Domain-Specific Language for EAM Entities and Views“ is now available.
Authors: Anass Amajoud, Muaaz Asif, Kieu Dai Tran, Markus Engelke, Stefan Kirsch, Jannik Kutscher, Dominic Leuchter, Regys Mene, Christoph Roehr