Auflistung nach Autor:in "Falkenthal, Michael"
1 - 9 von 9
Treffer pro Seite
Sortieroptionen
- KonferenzbeitragArchitecture Reference Lab des SOA Innovation Lab(INFORMATIK 2012, 2012) Jugel, Dierk; Falkenthal, Michael; Groß, Hans-Jürgen; Herrmann, Jochen; Piller, Gunther; Zimmermann, AlfredService-orientierte Software-Architekturen wachsen gegenwärtig mit Architekturen für Cloud Computing zusammen. Neue Software-Architekturen sind die strukturelle Basis für zukunftsweisende IT-Unternehmensarchitekturen und zugehörige leistungsstarke Informationssysteme. Das ARL - Architecture Reference Lab - des SOA Innovation Lab und der Hochschule Reutlingen erforscht in einem deutschlandweit ausgerichteten Partnernetzwerk aus Wissenschaft und Wirtschaft - Service-orientierte Software-Architekturen und IT-Unternehmensarchitekturen. Darüber hinaus unterstützt das Architecture Reference Lab Forschungsarbeiten von innovativen Workstreams des SOA Innovation Lab. Das SOA Innovation Lab ist ein bundesweites Netzwerk von Mitgliedsunternehmen, die serviceorientierte Architekturen, Methoden und Werkzeuge des Enterprise Architecture Management und zugehörige Infrastrukturen mit dem Zweck einer wirkungsvollen Anwendung und Integration der Systeme in komplexe Unternehmenslandschaften erforschen.
- KonferenzbeitragDarstellung des Konzeptes - DMA Decentralised Market Agent - zur Bewältigung zukünftiger Herausforderungen in Verteilnetzen(INFORMATIK 2015, 2015) Thomsen, Jessica; Hartmann, Niklas; Klumpp, Florian; Erge, Thomas; Falkenthal, Michael; Kopp, Oliver; Leymann, Frank; Stando, Sven; Turek, Nino; Schlenzig, Christoph; Schwarz, HolgerIn der vorliegenden Veröffentlichung wird ein Konzept für einen neuen Marktakteur im Strommarkt vorgestellt, der im zukünftigen Smart Grid als Aggregator und Planer fungieren kann. Dieser Decentralised Market Agent - DMA - soll die Informationen aller vorhandenen Erzeugungsund Speicheranlagen, Lasten und Netzinformationen auf Verteilnetzebene aggregieren sowie mit lokalen Akteuren und an den zentralen Märkten agieren um einen kostenoptimalen Betrieb und Ausbau des Systems Verteilnetzes zu realisieren. Zur Handlungsfähigkeit dieser neuen Marktrolle bedarf es hochauflösender Messungen im Verteilnetz und einer \?real-time“ Aufbereitung der Messdaten. Im vorliegenden Paper sollen das Konzept sowie die notwendigen Bausteine zur Erreichung der Handlungsfähigkeit des DMA vorgestellt sowie die zukünftig geplanten Untersuchungen erläutert werden. Die detaillierte Entwicklung des Konzepts sowie weiterführende Analysen sind Teil des Projektes NEMAR - Netzbewirtschaftung als neue Marktrolle, gefördert durch BMWi im Rahmen der Forschungsinitiative Zukunftsfähige Stromnetze.
- KonferenzbeitragDatenanalyse in den Digital Humanities - Eine Annäherung an Kostümmuster mittels OLAP Cubes(Datenbanksysteme für Business, Technologie und Web (BTW 2015), 2015) Falkenthal, Michael; Barzen, Johanna; Dörner, Simon; Elkind, Vadym; Fauser, Jan; Leymann, Frank; Strehl, TinoIm Film ist das Kostüm eines der prominentesten Gestaltungselemente, um Aussagen über eine Rolle, deren Charakter, Stimmung und Transformation, wie auch über Ortund Zeitgegebenheiten zu kommunizieren. Durch Kostümmuster sollen Kostümbildner befähigt werden, effizient auf bewährte Designlösungen zurückgreifen zu können. Diese Demo zeigt, wie generelle Designprinzipien aus einer großen Anzahl an Kostümen aus Filmen für die Entwicklung dieser Kostümmuster mittels OLAP Cubes abstrahiert werden können. Um generelle Designprinzipien feststellen zu können, werden Kostüme über kategoriale Merkmalstaxonomien beschrieben und in verschiedenen Aggregationsstufen ausgewertet. Die Abstraktion von generellen Lösungen für Kostümmuster wird durch Drill-Down und Roll-Up Mechanismen unterstützt.
- KonferenzbeitragEinfluss von cloud services auf auswahlverfahren für IT-lösungen(Informatik 2014, 2014) Bossert, Oliver; Falkenthal, Michael; Mauerwerk, Mark; Piller, GuntherImmer mehr Unternehmen setzen auf IT-Services aus der Cloud. Diese Entwicklung verändert auch die Auswahlverfahren für IT-Produkte und Dienstleistungen. Eine explorative Untersuchung zeigt dies beispielhaft f\?r Entscheidungsprozesse und Kriterien zur Bewertung von Angeboten f\?r betriebliche Anwendungssysteme sowie f\?r IT-Plattformen und Anbieter auf. 1\?Fragestellung und Vorgehensweise Cloud Computing spielt in der Unternehmens-IT eine immer wichtigere Rolle. Typische Gr\?nde hierf\?r sind ein erhšhter Automatisierungsgrad f\?r das Management von IT- Infrastrukturen oder kurze Beschaffungszeiten von IT-Services. Aufgrund der wachsenden Bedeutung von Cloud-Angeboten, stellt sich die Frage, ob und ggf. wie existierende Auswahlprozesse f\?r IT-Lšsungen angepasst werden m\?ssen. Die vorliegende explorative Untersuchung analysiert erstmals Vorgehensweisen zur Auswahl von IT-Systemen und Infrastrukturen, die Cloud Services ber\?cksichtigen und von bisher verwendeten Standardverfahren abweichen. Hierzu wurden exemplarisch mehrere Unternehmen zum Vorgehen bei der Bewertung von Software as a Service (SaaS), Platform as a Service (PaaS) und Infrastructure as a Service (IaaS) Angeboten befragt. Die hierbei extrahierten Ergebnisse kšnnen in nachfolgenden Untersuchungen quantitativ erhŠrtet werden. Trotz der zu diesem Zeitpunkt wissenschaftlich nicht zuverlŠssig gesicherten Resultate, erscheinen die gemachten Beobachtungen interessant genug, um hier zusammengefasst zu werden. Die von uns gemachten Beobachtungen liefern wertvolle Ansatzpunkte f\?r weiterf\?hrende Analysen und f\?r die Verbesserungen der Auswahlpraxis von IT-Lšsungen, die auf Cloud Services beruhen. Die Untersuchung fokussiert sich auf den operativen Auswahlprozess von Cloud- Lšsungen f\?r Softwareanwendungen aus den Anwendungsbereichen Customer Relationship Management (CRM) und Groupware/E-Mail sowie f\?r IT- Plattformkomponenten. Hierzu wurden qualitative Interviews mit IT-Spezialisten und Managern verschiedener Gro{\S}unternehmen durchgef\?hrt. Die Ergebnisse der Befragung werden in den nachfolgenden Abschnitten beschrieben. Abschnitt 2 gibt einen allgemeinen $\dagger $berblick \?ber die Resultate. GrundsŠtzliche $\dagger $berlegungen zu einem Einsatz von SaaS werden in Abschnitt 3 skizziert. In Abschnitt 4 werden verŠnderte 453 Kriterien f\?r eine Bewertung von betrieblichen Anwendungen vorgestellt. Abschnitt 5 erweitert diese Diskussion f\?r IT-Plattformen. Abschnitt 6 fasst die gemachten Beobachtungen zusammen. 2\? EURnderungen in Systemevaluation und Auswahl Viele Anwenderunternehmen folgen bei der Auswahl passender IT-Lšsungen und deren Anbietern typischen Standardverfahren. Der Abgleich funktionaler und nichtfunktionaler Anforderungen f\?r IT-Infrastrukturkomponenten oder Informationssysteme lŠuft meist nach Šhnlichen Mustern ab (siehe z.B. [BWV07], [Gr10]): Nach Projektvorbereitung und Ist-Analyse wird ein Soll-Konzept aufgestellt, das auf den Anforderungen der Auftraggeber basiert. Anschlie{\S}end wird nach der Systemevaluation in mehreren Schritten der beste Anbieter ausgewŠhlt: Marktsichtung und Vorauswahl auf Grundlage der Anforderungen, Systemtests einschlie{\S}lich Detailanalyse, nachfolgend Verhandlungen und Abschluss. Unsere Untersuchung konzentriert sich auf den Ablauf der Systemevaluation und Auswahl. Die Ergebnisse der vorangehenden Phasen Projektvorbereitung, Ist-Analyse und Soll-Konzeption werden als Input f\?r die Phase der Systemevaluation angenommen. So wird z.B. durch einen Abgleich der Ist-Analyse und der Soll-Konzeption der Handlungsraum aufgedeckt, der durch funktionale und nichtfunktionale Anforderungen an die neue IT-Lšsung beschrieben werden kann. Die so identifizierten Anforderungen flie{\S}en anschlie{\S}end als Kriterien zur Beurteilung von neuen Systemen in die Systemevaluation ein [BWV07]. Wie in den nachfolgenden Abschnitten gezeigt wird, verŠndern Cloud-Angebote (siehe z.B. [VHH12]) die bestehende Praxis der Systemevaluation. Unternehmen klŠren meist vor den Phasen Marktsichtung, Vorauswahl, Systemtest, Detailanalyse und Auswahlempfehlung, ob und in welchem Umfang ein Cloud-Ansatz wie SaaS, PaaS oder IaaS f\?r die geplante Lšsung \?berhaupt in Frage kommt. Dementsprechend wird eine zusŠtzliche Phase zur grundsŠtzlichen Beurteilung eines mšglichen Einsatzes von Cloud Computing dem bisherigen Vorgehen vorangestellt. Zudem werden in den nachfolgenden, \?blichen Phasen des Auswahlprozesses auch Cloud-spezifische Kriterien zur Beurteilung herangezogen. Abbildung 1 illustriert diese EURnderungen, die in den folgenden Abschnitten detailliert werden. Abbildung 1: Cloud-spezifische Erweiterung des Vorgehens bei einer Systemevaluation 454 Nur wenige der Befragten stellen Cloud-Angebote und klassische On-Premise-Lšsungen gleichrangig nebeneinander und bewerten sie Schritt f\?r Schritt. Vielmehr wird meist schon vorab entschieden, ob Cloud-Lšsungen \?berhaupt in Betracht gezogen werden sollen. Entsprechende Kriterien werden hier beispielhaft f\?r den Bereich SaaS beschrieben. GrundsŠtzliche Entscheidungen f\?r bzw. wider Cloud beruhen oft auf externen und internen Complianceund Sicherheitsanforderungen {\Dj} z.B. auf nationalen Gesetzen, die die Ablage sensitiver Daten in der Cloud einschrŠnken. Interviews mit Unternehmen zeigen aber auch, dass eine pauschale Ablehnung von Cloud-Lšsungen auf Grund solcher Anforderungen hŠufig differenziert hinterfragt wird. Bei genauerer Betrachtung sind oft auch Hybrid Cloud-AnsŠtze (siehe z.B. [Fe14]) mšglich und sinnvoll. Ist beispielsweise die Speicherung von Rechnungsdaten in der Cloud untersagt, kšnnen Unternehmen diese zwar unternehmensintern ablegen und dennoch, z.B. in den Prozessen einer SaaS-Lšsung f\?r CRM verwenden. Auch Token-basierte AnsŠtze ermšglichen oft den Umgang mit strikten Vorgaben zur Datenspeicherung. Dabei werden Daten anonymisiert und zur Identifikation mit einem generierten eindeutigen Token versehen. Die anonymisierten Daten kšnnen dann in die Cloud \?bertragen und dort genutzt werden. Die Tokens verbleiben in unternehmensinternen On-Premise- Systemen und kšnnen so zur Identifikation der Daten herangezogen werden (siehe hierzu auch das Compliant Data Replication Pattern in [Fe14]). Ebenfalls beachtet werden nicht-funktionale Anforderungen, die f\?r On-Premise-Lšsungen meist kein Problem darstellen. So fordern einige Staaten, dass Finanzdaten auf physischer Ebene auditierbar sind. Das bedeutet f\?r SaaS-Lšsungen mitunter eine erhebliche H\?rde, weil die gro{\S}en Anbieter normalerweise keinen Zugang zu ihren Rechenzentren gewŠhren. Dar\?ber hinaus werden bei der Grundsatzentscheidung f\?r oder gegen die Cloud všllig neue Aspekte wichtig. Ein Beispiel hierf\?r sind Risiken durch Imageverlust. So erscheint vielen Unternehmen eine Schlagzeile wie ãHacker laden vertrauliche Kundendaten der Firma XYZ aus der Cloud herunterÒ weit schŠdlicher als eine Meldung \?ber einen Einbruch in das firmeninterne IT-System. Aber auch die Frage, wie Cloud- Anwendungen in eine komplexe IT-Landschaft integriert werden sollen, ist nicht immer leicht zu klŠren. Beispiele aus Unternehmen zeigen, dass genauere Untersuchungen hierzu bei der Softwareauswahl oft zur\?ckgestellt werden {\Dj} oder die Unternehmen vertrauen den Zusicherungen von Implementierungsdienstleistern. Es erscheint aber sinnvoller, den Integrationsgrad schon zu Beginn des Auswahlprozesses zu klŠren. Denn je mehr die angestrebte Cloud-Lšsung mit unterschiedlichen Systemen \?ber Schnittstellen verbunden werden soll, desto hšher ist im Allgemeinen die H\?rde f\?r ein SaaS-Angebot. Im Fall von CRM-Systemen kommen viele Unternehmen allerdings mit wenigen Schnittstellen aus. Eine mšglicherweise schwierige Integration taugt also nicht per se als Argument gegen eine Cloud-Lšsung. Aus Architektursicht spielt schlie{\S}lich auch eine Rolle, dass Cloud-Lšsungen zu hšherer Standardisierung beitragen kšnnen. Denn mehrere Erfahrungsberichte zeigen, dass beispielsweise Marketing und Vertrieb bereitwilliger einen durch SaaS vorgegebenen 455 hšheren Standardisierungsgrad akzeptieren, wenn sie dadurch schnell eine flexibel skalierbare CRM-Lšsung bekommen. Einige Unternehmen setzen Cloud-Lšsungen deshalb bereits bewusst als Mittel ein, um strategische Konsolidierungsma{\S}nahmen rascher und mit hšherer Akzeptanz umzusetzen. 4\?Neue und verŠnderte Bewertungskriterien Wenn eine SaaS-Lšsung prinzipiell in Frage kommt, untersuchen Unternehmen die Anbieter in der nŠchsten Phase anhand der \?blichen Kriterien: $\dagger $bereinstimmung mit GeschŠftsanforderungen, funktionale Bandbreite, Usability, Konsens mit Architekturprinzipien, etc. Bei einigen dieser Punkte ergeben sich allerdings f\?r Cloud- Anwendungen neue Fragestellungen: \?\? Ist eine schnelle Umsetzung durch SaaS f\?r uns ein Vor- oder Nachteil? Die kurze Zeit bis zum Rollout wird hŠufig als Argument f\?r Cloud-Lšsungen genannt. Denn diese Geschwindigkeit erlaubt es beispielsweise, CRM- Anwendungen in neuen, dynamischen MŠrkten z\?gig auszubauen und Vertriebsorganisationen flexibel einzubinden. In einigen Unternehmen ging dies aber so schnell, dass Mitarbeiter hinterher beklagten, es habe keine Zeit mehr gegeben, die anfŠnglichen Konzepte noch einmal anzupassen. \?\? Bekommen wir eine Komplettlšsung? Mehrere Unternehmen betonen, wie wichtig es ist, ganzheitliche Lšsungen zu evaluieren. Denn SaaS-Dienstleister bieten nicht immer alles aus einer Hand. So werden in China Anwendungen, Rechenzentren und Netzwerkservices oft nicht als Gesamtpaket bereitgestellt, sondern m\?ssen von mehreren Dienstleistern bezogen werden. Zu einer CRM- Anwendung gehšren auch Komponenten, die gew\?nschte FunktionalitŠten abdecken, jedoch nicht Teil des SaaS-Standardprodukts sind (etwa eigenstŠndige Call-Center-Lšsungen). Zwar kšnnen solche Zusatzkomponenten spŠter noch auf der Technologieplattform des Cloud-Anbieters entwickelt und bereitgestellt oder als On-Premise-Applikationen eingebunden werden. Aber das bedeutet in der Regel zusŠtzlichen Integrationsaufwand und hšhere Betriebskosten. Auch die Integration der SaaS-Lšsung in das Data Warehouse des Unternehmens oder Backup-Konzepte gehšren zu einer Komplettlšsung und sollten bei der Angebotspr\?fung nicht \?bersehen werden. \?\? Wie innovativ ist der Anbieter? F\?r Endanwender erscheinen SaaS-Lšsungen oft attraktiv, weil sie eine hohe Usability aufweisen und innovative FunktionalitŠten schnell bereitstellen. So bot ein CRM- Dienstleister k\?rzlich seinen Kunden an, Sentiments aus aktuellen chinesischen und russischen sozialen Netzwerken in Neartime auszuwerten und in die Unternehmensprozesse einzubinden. Eine solche FŠhigkeit zur Innovation haben Unternehmen bisher selten auf der Liste funktionaler und nichtfunktionaler Anforderungen an Anbieter von SaaS- und On-Premise-Systemen. 456 \?\? Wie kšnnen interne Stakeholder von der Lšsung \?berzeugt werden? In mehreren FŠllen wurde die f\?r den Nutzer attraktive Usability einer Groupware/E-Mail SaaS-Lšsung verwendet, um das Change-Management f\?r einen unternehmensweiten Ident-Service zu erleichtern. \?\? Brauchen wir die angebotenen Anpassungen und Erweiterungen? Wenn Unternehmen SaaS-Angebote mit funktionalen Anforderungen abgleichen, fŠllt meist auf, wie viele Optionen f\?r Anpassungen und Erweiterungen die Anbieter sowie deren Implementierungsund Softwarepartner offerieren (z.B. zu CRM- Analytics). Diese Optionen sollten die Unternehmen sorgfŠltig evaluieren, weil sie hŠufig im Widerspruch zu Standardisierungsbestrebungen oder einer gew\?nscht hohen FlexibilitŠt stehen {\Dj} und so dem eigentlichen Ziel der SaaS- Lšsung zuwiderlaufen. Bei den Interviews zeigte sich, dass Unternehmen f\?r ein SaaS-Produkt in einem Anwendungssegment oft nur den jeweiligen Marktf\?hrer in Betracht ziehen. Dahinter steckte die Annahme, dass andere Anbieter wichtige Anforderungen bez\?glich Sicherheit oder Compliance kaum gen\?gen werden, wenn diese von den f\?hrenden Anbietern nicht erf\?llt werden. Zudem sind Unternehmen meist nicht bereit, Pilotkunden kleinerer SaaS-Dienstleister zu werden, insbesondere weil die langfristige MarktfŠhigkeit dieser Anbieter noch nicht erwiesen ist. Konsens aus den Interviews war zudem, dass ma{\S}gebende SaaS-Anbieter mit gro{\S}en, dynamisch wachsenden $\dots $kosystemen aus Systemintegratoren, unabhŠngigen Softwareherstellern (ISV) und weiteren Partnern punkten. Dadurch kšnnen sie Standardlšsungen an die Anforderungen bestimmter Branchen und Regionen anpassen oder f\?r NischenmŠrkte erweitern. Zudem sichern die Netzwerke gro{\S}er SaaS-Anbieter global verf\?gbare Ressourcen f\?r Implementierungsprojekte, Rollout und Wartung. Viele SaaS-Innovationen kommen auch gar nicht vom Anbieter selbst, sondern von ISV oder aus dem $\dots $kosystem des Anbieters. Unternehmen sollten allerdings darauf achten, dass solche Anpassungen, Erweiterungen und Innovationen schon in den Lizenzkosten ber\?cksichtigt sind. Wer das versŠumt, muss damit rechnen, spŠter das vorgesehene Budget zu \?berschreiten. Dar\?ber hinaus gilt es zu ber\?cksichtigen, dass Zusatzlšsungen, die auf dem PaaS- Angebot eines Dienstleisters aufbauen, nicht immer auf dem gleichen technischen Stand sind, denn oft werden nicht die neuesten Plattformservices und Funktionen genutzt. Dies kann zu Komplikationen bei der Integration und beim Zusammenspiel verschiedener Lšsungsbausteine f\?hren. So wurde beispielsweise der Datenaustausch einer Zusatzanwendung f\?r ein SaaS-CRM \?ber ein proprietŠres Protokoll gesteuert, obwohl die neueste PaaS-Version des Dienstleisters bereits standardisierte REST- und SOAP- Services zur Verf\?gung stellte. Erhšhte Integrations- und Betriebskosten waren die Folge. 457 Evaluieren Unternehmen PaaS als IT-Plattform, so lassen erste Interviews einen Unterschied zum SaaS-Fall vermuten: In einer ersten Phase der Analyse (siehe Abbildung 1) wird grundsŠtzlich entschieden, ob eine PaaS eingesetzt werden soll. Die nachfolgenden Schritte des Auswahlverfahrens konzentrieren sich dann hŠufig auf die Bewertung verschiedener PaaS-Angebote. Die Trigger f\?r die Einf\?hrung einer PaaS kšnnen vielfŠltig sein. Beispielsweise verspricht ihr Einsatz Vorteile beim Aufbau einer flexibel skalierbaren Plattform, die neue IT-Dienste besser unterst\?tzen und deren Markteinf\?hrung wesentlich beschleunigen kann. Insbesondere lassen sich moderne DevOps-Prinzipien, wie kontinuierliche Delivery [JHDF11] und Integration, optimal umsetzten. In Bezug auf Virtualisierungsmšglichkeiten sind IaaS und PaaS vergleichbar, da PaaS auf IaaS aufbaut und somit den Virtualisierungsund Automatisierungsgrad in Hinblick auf eine Industrialisierung der Lebenszyklen von Anwendungen erhšht (siehe hierzu u. a. das EU-Forschungsprojekt 4CaaSt zur Erstellung einer erweiterten PaaS-Cloud-Plattform [4C14]). Folgende Fragestellungen fanden wir hŠufig bei unseren Analysen vor, wenn in Unternehmen initial \?ber einen Einsatz von PaaS nachgedacht wird: \?\? Wie lŠsst sich der Automatisierungsgrad in der Softwareentwicklung erhšhen, um z.B. dynamisch skalierbare Umgebungen nahezu in Echtzeit bereit zu stellen? Mit PaaS kšnnen Anwendungsumgebungen in Form von vorkonfigurierten Anwendungscontainern, wie beispielsweise JavaEE Anwendungsservern, automatisch zusammen mit der Betriebssystemumgebung deployt werden. Idealerweise werden sŠmtliche Umgebungen von der Entwicklung \?ber die Teststufen bis hin zur Produktion auf die gleiche Weise mit den gleichen Managementwerkzeugen aus identischen Quellen bereitgestellt. Dar\?ber hinaus stehen Anwendungsmanagementdienste wie Health Monitoring, Resource Management, Skalierung und Deployment automatisiert zur Verf\?gung (siehe Elastic Platform in [Fe14]). Durch die Erhšhung des Automatisierungsgrads mit PaaS werden zudem Fehler bei der Umgebungsbereitstellung vermieden. \?\? Wie kann die Systemintegration verbessert werden? Die Kommunikation von Anwendungen untereinander erfolgt in einer PaaS \?ber mitgelieferte Middleware-Komponenten - i.d.R. Messaging Systeme (siehe Message- Oriented Middleware in [Fe14]). Im Vergleich zu Installationen in oft unterschiedlichen Infrastrukturumgebungen entfallen innerhalb einer PaaS umgebungsspezifische Konfigurationen. Es werden modulare, lose gekoppelte Services erstellt, die sich gegenseitig konsumieren kšnnen. Nach au{\S}en lassen sich diese Dienste mithilfe der Prinzipien einer Service Orientierten Architektur (SOA) integrieren, um eine lose Kopplung zu bewahren (siehe [ARE10]). 458 \?\? Wie lŠsst sich die Datenhaltung \?ber Cloud-AnsŠtze optimieren? Bei dieser Fragestellung bedarf es einer sorgfŠltigen Evaluierung: Verwendet man Datendienste innerhalb eines virtuellen Containers, so lassen sich DatenbankzustŠnde automatisch horizontal skalieren. Das f\?hrt allerdings zu einem Paradigmenwechsel in Bezug auf klassische Datenbank-zentrische Anwendungsarchitekturen, in welchen traditionell DatenbankzustŠnde zentral in relationalen Datenbankmanagementsystemen (RDBMS) gehalten werden (siehe Stateless Component und Stateful Component in [Fe14]). Transaktionsmonitore und RDBMS gewŠhren dann die referentielle IntegritŠt gemŠ{\S} dem ACID-Prinzip. Eine Skalierung erfolgt aufwŠndig \?ber die Infrastruktur. In verteilten Systemen bei einer horizontalen Verteilung von DatenbankzustŠnden kommt es zu einem Konflikt der unterschiedlichen ZugŠnglichkeitsaspekte, auch bekannt als CAP-Theorem [GL02]. Hier kšnnen immer nur zwei von drei Skalierungsaspekte gleichzeitig garantiert werden (Consistency vs. Availability vs. Partition Tolerance). Verschiedene NoSQL- Produkte unterst\?tzen diese Aspekte mit unterschiedlichen Schwerpunkten. Die Architektur einer Cloud-Anwendung muss dann gemŠ{\S} ihren Anforderungen ausbalanciert werden, um den benštigten CAP-Eigenschaften bei elastischen Skalierungen zu entsprechen [ACF12]. Stellt sich PaaS als vielversprechende Mšglichkeit dar, zeigen Interviews mit Unternehmen, dass eine grundsŠtzliche Entscheidung f\?r bzw. wider einer Einf\?hrung entsprechender Cloud Services oftmals wesentlich von organisatorischen Gegebenheiten abhŠngt. StŠrker als die Auswahl einer Plattformtechnologie stehen Anpassungen der Arbeitsweise und eine bereichs\?bergreifende Zusammenarbeit bei der Einf\?hrung einer PaaS im Mittelpunkt der Diskussion. Differenzierende Faktoren sind weniger die Produktmerkmale der Plattformtechnologie und die mitgelieferten Standardframewoks, als vielmehr die vorhandenen Rahmenbedingungen innerhalb der eigenen Organisation. In diesem Zusammenhang wurden folgende Fragen hervorgehoben: \?\? Sind interne Strukturen und Schnittstellen zu IT-Infrastrukturkomponenten f\?r eine vollstŠndige Automatisierung hinreichend? F\?r die Implementierung einer PaaS ist die durchgŠngige Automatisierung der Deployment-Mechanismen des vollstŠndigen Plattfom-Stacks erforderlich. Die betrifft insbesondere auch die Integration mit bestehender Abrechnungsund Managementsoftware. \?\? Bieten bereits vorhandene VirtualisierungsansŠtze eine hinreichende Grundlage f\?r eine weitere Dynamisierung? In der Regel f\?hrt der Weg zur Dynamisierung \?ber die sukzessive Virtualisierung der Infrastruktur, die sich meist historisch entwickelt hat. In einem konkreten Fall wurden bestehende AnsŠtze als zu schwerfŠllig f\?r weitere Dynamisierungsbestrebungen erachtet, was dann f\?r die Implementierung eines neuen Cloud-Stacks sprach. \?\? Gibt es geeignete Sicherheitsstandards, die sich auch auf dynamisch skalierende Infrastrukturen anwenden lassen? Sicherheitsstandards sind noch oft auf statische Infrastrukturen ausgerichtet. Auch gibt es in Unternehmen mitunter wenige Erfahrungen mit virtuellen Entkopplungsmechanismen einer PaaS. 459 Daher ist die Zusammenarbeit mit den zustŠndigen Verantwortlichen f\?r Sicherheit sorgfŠltig einzuplanen. \?\? Die Frage, ob mitgelieferten Anwendungsframeworks eine Rolle spielen, wurde als nachgelagertes Problem eingestuft. Ist eine initiale Entscheidung f\?r die Einf\?hrung einer PaaS gefallen, werden in nachfolgenden Phasen des Auswahlprozesses Detailfragen betrachtet. Beispiele hierf\?r sind: \?\? Welche Lifecycle-Services stehen zur Verf\?gung? Um den Industrialisierungsund Automatisierungsgrad in einem Cloud-Stack zu erhšhen, bedarf es aufeinander abgestimmter Hardware- und Softwarebausteine. Dies betrifft insbesondere auch Lifecycle-Aspekte. Beispielsweise sollten alle abhŠngigen Plattformkomponenten in definierten Zyklen \?ber sogenannte Matrix Updates zusammen gewartet werden. \?\? Wie kann eine optimale Integration von Hard- und Softwarebausteinen gesichert werden? Oft reicht es nicht, auf existierenden VirtualisierungsansŠtzen aufzubauen. Im Gegenteil, es besteht dann die Gefahr, dass sich durch zusŠtzliche PaaS-Komponenten die KomplexitŠt der Gesamtlandschaft eher erhšht. Auch wird in vielen Unternehmen im Entwicklungs- und Produktionsbereich separat virtualisiert. Ferner kšnnen bestehende Lizenzmodelle zu dezidierten Umgebungen zwingen. Derzeit entwickelt sich ein Markt f\?r vorintegrierte Technologiekomponenten (Converged Infrastructure, siehe z.B. [Be13]) die den Aufbau von Cloud- fŠhigen Rechenzentren erleichtern kšnnen. (F\?r einen systematischen Einstieg sowie Kriterien f\?r die Auswahl geeigneter Cloud Service Modelle siehe z,B. [Ka14]) \?\? Welche Vorteile bieten Open Source-Plattformen? Open Source-Lšsungen basieren meist auf offenen Standards. Allerdings ist davon auszugehen, dass Modifikationen bzw. ErgŠnzungen notwendig sind. So m\?ssen insbesondere Schnittstellen f\?r eigene Authentifizierungsmechanismen und Self Service- Verfahren implementiert werden. \?\? Wodurch zeichnen sich kommerzielle Produkte aus? Hier ist insbesondere die InteroperabilitŠt vorhandener APIs einer der wesentlichen Faktoren. Diese ist innerhalb des Stacks eines Lieferanten typischerweise gegeben, die Integration mit vorhandenen Management- und Abrechnungssystemen kann jedoch aufwŠndig werden. Es lŠsst sich feststellen, dass PaaS kein Thema f\?r eine einfache, vergleichende Plattformauswahl ist. Stattdessen wird meist in einem ersten Schritt geklŠrt, welche Mšglichkeiten und Ziele f\?r eine bestehende Organisation sinnvoll sind. 460 Cloud-Services verŠndern die Auswahlverfahren f\?r IT-Lšsungen. Dies ist das Fazit der vorliegenden Momentaufnahme. Es zeigt sich, dass dem typischen Muster f\?r die Evaluation von IT-Anwendungen und -Plattformen eine Phase vorgeschaltet wird, in der man grundsŠtzlich dar\?ber entscheidet, ob Cloud-Services in Betracht kommen oder nicht. Nachfolgende Entscheidungsschritte enthalten dann zum Teil geŠnderte Bewertungskriterien, die auf die unterschiedlichsten Aspekte von Cloud-Angeboten eingehen. Eine weiterf\?hrende Analyse zur ErhŠrtung und Detailierung der hier aufgezeigten ersten Beobachtungen erscheint sinnvoll. Sowohl f\?r Anwendungsunternehmen als auch f\?r Anbieter von IT-Dienstleistungen ist ein VerstŠndnis der sich stetig Šndernden Bewertungsprozesse und -kriterien von IT-Lšsungen wichtig. Literaturverzeichnis [ACF12] Andrikopoulos, V.; Fehling, C.; Leymann, F.: Designing for CAP {\Dj} The Effects of Design Decisions on the CAP Properties of Cloud-native Applications, Proceedings of the 2nd International Conference on Cloud Computing and Service Science, CLOSER, 2012; S. 365-374. [ARE10] Simon, A.; Rischbeck, T.; Erl, T.: Modern ESB Architecture for SOA, Pearson Education Schweiz, 2010. [Be13] Bernard, A.: Is Converged Infrastructure the Future of the Data Center?, CIO, 2013
- KonferenzbeitragMaturity assessments of service-oriented enterprise architectures with iterative pattern refinement(INFORMATIK 2012, 2012) Falkenthal, Michael; Jugel, Dierk; Zimmermann, Alfred; Reiners, René; Reimann, Wilfried; Pretz, MichaelCurrent practices for assessing maturity of service-oriented enterprise information architectures only provide a sparse metamodel and pattern foundation and were rarely validated. This is a real problem for practical architecture assessments in repeated (cyclic) evaluations of service-oriented systems. In preliminary research we have developed and validated an original pattern language for supporting architecture assessments and optimization of enterprise systems, leveraging and extending base frameworks like the Capability Maturity Model Integration and The Open Group Architecture Framework. Traditionally, patterns are derived after long experience by an expert group of pattern authors. This may lead to a decelerated reuse of available design knowledge. Our approach intends to integrate available knowledge from enterprise information architecture methods, services computing and software architects directly from the beginning of the iterative pattern development and refinement process.
- KonferenzbeitragMetamodell-basierte Integration von Service-orientierten EA-Referenzarchitekturen(INFORMATIK 2013 – Informatik angepasst an Mensch, Organisation und Umwelt, 2013) Zimmermann, Alfred; Sandkuhl, Kurt; Pretz, Michael; Falkenthal, Michael; Jugel, Dierk; Wisotzki, MatthiasEine EA-Referenzarchitektur soll die klare „Blaupause“ der effizienten, leistungsstarken und agilen Gestaltung sowie Nutzung von EAM für jedes Unternehmen sein. Heute ist dies nicht der Fall, weil EA-Referenzarchitekturen meist fehlen und die methodische Praxis von EAM meist nur Tool-zentriert ist. Es wird ein origineller Ansatz zur Metamodel-basierten Integration von EA-Frameworks für eine ganzheitliche Service-orientierte EA-Referenzarchitektur neu in die Diskussion eingebracht. Das Problem ist heute, dass es trotz einiger Standards auf dem Gebiet der IT-Unternehmensarchitekturen und vielfältiger EA-Frameworks keine Service-orientierte Referenzarchitektur für Enterprise Architecture Management gibt, die neuere Möglichkeiten des Services & Cloud Computing hinreichend berücksichtigt. Nach mehr als zehnjähriger Entwicklung der Konzepte für EAM – Enterprise Architecture Management und erster praktischer Reife, aber auch einiger Schwierigkeiten im Umgang mit EAM in der Praxis ist die Zeit heute reif, dass künftig klarere Konzepte, Modelle und Werkzeugparametrierungen eine leistungsstarke Basis für die praktische Arbeit von EAM-Architekturen ermöglichen. Unser Ansatz formuliert – in der Art eines Durchstichs – am Beispiel eines Ausschnitts der Business Architekturen von ArchiMate und TOGAF eine relevante methodische Basis für die Integration auch größerer Lösungskonzepte und ordnet diese zu einer konsistenten und ausbaubaren Grundlage für leistungsstarke EA-Referenzarchitekturen. Unsere innovative Idee der Zusammenführung teils heterogener Architekturkonzepte auf der Basis von EA-Capability-Maps, Metamodellen, Standards, Frameworks und Serviceorientierten Ontologien basiert auf eigens entwickelten und bereits erprobten Ansätzen mit Korrelationsmatrizen, weiterentwickelten EA-Metamodellen und auf unserem bisherigen integralen ESARC-Enterprise Services Architecture Reference Cube mit zugehörigen Ontologien, Reifegradmodellen und Patterns für EAM- Diagnostik und systematische Verbesserungen der Architektur.
- KonferenzbeitragSurvey and Comparison of Open Source Time Series Databases(Datenbanksysteme für Business, Technologie und Web (BTW 2017) - Workshopband, 2017) Bader, Andreas; Kopp, Oliver; Falkenthal, MichaelTime series data, i.e., data consisting of a series of timestamps and corresponding values, is a special type of data occurring in settings such as “Smart Grids”. Extended analysis techniques called for a new type of databases: Time Series Databases (TSDBs), which are specialized for storing and querying time series data. In this work, we aim for a complete list of all available TSDBs and a feature list of popular open source TSDBs. The systematic search resulted in 83 TSDBs. The twelve most prominent found open source TSDBs are compared. Therefore, 27 criteria in six groups are defined: (i) Distribution/Clusterability, (ii) Functions, (iii) Tags, Continuous Calculation, and Long-term Storage, (iv) Granularity, (v) Interfaces and Extensibility, (vi) Support and License.
- KonferenzbeitragTowards a cloud-based platform architecture for a decentralized market agent(INFORMATIK 2015, 2015) Kopp, Oliver; Falkenthal, Michael; Hartmann, Niklas; Leymann, Frank; Schwarz, Holger; Thomsen, Jessica
- KonferenzbeitragVon der Softwarekartographie zur Corporate Intelligence(INFORMATIK 2013 – Informatik angepasst an Mensch, Organisation und Umwelt, 2013) Jugel, Dierk; Falkenthal, Michael; Schweda, Christian; Pretz, Michael; Zimmermann, AlfredGraphische Modelle komplexer Systeme, sog. Views, werden in vielen Ingenieursund Managementdisziplinen als Mittel für die Dokumentation und zur Planung eben dieser Systeme verwendet. Mithilfe dieser Modelle, welche das System aus unterschiedlichen Blickwinkeln, sog. Viewpoints, betrachten, lassen sich die unterschiedlichen Interessenslagen (Concerns) der am System interessierten Rollen (Stakeholder) adäquat abbilden. Für das Management von Unternehmensarchitekturen bietet die Softwarekartographie ein Werkzeuginstrumentarium, mit dem sich unterschiedliche Sichten konsistent und automatisiert zu einem statischen Bericht über den Systemzustand zusammenführen lassen. Durch einen derartigen Bericht lassen sich jedoch nicht die veränderlichen Informationsbedarfe im Rahmen einer explorativen Analyse des Systems befriedigen. In dieser Publikation beschreiben wir einen Ansatz, der das Visualisierungsinstrumentarium der Softwarekartographie mit Instrumenten für die dynamische Aggregation von Daten zusammenführt, um am System interessierten Rollen interaktive Blickwinkel bieten zu können.