Wir schaffen
menschenorientierte
digitale Erlebnisse

 

 

 

Die Pandemie hat die Einführung von Technologien beschleunigt.https://cleverlance.com/de/blog/Seiten/Petr-Stros.aspxDie Pandemie hat die Einführung von Technologien beschleunigt.<p>​​Laut Petr Štros werden die Technologietrends in diesem Jahr Lieferdienste, Automatisierung und durch Daten gesteuerte Unternehmen sein. Sie werden den Unternehmen helfen, den Personalmangel zu beheben, sagt der Chef von Cleverlance.<br></p><p>Die letzten zwei Jahre waren für die Tech-Welt ein bisschen wie ein „Hundejahr“ - sieben echte Jahre. Das ist zumindest die Einschätzung von Petr Štros, dem Chef des einheimischen Technologieunternehmens Cleverlance, über die vergangene Pandemieperiode. Ihm zufolge war es während der Pandemie möglich, in rasantem Tempo Technologien umzusetzen, bei denen viele Unternehmen zuvor nur auf der Stelle traten. Und alles schreitet mit Meilenstiefeln voran.</p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/45.jpg" data-themekey="#" alt="" style="margin:5px 0px;" />In seinem Kommentar für CzechCrunch spricht der Chef von Cleverlance, einem Unternehmen, das im vergangenen Jahr 1,4 Mrd. CZK erwirtschaftet hat und zur Aricoma-Gruppe gehört, darüber, welche technologischen Trends uns im Jahr 2022 erwarten und worauf sich Unternehmen konzentrieren sollten, wenn sie sich nicht auf ihren Lorbeeren ausruhen, sondern zu den Technologieführern gehören wollen.<br></p><p>Einerseits verschärfen die durch die Pandemie beschleunigten Technologietrends den Mangel an IT-Spezialisten auf dem Arbeitsmarkt, die bei der Einführung neuer Technologien helfen können. Andererseits können sie den Unternehmen helfen, den Mangel an erfahrenen Arbeitskräften in vielen anderen Berufen zu beheben.<br></p><p>Die Kommunikationstechnologien ermöglichen es ihnen, Mitarbeiter außerhalb der normalen geografischen Reichweite ihrer Niederlassungen und Werke „remote“ einzusetzen. Gleichzeitig ist es beispielsweise möglich, das Schlüsselwissen von ausscheidenden Führungskräfte zu „algorithmisieren“ und so der neuen Generation zur Verfügung zu stellen.<br></p><h2>Bereitstellung von Remote-Dienstleistungen<br></h2><p>Die Arbeit von zu Hause aus (und die Telearbeit im Allgemeinen) hat es den Unternehmen in vielen Berufszweigen ermöglicht, Mitarbeiter von Orten außerhalb ihrer Büros in ihre Teams aufzunehmen. Mit dieser „Dezentralisierung“ der Arbeit geht die Möglichkeit einher, Dienstleistungen und Produkte „aus der Ferne“ zu liefern, ohne dass eine persönliche Anwesenheit beim Kunden erforderlich ist. IT- und Technologieberatungsfirmen aus Indien, Vietnam, der Ukraine, Weißrussland, Serbien, Nordmazedonien, Polen und der Tschechischen Republik bieten ihre Dienste bereits routinemäßig Unternehmen aus Westeuropa und Nordamerika an.<br></p><p>Auch der Online-Verkauf von Kleidung und Lebensmitteln ist weit verbreitet und wird sich laut der Beratungsfirma Cushman & Wakefield im Vergleich zum Vorjahr sogar verdoppeln. Sowohl die Automobilhersteller als auch die Autohäuser führen den Online-Verkauf ein, bei dem nicht nur die Auswahl des Fahrzeugs „aus der Ferne“ erfolgt, sondern auch die Finanzierung, die Unterzeichnung des Leasingvertrags, die Zahlung der ersten Rate und die Vereinbarung der Art und des Ortes der Lieferung.<br></p><p>Im Jahr 2022 werden also Unternehmen in Branchen, die sich niemand vorher vorstellen konnte, digitale Liefermöglichkeiten benötigen. Daher befassen sich die IT-Anbieter derzeit beispielsweise mit dem wachsenden Kundeninteresse an E-Shops, die mit Kundensystemen und digitalen Marketingplattformen verbunden sind und ihr Angebot auf einen bestimmten Besucher zuschneiden können.<br></p><p>Es gibt auch eine wachsende Nachfrage nach maßgeschneiderter Softwareentwicklung, da Unternehmen Kundenportale erstellen müssen, über die sie ihre digitalen Dienstleistungen anbieten können. Es ist jedoch keine Neuigkeit, dass der IT-Arbeitsmarkt bereits fast vollständig gesättigt ist. Ist es möglich, die wachsende Nachfrage nach IT-Dienstleistungen zu befriedigen?<br></p><h2>Automatisierung und künstliche Intelligenz<br></h2><p>Die Begriffe Automatisierung und künstliche Intelligenz werden am häufigsten im Zusammenhang mit der digitalen Transformation von Unternehmen genannt. Eine weitere wichtige Aufgabe besteht jedoch darin, das wichtige Fachwissen der ausscheidenden Führungskräfte zu „algorithmisieren“ und es der neuen Generation zugänglich zu machen.<br></p><p>Der Fachkräftemangel betrifft nicht nur die IT-Branche. Die Mitglieder der „Boomer“-Generation und ein Teil der Generation X gehen in den Ruhestand. In der Tschechischen Republik wird das Durchschnittsalter im Jahr 2022 auf 43 Jahre steigen (die Hälfte der Bevölkerung wird jünger, die andere Hälfte älter sein). Das Tempo, in dem erfahrene Arbeitnehmer durch jüngere Kollegen ersetzt werden, ist wahrscheinlich das schnellste in der Geschichte.<br></p><p>Künstliche Intelligenz und algorithmische Entscheidungsfindung werden dazu beitragen, dass das Fachwissen ausscheidender Fachleute im „Bewusstsein“ des Unternehmens verbleibt und in Zukunft praktisch genutzt werden kann. Der Vorteil von Software mit Funktionen der künstlichen Intelligenz ist die Fähigkeit zum maschinellen Lernen. Auf diese Weise hilft die Technologie den Unternehmen nicht nur, ihr Wissen zu bewahren, sondern auch, es viel schneller zu entwickeln und zu nutzen und so einen Wettbewerbsvorteil zu erlangen.<br></p><p>Typische Bereiche, in denen diese Technologien eingesetzt werden, sind zum Beispiel Cross- und Up-Selling, die Bewertung von Kreditanträgen oder die Planung und Verwaltung von Wartungsarbeiten. Sie werden z.B. im Verkauf zur flexiblen Preisgestaltung für einzelne Kundengruppen eingesetzt. In den letzten beiden Jahren hat ihre Verbreitung in anderen Gebieten stark zugenommen, was sich 2022 noch weiter beschleunigen wird.<br></p><h2>Durch Daten gesteuerte Organisationen<br></h2><p>Entscheidungsunterstützende Informationssysteme sind nicht neu. Die IT versucht seit langem, die Entscheidungsfindung von Unternehmen durch die Einführung von ERP-Systemen, Management-Informationssystemen, Business Intelligence und dergleichen zu unterstützen.<br></p><p>In der Vergangenheit dienten Entscheidungsunterstützungssysteme in erster Linie dazu, einfach auf Daten zuzugreifen, diese immer detaillierter aufzuschlüsseln und sie aus allen möglichen Blickwinkeln zu analysieren. Man musste jedoch seine eigenen Schlussfolgerungen ziehen.<br></p><p>Der gegenwärtige Trend geht jedoch zu „Einzweck“-Online-Dashboards, die die ihnen anvertrauten Daten analysieren und ihren Nutzern auf der Grundlage von Wissensmodellen Indikatoren und die aus ihren Werten resultierenden Schlussfolgerungen und Empfehlungen liefern. Es handelt sich um Anwendungen, die Anomalien aufspüren, sie hervorheben und eine geeignete Reaktion empfehlen können, so dass der Nutzer nicht selbst nach den Anomalien in den Daten suchen und die Ursachen analysieren muss.<br></p><p>Beispiele für derartige Dienste im Jahr 2022 sind die Verwaltung von Kundendienstleistungen, die Überwachung des Online-Verkaufs in Echtzeit, die Überwachung der Produktivität, die Bestandsverwaltung, die Bewertung von Immobilien oder die Bewertung des aktuellen Stands der Entwicklung von Softwareprodukten auf der Grundlage von Zeitreihenanalysen der Ergebnisse regelmäßig durchgeführter Tests. Im Jahr 2022 wird sich das Tempo, mit dem diese Cloud-Dienste auf dem Markt erscheinen, deutlich beschleunigen. Für Unternehmen bedeutet dies, dass sie keine Angst haben müssen, ihre Daten vertrauenswürdigen Dritten anzuvertrauen, die sich bereits darauf vorbereiten und massiv in die IT-Sicherheit investieren.</p><p><span style="color:#381457;font-size:15px;">source: </span><a href="https://cc.cz/pandemie-zrychlila-zavadeni-technologii-firmam-pomohou-resit-nedostatek-lidi-rika-sef-cleverlance/" style="font-size:15px;">CZECHCRUNCH​</a><br></p>
Für DevOps ist ein völliger Bewusstseinswandel wichtighttps://cleverlance.com/de/blog/Seiten/DevOps-mindset.aspxFür DevOps ist ein völliger Bewusstseinswandel wichtig<p>​​Die genaue Definition und Abgrenzung von DevOps ist eine sehr schwierige Frage, oft sogar für Fachleute, die schon die Hälfte ihrer beruflichen Laufbahn in diesem Bereich tätig sind. In diesem kurzen Artikel werden wir versuchen zu erklären, was diese Rolle beinhaltet und was sie zu vermeiden versucht. Der Schwerpunkt liegt auf Entwicklern, Systemadministratoren und Einsatzadministratoren (Betrieb).<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps_title.jpg" data-themekey="#" alt="" style="margin:5px 0px;" />In den Anfängen der Technologieentwicklung bestand das Projektteam, das die Anwendungen erstellte, aus Entwicklern, Analytikern, Testern, Systemadministratoren, Netzwerkern und Hardwarespezialisten. Wenn dieses Team zusammen war, war es schon die halbe Miete. Sehr vereinfacht: Die für die Entwicklung zuständigen Personen erstellten die Anwendung (Entwickler) und übergaben sie an Systemadministratoren, die sie (wie auch immer automatisiert) auf der Hardware im Serverraum installierten.<br></p><p>Vor nicht allzu langer Zeit kam der so genannte agile Entwicklungsansatz ins Spiel. Dadurch wurde die Kommunikation zwischen Entwicklern und Betreibern zunehmend komplexer. Im Grunde genügte wenig, um sicherzustellen, dass das Produkt (oder eine Version davon), auf das der Kunde ungeduldig wartete, überhaupt nicht geliefert wurde. Das Produkt, oder eine Version davon, wurde schließlich geliefert, aber mit erheblichen Fehlern. Schuld daran war und ist vor allem die Kommunikation zwischen den verschiedenen Teilen des Teams.<br></p><p>Es gibt also Entwickler und Betreiber. Diese beiden Lager können versuchen, miteinander zu kommunizieren und zu argumentieren, aber in der Praxis ist das sehr schwierig. Jeder spricht sozusagen seine eigene Sprache oder einen anderen Dialekt. Was aus Sicht der Entwicklung einfach ist, kann aus Sicht der Infrastruktur nicht auf Servern implementiert werden. Und was in der Infrastruktur sehr einfach zu lösen ist, wird für Entwickler eine sehr schwierige Aufgabe sein.<br></p><p>Was würde passieren, wenn wir einen Entwickler hätten und ihn zum Studieren zu den Betreibern schicken würden? Oder haben sie jemanden aus dem operativen Geschäft zu den Entwicklern geschickt, um sie herauszufordern? Dieser Schritt wird schließlich jemanden hervorbringen, der sich als DevOps-Spezialist bezeichnen kann. Aber um diesen Titel wirklich zu „verdienen“, müssen sie mehr als nur verstehen, woraus das Projekt besteht und wo es implementiert wird. Sie müssen vor allem ihre Denkweise ändern.<br></p><p>Es geht um eine ganze Reihe von Praktiken, die die Prozesse zwischen Softwareentwicklung und Betrieb automatisieren und standardisieren, damit Software schneller und zuverlässiger erstellt, getestet und freigegeben werden kann.<br></p><h3>Neue Denkweise + neue Tools + neue Fertigkeiten = DevOps<br></h3><h2>You build it, you run it!<br></h2><p>Die Grundidee ist, dass DevOps nicht nur eine Technologie ist, sondern ein ganzes Entwicklungsparadigma. Damit dies in einem Unternehmen funktioniert, müssen nicht nur die verwendeten Anwendungen geändert werden, sondern auch die gesamte Herangehensweise an die Entwicklung, das Testen und den Einsatz in der Produktion sowie das gesamte Denken über den Prozess.</p><p>Früher wäre dies utopisch gewesen, aber heute ist es möglich, ganze Cluster mit Verbindungen zu verschiedenen Diensten zu mieten und zu verwalten, von Datenbanken (z. B. PostgreSQL, MySQL oder CockroachDB), Warteschlangen (wie Kafka oder RabbitMQ), Analysesystemen (Hadoop), Logging- und Überwachungsinfrastruktur (Elasticsearch, Kibana, Grafana) bis hin zu verschiedenen IoT-Diensten und REST-APIs. Und wie könnte man den gesamten Prozess von der Erstellung bis zur Bereitstellung beschleunigen, wenn man diese Anwendungen nicht selbst ausführen kann?<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps1.png" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Hybrid Cloud Archite​​​​cture </h4><h2>Virtual Private Cloud</h2><p>Wenn ein Unternehmen eine Anwendung betreibt, geht der Trend heute dahin, die Cloud anstelle der eigenen On-Premise-Infrastruktur zu nutzen. Cloud-Infrastrukturen können heute schon auf hohe Verfügbarkeit und niedrige Latenzzeiten optimiert werden, sie können sogar so eingerichtet werden, dass z.B. Kunden aus Tschechien die Datenwolke in Deutschland nutzen und Kunden aus Frankreich in Frankreich. Moderne Clouds erfüllen hohe Sicherheitsstandards, und ein weiterer Vorteil ist die Möglichkeit, viele der mit ihrem Betrieb verbundenen Technologien als Service zu nutzen. In der Praxis bedeutet dies, dass die Unternehmen keine Spezialisten für die Infrastruktur, deren Wartung und Installation beschäftigen müssen, da sie all dies als Service erhalten, in dem sie ihre Anwendungen in Form von Microservices ausführen. Dies spart sowohl (heutzutage knappe) Arbeitskräfte als auch Geld. Es ist wichtig, neue Anwendungen als Cloud Native zu entwickeln. Die gängigsten Clouds sind Azure, AWS und Google Cloud.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps2.png" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Internet of Things Arc​hitecture<span class="Apple-converted-space"> </span></h4><h2>Microservice-Architektur<br></h2><p>Früher wurden die meisten Anwendungen als monolithische Systeme entwickelt. Heutzutage bestehen die Anwendungen aus kleineren Teilen, die über eine einzige Schnittstelle miteinander kommunizieren. Der Vorteil? Die monolithischen Anwendungen brauchen eine Viertelstunde, um zu starten, während kleinere Anwendungen nur wenige Sekunden benötigen. Bei Microservice-Architekturen versuchen wir immer, sie als Platform as a Service oder Software as a Service einzusetzen.<br></p><p>Eine beliebte Methode in diesem Bereich ist die „Zwölf-Faktoren-App“, bei der es sich um eine Reihe von Regeln handelt, die die Entwicklung viel transparenter machen, wenn sie vom gesamten Team befolgt werden. Es wird beschrieben, wie man mit dem Code umgeht, wo man Konfigurationen speichert, was man mit Backups und Builds macht, wie man skaliert, Protokolle erstellt oder verwaltet.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps3.png" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Caching Cluster Arc​​​hitecture<span class="Apple-converted-space"> </span></h4><h2>Serverlose Architektur<br></h2><p>Ein weiterer sehr interessanter Baustein der modernen Anwendungsarchitektur ist „serverless“. Von den oben erwähnten kleinen Anwendungen nehmen wir einfach einen Teil des Codes, der rechenintensiv sein könnte, oder im Gegenteil, es ist nicht notwendig, ihn ständig laufen zu lassen, und verwenden eine Schnittstelle, die sowohl AWS (AWS Lambda) als auch Azure (Azure Functions) offenlegt, die kleine Unterprozesse startet, die Ergebnisse berechnet und sie an den Dienst zurückgibt. Es kann sogar auf der Ebene von Funktionen skaliert werden, die parallel und unabhängig voneinander laufen können.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/DevOps4.png" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><h4 style="margin-bottom:10px;font-family:source-sans-pro, open-sans, sans-serif;font-size:16px;color:#888888;text-align:center;">Serverless Applic​​ation Architecture<br><br></h4><h2>Automatisierung<br></h2><p>Eine weitere Eigenschaft, die für DevOps geeignet ist, haben wir noch nicht erwähnt: die Faulheit. DevOps versucht, das Leben durch Automatisierung so einfach wie möglich zu machen. Und die Automatisierung ist das A und O der heutigen DevOps-Entwicklung. Wir automatisieren die Bereitstellung, die Arbeitsabläufe, die Tests, die Infrastruktur und die Verwaltung und Überprüfung der Benutzerrechte und des Zugriffs - einfach alles. Wann sollte man mit der Automatisierung beginnen? Wenn eine Aktivität mehr als einmal wiederholt werden muss.<br></p><h2>Automatisierte Codeprüfung<br></h2><p>Um schnell entwickeln zu können und sicherzustellen, dass wir nichts kaputt gemacht haben, müssen wir alles durch Tests abdecken, die die Entwickler selbst schreiben. Dieser Gedanke wird ad absurdum geführt und bedeutet, dass zuerst der Test und dann die Funktion programmiert werden sollte. Test Driven Development ist keine Neuheit in der Softwareentwicklung. Nicht auf Tester zu warten und eigene Tests zu schreiben, ist Teil des oben erwähnten DevOps-Denkens.</p><p>In der Java-Welt verwenden wir zu diesem Zweck JUnit, Mockito, MockMvc, Selenium, Sonar, usw.. Es gibt also genügend Werkzeuge, oft fehlt es aber an der Bereitschaft der Entwickler, dies zu tun.<br></p><h2>Automatisierung von Arbeitsabläufen<br></h2><p>Wir verwenden Tools wie Jenkins (CI/CD), GitLab, Container Registry, Jira, um Arbeitsabläufe zu automatisieren. In der Praxis sieht es so aus, dass der Entwickler seinen Code in GitLab einstellt, die automatisierte Pipeline darauf Unit-Tests durchführt, das Programm kompiliert und es in die Umgebung auf dem Server einstellt, wo es dann kontinuierlich überwacht wird. Im Idealfall läuft wirklich alles von selbst.<br></p><h2>Automatisierung der Infrastruktur: Infrastruktur als Code!<br></h2><p>Der ideale Endzustand ist, dass in allen Umgebungen immer alles gleich läuft und dass diese Umgebungen mit einem Klick erstellt werden. So installiert jedoch niemand das Betriebssystem, sondern alles soll über verschiedene Vorlagen in einem Skript erfolgen. Um Infrastruktur als Code zu erstellen, müssen wir zunächst die Anwendung von der Hardware entkoppeln. Tools wie Docker und Podman übernehmen diese Aufgabe. Wir nehmen die von uns erstellte Anwendung und stellen sie in einem Ökosystem bereit - in der Regel Kubernetes oder OpenShift. Alles kann vor Ort ausgeführt werden, aber das ist nicht das, worum es bei DevOps geht. Sowohl Kubernetes als auch OpenShift können mit wenigen Klicks ausgeführt werden. Kubernetes läuft gehostet bei allen großen Anbietern (AWS EKS, Azure AKS oder Google GKE).<br></p><p>Für die Infrastruktur haben wir mehrere Möglichkeiten. Wir können die Infrastruktur bequem von einem Webbrowser aus „anklicken“ oder, und das ist vorzuziehen, eine Vorlage für den Anbieter erstellen, um die Infrastruktur direkt über die API-Ebene aufzubauen.<br></p><p>Die am häufigsten verwendete universelle Vorlagensoftware ist Terraform. Sie enthält Verbindungen zu allen wichtigen Providern, aber auch die Nutzung von Servern vor Ort ist möglich. Einfacher und oft besser ist es, diese Vorlagen in nativen Skripten zu schreiben (für AWS z. B. CloudFormation in YAML und JSON, oder neuerdings AWS CDK, wo es möglich ist, die Infrastruktur z. B. in JavaScript, JAVA oder Python zu beschreiben). Dadurch werden die Möglichkeiten des Anbieters optimal genutzt. Diese Vorlage kann verwendet werden, um identische Umgebungen mehrmals hintereinander zu erstellen (geeignet für verschiedene Entwicklungs-/Testumgebungen). Die Anwendungen selbst können mit allen bekannten Tools von Jenkins, Gitlab, Bitbucket in die Umgebung übertragen werden.<br></p><h2>Messungen<br></h2><p>Wir haben die Anwendung in Betrieb, aber das ist noch nicht alles. Wir müssen damit beginnen, sie zu bewerten, zu analysieren und Fehler zu korrigieren, also brauchen wir kontinuierliche Metriken und Analysewerkzeuge. Um Protokolle zu sammeln und zu visualisieren, können Sie ELK Stack verwenden, was ein ganzes Paket von Tools für diesen Zweck ist. Kibana ist ein Werkzeug, mit dem Sie Protokolle in einer visualisierten Form an einem Ort durchsuchen können, was es Ihnen ermöglicht, die Leistung der Anwendung herauszufinden und möglicherweise herauszufinden, wo genau das Problem liegt, zusätzlich zur Fehlerfilterung können Sie auch Metriken der CPU usw. anzeigen.<br></p><h2>Methodik<br></h2><p>Der früher beliebte und häufig verwendete Wasserfallansatz ermöglicht eine sorgfältige, aber keineswegs schnelle Entwicklung. Aus diesem Grund werden heute die viel diskutierten agilen Methoden eingesetzt, die es ermöglichen, die Entwicklung in kleine Teile zu zerlegen und stückweise auszuführen. Wenn man darüber nachdenkt, ist dies im Grunde die Essenz der gesamten DevOps-Philosophie - von der Infrastruktur bis zur Methodik und andersherum. So praktizieren wir tägliche Stand-Ups und Entwicklungsläufe in kurzen Sprints. Es ist wichtig, den gesamten Entwicklungsprozess zu standardisieren, angefangen bei der Analyse über die Entwicklung, das Testen, die Bereitstellung und die Überwachung der Leistung der fertigen Anwendung.<br></p><h2>Schlussfolgerung<br></h2><p>Damit ein DevOps-Projekt erfolgreich ist, bedarf es einer Kombination aus Fachwissen, hochwertiger Technologie, handwerklichem Geschick und vor allem einer Veränderung in der Arbeitsweise des Teams und der Denkweise der Entwickler. Aber dann ist es das wert. Ein gut konfiguriertes Projekt ermöglicht schnellere Innovationen, ist in der Lage, auf geschäftliche Anforderungen zu reagieren, die Zusammenarbeit im Team ist effizienter, die allgemeine Codequalität steigt und führt zu häufigeren Veröffentlichungen.​</p><p><span style="color:#381457;font-size:15px;">Source: </span>SystemOnLine​​<br></p>
Warum Berater Kreative kaufenhttps://cleverlance.com/de/blog/Seiten/droga5.aspxWarum Berater Kreative kaufen<p>​​Anfang April berichtete die New York Times, dass das Beratungsunternehmen Accenture die Kreativagentur <a href="https://droga5.com/">Droga5</a> kaufen will. Das Unternehmen mit mehr als 500 Mitarbeitern wird Teil von <a href="https://www.accenture.com/us-en/about/accenture-song-index">Accenture Interactive.</a></p><p>​Diese Verbindung ist unter zwei Gesichtspunkten interessant. Erstens ist das strategische und beratungsorientierte Geschäft mit dem kreativ orientierten Geschäft verflochten. Und zweitens erlebt die Kreativität als taktisches Instrument nach der Ära der Beratungsunternehmen ein massives Comeback.<br></p><p>Droga5 ist derzeit eine der bekanntesten unabhängigen Werbeagenturen in den USA. Das von David Droga gegründete Unternehmen steht für Kreativität in ihrer reinsten Form. Sie soll sich nun in die Kultur der Beratungs- und Technologieunternehmen einfügen. Diese Welten könnten nicht weiter voneinander entfernt sein. Die eine produziert Spitzenleistungen in Form von TV-Spots und Kampagnen, die andere präsentiert Forschungsergebnisse, die heute oft von technischen Lösungen begleitet werden. Eine Gruppe von Kreativen setzt sich mit Beratern an einen Tisch und findet gemeinsam heraus, was das Beste für ihren Kunden ist.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/droga5.jpg" data-themekey="#" alt="" style="margin:5px 0px;" /><br></p><p>Diese Verbindung ist definitiv eine gute Nachricht für Kreative, die sich nicht mit einer erfolgreichen, aber dennoch einmaligen Werbekampagne zufrieden geben, sondern ein langfristiges, umfassendes Kundenerlebnis bieten wollen. Seit geraumer Zeit haben die Kunden das gleiche Ziel und träumen von einem Anbieter, der in der Lage ist, Marke und Technologie über alle <a href="https://en.wikipedia.org/wiki/Touchpoint">Kundenkontaktpunkte​</a> hinweg zu verbinden. Sie haben erkannt, dass nach einem Jahrzehnt, in dem sie sich nur auf Technologie und Prozessautomatisierung konzentriert haben, es die Kreativität und ihre Art der Kommunikation mit den Kunden ist, die alles zum Leben erweckt und den Dingen einen Sinn gibt.<br></p><p>Eine große Unbekannte bleibt die Frage, ob die Wege, auf denen die Bedürfnisse der Kunden angegangen werden, mit einem gemeinsamen Ziel verknüpft werden oder ob sie, wie bisher, geistig und damit verfahrenstechnisch getrennt bleiben. Der Schritt von Accenture bildet jedoch keine Ausnahme. Im Gegenteil, er spiegelt den Trend eines sich rasch verändernden Wettbewerbsumfelds wider. Die Verschmelzung von Technologie, Marke und Kreativität, mit der Apple einst begann, wird langsam aber sicher zu einer Voraussetzung für das Überleben. Wir können also mit weiteren Übernahmen von Kreativteams durch Beratungs- und Technologieunternehmen rechnen.<br></p>

 

