Nichts ist so beständig wie die Veränderung, so auch in der Softwareentwicklung. War das System an dem man arbeitet vor Jahren noch jung, frisch und voller Neuerungen, ist ihm der Alterungsprozess nicht gut bekommen. Daher soll es nun abgelöst oder zumindest in Teilen ersetzt werden. Doch wie geht man vor? Worauf soll man achten?
In diesem Vortrag behandeln wir die unterschiedlichen Strategien anhand eines fiktiven Beispiels und klären auf Basis welcher Voraussetzungen, welches Migrationsstrategien gewählt werden sollten. Zeitgleich werden aber auch die damit verbundenen Gefahren erläutert und wie man sie möglicherweise kompensieren kann.
Dieser Vortrag beschreibt typische Fehler bei der Pflege von Software, anhand von Realbeispielen und welche Schlüsse man aus diesen Fehlern ziehen kann.
Ihr Weg ins Next Generation DatacenterInterFace AG
Eine zukunftsfähige und performante IT-Infrastruktur ist die Basis zur Digitalisierung ihres Unternehmens. Machen Sie sich gemeinsam mit uns auf den Weg in IHR Next Generation Data Center und damit bereit für die Zukunft!
Live-Webinar zur Anbindung von Produktions-Equipment mit Live-Daten an das SAP Digital Manufacturing Cloud for Execution (DMCe)
Eine intelligente Fabrik ist effizient und flexibel zugleich. Die Intelligenz einer Industrie-4.0-Produktion basiert auf Sammlung und Nutzung von Daten. Die Anbindung von Produktionsressourcen, die Live-Daten an ein MES und / oder ERP senden, ist somit eine Grundvoraussetzung für eine vernetzte Fertigung.
Viele Produktionsfunktionen bis hin zu ganzen MES wandern mittlerweile in die Cloud, um noch flexibler reagieren zu können und zukunftssicher aufgestellt zu sein. Wie funktioniert in dieser hybriden Architektur die Anbindung und Kommunikation mit Produktionsequipment in der Linie am Produktionsstandort irgendwo auf der Welt?
In dem Webinar zeigt Tim-Julian Seher, Berater und SAP DMC Produktspezialist bei Trebing + Himstedt, wie ein beispielhafter Montageprozess im Cloud MES funktioniert und wie die Anbindung und Kommunikation mit einem elektrischen Schrauber nahtlos in die Cloud integriert wird.
Interessant für Werks-, Fertigungs-, Betriebs-, Produktionsleiter, Leiter Produktions-IT, die wissen wollen, wie die MES-Migration in die Cloud gelingt.
Dieser Vortrag beschreibt typische Fehler bei der Pflege von Software, anhand von Realbeispielen und welche Schlüsse man aus diesen Fehlern ziehen kann.
Ihr Weg ins Next Generation DatacenterInterFace AG
Eine zukunftsfähige und performante IT-Infrastruktur ist die Basis zur Digitalisierung ihres Unternehmens. Machen Sie sich gemeinsam mit uns auf den Weg in IHR Next Generation Data Center und damit bereit für die Zukunft!
Live-Webinar zur Anbindung von Produktions-Equipment mit Live-Daten an das SAP Digital Manufacturing Cloud for Execution (DMCe)
Eine intelligente Fabrik ist effizient und flexibel zugleich. Die Intelligenz einer Industrie-4.0-Produktion basiert auf Sammlung und Nutzung von Daten. Die Anbindung von Produktionsressourcen, die Live-Daten an ein MES und / oder ERP senden, ist somit eine Grundvoraussetzung für eine vernetzte Fertigung.
Viele Produktionsfunktionen bis hin zu ganzen MES wandern mittlerweile in die Cloud, um noch flexibler reagieren zu können und zukunftssicher aufgestellt zu sein. Wie funktioniert in dieser hybriden Architektur die Anbindung und Kommunikation mit Produktionsequipment in der Linie am Produktionsstandort irgendwo auf der Welt?
In dem Webinar zeigt Tim-Julian Seher, Berater und SAP DMC Produktspezialist bei Trebing + Himstedt, wie ein beispielhafter Montageprozess im Cloud MES funktioniert und wie die Anbindung und Kommunikation mit einem elektrischen Schrauber nahtlos in die Cloud integriert wird.
Interessant für Werks-, Fertigungs-, Betriebs-, Produktionsleiter, Leiter Produktions-IT, die wissen wollen, wie die MES-Migration in die Cloud gelingt.
Quantitativer und qualitativer Nutzen von PLM ProjektenIntelliact AG
Besuchen Sie das nächste Webinar! Mehr Informationen und Termine: https://intelliact.ch/events/plm-open-hours
****
PLM-Projekte sind in der Regel komplex und belasten Unternehmen durch erhebliche finanzielle und personelle Ressourcen. Deswegen stellt sich für die Entscheidungsträger im Top-Management oft die Frage nach deren konkreten Nutzen sowie der strategischen Bedeutung. Vor allem Organisationen ohne dedizierte inhaltliche Vertretung von PLM in der Geschäftsleitung tun sich schwer, mit einer objektiven Einordnung. Sie neigen dazu, PLM-Vorhaben rein durch klassische Finanzkennzahlen (KPIs) zu bewerten.
(link: https://intelliact.ch/team/patrick-henseler text: Patrick Henseler target: _blank), Senior Consultants & Geschäftsführer, Intelliact AG hat dieses Spannungsfeld zwischen Projekt- und Geschäftsleitung unter die Lupe genommen und zeigte Wege auf, wie Sie PLM-Projekte quantitativ und qualitativ bewerten können, um den notwendigen Management-Support zu erhalten.
Das Dasein eines Codehausmeisters ist schon nicht einfach. Da müht man sich tagein, tagaus damit ab die Software am Laufen zu halten und niemand dankt es einem. Schlimmer noch, ständig kommt jemand und beschwert sich das etwas nicht funktioniert oder macht die ganze Sache sogar noch schlimmer. Bloß wenn man mal etwas ändern will, dann ist kein Weg drin. Erkennen Sie sich hier wieder? Wenn ja hilft Ihnen unser Survival Kit weiter. Es unterstützt Sie mit Werkzeugen sowie Argumenten beim steten Kampf um Softwarequalität, Wartbarkeit und Restrukturierungsbudgets; mit dem Ziel Ihnen die Arbeit zu erleichtern und Ihrer Software endlich die Pflege zu Teil werden zu lassen, die sie so bitter nötig hat.
DevOps Prinzipien im Zusammenspiel mit Kubernetes QAware GmbH
Fachposter, 2020: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Technische Hochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM).
Bestellbar unter https://www.sigs-datacom.de/order/poster/DevOps_Prinzipien-Kubernetes.php
(Dokument bitte herunterladen für bessere Lesbarkeit)
Microsoft Dynamics® Sure Step ist sowohl für Kunden als auch für Partner ein zentraler Bestandteil bei der Verwendung von Microsoft Dynamics. Sure Step bietet eine skalierbare und wiederholbare Implementierungsmethode für Microsoft-Partner, die bei der Implementierung von Microsoft Dynamics-Lösungen verwendet werden kann. Durch Verwendung konsistenter Methodologien, für die auf Best Practices zurückgegriffen wird, die aus den Erfahrungen mit Microsoft Dynamics-Implementierungen in aller Welt resultieren, können Partner bei gleichzeitiger Steigerung der Produktivität ihrer Berater Implementierungszeit, Kosten und Risiken verringern.
http://www.opitz-consulting.com/go/3-4-11
Viele Betriebe haben in den letzten Jahren ihren Anwendungsbetrieb an ITIL ausgerichtet. Jetzt kommt mit DevOps eine neue Philosophie daher, die vielfach aus der Entwicklung getrieben wird. Das Misstrauen auf beiden Seiten ist groß. Unsere Application-Management-Experten Richard Attermeyer und Ines Möckel zeigten in einem Vortrag bei der OOP 2015, dass ITIL und DevOps eine gute Kombination sein können, von der alle Projektbeteiligte profitieren.
DevOps findet schnell Anklang in SMBs. Organisationen, die bisher auch eine nicht sehr formalisierte Trennung zwischen Entwicklung und Betrieb hatten und häufig auch noch nicht über formalisierte Prozesse verfügen. Viele andere Betriebe haben dann in den letzten Jahren angefangen ITIL / ITSM einzuführen, eine Initiative, die eher aus dem Betrieb getrieben wurde und auf Entwicklungsbereiche häufig als Behinderung betrachtet werden.
DevOps auf der anderen Seite ist eine Philosophie, die häufig aus den Entwicklungsabteilungen getrieben wird und auf Skepsis in den Betriebsabteilungen trifft (die wollen uns überflüssig machen, funktioniert nicht mit SOX). Häufig liegt das an falsch verstandenen Ideen der beiden Methoden / Philosophien. Im Vortrag zeigen wir am Beispiel der Einführung von ITIL für Managed Services, wie DevOps Prinzipien bei der Umsetzung von ITIL unterstützen können.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.TechDivision GmbH
Welches größere Unternehmen bzw. welcher Dienstleister kennt sie nicht, die sog. RFPs. Dabei steht der Begriff als Abkürzung für „Request for Proposal“ und bezeichnet im Softwareauswahl-prozess ein Dokument mit inhaltlich bindenden Angaben über Vertragsspezifikationen und weiteren Verhandlungsgegenständen, die vor der Ausarbeitung des eigentlichen Vertragswerkes
(Softwareerstellungsvertrag, Lizenzvertrag etc.) definiert werden.
Bei einem traditionellen Ausschreibungsprozess geht dem RFP meist ein sog. RFI (Request for Information) voraus, in dem unverbindliche Preis- und Leistungslisten möglicher Dienstleister eingeholt werden. Anhand dieser Information kann – zumindest
in der Theorie – bereits eine erste Vorauswahl (für den nachfolgenden RFP) vorgenommen werden.
Nachdem Projekte inzwischen richtigerweise häufig mit agilen Projektmanagementmethoden realisiert werden, passt ein klassisches Ausschreibungsverfahren in der Regel auch nicht mehr wirklich. Die Lösung hierfür ist ein Agiler Ausschreibungsprozess! In vorliegendem Dokument erklären wir die Vorgehensweise, Besonderheiten und Vorteile dieses Ansatzes.
Sollten Sie hierzu noch Fragen haben, stehen wir natürlich jederzeit gerne unter info@techdivision.com zur Verfügung.
VerbesserungsKATA – Umsetzung in einem Kommunalunternehmen – ein Praxisbericht!Learning Factory
Das moderne Geschäftsprozessmanagement beinhaltet Prozessdesign mit Potenzialanalyse und Soll-Prozessgestaltung mit Potenzialumsetzung.
In der ergebnisorientierten Analysephase, indem i.d.R. das Tagesgeschäft mit Schwachstellen/Potenzialen abgebildet wird, wurden nach der herkömmlichen, klassischen Vorgehensweise Maßnahmen definiert. Nicht selten entstanden dabei „Maßnahmenlisten“ mit mehreren hundert Maßnahmen, die dann auf Quick-Win´s „untersucht“ wurden.
Die mit viel Euphorie gestartete Umsetzung dieser Maßnahmen, bleibt jedoch mit Erledigung wichtiger und eiliger Aufgaben im Tagesgeschäft, oft nach kurzer Zeit „auf der Strecke“.
Da das strategische und operative Prozessmanagement kein Projekt, sondern eine Unternehmensphilosophie ist, haben wir zur Gestaltung der Soll-Prozesse die KATA-Methodik in großen Kommunalunternehmen installiert.
Erschließen Sie neue Geschäftschancen durch optimierte, automatisierte und ...Wolfgang Schmidt
Als Spezialist für digitalisierte Prozesse und Entscheidungsunterstützung auf Basis etablierter Methodik, offener Standards und IBM Middleware lösen wir Ihre Schnittstellenprobleme, schaffen flexible, optimierte und automatisierte Prozessanwendungen und verbessern mittels mathematischer und kognitiver Verfahren Ihre Entscheidungsprozesse – On-Premises, in der Cloud oder in hybriden Szenarien.
Unsere Expertise in Digitalisierung und Entscheidungsunterstützung
Prozessintegrationen
-flexibel digitalisiert entlang Ihrer Wertschöpfungskette
-Zeitersparnis durch effizientes Ressourcenmanagement
Entscheidungsprozesse
-automatisiert, Datenanalyse – gestützt und mathematisch optimiert
-mit dem passenden Verfahren, ob cognitive, predictive oder prescriprive
Fachanwendungen
-flexible, optimierte und automatisierte Prozessanwendungen
-mehr Transparenz, mehr Kontrolle und geringere Kosten
Daten- und Anwendungsschnittstellen
-automatisiert, zuverlässig und stabil im Betrieb
-für B2B, M2M oder Industrie 4.0
Middleware-Platformen
-maximal verfügbar, flexibel und skalierbar
-ob Standardapplikation oder IoT, ob Microservices oder SOA
Lösungsarchitektur
-die optimale Lösung mittels Kombination passgenauer Komponenten und Methoden
-Die Mischung macht’s: Ob Open Source, Herstellersoftware oder Cloud-Services
Einfache Wartungsplanung in SAP mit einer Portallösung plus mobiler Checklistenargvis GmbH
Das Arbeiten mit Wartungsplänen und den dazugehörigen Terminen und Prozessen ist in SAP nicht sehr intuitiv. Das argvis; Maintenance Portal bietet als Alternative zum SAP GUI eine benutzerfreundliche Oberfläche, um z. B. Wartungspläne und deren Termine einzusehen. Mit dem Wartungsplan Monitor behalten Sie kommende Wartungspläne einfach im Überblick und können Abrufe einfach anwählen und disponieren. Dabei arbeitet der Anwender in modernen und optimierten Oberflächen, die ihn bei Bedarf dennoch direkt in die entsprechende SAP-Transaktion führen.
Inhalte des Workshops:
• UX und UI in modernen Oberflächen für SAP Instandhaltung
• Wie funktioniert Wartungsplanung in SAP PM/EAM
• Mobile Checklisten mit Prüflosen
• Woher stammen meine Wartungsinformationen und wie kann ich diese vereinfacht darstellen – Wartungsplan Monitor – Abrufe und Zyklen
• Welche Vorteile ergeben sich für den Anwender
Fachliche Leitung und Moderation: Philipp Reinhard, Geschäftsführer, argvis, GmbH, und Frank Ostwald, Head of Sales/Marketing, argvis; GmbH
DevOps fordert die Anwendung agiler Methoden und Konzepte des Software-Managements für die IT Operations. Was das bedeutet, erfahren Sie hier!
Eine Revolution findet zurzeit in den Anwendungsentwicklungs-Abteilungen statt: Agile Entwicklungs- und Projektmanagement-Ansätze ersetzen schwerfällige Wasserfall-Methoden und versprechen rasche Auslieferung von neuer Funktionalität mit besserer Qualität.
Doch dies kann nur eine Seite der Medaille sein: Der IT-Betrieb muss genauso in der Lage sein, den sehr viel höheren Rhythmus an Changes und Releases bewältigen zu können. Die Antwort darauf: DevOps!
In dieser Präsentation erhalten Sie eine Übersicht über die neusten Trends im IT-Betrieb und wie man neu (DevOps) mit alt (ITIL) verbindet und Hype vn der Realität unterscheidet.
Management of the system architecture in large-scale projectsCapgemini
Es werden zunächst die Probleme dargestellt, die sich aus den besonderen Anforderungen ergeben, die Großprojekte mit sich bringen und sich erst im Verlauf des Projektes zeigen. Diese Probleme erfordern ein aktives Management der Systemarchitektur. Trotzdem sind historisch anwachsende Strukturen mit Wartungsproblemen teilweise nicht zu vermeiden, welche durch Refactorings aufgelöst und bereinigt werden sollten. Dieser Vortrag stellt eine in der Praxis erprobte Methodik vor, mit der Architekturen gemanagt sowie strukturelle Probleme behoben werden können.
Software has several characteristics that distinguish it from other goods. These include, that it is not subject to any laws of nature, is easy to change, theoretically infinitely replicable and largely invisible. This culminates in a special kind of complexity that makes it difficult even for experienced software developers and architects to lead their projects to success. In this talk, we will therefore look deeper into the effects that the described characteristics have and how they affect any software system, be it the small mobile app or the enterprise cloud cluster.
We (don't) need a software architect!?!Hendrik Lösch
„Softwarearchitekt“ – in Zeiten agiler Entwicklung wirkt dieser Begriff fast schon angestaubt und veraltet, vermittelt er doch den Eindruck, man würde vorrangig Blaupausen erstellen, die dann von anderen Personen in Beton gegossen und nie wieder verändert werden. Dies ist nicht korrekt. Software verändert sich kontinuierlich und evolutionär. Beachtet man dies nicht, kann es zu erheblichen Problemen kommen.
Der Vortrag soll daher einen Einblick in die Arbeit von Softwarearchitekten bieten und aufzeigen, was passieren kann, wenn es sie nicht gibt oder ihre Arbeit falsch verstanden wird. Hierbei wird auf die unterschiedlichen Arten von Software und die Zusammenstellung von Teams eingegangen sowie betrachtet, welche Aspekte der Softwareentwicklung in besonderem Maße von Softwarearchitekten profitieren können.
Dabei sei gleich vorweg verraten: Es geht nicht nur um Quellcode…
Quantitativer und qualitativer Nutzen von PLM ProjektenIntelliact AG
Besuchen Sie das nächste Webinar! Mehr Informationen und Termine: https://intelliact.ch/events/plm-open-hours
****
PLM-Projekte sind in der Regel komplex und belasten Unternehmen durch erhebliche finanzielle und personelle Ressourcen. Deswegen stellt sich für die Entscheidungsträger im Top-Management oft die Frage nach deren konkreten Nutzen sowie der strategischen Bedeutung. Vor allem Organisationen ohne dedizierte inhaltliche Vertretung von PLM in der Geschäftsleitung tun sich schwer, mit einer objektiven Einordnung. Sie neigen dazu, PLM-Vorhaben rein durch klassische Finanzkennzahlen (KPIs) zu bewerten.
(link: https://intelliact.ch/team/patrick-henseler text: Patrick Henseler target: _blank), Senior Consultants & Geschäftsführer, Intelliact AG hat dieses Spannungsfeld zwischen Projekt- und Geschäftsleitung unter die Lupe genommen und zeigte Wege auf, wie Sie PLM-Projekte quantitativ und qualitativ bewerten können, um den notwendigen Management-Support zu erhalten.
Das Dasein eines Codehausmeisters ist schon nicht einfach. Da müht man sich tagein, tagaus damit ab die Software am Laufen zu halten und niemand dankt es einem. Schlimmer noch, ständig kommt jemand und beschwert sich das etwas nicht funktioniert oder macht die ganze Sache sogar noch schlimmer. Bloß wenn man mal etwas ändern will, dann ist kein Weg drin. Erkennen Sie sich hier wieder? Wenn ja hilft Ihnen unser Survival Kit weiter. Es unterstützt Sie mit Werkzeugen sowie Argumenten beim steten Kampf um Softwarequalität, Wartbarkeit und Restrukturierungsbudgets; mit dem Ziel Ihnen die Arbeit zu erleichtern und Ihrer Software endlich die Pflege zu Teil werden zu lassen, die sie so bitter nötig hat.
DevOps Prinzipien im Zusammenspiel mit Kubernetes QAware GmbH
Fachposter, 2020: Erstellt von QAware in Zusammenarbeit mit Prof. Dr. Kratzke, Technische Hochschule Lübeck und ObjektSpektrum (Verlag: SIGS DATACOM).
Bestellbar unter https://www.sigs-datacom.de/order/poster/DevOps_Prinzipien-Kubernetes.php
(Dokument bitte herunterladen für bessere Lesbarkeit)
Microsoft Dynamics® Sure Step ist sowohl für Kunden als auch für Partner ein zentraler Bestandteil bei der Verwendung von Microsoft Dynamics. Sure Step bietet eine skalierbare und wiederholbare Implementierungsmethode für Microsoft-Partner, die bei der Implementierung von Microsoft Dynamics-Lösungen verwendet werden kann. Durch Verwendung konsistenter Methodologien, für die auf Best Practices zurückgegriffen wird, die aus den Erfahrungen mit Microsoft Dynamics-Implementierungen in aller Welt resultieren, können Partner bei gleichzeitiger Steigerung der Produktivität ihrer Berater Implementierungszeit, Kosten und Risiken verringern.
http://www.opitz-consulting.com/go/3-4-11
Viele Betriebe haben in den letzten Jahren ihren Anwendungsbetrieb an ITIL ausgerichtet. Jetzt kommt mit DevOps eine neue Philosophie daher, die vielfach aus der Entwicklung getrieben wird. Das Misstrauen auf beiden Seiten ist groß. Unsere Application-Management-Experten Richard Attermeyer und Ines Möckel zeigten in einem Vortrag bei der OOP 2015, dass ITIL und DevOps eine gute Kombination sein können, von der alle Projektbeteiligte profitieren.
DevOps findet schnell Anklang in SMBs. Organisationen, die bisher auch eine nicht sehr formalisierte Trennung zwischen Entwicklung und Betrieb hatten und häufig auch noch nicht über formalisierte Prozesse verfügen. Viele andere Betriebe haben dann in den letzten Jahren angefangen ITIL / ITSM einzuführen, eine Initiative, die eher aus dem Betrieb getrieben wurde und auf Entwicklungsbereiche häufig als Behinderung betrachtet werden.
DevOps auf der anderen Seite ist eine Philosophie, die häufig aus den Entwicklungsabteilungen getrieben wird und auf Skepsis in den Betriebsabteilungen trifft (die wollen uns überflüssig machen, funktioniert nicht mit SOX). Häufig liegt das an falsch verstandenen Ideen der beiden Methoden / Philosophien. Im Vortrag zeigen wir am Beispiel der Einführung von ITIL für Managed Services, wie DevOps Prinzipien bei der Umsetzung von ITIL unterstützen können.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Warum ein traditioneller Ausschreibungsprozess (RFP) nicht mehr zeitgemäß ist.TechDivision GmbH
Welches größere Unternehmen bzw. welcher Dienstleister kennt sie nicht, die sog. RFPs. Dabei steht der Begriff als Abkürzung für „Request for Proposal“ und bezeichnet im Softwareauswahl-prozess ein Dokument mit inhaltlich bindenden Angaben über Vertragsspezifikationen und weiteren Verhandlungsgegenständen, die vor der Ausarbeitung des eigentlichen Vertragswerkes
(Softwareerstellungsvertrag, Lizenzvertrag etc.) definiert werden.
Bei einem traditionellen Ausschreibungsprozess geht dem RFP meist ein sog. RFI (Request for Information) voraus, in dem unverbindliche Preis- und Leistungslisten möglicher Dienstleister eingeholt werden. Anhand dieser Information kann – zumindest
in der Theorie – bereits eine erste Vorauswahl (für den nachfolgenden RFP) vorgenommen werden.
Nachdem Projekte inzwischen richtigerweise häufig mit agilen Projektmanagementmethoden realisiert werden, passt ein klassisches Ausschreibungsverfahren in der Regel auch nicht mehr wirklich. Die Lösung hierfür ist ein Agiler Ausschreibungsprozess! In vorliegendem Dokument erklären wir die Vorgehensweise, Besonderheiten und Vorteile dieses Ansatzes.
Sollten Sie hierzu noch Fragen haben, stehen wir natürlich jederzeit gerne unter info@techdivision.com zur Verfügung.
VerbesserungsKATA – Umsetzung in einem Kommunalunternehmen – ein Praxisbericht!Learning Factory
Das moderne Geschäftsprozessmanagement beinhaltet Prozessdesign mit Potenzialanalyse und Soll-Prozessgestaltung mit Potenzialumsetzung.
In der ergebnisorientierten Analysephase, indem i.d.R. das Tagesgeschäft mit Schwachstellen/Potenzialen abgebildet wird, wurden nach der herkömmlichen, klassischen Vorgehensweise Maßnahmen definiert. Nicht selten entstanden dabei „Maßnahmenlisten“ mit mehreren hundert Maßnahmen, die dann auf Quick-Win´s „untersucht“ wurden.
Die mit viel Euphorie gestartete Umsetzung dieser Maßnahmen, bleibt jedoch mit Erledigung wichtiger und eiliger Aufgaben im Tagesgeschäft, oft nach kurzer Zeit „auf der Strecke“.
Da das strategische und operative Prozessmanagement kein Projekt, sondern eine Unternehmensphilosophie ist, haben wir zur Gestaltung der Soll-Prozesse die KATA-Methodik in großen Kommunalunternehmen installiert.
Erschließen Sie neue Geschäftschancen durch optimierte, automatisierte und ...Wolfgang Schmidt
Als Spezialist für digitalisierte Prozesse und Entscheidungsunterstützung auf Basis etablierter Methodik, offener Standards und IBM Middleware lösen wir Ihre Schnittstellenprobleme, schaffen flexible, optimierte und automatisierte Prozessanwendungen und verbessern mittels mathematischer und kognitiver Verfahren Ihre Entscheidungsprozesse – On-Premises, in der Cloud oder in hybriden Szenarien.
Unsere Expertise in Digitalisierung und Entscheidungsunterstützung
Prozessintegrationen
-flexibel digitalisiert entlang Ihrer Wertschöpfungskette
-Zeitersparnis durch effizientes Ressourcenmanagement
Entscheidungsprozesse
-automatisiert, Datenanalyse – gestützt und mathematisch optimiert
-mit dem passenden Verfahren, ob cognitive, predictive oder prescriprive
Fachanwendungen
-flexible, optimierte und automatisierte Prozessanwendungen
-mehr Transparenz, mehr Kontrolle und geringere Kosten
Daten- und Anwendungsschnittstellen
-automatisiert, zuverlässig und stabil im Betrieb
-für B2B, M2M oder Industrie 4.0
Middleware-Platformen
-maximal verfügbar, flexibel und skalierbar
-ob Standardapplikation oder IoT, ob Microservices oder SOA
Lösungsarchitektur
-die optimale Lösung mittels Kombination passgenauer Komponenten und Methoden
-Die Mischung macht’s: Ob Open Source, Herstellersoftware oder Cloud-Services
Einfache Wartungsplanung in SAP mit einer Portallösung plus mobiler Checklistenargvis GmbH
Das Arbeiten mit Wartungsplänen und den dazugehörigen Terminen und Prozessen ist in SAP nicht sehr intuitiv. Das argvis; Maintenance Portal bietet als Alternative zum SAP GUI eine benutzerfreundliche Oberfläche, um z. B. Wartungspläne und deren Termine einzusehen. Mit dem Wartungsplan Monitor behalten Sie kommende Wartungspläne einfach im Überblick und können Abrufe einfach anwählen und disponieren. Dabei arbeitet der Anwender in modernen und optimierten Oberflächen, die ihn bei Bedarf dennoch direkt in die entsprechende SAP-Transaktion führen.
Inhalte des Workshops:
• UX und UI in modernen Oberflächen für SAP Instandhaltung
• Wie funktioniert Wartungsplanung in SAP PM/EAM
• Mobile Checklisten mit Prüflosen
• Woher stammen meine Wartungsinformationen und wie kann ich diese vereinfacht darstellen – Wartungsplan Monitor – Abrufe und Zyklen
• Welche Vorteile ergeben sich für den Anwender
Fachliche Leitung und Moderation: Philipp Reinhard, Geschäftsführer, argvis, GmbH, und Frank Ostwald, Head of Sales/Marketing, argvis; GmbH
DevOps fordert die Anwendung agiler Methoden und Konzepte des Software-Managements für die IT Operations. Was das bedeutet, erfahren Sie hier!
Eine Revolution findet zurzeit in den Anwendungsentwicklungs-Abteilungen statt: Agile Entwicklungs- und Projektmanagement-Ansätze ersetzen schwerfällige Wasserfall-Methoden und versprechen rasche Auslieferung von neuer Funktionalität mit besserer Qualität.
Doch dies kann nur eine Seite der Medaille sein: Der IT-Betrieb muss genauso in der Lage sein, den sehr viel höheren Rhythmus an Changes und Releases bewältigen zu können. Die Antwort darauf: DevOps!
In dieser Präsentation erhalten Sie eine Übersicht über die neusten Trends im IT-Betrieb und wie man neu (DevOps) mit alt (ITIL) verbindet und Hype vn der Realität unterscheidet.
Management of the system architecture in large-scale projectsCapgemini
Es werden zunächst die Probleme dargestellt, die sich aus den besonderen Anforderungen ergeben, die Großprojekte mit sich bringen und sich erst im Verlauf des Projektes zeigen. Diese Probleme erfordern ein aktives Management der Systemarchitektur. Trotzdem sind historisch anwachsende Strukturen mit Wartungsproblemen teilweise nicht zu vermeiden, welche durch Refactorings aufgelöst und bereinigt werden sollten. Dieser Vortrag stellt eine in der Praxis erprobte Methodik vor, mit der Architekturen gemanagt sowie strukturelle Probleme behoben werden können.
Software has several characteristics that distinguish it from other goods. These include, that it is not subject to any laws of nature, is easy to change, theoretically infinitely replicable and largely invisible. This culminates in a special kind of complexity that makes it difficult even for experienced software developers and architects to lead their projects to success. In this talk, we will therefore look deeper into the effects that the described characteristics have and how they affect any software system, be it the small mobile app or the enterprise cloud cluster.
We (don't) need a software architect!?!Hendrik Lösch
„Softwarearchitekt“ – in Zeiten agiler Entwicklung wirkt dieser Begriff fast schon angestaubt und veraltet, vermittelt er doch den Eindruck, man würde vorrangig Blaupausen erstellen, die dann von anderen Personen in Beton gegossen und nie wieder verändert werden. Dies ist nicht korrekt. Software verändert sich kontinuierlich und evolutionär. Beachtet man dies nicht, kann es zu erheblichen Problemen kommen.
Der Vortrag soll daher einen Einblick in die Arbeit von Softwarearchitekten bieten und aufzeigen, was passieren kann, wenn es sie nicht gibt oder ihre Arbeit falsch verstanden wird. Hierbei wird auf die unterschiedlichen Arten von Software und die Zusammenstellung von Teams eingegangen sowie betrachtet, welche Aspekte der Softwareentwicklung in besonderem Maße von Softwarearchitekten profitieren können.
Dabei sei gleich vorweg verraten: Es geht nicht nur um Quellcode…
Restrukturierung einer industriellen GroßapplikationHendrik Lösch
In diesem Vortrag stellt Hendrik Lösch seine Erkenntnisse aus der Restrukturierung einer industriellen Großapplikation vor und zieht ein Zwischenfazit. Damit soll den Zuschauern ein Bild von den Punkten vermittelt werden, auf die bei einem solchen Vorhaben besonders zu achten ist.
Der Software auf den Zahn gefühlt - Einstieg in die ArchitekturbewertungHendrik Lösch
Eine Softwarearchitektur ist kein starres Gebilde. Sie wird nicht einmal festgelegt, dann errichtet und danach nie wieder angefasst. Softwarearchitekturen leben. Sie verändern sich und können gegebenenfalls auch mutieren. Aus diesem Grund sollten sie regelmäßig überprüft und bewertet werden, denn sonst droht der Verfall.
In diesem Workshop sehen wir uns verschiedene Vorgehen und Werkzeuge zur Bewertung von Softwarearchitekturen an. Wir betrachten Qualitätsziele, erstellen passende Überprüfungsszenarien und widmen uns objektiven Risikobewertungen.
„Wie reden Sie denn mit mir?!?“ – Stakeholder überzeugen als SoftwarearchitektHendrik Lösch
Softwarearchitekt wird man nicht von heute auf morgen. In aller Regel erhält man den Titel, nachdem man viele Jahre Quellcode geschrieben und sich mit technischem Klein-Kram beschäftigt hat. Dies hat gegebenenfalls zur Folge, dass wir Architekten nicht so recht vorbereitet sind, wenn es dann darum geht, unsere Belange gegenüber Personen zu erläutern, die keinen technischen Hintergrund besitzen. Schnell läuft man also Gefahr, notwendige Maßnahmen an der falschen Stelle zu adressieren, wichtige Stakeholder zu vergessen oder – dank zu technischen Begründungen – jene gänzlich zu verschrecken.
Aus diesem Grund wollen wir uns zunächst einige allgemeine Hilfsmittel ansehen, die nicht zwangsläufig etwas mit Softwarearchitekturen zu tun haben, uns aber bspw. helfen, Gespräche besser zu planen und vorzubereiten. Es geht aber auch um konkrete Werkzeuge wie zum Beispiel Stakeholder-Maps, mit denen wir unsere Zielgruppen im Blick behalten, Issue-Maps, mit denen wir die Problemstellen überblicken können oder auch Risikomatrizen, durch die es uns leichter fällt, Maßnahmen zu priorisieren.
Ziel des Ganzen ist es, den Teilnehmern neben den Werkzeugen auch ein Gefühl dafür zu geben, welche Stolpersteine außerhalb des Softwaredesigns und der Implementierung liegen, damit diese zukünftig leichter umschifft werden können.
Ziel des Vortrags ist es ein Gefühl für Themen außerhalb der reinen Programmierung zu schaffen. Hierbei siollen vor allem die Auswirkungen wichtiger Entscheidungen herausgearbeitet werden. Zielgruppe: Studierende
.NET 5 klopft nicht mehr nur leicht an die Tür, es trommelt vielmehr in ohrenbetäubender Lautstärke. Seit Microsoft angekündigt hat, dass das klassische .NET zukünftig nicht mehr unterstützt wird, stellt sich kaum noch die Frage ob, sondern nur noch wann, eine Migration notwendig wird.
In dieser Dev Session betrachten wir deshalb zunächst was es mit den verschiedenen .NET Versionen auf sich hat und wie sich diese über die Jahre entwickelt haben. Anschließend migrieren wir eine WPF Anwendung und betrachten hierbei das Vorgehen, sowie die damit verbundenen Herausforderungen. Dabei gehen wir auch auf die Zukunft von so wichtigen Bestandteilen wie Entity Framework und Windows Communication Foundation ein. Abschließend behandeln wir Migrationsszenarien bei denen nicht die gesamte, sondern nur Teile von Anwendungen migriert werden und erläutern die damit verbundenen Migrationsstrategien beispielhaft.
Im Kosmos der Web UI Frameworks ist es nicht leicht sich neben den Platzhirschen Angular und React zu behaupten, bieten diese doch scheinbar alles was das Entwicklerherz begehrt. Nichts desto trotz hat sich Vue.js in den vergangenen Jahren einen Namen als dritte Möglichkeit erarbeitet.
In dieser Session soll daher begründet werden wie dem Framework das gelingen konnte. Wie es grundsätzlich funktioniert und wie es das Ökosystem aussieht, dass sich mittlerweile rund um Vue.JS gebildet hat. Zeitgleich werden die darin befindlichen Ansätze mit denen in Angular und React verglichen um eine Entscheidungsgrundlage für oder auch gegen Vue.JS bieten zu können.
Haben Sie das Ihr Softwaresystem schon einmal gefragt? Haben Sie sich schon einmal ernsthaft mit dem Befinden der Applikation beschäftigt, die Sie oder Ihre Entwickler tagtäglich erweitern? Hat sie vielleicht keine Lust mehr und will kündigen, oder geht es ihr blendend und sie verlangt nach MEHR?
In diesem Vortrag sehen wir uns an wie wir das Befinden unserer Software ermitteln können. Dazu zählen Prozess- und Codemetriken, aber auch direkte Betrachtungen im Alltag. Ziel ist es, eine Art Frühwarnsystem zu etablieren, das uns sagt wann wir evtl. zu viel oder sogar zu wenig verlangen in dem wir Symptome aufdecken und diesen mögliche Krankheitsbilder zuordnen.
Clean Code ist wichtig, darin sind wir uns einig. Doch wie stellt man sicher, dass der Code sauber wird und auch sauber bleibt? Vor allem: was heißt eigentlich Sauberkeit und woran genau misst sie sich?Hendrik Lösch erklärt in seinem Vortrag verschiedene Qualitätsmetriken und wie diese mit Visual Studio geprüft werden können. Zu den betrachteten Metriken und Begriffen zählen zum Beispiel Klassiker wie Code Coverage und Lines of Code, aber auch die zyklomatische Komplexität und technische Schuld. Darüber hinaus wird der generelle Umgang mit Coding Conventions betrachtet und welche Herausforderungen sich ergeben wenn man sie in einem Unternehmen einführen möchte.
Refactoring gehört zum wichtigen Handwerkszeug eines jeden Entwicklers. Dabei wird der Code schrittweise transformiert um ihn besser verständlich und lesbar zu gestalten. In dieser Session beschäftigen wir uns mit unterschiedlichen Refactoring Patterns, basierend auf häufig auftretenden Fehlersituation. Zu diesen gehören die einfachen Grundlagen wie das extrahieren und Zusammenfassen von Funktionalität, insbesondere aber komplexe Szenarien wie beispielsweise das Aufbrechen von Vererbungshierarchien hin zu einer Objektkomposition, oder das Auflösen von statischen Klassen hin zu Dependency Injection.
Erfahrene Ärzte können einige Krankheiten bereits am Geruch ihres Patienten erkennen. Ähnliches können erfahrene Softwareentwickler, im übertragenen Sinne auch mit Software tun. Beide Berufsgruppen nehmen dazu unterschwellige Hinweise auf und können Rückschlüsse darauf ziehen welche Bereiche nicht arbeiten wie sie sollten. Typische schlechte Gerüche wollen wir uns in diesem Vortrag ansehen und darüber sprechen wie man ihnen begegnet. Um sie leichter zu verstehen, werden sie dabei als Antipattern beschrieben. Auf diese Weise wird der Rahmen abgesteckt in dem sie auftreten und wie man ihnen begegnen kann.
Innerhalb eines Softwareprojektes geht es nicht vorrangig um Quellcode. Dieser ist meist eher das End- oder Zwischenprodukt verschiedenster externer Einflüsse. Zu solchen Einflüssen zählen natürlich die Anforderungen und die Zusammensetzung des Projektteams, aber beispielsweise auch der Zeitrahmen innerhalb dem eine Leistung zu rbringen ist, die fachliche Domäne, sowie das Alter des bestehenden Systems.Im Rahmen dieses Vortrags sollen die Herausforderungen bei der Bewertung von Softwaresystemen skizziert und ein Vorgehen erläutert werden, mit dem es möglich ist Risiken innerhalb der Code Basis, aber auch der Projektzusammensetzung zu erkennen. Denn nur wenn man konkrete Risiken kennt, kann man auch Maßnahmen einleiten um jenen effektiv zu begegnen.
Diese Folien beschreiben die wichtigsten Informationen rund um das Thema MVVM mit WPF. Dazu gehört ein Vergleich von Frameworks, die Erläuterung von IoC Containern, die Klärung was MVVM ist und vieles mehr.
3. ANPASSBARKEIT VS. BUSSINESS VALUE
Innere Qualität /
Anpassbarkeit
Business Value
Start der
Entwicklung
Featureentwicklung mit
geringem Qualitätsanspruch
Featureentwicklung
unter hohem Zeitdruck
Entfernen fehlerhafter
Bestandteile
Umfassende
Restrukturierung inkl.
neuer Features
Einsatz der
Pfadfinderregel
7. › Restrukturierung
› Anpassung der Struktur ohne Verhaltensänderung
› Migration
› Übertragung vorhandener Funktionalität auf neue technische Basis
› Sanierung
› Versetzen des Systems in seinen ursprünglich geplanten Zustand
DEFINITIONEN
44. Analyse des
Bestandssystems
Zerlegung der
Systemstruktur
Design der
Zielschnittstellen
Design des
Zielsystems
Design der
Zieldatenbank
Aufbau
notwendiger
Gateways
Migration der
Legacy
Datenbanken
Migration der
Legacy
Applikationen
Migration der
Legacy
Schnittstellen
Abschalten des
Altsystems
CHICKEN LITTLE
46. Schritt 1 – Abhängigkeiten analysieren
CHICKEN LITTE
Invoice
Service
Von Nach Wie
SalesAgreementManager InvoiceCalculationPresenter Direktaufruf
SalesDetailPresenter InvoiceCalculationSheetPresenter Direktaufruf
ConsultingDetail Invoice Dto & InvoiceCalculationManager GetById
47. Schritt 2 – Schnittstelle extrahieren
CHICKEN LITTE
Invoice
Service
Von Nach Wie
SalesAgreementManager InvoiceCalculationPresenter Direktaufruf
SalesDetailPresenter InvoiceCalculationSheetPresenter Direktaufruf
ConsultingDetail Invoice Dto & InvoiceCalculationManager GetById
IInvoice
Service
48. Schritt 3 – Aufrufer auf Schnittstellen anpassen
CHICKEN LITTE
Invoice
Service
Von Nach Wie Ersetzen durch
SalesAgreementManager InvoiceCalculationPresenter Direktaufruf ShowInvoiceSheet
SalesDetailPresenter InvoiceCalculationSheetPresenter Direktaufruf ShowInvoiceSheet
ConsultingDetail Invoice Dto & InvoiceCalculationManager GetById entfernen
IInvoice
Service
49. Schritt 3 – Schnittstelle ändern
CHICKEN LITTE
Invoice
Service
IInvoice
Service
Von Nach
SalesAgreementManager ShowInvoiceSheet
SalesDetailPresenter ShowInvoiceSheet
50. Schritt 4 – Migration der Funktionalität
CHICKEN LITTE
Invoice
Service 2.0
IInvoice
Service
Von Nach
SalesAgreementManager ShowInvoiceSheet
SalesDetailPresenter ShowInvoiceSheet
Man beachte auch, dass die Pfeile immer kürzer werden.
Verringerung des Ressourcenbedarfs.
Optimierung des Quellcodes durch vereinheitlichte Konzepte.
Ablösen alter Frameworks durch neue.
Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
Das Softwaresystem war ein Monolith. Wir haben Teile des Monolithen verändert. Damit wurden unsere Änderungen Teil des Monoliths und wir übernahmen die Verantwortung für alle Fehler die darin enthalten sind.
Skype kann nicht mehr verwendet werden wenn auf Teams umgestellt wird.
Den Nutzern fallen reihenweise fehlende oder geänderte Features auf:
Verwendung mehrerer Chatfenster zeitgleich? -> Geht nicht mehr
Auswahl des aktuellen Sprechers? -> Teams teilt die Darstellung auf, man kann aber nicht konfigurieren wie.
Zeitgleiche Pflege mehrerer Systeme.
Investitionen in das Altsystem gehen nach Migration komplett verloren.
Geringe Akzeptanz des neuen Systems wenn Funktionalität eingeschränkt gegenüber Altsystem.
Neuer Code bedeutet auch neue Fehler.
Skype kann nicht mehr verwendet werden wenn auf Teams umgestellt wird.
Den Nutzern fallen reihenweise fehlende oder geänderte Features auf:
Verwendung mehrerer Chatfenster zeitgleich? -> Geht nicht mehr
Auswahl des aktuellen Sprechers? -> Teams teilt die Darstellung auf, man kann aber nur eingeschränkt konfigurieren wie.
Es gibt keine Bugs oder Fehler, es gilt nur die Frage ob ein Verhalten akzeptabel ist oder nicht.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Farben – Fachlichkeit
Vierecke – Teams
Schwarze Pfeile – Upstream Beziehung
Rote Pfeile – Schlecht gewählte Upstream Beziehungen
Orangene Pfeile – Partnerschaftliche Beziehungen
Legt man die Verantwortlichkeiten der Teams darüber, merkt man, wo Abhängigkeiten zwischen den Teams bestehen. Hier ist es insbesondere schwierig, weil Partnerschaftliche Beziehungen zwischen Modulen bestehen die bei unterschiedlichen Teams liegen. Außerdem liegen Module der gleichen Fachlichkeit bei unterschiedlichen Teams.
Grüne Pfeile -> bewusste Abhängigkeitsumkehr.
Die Quellcodemenge die zu betreuen ist, ist fast noch die gleiche. Team 1 hat etwas mehr zu tun.
Klare fachliche Trennung einzelner Module.
Fachliche wie technische Bestandteile können leicht ausgetauscht oder verändert werden.
Gerichtete und damit nachvollziehbare Abhängigkeiten.
Änderungen wirken sich nur auf einen definierten Teilbereich aus und sind frei von Nebeneffekten.
Kommunikation nur über abstrakte Schnittstellen.
Es ist leicht automatisierte Tests zu verfassen und Bestandteile unabhängig voneinander zu betrachten.
Zusammensetzung der Anwendung durch entsprechende Modulaggregatoren und eine Rahmenapplikation.
Definierte Schlüsselpunkte weisen hohe Komplexität auf, alle anderen eher geringe.
Einheitliches Vorgehen bei der Umsetzung neuer Funktionalität.
Geringer Einarbeitungsaufwand.
Anwendung wird geklont. Ab der Stelle wo sie geklont wurde, laufen sie bewusst auseinander und kümmern sich nicht mehr umeinander.
Der Code wird aufgespalten Man entfernt die anderen Bestandteile komplett.
Es wird nur das entfernt was definitiv nicht gebraucht wird. Alles andere bleibt drin, selbst wenn es ggf. nicht benötigt wird.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Die gemeinsamen Bestandteile werden wieder zusammen geführt und den anderen Teilen zur Verfügung gestellt.
Das System wird in viele, völlig eigenständige Systeme (Self-Contained Services zerlegt).