Projektbeschreibung
Die Neuentwicklung der Projektbörse Campus GM läuft seit etwa einem Jahr, vorangetrieben in verschiedenen Lehrveranstaltungen und inhaltlich betreut durch das ArchiLab-Team. Guided-Projects-Teams übernahmen die Verantwortung für Microservices und deren Entwicklungs- und Ausführungsinfrastruktur. Je nach Bedarf wurden neue Microservices entwickelt, Umsysteme eingebunden und die Infrastruktur verfeinert. Die entwickelten Microservices basieren dabei auf dem Spring Boot Framework (Java).
Langfristiges Ziel des Projekts ist es, für den Campus Gummersbach ein API-Ökosystem zu schaffen. Die verschiedenen hier genutzten und teilweise auch entwickelten Applikationen (Projektbörse, Praktikumsverwaltung, ILIAS, HOPS, …) sollen unabhängig und ohne den Zwang zur gegenseitigen Rücksichtnahme und Abstimmung entwickelt werden können. Andererseits soll aber auch eine lose Vernetzung mit einem Austausch von Daten möglich sein. Dies wird durch unsere Microservice-Infrastruktur, an der wir im ArchiLab-Team kontinuierlich arbeiten, grundsätzlich ermöglicht.
Im kommenden Semester möchten wir hier den nächsten Schritt gehen und mit einer ersten schmalen Version der Projektbörse, die mit HOPS über eine REST-Schnittstelle vernetzt ist, live gehen. Dazu gehören dann auch alle Aspekte des Livegangs:
- Weiterentwicklung der Projektbörse in Code und Infrastruktur so, dass ein Continuous Delivery möglich ist (und die Produktivdaten erhalten bleiben)
- Gewinnen von „Early Adopters“ unter Professoren und Studierenden (drei Professoren sind schon als Stakeholder an Bord)
- Einholen von neuen Praxis-Anforderungen, wenn man mit Stakeholdern spricht, und das Einarbeiten von diesen Anforderungen gemäß des Domain-Driven-Design-Ansatzes.
Bei diesen Schritten werden die Betreuer das Team intensiv unterstützen.
Projektmethodik
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen.
Vermutlich wird der wesentliche Teil des Projekts als Blockveranstaltung mit drei Tagen die Woche im März stattfinden.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen
- Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
- Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Grundkenntnisse Linux
- Interesse an professioneller Software-Entwicklung
- Interesse an der Softwarearchitektur
- Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
- Bereitschaft sich eigenständig in neue Frameworks, Tools und Konzepte einzuarbeiten
- Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
- Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen
Externe Projektpartner
–
Problembeschreibung
Machine Learning und Deep Learning haben sich in den letzten Jahren rasant entwickelt. Insbesondere im Bereich der natürlichen Sprachverarbeitung (Natural Language Processing, NLP) sind ChatBots konkrete Anwendungsbeispiele dieser Technologien. Sie bilden für den Menschen erlebbare Schnittstellen, um direkt mit „der Maschine“ zu kommunizieren.
In der Zurich Gruppe Deutschland wird derzeit schon an einem ChatBot für Schadenmeldungen geforscht. Dieser nutzt ML Methoden des NLP, um die Klassifizierung des Gesagten vorzunehmen und Entitäten aus dem Text zu extrahieren. Der Nutzer wird dann abhängig von dem so gebildeten Kontext intelligent durch einen Entscheidungsbaum geführt. Zurzeit wird hierzu eine kommerzielle Software genutzt.
Die Nutzung eines Entscheidungsbaums in Kombination mit einem Kontext ermöglicht die Entwicklung von komplexen und genau definierten State Machines. Und genau das ist die Herausforderung dabei: Kleine Änderung in der Abfragelogik ziehen z.T. umfassende Änderungen in der gesamten Entscheidungslogik mit sich. Die Skalierung eines solchen Vorhabens ist kaum möglich, da es schwierig (unmöglich) ist, alle möglichen Konversationen explizit zu modellieren.
Projektdefinition
Eine mögliche Lösung dieses Problems besteht darin, ein probabilistisches Modell basierend auf historischen Konversationen zu entwickeln. Dies beruht auf der Idee, dass es einfach ist, innerhalb einer Konversation zu spezifizieren, ob eine Antwort richtig oder falsch ist. Ein solches Modell kann mit Hilfe von Supervised, Reinforcement oder Interactive Learning Methoden entwickelt werden.
Die Projektarbeit gliedert sich in zwei Ziele:
- Eine Weiterentwicklung der aktuellen State Machine in ein probabilistisches Modell mit Hilfe des Open Source Stacks ai. Dazu zählen u.a. die Überführung der (aktuell in der kommerziellen Software erstellten) „Dialogflows“ nach Rasa.
- Die Entwicklung einer Zielarchitektur zur Einbindung des ChatBots in die bestehende Systemlandschaft einer großen Versicherung. Eingehende Chats sollen von verschiedenen Endpoints möglich sein (z.B. FB, Webchat, Alexa, Telegram,…). Die Einbindung ermöglicht eine Integration bestehender Backendsystem, wie z.B. Kundendatenbanken, ausgehend von einer lokal integrierten Cloud Server Architektur.Weiterhin soll die Zukunftsfähigkeit der Plattform sichergestellt werden um weitere Use Cases, wie z.B. die Klassifizierung von Emails oder transkribierter (oder text-to-speech) Telefonate mittels der Rasa NLP Engine zu realisieren.
Projektform
Der Projektpartner Zurich wird das Projekt sehr aktiv begleiten und bei der Einarbeitung in Konzepte und Technologien unterstützen.
- Ein Zurich-Mitarbeiter mit Projektvorwissen wird dauerhaft im Team mit coden.
- Der Sponsor (Jeronim Morina, https://www.linkedin.com/in/jeronim-morina/) wird in der „heißen“ Projektphase ca. 1d / Woche für das Projekt.
Das Projekt wird in agilen Sprints durchgeführt. Die Scrum-Master-Rolle wird von einem TH-Köln-Betreuer eingenommen, der Product Owner wird J. Morina sein.
Aufgrund dieser schon sehr konkreten Planung und gewisser organisatorischer Bedingungen auf Seiten der Zurich sind für das Projekt zeitliche Rahmenbedingungen gesetzt, die leider nicht veränderlich sind.
- Das Projekt beginnt am Mo 3.9.
- In der Zeit von 3.9. bis 10.10. (6 Wochen) sind jede Woche die Tage Mo, Di und Mi als Vor-Ort-Arbeitstage zu reservieren.
- Danach wird es noch einen Produktifizierungs- und Finalisierungs-Sprint geben, der zeitlich noch nicht fixiert ist; es kann aber davon ausgegangen werden, dass das Projekt früh endet.
Wer diese Randbedingungen nicht einhalten kann, kann an dem Projekt leider nicht teilnehmen.
Learning Outcomes
- Kenntnisse in Machine Learning, NLP und ChatBots
- Praktische Erfahrungen in Cutting Edge Software Development / Architecture
- Arbeiten im agilen Team
Voraussetzungen
- Python
- Aus der Dokumentation von rasa.ai (https://core.rasa.com/motivation.html):
- Why python? Because of its ecosystem of machine learning tools. Head over to But I don’t code in python! for details.
- Is this only for ML experts? You can use Rasa if you don’t know anything about machine learning, but if you do it’s easy to experiment.
- How much training data do I need? You can bootstrap from zero training data by using interactive learning. Try the tutorials!
- Kenntnisse moderner Softwaretechnologien wie z.B. Web-Services
- Bereitschaft, sich in Konzepte der AI und des NLP einzuarbeiten
- Bereitschaft, agil und teilweise im Blockformat zu arbeiten
- Aus der Dokumentation von rasa.ai (https://core.rasa.com/motivation.html):
Externe Projektpartner
Zurich Gruppe Deutschland
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, ganze Anwendungslandschaften nach Geschäftsfähigkeiten zu segmentieren. Die resultierenden Teilfunktionalitäten können dann in Form von Microservices implementiert und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können.
Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von Räumen, Praktika, Veranstaltungen, Projekten, Prüfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.
Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gewähren, wäre ein Architektur-Blueprint für Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine große Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.
Projektbeschreibung
Ziel des Projekts ist es, für die Applikationslandschaft „Campus Gummersbach“ einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.
Dieses Konzept soll am Beispiel der Projektbörse Campus GM pilotiert und iterativ-inkrementell erarbeitet werden.
In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierfür eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Im SS 18 wurde in einem Guided Project mit der eigentlichen Implementierung der Projektbörse begonnen, erste Microservices wurden umgesetzt und nötige Infrastruktur geschaffen.
Die Teams des folgenden Guided Projects übernehmen die Verantwortung für einzelne (bereits bestehende) Microservices und kümmern sich sowohl um Weiterentwicklung/Betrieb der Services als auch der Entwicklungs- und Ausführungsinfrastruktur. Je nach Bedarf werden neue Microservices entwickelt, Umsysteme eingebunden und die Infrastruktur verfeinert. Die entwickelten Microservices basieren dabei auf dem Spring Boot Framework (Java).
Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu verfeinern, zu validieren und offene Fragen zu identifizieren.
Projektmethodik
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die Teams werden hierbei durch wissenschaftliche Mitarbeiter in der Rolle des Scrum Masters betreut. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen
- Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
- Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Grundkenntnisse Linux
- Interesse an professioneller Software-Entwicklung
- Interesse an der Softwarearchitektur
- Interesse an komplexen Aufgabenstellungen und methodischem Vorgehen
- Bereitschaft sich eigenständig in neue Frameworks, Tools und Konzepte einzuarbeiten
- Bereitschaft, Teamarbeit tatsächlich physisch gemeinsam (im gleichen Raum, „collocated“) durchzuführen, um zu einem agilen Team zu reifen
- Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen
Externe Projektpartner
–
Problembeschreibung
„Warum ist im ThoughtWorks TechRadar das UI-Framework ReactiveX auf Status ‚Adopt‘, während Angular2 nur den Status ‚Assess‘ hat?“
Auf eine Frage wie diese werden die Teilnehmer dieses Guided Projects am Ende vermutlich eine Antwort haben. Das ThoughWorks TechRadar (https://www.thoughtworks.com/radar) ist als Bewertung von innovativen Technologien mittlerweile in die obersten Liga der industrieweit beachteten Ratings vorgestoßen. Es bewegt sich auf einer etwas detaillierteren, programmiernäheren Ebene als beispielsweise der Gartner® Magic Quadrant oder Forrester Wave™.
Wie soll man aber als „einfacher Entwickler“ mit den Aussagen solcher Marktübersichten umgehen? Muss / soll / kann man diese einfach so hinnehmen? Da es immer gut ist, sich sein eigenes fundiertes Bild zu machen, werden wir in diesem Guided Project genau dies tun.
Projektdefinition
ThoughtWorks bietet an, ihr Tool zu nutzen, um eine eigene Version des TechRadars zu erstellen (https://info.thoughtworks.com/visualize-your-tech-strategy-guide.html). Dies wird der Inhalt dieses Projekts sein.
Fokussiert auf einen bestimmten, im Rahmen der verfügbaren Zeit machbaren Ausschnitt aus aktueller Entwicklungstechnologie wird das Team einen methodischen Bewertungsansatz für diese Technologien entwickeln, und diesen Bewertungsansatz dann auf das gewählte Segment anwenden. Als Klassifikation werden wir dabei der Einfachheit halber den ThoughtWorks-Ansatz übernehmen.
Dies bedeutet die folgenden Schritte, die das Team eigenständig durchführt:
- Auswahl von 1…n geeigneten Technologiesegmenten, je nach Machbarkeit
- Definition von Kriterien und Auswertungsmethoden zur Klassifikation, z.B.
- Auswertung von Quellen wie Literatur, Blogs, …
- Umfragen
- Kurze Spikes / Proof-of-Concepts
- …
- Durchführung der Klassifikation
- Bewertung, Dokumentation, Präsentation
Learning Outcomes
- Selbstorganisiertes, methodisches Vorgehen
- Durchführung eines Technologie-Auswahlprozesses
- Verteidigung von Bewertungen gegen fachliche Kritik
- Tiefgehende Beschäftigung mit aktuellen Entwicklungstechnologien
- Einsicht in aktuelle Trends und Marktentwicklungen
Voraussetzungen
- Programmier-Affinität
- Interesse an Software-Technologie
- Spaß an methodischem Arbeiten (langes Stehen an Whiteboards mit viel Diskussion)
- Hartnäckigkeit, um eigene Einschätzungen wirklich „wasserdicht“ bewerten zu können
Externe Projektpartner
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, ganze Anwendungslandschaften nach Geschäftsfähigkeiten zu segmentieren. Die resultierenden Teilfunktionalitäten können dann in Form von Microservices implement und lose gekoppelt werden. So entstehen Systeme von Anwendungen, die einerseits miteinander kommunizieren, und andererseits jeweils mit einem Höchstmaß an Unabhängigkeit entwickelt und gewartet werden können.
Eine Microservice-Architektur bietet sich daher besonders an, um Softwareprojekte an der Hochschule (wie dem Campus Gummersbach) zu realisieren. Es ist offensichtlich sinnvoll, Systeme zur Verwaltung von Räumen, Praktika, Veranstaltungen, Projekten, Prüfungen etc. miteinander zu vernetzen. Andererseits werden diese Anwendungen von verschiedenen Gruppen mit verschiedenen Technologien gepflegt. Eine enge Abstimmung ist an der Hochschule weder sinnvoll noch durchsetzbar.
Um solchen Projekten ein Maximum an Freiheit bei Technologiewahl und Umsetzungsform zu gewähren, wäre ein Architektur-Blueprint für Basistechnologien zur Umsetzung von Services und Koppelung von Schnittstellen eine große Hilfe. Dies soll im Rahmen dieses Projekts an einem konkreten Beispiel konzipiert und pilotiert werden.
Projektbeschreibung
Ziel des Projekts ist es, für die Applikationslandschaft „Campus Gummersbach“ einen Architektur-Blueprint, basierend auf dem Microservices-Ansatz, zu konzipieren.
Dieses Konzept soll am Beispiel der Projektbörse Campus GM pilotiert werden. In der Master-Veranstaltung Anforderungsmanagement (SS17) wurde hierfür eine Anforderungsspezifikation (Lastenheft) erstellt. Darauf aufbauend hat die Master-Veranstaltung FAE eine Architekturspezifikation (Pflichtenheft) erstellt. Je nach Teilnehmerzahl wird/werden einer oder mehrere Services der Projektbörse sowie prototypisch entwickelt. Dazu werden Mocks eines oder mehrere Umsysteme (wie etwa ILIAS oder HOPS) erstellt.
Diese Pilotanwendung wird genutzt, um den entwickelten Architektur-Blueprint zu validieren und offene Fragen zu identifizieren.
Beitrag des Projektpartners Capgemini
Projektpartner ist Capgemini (Axel Burghof, Senior Delivery Architect). Capgemini entwickelt für den Einsatz in Kundenprojekten die Devon-Plattform, eine Best-of-Breed-Sammlung von Technologien und Good Practices. Die Zielstellung von Devon ist durchaus vergleichbar mit dem Ziel des Architektur-Blueprints für den Campus. Daher kann Devon als Anregung, Vergleichsmaßstab und Grundlage für das Projekt genutzt werden. Capgemini kann wiederum die Ergebnisse des Projekts in die Devon-Entwicklung zurückfließen lassen. Daher wird Axel Burghof die Entwicklung eng begleiten.
Projektmethodik
Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik (Scrum mit Elementen aus XP) erfolgen. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf methodisch begleitet. Das Projekt wird in (vermutlich vierwöchige) Sprints gegliedert. Axel Burghof von Capgemini wird bei den Sprint Reviews zugegen sein.
Learning Outcomes
- Praxiserfahrung mit Microservice-Architekturen
- Erfahrung in der Konzeption und Pilotierung eines praxisnahen, umfangreichen Softwareprojekts
- Gelegenheit zur konkreten Verwendung von „Bleeding Edge“ Technologien
- Erfahrung mit agiler Entwicklungsmethodik in einem realistischen Softwareprojekt
- Expertise in Kommunikation und Dokumentation
- Teamwork- und Projektmanagement-Erfahrung
Voraussetzungen
- Programmierkenntnisse
- Interesse an professioneller Software-Entwicklung
- Interesse an der Softwarearchitektur
- 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
- Bereitschaft, gemäß agiler Vorgehensweise durch geeignete Tools Transparenz über den eigenen Beitrag zur Gruppenleistung zuzulassen
Externe Projektpartner
Capgemini, Niederlassung Köln
Am Donnerstag, 2.11.17, wirke ich zusammen mit meinem Kollegen Prof. Dr. Matthias Böhmer an einem Webinar der Firma ThingForward mit, Titel „Rapid IoT Prototyping am Praxisbeispiel einer Versicherung“. Wir stellen dabei die Ergebnisse zweier Guided Projects aus dem Informatik Master vor, die wir in Zusammenarbeit mit ThingForward und der Gothaer Versicherung betreut haben.
Teil 1 – Der Prototyp
Teil 2 – Kommunikation zwischen Prototyp und Versicherungs-IT-Landschaft
Teil 3 – Einbettung als Geschäftsprozess in die SOA der Versicherung
Problem Description
Blockchain has gained a (sometimes somewhat infamous) reputation as basis for crypto-currencies like BitCoin. But actually, the potential of blockchain reaches far beyond ersatz currencies.
Basically, a blockchain is a secure, distributed ledger (i.e. master record) of transactions. All transactions can be verified by all participants at any given time. No transaction can be altered without being noticed. This makes blockchain a great base for so-called “smart contracts”.
Blockchain-based smart contracts have the potential to disrupt all “trust platform” businesses – as the trust is kind of built into the technology, there is no need for a centralized platform-in-the-middle approach anymore. This is a challenge for the Ubers, AirBnbs, insurances, and banks of this world. Blockchain-based smart contracts offer a reliable, light-weight, and therefore cheap way of creating small-footprint transactions between market participants.
A great introduction to get started on the subject is this reference architecture document: http://www.cloud-council.org/deliverables/CSCC-Cloud-Customer-Architecture-for-Blockchain.pdf.
Project Definition
In this project, we will design a showcase for a smart contract based on blockchain technology. For the purpose, the team will conduct the following steps:
- Selection of a proper showcase application
- In collaboration with our project partner, Viadee consulting, the team will pick a showcase, for instance an ad-hoc insurance contract like
- insuring passengers and material during the test drive of a car
- insuring open air parties or festivals (i.e. marriages, birthdays, concerts, …) against cancellation or damages due to bad weather
- insuring medium-priced goods like smart phones, tablets, ski, bikes,… against risk of damage, loss, or theft during a period of increased risk (travel, sports competition, relocation, …)
- As of planned today, there will be another additional project partner, most likely an international insurance company, helping us with picking a realistic showcase.
- In collaboration with our project partner, Viadee consulting, the team will pick a showcase, for instance an ad-hoc insurance contract like
- The subsequent steps will be conducted in two parallel, coupled subprojects:
- Technology & Implementation (this project)
- Implementation of the smart contract using Hyperledger Fabric (https://www.hyperledger.org/projects/fabric)
- Evaluation of technical obstacles and pitfalls
- Identification of good practices and architectural patterns for building blockchain-based smart contracts
- Business Case (the other project, supervised by Prof. Eckstein) – please see other description
- Technology & Implementation (this project)
- Assessment of blockchain-based smart contracts with regard to the showcase at hand
- Documentation and presentation
Learning Outcomes
- Gaining familiarity with a state of the art technology
- Out-of-the-box thinking, practically applied to some everyday business application
- Designing and implementing a realistic business case
- Working together in mixed team (business & technology)
Requirements
- Willingness to delve into an hitherto unknown technological concept
- Interest in business model and large-scale implications of technologies
- Programming skills
- Willingness and ability to adopt a new technology and programming model (Hyperledger Fabric)
External Project Partner
- Viadee Consulting, https://www.viadee.de
- Probably an insurance company, to be decided yet
Gegenstand des Verbundprojekts ist ein Proof-of-Concept (PoC) eines gekoppelten Sensor-Netzes im häuslichen Bereich mit Fokus auf Erkennung von Leitungswasserschäden. Dieses Verbundprojekts haben Professor Dr. Matthias Böhmer und ich in Zusammenarbeit angeboten.
Im Internet der Dinge (IoT – Internet of Things) werden elektronische Kleingeräte in der Lage sein, über Funknetzwerke miteinander zu kommunizieren und in großem Umfang Daten austauschen. Für die Versicherungswirtschaft beispielsweise ermöglichen Sensoren im häuslichen Bereich, traditionelle Produkte wie etwa eine Hausratsversicherung kosten- und nutzeneffizienter anzubieten. So verursachen etwa Leitungswasserschäden bei Versicherungen hohe Kosten und stellen Betroffene vor große Herausforderungen.
- Subteam 1: GP-A Microservices, WS16-17, Team 1
- Subteam 2: GP-A Microservices, WS16-17, Team 2
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 Gegenstand des Projekts wird ein hypothetisches Entwicklungsprojekt für einen öffentlichen Auftraggeber sein. Die Umsetzung des Projekts sowie die Erstellung des Evaluationsberichts wird nach agiler Methodik erfolgen. Die agilen Teamprozesse werden gemäß Typ-A-Definition von Prof. Stumpf und seinem Team methodisch begleitet. Die agilen Teams wählen jeweils einen Scrum Master und einen Product Owner.