Eine der größten
IT Spezialisten-Basen
in Mitteleuropa.

Jedes Projekt beginnt bei den Menschen. Mit über 800 IT-Spezialisten sind wir einer der größten IT-Dienstleister in Mitteleuropa.

  • Škoda
  • DHL
  • T-mobile
  • NN
  • Societe Generale
  • ING
 

 

 

 

 

Scrum smells, pt. 1: Irregular Releases - ein Überblickhttps://cleverlance.com/de/blog/Seiten/scrum-smells-1.aspxScrum smells, pt. 1: Irregular Releases - ein Überblick<p>​​​​​​Es wurde schon viel darüber geschrieben, was agile Entwicklung und Scrum für ein Team leisten sollten.  Nachdem ein Team einige Zeit gereift ist, wird es leicht blind und unempfindlich für Phänomene, die seine Effektivität behindern und sein Potenzial einschränken. Nennen wir sie „Scrum-Gerüche“.<br></p><p>Es gibt Teams, die gerade erst mit der Einführung von Scrum beginnen, und andere, die schon einigermaßen ausgereift sind oder sogar Erfahrung damit haben. Jede Stufe bringt ihre eigenen Gerüche und Düfte mit sich. In dieser Serie werden wir uns auf die grundlegenden und fortgeschrittenen Herausforderungen konzentrieren, denen Scrum-Teams häufig begegnen. Heute sprechen wir über das Problem der unregelmäßigen Releases.</p><p></p><h2>​Unfähigkeit, regelmäßig veröffentlichungsfähige Versionen bereitzustellen</h2><p>Eines der grundlegenden Scrum-Prinzipien ist die Bereitstellung eines potenziell veröffentlichungsfähigen Produktinkrements als Ergebnis der Arbeit jedes Sprints. Ich persönlich glaube, dass dies einer der wertvollsten und am meisten unterschätzten Vorteile der gesamten Scrum-Welt ist. Scrum besagt, dass das Entwicklungsteam am Ende eines jeden Sprints ein Stück Software produzieren sollte, das der Product Owner dann sofort freigeben und produktiv einsetzen kann, wenn er das möchte. Das bedeutet, dass die Software funktionstüchtig sein muss, ohne Regressionen und ohne unfertiges Material. Jeder im Team muss das Gefühl haben, dass es keine Schulden gibt - weder technische noch funktionale.<br></p><p>Im wirklichen Leben werden die Produktions-Builds jedoch eher zufällig bereitgestellt. Die Tage und Sprints vergehen, und es gibt immer etwas in der aktuellen Version zu beheben. Jedes Scrum-Team hat das schon einmal erlebt. Am Ende des Sprints möchte das Team eine endgültige Version bereitstellen, aber es gibt unvollständige Funktionen oder Regressionen, die so schwerwiegend sind, dass diese Version nicht für den produktiven Einsatz freigegeben werden kann.  Im darauffolgenden Sprint versucht das Team also, die Fehler zu beheben, entwickelt aber parallel dazu neue Funktionen weiter, was eine neue Quelle potenzieller Probleme und Unsicherheiten mit sich bringt. Die Tage und Sprints vergehen, und es gibt immer etwas in der aktuellen Version zu beheben.<br></p><p>Dieser Teufelskreis setzt den Product Owner unter Druck, endlich alles zu veröffentlichen, was bis dahin implementiert wurde. Es gibt das allgegenwärtige „fast fertig“-Syndrom, den sich hinziehenden Moment der problemfreien Freigabe. Der Product Owner wird nervös und es ist verlockend zu versuchen, eine weitere „wichtige“ Sache in den Sprint einzuschleusen, denn wer weiß, wann die nächste Veröffentlichung stattfindet. Lange Markteinführungszeiten sind eine Realität. Es kommt zu so genannten Härtungs- oder Stabilisierungssprints, bei denen die Teams lediglich versuchen, das Produkt in einen brauchbaren Zustand zu versetzen.</p><p>Abgesehen von der unvermeidlichen Demotivation und dem Druck, die dadurch entstehen, führt dies auch zu Problemen bei der Planung und Transparenz. Sie wissen nie, wo man wirklich steht, bis Sie keine Arbeit mehr an den bereits entwickelten Backlog-Elementen haben.​<br></p><h2>Den​ Boden vorbereiten</h2><p>Wie kann man also die Wahrscheinlichkeit erhöhen, dass am Ende des Sprints regelmäßig potenziell veröffentlichungsfähige Versionen entstehen?  Hier geht es zum Teil um eine Änderung der Denkweise. Die Bereitstellung eines funktionierenden, schuldenfreien, fertigen Software-Inkrements muss für das Team während des Sprints oberste Priorität haben, und alle Aktivitäten müssen sich auf dieses eine Ziel konzentrieren.<br></p><p>Alles beginnt mit der Verfeinerung des Backlogs. Backlog-Elemente müssen in möglichst kleine Teile zerlegt werden, um dem Team ein hohes Maß an Manövrierfähigkeit bei der Planung zu geben. Oft ist es notwendig, wirklich atomare Benutzergeschichten zu erstellen, d. h. die Benutzergeschichte auf den Kern der Bedürfnisse des Benutzers zu reduzieren und sie mit dem einfachsten Ansatz zu lösen.  Der ganze Rest wird einfach zu einem weiteren Backlog-Element, das unabhängig davon priorisiert wird.  Zu große Backlog-Elemente oder ein zu großer Optimismus in Bezug auf die Beibehaltung einiger „einfach zu erledigenden“ Nice-to-have-Elemente, die mit dem Kern der User Story verknüpft sind, sind einfach nur naiv und häufig mit einer gewissen Bequemlichkeit verbunden.</p><p>Bei der Sprintplanung entwickelt das Team dann eine Strategie, um das Risiko zu steuern, dass kurz vor Ende des Sprints ein schwerwiegendes Problem entdeckt wird und zu wenig Zeit bleibt, um es tatsächlich zu lösen. Es ist hilfreich, den Sprint mit den risikoreichsten Funktionen zu beginnen und sich zu bemühen, auch einzelne Teile davon so früh wie möglich zu testen. Auf diese Weise lässt sich besser abschätzen, wie viel Arbeit wirklich noch zu erledigen ist.  Elemente mit geringem Risiko (wie einfache Textänderungen oder Anpassungen der Benutzeroberfläche) können auf einen späteren Zeitpunkt im Sprint verschoben werden.</p><p>Das Entwicklungsteam darf nicht zu viel Arbeit einplanen, in der Hoffnung, dass wir es dieses Mal „schaffen werden“.  Das Team muss auf der Grundlage früherer Erfahrungen realistisch mit zusätzlichen unerwarteten Arbeiten rechnen, selbst bei „sicheren“ Backlog-Elementen.</p><p>Und natürlich gibt es die bekannte Definition of Done (DoD), die Fertigstellungskriterien. Jedes Teammitglied muss verstehen, was nötig ist, damit ein Punkt als erledigt gilt, und jeder muss dies auf dieselbe Weise verstehen.  Was steht auf der DoD-Checkliste? Nun, das hängt von dem jeweiligen Team, dem Produkt und den verwendeten Technologien ab. Aber wenn sich ein Team einig ist, besteht die DoD für jeden Punkt aus dem zu schreibenden Code, den Einheitstests oder automatisierten Tests, der Dokumentation, der Codeüberprüfung, dem End-to-End-Test und allem anderen, was erforderlich ist. Niemand kann behaupten, dass ein Element fertig ist, solange nicht alle diese Arbeiten erledigt sind. Dies trägt dazu bei, einen gemeinsamen Standard für die Qualität und für die Komplexitätsabschätzung zu schaffen. Durch die strikte Einhaltung dieses Standards wird das Risiko einer Schuldenanhäufung verringert. Fehlende oder ungenutzte DoD schaffen einen fruchtbaren Boden für Schulden und machen eine Planung fast unmöglich.</p><h2>Alltägliche Aktivitäten und Entsc​heidungen<br></h2><p>Häufige End-to-End-Tests während eines Sprints sind absolut unerlässlich.  Es ist eine gefährliche Illusion, einen Tag vor Ende des Sprints eine einzige Version zu erstellen, sie zu testen und zu erwarten, dass alles in Ordnung sein wird. Das ist keine Planung, das ist Glücksspiel.<br></p><p>Um dies zu ermöglichen, müssen neue Builds so oft wie möglich erstellt werden, sogar mehrmals am Tag. CI/CD-Pipelines sind ein Muss. TDD ist sehr hilfreich. Automatisierte Regressionstests sind ein Muss. Im Grunde genommen beseitigt die Automatisierung eines möglichst großen Teils der manuellen Arbeit die Gründe, warum Teams es normalerweise vermeiden, regelmäßig Builds zu erstellen. Diese Investition in die Automatisierung lohnt sich in der Regel auf lange Sicht.</p><p>Das Hinzufügen von Feature Switches (oder Flags) hilft. Wenn es offensichtlich ist, dass das Team nicht in der Lage sein wird, ein bestimmtes Backlog-Element fertigzustellen (d. h. die DoD zu erfüllen), wird es „ausgeschaltet“ und beeinträchtigt den Rest der Software nicht.<br></p><p>Das Team muss sich auch darüber im Klaren sein, dass ein erledigter und ausgelieferter Backlog-Punkt viel mehr wert ist als zehn in Arbeit befindliche Punkte. Das tägliche Scrum ist ein idealer Zeitpunkt für das Team, um den Fortschritt des Sprint Backlogs zu bewerten und gemeinsam daran zu arbeiten, die in Arbeit befindlichen Elemente so schnell wie möglich in einen „fertigen“ Zustand zu überführen. Das Team muss lernen, immer wieder neu zu bewerten, wo jeder Einzelne gerade arbeitet, und entscheiden, ob es etwas Wertvolleres gibt, auf das man sich konzentrieren kann. Alle Sprint-Backlog-Elemente sind die Aufgabe des gesamten Teams, nicht die eines Einzelnen. Es geht darum, ständig neu zu bewerten, wo die Anstrengungen des Tages investiert werden sollen, um die Chance zu maximieren, am Ende des Sprints eine schuldenfreie Software zu erhalten.<br></p><p>Wenn ein Sprint-Backlog-Element riskant wird und es den Anschein hat, dass im Sprint nicht mehr genug Zeit zur Verfügung steht, muss das Team entscheiden, ob es mehr Energie in dieses Element investieren will (um die Chance zu erhöhen, dass es erledigt wird, z. B. indem es mehr Entwickler darauf ansetzt) oder ob es die Arbeit daran ganz einstellen und sich auf ein anderes Element konzentrieren will, das eine echte Chance hat, erledigt zu werden. Die Entscheidung, ein Sprint Backlog Item fallen zu lassen, muss mit dem Product Owner abgesprochen werden.​</p><p>Wenn Sie mehr über Strategien zur Erreichung regelmäßiger Releases erfahren möchten, lesen Sie bitte den Folgebeitrag „<a href="/de/blog/Seiten/scrum-smells-2.aspx" target="_blank">Scrum-Smells Teil ​2</a>“.​​<br></p>

 

 

Entwicklung von Multiplattform-Mobil- und Webanwendungenhttps://cleverlance.com/de/blog/Seiten/Multiplatform.aspxEntwicklung von Multiplattform-Mobil- und Webanwendungen<p>​​​​​​Möchten Sie Ihre eigene mobile Anwendung? Es ist jedem klar, dass man sowohl an die Android- als auch an die iOS-Plattform denken muss, eine davon reicht nicht aus. Und oft kommen wir nicht ohne eine Webschnittstelle aus. Praktisch seit dem Aufkommen der mobilen Geräte auf dem Markt hört man jedoch, dass es teuer ist, für jede Plattform separat zu entwickeln. Aus diesem Grund haben verschiedene Unternehmen versucht, Alternativen in Form von Multiplattform-Lösungen anzubieten, aber keine von ihnen hat sich wirklich durchgesetzt. Sie hatten ihre Tücken, waren unnötig komplex und hielten ein Unternehmen, das seine mobilen Anwendungen flexibel entwickeln will, in einem imaginären „Käfig“ begrenzter Möglichkeiten. Aus diesem Grund wird für B2C-Anwendungen oft die native Entwicklung bevorzugt, da sie nicht durch UX, Animationsmöglichkeiten und andere Details eingeschränkt sind, die für diese Zielgruppe sehr wichtig sind</p><p>In den letzten Jahren haben sich jedoch mobile Unternehmensanwendungen herausgebildet, bei denen nicht die perfekte Benutzeroberfläche und das Design im Vordergrund stehen, sondern die Funktionalität, die Benutzerfreundlichkeit und vor allem die Geschwindigkeit der Bereitstellung und die Flexibilität der Anpassung. Und hier zeigte sich Spielraum für den Einsatz ausgewählter Technologien, die eine plattformübergreifende Nutzung ermöglichen. Natürlich unter Einhaltung bestimmter Regeln.<br></p><p>Bei Cleverlance haben sich drei Arten der Implementierung bewährt. Wenn wir es stark vereinfachen, müssen wir gleich zu Beginn entscheiden, wie robust das Back-End mit MOA (Microservice Oriented Architecture) ist oder ob wir es erstellen müssen, und dann, ob die Anwendung nicht zu viel Geschäftslogik haben wird, sondern eher eine reine Präsentationsebene sein wird. In diesem Fall ist es vorteilhaft, Flutter zu verwenden. Wenn wir Warteschlangen für die Synchronisation, Geschäftslogik und die Einführung einer gewissen Komplexität außerhalb von Formularen in unserer Anwendung benötigen, ist Kotlin Multiplatform eine gute Lösung. Oder es gibt einen dritten Player = PWA (Progressive Web Applications), der die starke Basis moderner Browser nutzt.<br></p><h2>Flutter<br>​<br></h2><p>Wir betrachten Flutter als eine echte Multi-Channel-Display-Ebene, mit der wir mobile, Web- und Desktop-Anwendungen erstellen können. Es handelt sich um eine flexible Lösung, mit der sich B2B- und unter bestimmten Voraussetzungen auch B2C-Anwendungen effizient gestalten lassen. Ein Beispiel ist eine mobile Anwendung für BMW. Aber wenn Sie keine Probleme lösen wollen, ist es besser, sich auf das Backend zu verlassen und ihm das „Denken“ zu überlassen.<br></p><h2>Kotlin Multiplattform<br></h2><p>Eine weitere Option ist die Multiplattformsprache Kotlin. Der Vorteil ist, dass Sie eine „native App“ für Android programmieren, von der ein Teil auch für iOS verwendet werden kann. Meistens sprechen wir über die Geschäftslogik und die Integrationsebene, was uns später in der QA-Phase eine Menge Zeit erspart. Die Visualisierungsebene ist nativ für iOS und Android programmiert, so dass es möglich ist, das „Look & Feel“ der jeweiligen Plattform zu erreichen und die „One Code Base“ für die unsichtbaren Teile der App zu übernehmen. Bei einigen Projekten können bis zu 70-80 % des Codes auf diese Weise verwendet werden.<br></p><h2>PWA<br></h2><p>Progressive Web Applications gehören zu einem der neuesten Trends in der Entwicklung von Webanwendungen. Bis zu einem gewissen Grad verwischen sie die Grenzen zwischen webbasierten und nativen mobilen Anwendungen, indem sie Offline-Arbeit, den Zugriff auf die Gerätehardware und die Möglichkeit, Push-Benachrichtigungen zu empfangen, ermöglichen. Sie vereinen das Beste aus beiden Welten, nur begrenzt durch die Einschränkungen des Browsers. Dies eröffnet eine breite Palette von Funktionalitäten, zum Beispiel können bereits eine Kamera oder einen Fingerabdruckleser in der Basis verwendet werden. Das Erfordernis, tiefer gehende Gerätefunktionen zu nutzen, kann mit einer nativen „Hülle“, der sie verfügbar macht, effizient erfüllt werden. PWA-Apps können in allen gängigen App-Stores (Google Play, Apple Store, Huawei AppGallery und Microsoft Store) platziert werden und auf Android-, iOS- und Windows-Geräten laufen.<br></p><h2>Wo funktioniert es?<br></h2><p>Als Anbieter wollen wir natürlich neben den Standard-Entwicklungstechnologien auch „neue“ Technologien anbieten, und es freut uns umso mehr, dass unsere Kunden, die von Anfang an nach Kotlin Multiplatform gefragt haben, zu uns kommen. Als Beispiel sei hier das amerikanische Unternehmen Globstar genannt, für das die Aricoma-Gruppe eine mobile Anwendung für die Konfiguration und Verwaltung von Satellitenmodems für den Internetanschluss liefert. Der Einsatz von Kotlin Multiplatform war in diesem Fall wirklich erfolgreich, da es sich um eine Anwendung handelte, die in Bezug auf Integration und Datentransfer anspruchsvoll war. Darüber hinaus erfolgt die Integration über BLE (Bluetooth Low Energy), das Dutzende von Geräten gleichzeitig bedienen und beispielsweise deren Firmware aktualisieren kann. Die Technologie hat sowohl den Kunden als auch uns als Anbieter überzeugt, und es ist uns gelungen, eine partnerschaftliche Zusammenarbeit bei der Entwicklung der Anwendung aufzubauen.<br></p><p>Wir haben die PWA-Technologie zum Beispiel im Online-Service für SAZKAmobil-Kunden erfolgreich eingesetzt. Ihr Hauptvorteil ist die extrem verkürzte Time-To-Market (die Zeit, die benötigt wird, um neue Funktionen auf den Markt zu bringen) und die große Zahl von Entwicklern, die diese Technologie beherrschen. Darüber hinaus eignen sich PWAs am besten für Anwendungen, bei denen die Nutzung der Komponenten des Geräts selbst wenig im Vordergrund steht, z. B. für interne Unternehmensanwendungen, die von Außendienstmitarbeitern oder Produktionsmitarbeitern genutzt werden.<br></p><p>Wenn Sie an technischen Details interessiert sind, lesen Sie diesen Artikel in unserem Blog mobile it, in dem Sie auch erfahren, worauf Sie bei der Auswahl einer Technologie für die Entwicklung einer mobilen Anwendung achten sollten.<br></p>

Cleverlance bietet umfassende IT-Dienstleistungen und End-to-End-Lösungen.

Wir decken für Sie den ganzen Softwareentwicklungsprozess vom Konzept über die Analyse, das Design, die Entwicklung und die Markteinführung bis hin zu Projektmanagement, Sicherheit, Support oder vollständigem Outsourcing ab. Und das in einem breiten Spektrum von Branchen.

  • Analysis
  • SW Architecture
  • UX Design
  • Software Development
  • ICT Security
  • Integration
  • Quality Assurance
  • Deployment
  • Support & Maintenance

Egal, ob Sie Remote-Mitarbeiter bevorzugen, die die Kosten senken, oder persönliche Begegnungen, bei uns finden Sie alles.

Nehmen Sie Kontakt mit uns auf. Wir würden uns freuen, von Ihnen zu hören.

 

ARICOMA