Dummy Title http://example.com en-gb TYPO3 News Fri, 30 Oct 2020 02:05:18 +0000 Fri, 30 Oct 2020 02:05:18 +0000 TYPO3 EXT:news news-12 Tue, 29 Sep 2020 14:10:02 +0000 Apptio Digital Fuel IT Business Management 9.4. verfügbar https://www.amasol.de/blog/detail-page/apptio-digital-fuel-it-business-management-94-verfuegbar Apptio hat die neue Version 9.4 von Digital Fuel IT Business Management vorgestellt. Das neue Release ist ein weiterer Schritt von Apptio bei der mehrstufigen Modernisierung seiner IT-Business-Management-Plattform. Der Schwerpunkt liegt dieses Mal auf Qualitätsverbesserungen. Apptio hat die neue Version 9.4 von Digital Fuel IT Business Management vorgestellt. Das neue Release ist ein weiterer Schritt von Apptio bei der mehrstufigen Modernisierung seiner IT-Business-Management-Plattform. Der Schwerpunkt liegt dieses Mal auf Qualitätsverbesserungen.

Zu den wichtigsten Neuerungen gehören unter anderem die modernisierten Service-Level-Management-Module Compliance sowie Credits and Bonuses, ein modernisiertes Erstellen und Verwalten von Berichten sowie Support für Oracle 19c.

 

Modernisierte Berichtsverwaltung

Die Version v9.4 von Apptio-Digital Fuel ITBM ermöglicht ein schnelleres und einfacheres Erstellen und Verwalten von Berichten. Die Aufgaben wurden dazu aus dem Designer ausgelagert. Damit sind sie zukünftig leichter zugänglich und weniger komplex. Die Anzahl der erforderlichen Klicks zum Erledigen allgemeiner Aufgaben wird dadurch deutlich verringert.

Die Funktionen können nun über das Report-Administration-Modul im Abschnitt Berichte ausgeführt werden und stehen für die folgenden Berichtsarten zur Verfügung:

  • Tortendiagramme
  • Gauge-Berichte
  • Liniendiagramme
  • Balkendiagramme
  • Timelines
  • Tabellen
  • Zusammengesetzte Berichte

Das geht inhaltlich aber nur, wenn diese Bericht jeweils nur aus den Darstellungsformen bestehen, ohne weitere Elemente.

Die neue Funktion steht für Benutzer zur Verfügung, die über die Zugangsberechtigung zum Designer-Modul in ITBM verfügen. Zum Verständnis der Funktionsweise wird auf den Abschnitt „Nicht modernisierte Funktionen“ verwiesen, da dieser für die Berichtsverwaltung noch implementiert werden muss.

 

Neue UI-Funktionen

Die Version 9.4 bietet Support für die folgenden Funktionen im Modul Reports and Dashboards: Berichte:

  • Berichte: Drilldown zum Business-Rule-Template, Breach Adjustment, Upload File Adapter
  • Dashboards: Mehrere Notizen-Widgets können bei einem Dashboard ergänzt werden.
  • Dashboards: Mehrere Quick-Link-Widgets können bei einem Dashboard ergänzt werden.
  • Neue Funktion „Generate Shareable Link“. Damit können Report- und Dashboard-Links mit anderen Benutzern geteilt werden.

 

Shareable Links auf Berichte

Benutzer möchten von Zeit zu Zeit Links auf ITBM-Berichte mit anderen Benutzern teilen. Um dies zu erleichtern, wurde eine „Generate Shareable Link“-Funktion in die Menüleiste von Reports and Dashboards integriert. Ein Klick darauf kopiert den Link in die Zwischenablage des Systems. Der Anwender kann ihn dann in eine E-Mail oder andere Kommunikationsanwendung einfügen.

 

Compliance, Credits, Bonus

Die Module Compliance View, Adjust and Approve sowie Credits and Bonuses wurden modernisiert, stehen aber nur mit der neuen Benutzeroberfläche zur Verfügung. Die Module Personalized View und Adjust Reports können in den allgemeinen Einstelllungen konfiguriert werden, um anstelle von Out-of-the-Box-Berichten angezeigt zu werden.

Weitere Funktionen, die modernisiert wurden, sind Filtern Speicher (Favoriten erstellen), Veröffentlichen und Tools.

 

Support für Oracle 19c

Neu in der Version 9.4 ist der Support für Oracle Database19c. Der Support für Oracle Database 12c Release 2 endet am 30. November, wenn auch Oracle seinen Support einstellt.

Version 9.4. integriert den ojdbc8-Oracle-Database-Treiber anstelle des älteren ojdbc6-Treibers in älteren Versionen. Mit diesem Wechsel auf den neuen Oracle-Database-Treiber endet der Support für Oracle Database 12c Release 1 und ältere Versionen.

 

Support für AdoptOpenJDK8

Die Version 9.4 unterstützt ab sofort sowohl Oracle JDK8 als auch die Open-Source-AdoptOpenJDK8-Distributionen. Bitte beachten Sie, dass ITBM nur Java-1.8-Versionen von AdoptOpenJDK und Oracle JDK unterstützt. Konfigurationshinweise für Java finden Sie im ITBM Installation Guide.

 

Erweiterung für Sommerzeit

Versionen vor Version 9.3 unterstützen die Sommerzeit (Daylight Savings Time, DST) bis März 2021. Bei der Verwendung der koordinierten Weltzeit (UTC) hat dies keine Auswirkungen. Version 9.4 erweitert den Support für Sommerzeit bis 2027.

Mit Digital Fuel Version 9.4. plant Apptio, amasol als Partner exklusiv REST-APIs zur Ansteuerung von SLM-Funktionen zur Verfügung zu stellen. Diese APIs werden von amasol zukünftig in Projekten zur Anbindung von Funktionen der Vertragsverwaltung verwendet. Aktuell arbeitet unser amasol-Team an ersten Prototypen mit unseren Kunden. Auch sind wir dabei, die technischen Schnittstellen mittels eines API-Gateways zu veredeln, sodass wir zentrale Use Cases unserer Kunden einfacher abbilden können.

Über die SLM-Schnittstelle wird es dann möglich sein, die bislang nur manuell über das UI zu pflegenden Verträgen nun auch zu automatisieren. Hier stehen wir eine Vielzahl an möglichen Anwendungsfällen von zusätzlichen Listen und Suchfunktionen über Massenänderungen bis hin zum vereinfachten Onboarding neuer Kunden oder der Integration in Bestellprozess. 

+++ UPDATE 30.09.2020 +++

Neues Release 9.4.1: Update auf Apache Tomcat 7.0.105

Apptio hat mittlerweile die Version 9.4.1 von Digital Fuel ITBM veröffentlicht. Grund dafür war eine Sicherheitslücke in Apache Tomcat, die ein amasol-Kunde entdeckt und an uns gemeldet hatte. Diese Lücke wurde mit einem Upgrade auf die Tomcat Version 7.0.105 geschlossen.

Für Fragen zur neuen Version und zum Upgrade wenden Sie sich bitte gerne an Ihren Ansprechpartner bei amasol.

]]>
news-11 Tue, 29 Sep 2020 14:07:00 +0000 Als Sozialwissenschaftlerin unter vielen ITler*innen https://www.amasol.de/blog/detail-page/als-sozialwissenschaftlerin-unter-vielen-itlerinnen Nach 18 Monaten endet am 31. Dezember meine Zeit hier bei amasol. Es war eine spannende Zeit, in der ich viel gelernt habe – auch über IT – und die wie im Flug vergangen ist. Mit einem Sprung ins kalte Wasser im März 2018 – die Vorbereitungen für das Anwenderforum liefen auf Hochtouren – begann ich mein Praktikum. Von ersten Tag an war ich in die Vorbereitungen für das Kundenevent eingebunden. Ich übersetzte Unternehmensbeschreibungen vom Englische ins Deutsche, aktualisierte die Inhalte in der Veranstaltungsapp und übernahm weitere Aufgaben, die bei der Vorbereitung einer großen Veranstaltung so anfallen. Ende April stieg ich schließlich mit den anderen Kolleginnen und Kollegen ins Flugzeug nach Köln, um selbst am Anwenderforum dabei zu sein. Aber nicht nur das Anwenderforum sondern auch die Umstellung auf ein neues Corporate Design prägten die ersten Woche meines Praktikums. Viele meiner Aufgaben waren kreativ. So hab ich zum Beispiel in der Adventszeit die Lose für unsere Tombola gestaltet.

Nach und nach übernahm ich zu den Aufgaben im Marketing auch Aufgaben im Recruiting. Ich war angefixt und wollte mehr lernen. Weil es bei amasol immer etwas Neues zu lernen gibt und die Arbeit nie ausgeht, wechselte ich dann auf die andere Seite des langen Flures – in den sogenannten „Teppich-Trakt“.

Von nun an widmete ich mich nicht nur dem Schalten von Stellenanzeigen in den Jobbörsen und dem Personalmarketing in den Sozialen Medien , sondern lernte auch den kompletten Recruiting-Prozess kennen. Ich erstellte Stellenanzeigen, sichtete Lebensläufe, kontaktierte passende Bewerber*innen, führte Telefoninterviews und schrieb auch Absagen an zwar qualifizierte, aber für die Positionen ungeeignete Personen. Interviews führen gehört in meinem Studium zur Methodenausbildung. Doch die Perspektive zu wechseln und nicht mehr die Bewerberin zu sein, sondern die Person, die für das Unternehmen geeignete KandidatInnen sucht, ist dann doch eine ganz andere Nummer. Es war spannend, aber auch mit Nervosität verbunden. Der Interviewleitfaden und Silke als Coach, die mir nach jedem Interview wertvolles Feedback gegeben hat, waren eine unglaubliche Unterstützung.

Recruiting war aber nicht alles, was ich lernen durfte. Ich habe mich mit Onboarding-Prozessen beschäftigt, um neuen Kolleginnen und Kollegen das Ankommen und die Einarbeitung möglichst angenehm zu machen. Sie sollen sich auch von Anfang an genauso wohl fühlen wie wir.

Datenschutz, Arbeitssicherheit und Zeugnisse verfassen standen ebenfalls auf dem Stundenplan. Zu guter Letzt ein Thema, wodurch ich weiterhin mit amasol verbunden bleiben werde, war das Alumni Netzwerk. Denn ab Januar bin ich selbst eine Alumna.

Ich habe hier unglaublich viel gelernt. Ich durfte mit hilfsbereiten und netten Menschen zusammenarbeiten, die jede Frage gerne beantworteten, und mit denen es auch viel zu lachen gab. Hier sitze ich also ein letztes Mal mit Blick auf die Berge und einem weinenden Auge, weil ich die Menschen und die Arbeit hier unglaublich vermissen werde, und einem lachenden Auge, das sich auf die neuen Herausforderungen, die mich erwarten werden, freut.

]]>
amasol Insight
news-10 Mon, 21 Sep 2020 14:58:20 +0000 Autonomous Cloud journey at amasol with Keptn https://www.amasol.de/blog/detail-page/autonomous-cloud-journey-at-amasol-with-keptn About two years ago we launched the amasol Managed Cloud offering Dynatrace as a Managed Service hosted in Germany, so we could offer our customer the comfort of a SaaS solution while still allowing them to follow strict data protection regulations. Video – Webinar Autonomous Cloud at amasol with Keptn, GitLab, JMeter & Dynatrace on AKS

 

About two years ago we launched the amasol Managed Cloud offering Dynatrace as a Managed Service hosted in Germany, so we could offer our customer the comfort of a SaaS solution while still allowing them to follow strict data protection regulations. 

Since then we have been extending the platform and adding more features like our aMC Synthetic App, aMC Config Management or a central User Management Portal for all aMC services. 

Because we started on a green field, we were able to pick a modern technology stack and decided to deploy everything on Kubernetes. 

When looking for a Continuous Delivery Solution we quickly settled on Keptn as the control plane. Keptn comes with out-of-the-box integrations of several tools we already had in place for our Continuous Integration setup like GitLab, JMeter or Dynatrace. Thanks to its event-driven architecture we can easily extend it to other tools we may need in the future. 

Keptn also supports us on the way to an Autonomous Cloud by enabling an easy start with SLO-based Quality Gates to improve the quality and continue to other topics like different deployment strategies and auto remediation. 

Current Setup  

We use GitLab CI with a simple pipeline to build and unit-test new versions of our applications. If the build is successful a new image is created and pushed to our container registry. 

 

From there we trigger the deployment (currently manual) with a simple Keptn CLI call, telling it to deploy our new artifact: 

We trigger the deployments through the CLI because we still want manual approval for production deployments. In the next Keptn Version (0.7.0) it will be possible to do manual approvals between stages with Keptn’s new Delivery Assistant, which will allow us to trigger the deployment directly from our CI pipeline and still maintain control when a version should be promoted to production. 

Let me explain what happens behind the scenes when sending the new-artifact event. 

Continuous Delivery 

Once the event is sent Keptn takes the rudder and deploys our new artifact to the first stage. In our case that is the development environment.  

The different stages are defined in a simple YAML file called shipyard: 

For every stage Keptn allows us to specify the deployment strategy, e.g. direct, blue/green or canary and the testing strategy, e.g.: functional, performance. This gives us declarative control about what should happen in each stage as an artifact gets pushed through the delivery process. 

After Keptn deployed an artifact and then triggered the tests it automatically enforces a quality gate. This is done through Keptn’s Lighthouse service which verifies metrics from a monitoring system as Service Level Indicators (SLIs) against defined Service Level Objectives (SLOs).  

In our case, after the deployment is finished Keptn starts the test through Keptn’s JMeter service that is already shipped with Keptn. It does a short functional test to check if the environment is operational and then starts a load test. 

The SLOs are defined in a YAML file and following the GitOps approach are stored along with the other files (SLIs, JMeter Scripts and Helm Charts) in a git repository. 

For every SLO the passing criteria can be specified as an absolute and/or relative value. The relative values are compared against the last X number of builds allowing for automatic regression detection, e.g.: do not allow an increase in response time by more than 10% to the previous build. The absolute allows us to enforce strict thresholds that we may have, e.g.: do not allow a failure rate of more than 1% 

Every SLO has a weight which influences the calculation of the total score. The total score section allows us to specify what score we consider as a successful or failed build: 

With the bridge, Keptn has a great built-in Web UI to get an overview of all your Keptn workflows. 

Keptn follows an event-based approach and each event is listed in the bridge. Staring at the configuration changed event triggered by our keptn CLI call, all subsequent steps are listed in the bridge: 

 

In this case the tests are executed but the thresholds defined in our SLOs are not met because the error rate is to high: 

Because our Total Score is below the defined passing mark Keptn stops the workflow here and does not deploy to our production stage. That is immediate feedback delivered back to engineering so they can start fixing newly introduced issues right away. 

So, once we fix the problem, we run a new deployment and Keptn validates if we are now meeting our SLOs. Looks fine now :

With the successful evaluation Keptn goes ahead an deploys the new artifact automatically to production. 

Summary 

Keptn enabled us to quickly onboard multiple projects and services to a robust Continuous Delivery process, without the overhead of managing multiple Pipelines. 

The SLO-based Quality Gates help us in providing a good experience to our End Users and give our engineers immediate feedback for their deployed changes. 

With Keptn 0.7 we will link our Continuous Integration Flow to Keptn for automatic deployments while still retaining manual approval for production with Keptn’s Delivery Assistant. After that we are looking forward to advanced use cases like auto remediation.  

]]>
APM
news-9 Mon, 21 Sep 2020 14:57:01 +0000 KI-basierte Netzwerk-Monitoring- und Analyse-Lösung: Broadcom stellt DX NetOps vor https://www.amasol.de/blog/detail-page/ki-basierte-netzwerk-monitoring-und-analyse-loesung-broadcom-stellt-dx-netops-vor Broadcom hat die neue Netzwerk-Monitoring–Lösung DX NetOps vorgestellt. Sie basiert auf Broadcom Silicon, der KI-basierten Lösung für hoch skalierbares Operations–Monitoring und -Analyse. Broadcom hat die neue Netzwerk-Monitoring–Lösung DX NetOps vorgestellt. Sie basiert auf Broadcom Silicon, der KI-basierten Lösung für hoch skalierbares Operations–Monitoring und -Analyse. Ziel ist es, auf der Grundlage fortschrittlicher KI-Funktionen einen einheitlichen Überblick über die User Experience in modernen IT-Architekturen zu vermitteln.

DX NetOps konvertiert dazu Inventory- und Topologie-Daten, Device-Metriken, Fehler-, Datenfluss- und Datenpaket-Analysedaten zu einer zentralen Informationsplattform, mit der Network-Operations-Teams sofort Optimierungsmaßnahmen ergreifen können.

In Kombination mit der AIOPs-Lösung von Broadcom versetzt DX NetOPs IT-Teams in die Lage, proaktive und autonome Verfahren zur Fehlerbehebung für die IT-Infrastruktur sowie für alle Anwendungen und Netzwerksysteme zu etablieren. Damit liefern sie die Grundlage für eine noch bessere User Experience.

DX NetOps Powered by Broadcom Silicon adressiert die aktuellen Ursachen von Netzwerk-engpässen

Broadcom ermöglicht mit der neuen Lösung ein hoch skalierbares Operations-Monitoring für den Einsatz in 5G-, IoT-, Cloud- und SD-WAN-Umgebungen und setzt dabei auf moderne KI- und Machine-Learning-Technologien. Damit können umfangreiche Daten auf Chip-Level erfasst werden. Broadcom trägt damit der Erkenntnis Rechnung, dass eine Monitoringlösung, die Paket- und Datenflussdaten in Echtzeit direkt auf den Broadcom-Chips und anderen Endgeräten erfasst, ein wichtiges Differenzierungsmerkmal am Markt und entscheidend für eine verbesserte „Digital Experience“ ist.

DX NetOps baut auf AIOps von Broadcom auf und agiert als „trusted proof point“ für die IT-Operations-Analyse von Broadcom BizOps. AIOps von Broadcom enthält neue intelligente Funktionen zur zum Teil automatischen Problembehebung, die IT-Abteilungen dabei unterstützen, Probleme zu prognostizieren und zu beheben, bevor sie die User Experience beeinträchtigen.

Erweitertes SD-WAN-Monitoring durch strategische Partnerschaften

Broadcom hat die Analysefunktionen in der DX-NetOps-Plattform so erweitert, dass diese Network-Operation-Teams in die Lage versetzt, zuverlässige Daten über die Anwendungserfahrung über SD-WAN-Technologien auf Basis von Silver Peak, VMware (VeloCloud) und 128 Technology zu liefern.

Eine erweiterte anwendungsorientierte Optimierungstechnologie ermöglicht es Unternehmen, das Anwendungs-Monitoring in Echtzeit über ihre SD-WAN-Implementierungen verschiedener Anbieter zu einer zentralen Übersicht zu zentralisieren, in der eingesetzte Netzwerk-Devices unterschiedlicher Hersteller, Infrastrukturschichten und Anwendungen enthalten sind.

Je mehr moderne Architekturen für den Support digitaler Business-Initiativen entstehen, desto zwingend notwendiger ist es für Unternehmen, über einen vollständigen Überblick zu verfügen. In Kombination mit KI- und Machine–Learning-Funktionen sind sie dann nämlich in der Lage, das Anwendungsverhalten wirklich zu verstehen und damit ihre Investitionen im SD-WAN-Bereich zu optimieren.

Weitere Informationen zu DX NetOps von Broadcom haben wir für Sie zum Download zusammengestellt.

]]>
news-8 Mon, 21 Sep 2020 14:49:00 +0000 Apptio Cloudability ermöglicht integriertes Kubernetes Financial Management https://www.amasol.de/blog/detail-page/apptio-cloudability-ermoeglicht-integriertes-kubernetes-financial-management Apptio hat mit Cloudability eine neue Funktion vorgestellt, die es ermöglicht, Kubernetes-Container in den Cloud-Financial-Management-Prozess zu integrieren. Apptio hat mit Cloudability eine neue Funktion vorgestellt, die es ermöglicht, Kubernetes-Container in den Cloud-Financial-Management-Prozess zu integrieren. In einem Blog-Beitrag geht Apptio Product Management Consultant Stephen Whinston näher auf die Hintergründe und Vorteile von Cloudability ein.

Unternehmen arbeiten immer häufiger mit Public-Cloud-Anbietern zusammen, um die Skalierbarkeit und Flexibilität ihrer IT-Systeme zu optimieren und dabei gleichzeitig die Kosten im Griff zu haben. Der Einsatz von Containern als Mechanismus für das Deployment von Services in einer Public Cloud wächst derzeit fast doppelt so schnell wie die Cloud-Computing-Nutzung allgemein. Integriertes Finanzmanagement für Container wurde damit in den letzten Jahren zum sprichwörtlichen Mount Everest für die IT-Branche. Mit Cloudability bietet Apptio ab sofort eine Lösung, diesen „höchsten Berg“ zu bezwingen und Kubernetes-Container vollständig in den Cloud-Financial-Management-Prozess zu integrieren.

Das „Black Box“-Problem bei Containern

Das rasante Wachstum der Container-Nutzung wird insbesondere von Unternehmen vorangetrieben, die neue Ansätze bei der Anwendungsarchitektur sowie beim Einsatz und Betrieb von Applikationen verfolgen. Mit Containern ist es möglich, ein Betriebssystem zu virtualisieren und damit unterschiedliche Prozesse voneinander isoliert auf demselben Kernel ablaufen zu lassen. Kubernetes als Container Orchestration Layer bietet ein riesiges Potenzial bei der Anwendungsentwicklung, stellt aber auch riesige neue Herausforderungen in Bezug auf die Kostenallokation, -analyse, -planung und -dokumentation.

Die Herausforderung besteht dabei insbesondere darin, zuverlässig die Kosten für jedes Kubernetes-Cluster zu bestimmen. Diese können jeden Monat für Tausende kurzlebige Cloud-Ressourcen auftreten. Eine weitere Herausforderung besteht darin, diese Kosten dann individuellen Delivery–Teams zuzuordnen. Da jede virtuelle Maschine in einem Cluster tatsächlich multi-tenant ist, d.h. darauf mehrere Applikationen über unabhängige Container laufen, ist es nicht möglich, sich auf Standard-Abrechnungsattribute zu verlassen, um die Kosten abzubilden. Kurzum: Weder die Gesamtkosten eines jeden Clusters noch der Betrag, der den darin enthaltenen Anwendungen zugewiesen werden kann, können von den Cloud-Service-Providern präzise dokumentiert werden. Die Folge: Ein immer schneller ansteigender Teil der Cloud-Rechnung, die eine „Black Box“ ist, wenn es darum geht, die einzelnen Kosten genau auf die entsprechenden Kostenstellen eines Unternehmens umzulegen.

Cloudability-Container öffnet die „Black Box“

Apptio-Kunden können ab sofort die  Kosten eines jeden eingesetzten Kubernetes-Clusters präzise belegen und erhalten so die erforderliche Transparenz, um die Ausgaben auf die entsprechenden Services, Apps und Teams zu verteilen, die dafür verantwortlich sind.

Dies gelingt mit einem schlanken, speziell für diesen Zweck erstellten Cloudability-Container in jedem Cluster, der alle Kosten intelligent abbilden und aufteilen kann. Grundlage dafür sind fortschrittliche Algorithmen, die vier relevante Messgrößen zur Ressourcen-Nutzung an jedem Knoten analysieren – CPU, Speicher, Netzwerk und Festplatte – und Quality-of-Service-Einstellungen auf Pod-Ebene evaluieren. Damit können die Ressourcen-Kosten in Bezug auf native Kubernetes-Systeme aufgebrochen werden. Der Anwender kann diese Informationen dann über die entsprechenden Kubernetes-Konstrukte (wie z.B. Cluster, Namespace oder Label) im Container „Cost Allocation Report“ visualisieren.

Der Launch der neuen Funktion geht jedoch darüber hinaus, einfach nur die Ressourcen eines jeden Kubernetes-Clusters detailliert aufzuführen und zu zeigen, welche Teams darauf Container nutzen. Es geht dabei auch darum, diese ganzen Informationen in den gesamten Cloud-Financial-Management-Prozess zu integrieren. Ein Gesamtüberblick über alle Cloud-Computing-Ausgaben wird damit möglich. Apptio-Cloudability-Kunden können ihre Kubernetes-Kosten gemeinsam mit ihren anderen Cloud-Computing-Kosten in Kostenberichten, Dashboard-Widgets und dem TrueCost Explorer aufrufen.

Auf der Grundlage der unternehmensspezifischen Kubernetes-Labels können Anwender Business Mappings erstellen und optimieren, um Kostenstrukturen und Geschäftseinheiten zu definieren, die widerspiegeln, wie das Unternehmen Chargebacks mit Kostenstellen abwickelt.

Weitere Informationen zu Cloudability finden Sie auf der Apptio–Webseite.

Für Fragen zu Cloudability wenden Sie sich bitte gerne an Ihren Ansprechpartner bei amasol.

]]>
TBM
news-3 Mon, 21 Sep 2020 11:15:00 +0000 User Behavior Analytics: übergeordneter Nutzen für neue Geschäftsmodelle https://www.amasol.de/blog/detail-page/user-behavior-analytics-uebergeordneter-nutzen-fuer-neue-geschaeftsmodelle Es ist ein immerwährender Kreislauf: Innovationen und neue Geschäftsmodelle führen zu Veränderungen im Kundenverhalten und erzeugen neue Kundenbedürfnisse... Es ist ein immerwährender Kreislauf: Innovationen und neue Geschäftsmodelle führen zu Veränderungen im Kundenverhalten und erzeugen neue Kundenbedürfnisse – was wiederum Anpassungen in Geschäftsmodellen bedingt und Innovationen in eine vom Kunden bestimmte Richtung vorantreibt. Mal dauert der Wandel länger, mal erfordern äußere Umstände eine schnelle Adaptation. Was aber immer bleibt, sind der Nutzer sowie die Art und Weise seines IT-Konsums.

Jeder Klick zählt: für eine positive User Experience …

An dieser Stelle setzt User Behavior Analytics an und stellt den Nutzer in den Mittelpunkt – egal, ob On-Premise oder in der Cloud. Dabei können nicht nur Daten über das Nutzerverhalten, sondern gleichzeitig auch Performancedaten der verwendeten Applikationen gesammelt werden. Auf dieser Grundlage sind dann Optimierungen der benutzerfreundlichen Bedienbarkeit und der Performance der Applikation möglich – für eine positive User Experience.

… und mehr Sicherheit

Darüber hinaus trägt User Behavior Analytics auch zur Sicherung wertvoller Unternehmensdaten bei, indem es untypische bzw. unerwünschte Verhaltensmuster erkennt und isoliert, beispielsweise bei einem untypischen Zugriff auf eine Datenbank zu einer ungewohnten Uhrzeit. Unterstützt wird die Anomalieerkennung durch Machine-Learning-Algorithmen, die jede Abweichung von der Norm aufzeigen. Auch wenn die Traffic-Analyse durch Weiterentwicklungen wie TLS 1.3 erschwert wird, ermöglicht User Behavior Analytics den übergeordneten Blick auf das Netzwerk hinsichtlich Verfügbarkeit und Sicherheit.

NetOps + SecOps = Mehrwerte für BizOps

Die Nutzung von User Behavior Analytics in den Bereichen Performance und Security schafft nicht nur eine größere Produktivität in NetOps und SecOps durch eine gemeinsame Datenbasis, sondern bietet auch konkrete BizOps-Mehrwerte:

  • Kosteneinsparungen durch Reduktion von Datensilos und weniger Tools
  • Besseres Verständnis darüber, wie IT genutzt wird, um Umsätze zu generieren
  • Abgeleitete Kennzahlen aus Netzwerkmetriken wie Packet Loss und Downtime zur Darstellung des Wertbeitrags zum Umsatz und Produktivitätsverlust in kundennahen Abteilungen
  • Wirtschaftliche Bewertung der technischen Umsetzung von kundengetriebenen Anforderungen

Sie wollen mehr zu diesem Thema wissen? Dann sprechen Sie uns gerne an: Fabian Fink, Account Manager, oder Olga Wall, Consultant für Application Performance Management.

]]>
APM
news-20 Sun, 20 Sep 2020 14:49:00 +0000 What’s new at Dynatrace? https://www.amasol.de/blog/detail-page/whats-new-at-dynatrace In den letzten Wochen hat es einige Neuerungen bei unserem Herstellerpartner Dynatrace gegeben. Die Highlights haben wir im Folgenden für Sie zusammengefasst. Operative Einblicke in Kubernetes Pods – mit dem neuen Cloud Application View

Für alle Early Adopter gibt es einen neuen Cloud Application View für tiefe Einblicke in Container und Prozesse. Damit sollen folgende Fragestellungen beantwortet werden:

  • Welche Applikationen und Workloads laufen in meinen Kubernetes-Umgebungen?
  • Sind diese Applikationen und Workloads performant?

Dynatrace gibt einen Überblick über das gesamte Kubernetes Cluster, die Anzahl der gewünschten sowie der tatsächlich laufenden Pods und informiert darüber, wieviele Cluster-Ressourcen die Workloads aktuell verbrauchen. Zusätzlich können Countainer-Ressourcen überwacht und deren Limits angezeigt werden.
Darüber hinaus wurde ab Dynatrace Version 1.196 der Full-Stack Kubernetes-Workload und die Infrastruktur-Beobachtbarkeit mit Schwerpunkt auf Pods und die Verwendung von Namespaces ausgeweitet. Damit kann nun festgestellt werden, ob Kubernetes die Workloads und die Ressourcen optimal verwaltet.

Enhanced User Action Naming Rules

Dynatrace erkennt, wie Benutzer mit einer Webseite oder Anwendung interagieren und bildet diese Interaktionen als User-Actions ab. Diese User-Actions werden automatisch nach vordefinierten Standard-Regeln benannt. Um die Analyse der User-Actions zu vereinfachen, ist es möglich eigene Regeln zur Benennung und Gruppierung zu definieren. Da Web-Anwendungen jedoch immer dynamischer werden, kann die Erstellung effektiver Regeln für die Benennung von User-Actions eine Herausforderung darstellen.
Durch die verbesserten Regeln ist es seit Dynatrace Version 1.192 nun noch einfacher, diese nach eigenen Wünschen umzubenennen und zu gruppieren. Folgende Verbesserungen wurden eingeführt:

  • Placeholders – ermöglichen eine flexiblere Benennung und Analyse von User-Actions
  • Delimiters – vereinfachen das Extrahieren und Ersetzen von Informationen
  • API support – Benennung von User-Actions über die REST-API

Neue RUM Performance Metriken und Verbesserungen bei „Visually complete“

Dynatrace hat mit der Managed-Version 1.194 den „Visually complete“-Algorithmus überarbeitet, um den Nutzern mehr Kontrolle über die Berechnung von „Visually complete“ zu geben. Die Optimierung dieses Bereichs ist oft sinnvoll, da er eine direkte Auswirkung auf die User Experience hat. Außerdem wurden neue Performance Metriken wie „first input delay“, „first contentful paint“ und „largest contentful paint“ hinzugefügt, die bei der Analyse unterstützen sollen. Neben zusätzlichen Möglichkeiten zur Darstellung von Metriken in Dashboards sind damit Analysen von Performanceproblemen über mehrere Dimensionen hinweg in der Multidimensional Analysis View, Analysen der User Action Performance sowie die Detailanalyse in aggregierten Waterfall Charts möglich.

Verbesserungen der API

Einige der Neuerungen in Dynatrace betreffen die API. Die Extension API ermöglicht Early Adoptern die Verwaltung integrierter sowie benutzerdefinierter Erweiterungen für den OneAgent, ActiveGate oder JMX/PMI. Für alle Nutzer sind mittlerweile die Dynatrace v2 APIs verfügbar. Durch den standardisierten Zugang zu Ressourcen, standardisierte Fehlermeldungen und paginierte Endpunkte ist es einfacher, Monitoring-Prozesse zu automatisieren und die Developer Experience mit Konsistenz und Skalierbarkeit zu erleichtern. Ein Preview Program (ab Dynatrace Managed 1.194) bietet ein schnelleres OneAgent Lifecycle Management durch eine verbesserte REST API. Damit können Integrationen schnell und einfach erfolgen sowie hunderte von OneAgents mit nur einem Befehl verwaltet werden. Die aktualisierten REST API Methoden befinden sich im Bereich „OneAgent on a host“ der Environment API sowie in der Configuration API, wo sie auch ausprobiert werden können. Die aktuellste Neuerung betrifft die Monitored entities API. Mit der zweiten Version können nun Kontextinformationen aus Dynatrace an Integrationen von Drittanbietern sowie an weitgehend automatisierte businesskritische Prozesse wie Deployment Pipelines, CI Toolchains und Projekte zur Cloud Migration übermittelt werden.

Premium High Availability

Auch wenn Dynatrace bei einem Ausfall von bis zu zwei Cluster Nodes funktionsfähig bleibt, kann es passieren, dass ein komplettes Rechenzentrum ausfällt. Dieses Problem löst die Premium High Availability von Dynatrace ohne jegliches externes Load Balancing oder Replikationstechnologien. Im Gegensatz zur bereits existierenden High Availability werden dabei zwei Rechenzentren von der Cluster Management Console unterstützt. Neben einem aktiven Deployment-Modell für optimale Hardware-Nutzung sind damit eine automatische Wiederherstellung nach Ausfällen von bis zu 72 Stunden sowie kontinuierliches Monitoring ohne Datenverlust in Failover-Szenarien möglich. Zusätzlich bietet die eigenständige, schlüsselfertige Lösung einen minimierten Netzwerktraffic zwischen den Rechenzentren.

Verfügbarkeit von Premium High Availability

Premium High Availability benötigt eine separate Lizenz und ist für Umgebungen mit 1000+ Host Units vorgesehen. Für das Setup ist die Zusammenarbeit mit Dynatrace R&D erforderlich. Das ab Version 196 verfügbare Early Adopter Release ist nicht für Produktions- oder Offline-Cluster zu empfehlen. In dem im August 2020 folgenden Release soll Premium High Availability GA sein.

Netzwerkzonen für große Umgebungen

Dynatrace führt aktuell Netzwerkzonen ein, die von Early Adoptern ab Dynatrace SaaS Version 1.195 bzw. Managed Version 1.196 getestet werden können. Hintergrund für diese Neuerung ist, dass große globale Unternehmen in der Regel Rechenzentren überall auf der Welt nutzen. Bisher war dabei der Datenverkehr zwischen den Rechenzentren und Dynatrace ineffizient, was bisweilen zu Ressourcenverschwendung oder unvorhersehbaren Ausfällen führen konnte. Dynatrace hat sich das Ziel gesetzt, die Bandbreite und unnötigen Traffic zwischen Rechenzentren zu minimieren. In Kombination mit entsprechend positionierten ActiveGates wird OneAgent-Traffic gemäß definierten Prioritäten geroutet, idealerweise an ein ActiveGate in der eigenen Netzwerkzone. Erst bei einem Ausfall wird ein anderes, nahe gelegenes ActiveGate genutzt. Zusätzlich wird dieser Traffic vor dem Senden an das Dynatrace Cluster komprimiert. Damit kommen die Daten schneller und ohne Umwege im Cluster an. Auf diese Weise können auch große Deployments nach der Lage der Rechenzentren und deren geographischen Lage gruppiert werden. Sie wollen zeitnah über Neuerungen informiert werden? Kunden mit erweitertem Support (Systemservice) durch amasol erhalten wöchentliche Updates über Neuerungen und Verbesserungen an ihrer Dynatrace Plattform. Für weitere Informationen steht Ihnen Ihr APM Consultant gerne zur Verfügung.

]]>
news-1 Sun, 13 Sep 2020 11:15:00 +0000 Servicetrace APM/TestAutomation: neue Version 2020.1 vorgestellt https://www.amasol.de/blog/detail-page/servicetrace-apm/testautomation-neue-version-20201-vorgestellt Servicetrace hat Servicetrace APM/TestAutomation 2020.1 veröffentlicht. Servicetrace hat Servicetrace APM/TestAutomation 2020.1 veröffentlicht.
Die wichtigsten Highlights der neuen Version sind:

  • Neues Design des Workflows Studio: neue Farben und neue Icons für ein modernes Erscheinungsbild
  • Neue „Action Steps“
    • KI-unterstützte OCR: Erkennt Text auf eingescannten Bildern
    • Mail Operations: Ermöglichen den Abruf, die Bearbeitung und das Versenden von E-Mails aus Postfächern ohne vorinstalliertes Mail-Programm
    • REST Call: Spricht jede beliebige REST-Schnittstelle an durch Ausführen von REST Calls mit den Methoden Get, Post, Put, Patch, Delete, Head und Options

Zu den weiteren Neuerungen gehören:

  • Eine verbesserte Run Result Validation im Control Center
  • Neue Dashboard-Widgets
  • Passwort-Richtlinien für User-Management
  • Über 20 neue REST API-Calls (z.B. im Bereich Workflows oder Test Automation)

Ein Überblick über die neuen Funktionen von Servicetrace APM/TestAutomation 2020.1 steht unter https://www.servicetrace.de/was-ist-neu-apm-ta/ zur Verfügung.

Webcast zu Servicetrace APM/Testautomation 2020.1

Zum Update seiner Software-Robotic-Lösungen für automatisierte Softwaretests und Application Performance Monitoring bietet Servicetrace ab sofort einen Webcast-on-Demand an. Servicetrace Presales Consultant Helmut Apel stellt in diesem Webcast die neuen Funktionen und Optimierungen von APM und TestAutomation ausführlich vor und zeigt sie live in der Anwendungsumgebung.

Hier geht es zum Webcast >>

Für Fragen zur neuen Version von Servicetrace wenden Sie sich bitte an Ihren Ansprechpartner bei amasol.

]]>
APM
news-5 Wed, 02 Sep 2020 11:15:00 +0000 Broadcom stellt Update für BSI vor https://www.amasol.de/blog/detail-page/broadcom-stellt-update-fuer-bsi-vor Broadcom hat CA Business Service Insight 8.3.5.5 vorgestellt. Die wichtigste Neuerung in der neuen Version besteht darin, dass der Adobe Flash Player ersetzt wurde. Damit ist sichergestellt, dass CA BSI nicht durch den zum 31.12.2020 angekündigten End of Support für Adobe Flash beeinträchtigt wird.

Weitere Neuerungen:

  • Windows Server 2019 Oracle-19c-Zertifizierung: Installieren Sie CA BSI 8.3.5.5, um CA BSI mit Oracle 19c Server/Client zu konfigurieren.
  • Windows-Server-2019-Zertifizierung: Um CA BSI App/WebServer auf Windows 2019 zu installieren, ohne den Datenbankserver zu ersetzen, können Sie CA BSI 8.3.5.4.0 installieren.

Darüber hinaus wurden einige Fehler aus dem Vorgänger-Update korrigiert.

Für weitere Informationen zur neuen CA-BSI-Version wenden Sie sich bitte an Ihren Ansprechpartner bei amasol.

]]>
TBM
news-19 Tue, 01 Sep 2020 13:12:00 +0000 Das sollte ein SLM-Tool können: Anforderungen an SLM-Softwarelösungen https://www.amasol.de/blog/detail-page/das-sollte-ein-slm-tool-koennen-anforderungen-an-slm-softwareloesungen-1 Zum Abschluss der Beitragsreihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ möchte ich noch auf das Anforderungsprofil für ein Service-Level-Management-(SLM-) Tool eingehen und Ihnen einen kurzen Marktüberblick – natürlich ohne Anspruch auf Vollständigkeit – vermitteln. Zum Abschluss der Beitragsreihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ möchte ich noch auf das Anforderungsprofil für ein Service-Level-Management-(SLM-) Tool eingehen und Ihnen einen kurzen Marktüberblick – natürlich ohne Anspruch auf Vollständigkeit – vermitteln.

Zentrale Anforderung: Sammeln und Auswerten der definierten Metriken

Auf die Bedeutung von Kennzahlen und Metriken bin ich ja bereits im zweiten Beitrag der Beitragsserie eingegangen. Da in der Praxis die Anzahl und Vielzahl von Metriken schnell steigt, ist eine Software-Lösung erforderlich, die dieses Volumen auch bewältigt, d.h. automatisiert sammelt und auswertet.  Konkret bedeutet dies, dass die Metriken auf eine geeignete Art und Weise abgebildet und dann den definierten IT-Services zugeordnet werden. Um dann den Erfüllungsgrad der Service Level auswerten zu können, müssen Messpunkte der Services mit einem Messkonzept zuverlässig überwacht werden.

In meiner Arbeit habe ich versucht, eine Anforderungssammlung zu erstellen, die die Notwendigkeit eines integrierten Gesamtsystems verdeutlicht. An dieser Stelle nochmals herzlichen Dank an meine Kollegen bei amasol, die mir beim Erstellen des Anforderungskatalogs geholfen haben.

Als Grobschema wurden die folgenden Anforderungskategorien definiert:

  • Definition der SLM-Objekte
  • Servicekatalog und Leitungsstrukturen
  • Management von SLAs
  • Management von Dienstlieferanten
  • Management der Dienstqualität
  • Schnittstellen zu Prozessen und Datenquellen
  • Grundsätzliches Verwenden des Tools
  • Tool-Hersteller

Die einzelnen Kategorien wurden dann mit drei Prioritätsstufen gewichtet:

  • Prioritätsstufe 1: essenziell
  • Prioritätsstufe 2: erforderlich
  • Prioritätsstufe 3: optional

Die Darstellung des kompletten Anforderungskatalogs würde den Umfang dieses Beitrags sprengen, ich kann ihn aber bei Interesse gerne auf Anfrage zur Verfügung stellen.

Marktüberblick: Sammeln und Überwachen vs. Verarbeiten

Betrachtet man derzeit den Markt für SLM-Softwarelösungen, so muss generell zwischen Lösungen zum Sammeln und Überwachen der Metriken und Lösungen, die diese Metriken auch verarbeiten, unterschieden werden. Zum Messen der Applikations-Performance bietet der Markt eine Vielzahl von Produkten. Der „Peer Insights“ von Gartner in der Kategorie APM enthält allein ungefähr 25 Produkte.

Die Software-Lösungen sind dabei häufig in unterschiedliche Pakete unterteilt, die jeweils nur eine bestimmte Funktionalität abdecken. Darüber hinaus setzen die Hersteller auf verschiedene Messmethoden und -technologien. Um aber eine Gesamtlösung zu erhalten, müssen diese Einzelprodukte zu einem „Bundle“ zusammengefasst werden. Problem in der Praxis: Häufig arbeiten die Programme nur mit Systemen des gleichen Herstellers zusammen.

Auch für die Auswertung der erfassten Metriken gibt es auf dem Markt mittlerweile eine ganze Reihe von Lösungen.  Diese werden in der Regel unter der Kategorie IT-Servicemanagement (ITSM) geführt, ein direkter Vergleich dieser Lösungen istallerdings häufig nicht möglich. Der Grund: Die Lösungen sind aus einer Kombination aus Hard- und Softwareverwaltungsprogramme sowie Help-Desk-Tools entstanden und damit kaum vergleichbar. Darüber hinaus wird die Definition, was ITSM genau ist, von sehr differenzierten Begriffserklärungen und Sichtweisen beeinflusst.

Deshalb mein Tipp: Eine spezifische Marktevaluierung sollte immer auf der Grundlage eines individuellen Anwendungsfalles erfolgen.

Das SLM-Toolset der amasol AG

Als naheliegenden Anwendungsfall aus der Praxis möchte ich zum Abschluss kurz zwei SLM-Lösungen vorstellen, die bei der amasol AG im Portfolio sind und für meine Arbeit zu Einsatz kamen:

Dynatrace Managed diente als Monitoring- Lösung und zeichnete Messdaten der amasol -Anwenderaktionen durch Real User Monitoring auf. Zusätzlich wurden auch synthetische Messwerte von externen Messstationen des Herstellers einbezogen. So konnte ich die Kennzahlen „optische Vollständigkeit“ und „Verfügbarkeit“ eines amsaol-internen Service messen.

Apptio Digital Fuel ITBM wurde für die Abbildung der Metriken verwendet. Die Messdaten aus Dynatrace wurden über eine Schnittstelle an ITBM angebunden und anschließend systematisch verarbeitet und aufbereitet. Damit wurde exemplarisch die SLA-Tauglichkeit der Metriken nachgewiesen.

Falls Sie Fragen zu den hier vorgestellten Produkten haben oder weitere Informationen benötigen, stehen Ihnen meine Kollegen jederzeit gerne zur Verfügung.

Damit endet die Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“. Ich hoffe, ich konnte Ihnen einige interessante Denkanstöße zum Thema Service Level Management vermitteln.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de.

]]>
news-18 Sun, 23 Aug 2020 13:09:00 +0000 Von der Messzahl zur Beurteilung der Performance: Ansatz eines Konzepts zur Beurteilung der Anwendungs-Performance https://www.amasol.de/blog/detail-page/von-der-messzahl-zur-beurteilung-der-performance-ansatz-eines-konzepts-zur-beurteilung-der-anwendungs-performance-1 Im dritten Beitrag der Reihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ werde ich nun konkret auf einige zentrale Aspekte bei der Performance-Bewertung eingehen. Im dritten Beitrag der Reihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ werde ich nun konkret auf einige zentrale Aspekte bei der Performance-Bewertung eingehen.

Damit wird auch ein logischer nächster Schritt von einer rein theoretischen Betrachtung und Definition der Begriffe Kennzahlen und Metriken hin zu einem in der Praxis umsetzbaren Konzept zur Beurteilung der Anwendungs-Performance vollzogen.

Verfügbarkeit, optische Vollständigkeit und Geschwindigkeitsindex als zentrale Aspekte der Performance-Bewertung

Betrachtet man die Bewertung der Anwendungsperformance aus Anwendersicht, so spielen die Kennzahlen „Verfügbarkeit“ und „Antwortzeit“ in teilweise verschiedenen Ausprägungen eine zentrale Rolle. Aus diesem Grund standen diese  Kennzahlen und Metriken auch im Mittelpunkt meiner Arbeit. Im Rahmen dieses Beitrags möchte ich insbesondere auf die Kennzahlen „Verfügbarkeit“, „optische Vollständigkeit“ und „Geschwindigkeitsindex“ eingehen.

Verfügbarkeit

Die Verfügbarkeit eines IT-Services ist in der Regel die wichtigste Kennzahl, mit der sich die Leistungsfähigkeit einer Applikation bewerten lässt. Dies liegt schon allein daran, dass eine Anwendung dem Nutzer nur während dieser Zeit zur Verfügung steht. Darüber hinaus wirkt sich eine Nichtverfügbarkeit der Applikation auch automatisch negativ auf alle anderen Kennzahlen aus.
Um die Verfügbarkeit einer Anwendung zu bestimmen, wird das sogenannte Approximationsverfahren eingesetzt. Dieses Verfahren versucht, in sechs aufeinanderfolgenden Arbeitsschritten einen Näherungswert für die Verfügbarkeit zu ermitteln. Dazu werden die verfügbaren Rohdaten (unverarbeitete und nicht ausgewertete Daten) sequenziell analysiert und aufgearbeitet, bis der Kennzahl eine qualitativ hochwertige Beweiskraft attestiert werden kann.

Der Service-Provider ist mit diesem Verfahren in der Lage, die Verfügbarkeit von Anwendungen zur Bewertung im SLA unter Berücksichtigung technischer und organisatorischer Aspekte darzustellen.Einzige Einschränkung: Die Perspektive eines einzelnen Endanwenders kann nicht vollumfänglich berücksichtigt werden, denn die Messdaten basieren primär auf synthetischen Transaktionen, die von Applikationsrobotern ausgeführt werden. Allerdings fließen im Rahmen der Approximation Störungsmeldungen zur Nichtverfügbarkeit von Anwendern ein, sodass die Metrik als solide Bewertungsgrundlage für die Applikationsverfügbarkeit verwendet und deshalb auch in den SLAs im Geschäftsbetrieb berücksichtigt werden kann.

Optische Vollständigkeit

Die optische Vollständigkeit (OV) einer Web-Anwendung ist generell ein wichtiger Teilaspekt der Antwortzeit. Aufgrund ihrer hohen Relevanz für den Endanwender habe ich sie in meiner Bachelorarbeit aber als eigene Kennzahl behandelt.

Die optische Vollständigkeit ergibt sich genau dann, wenn der Bereich der Darstellung einer Anwendung im Web-Browser verarbeitet wurde, der im optischen Ausgabegerät des Anwenders komplett angezeigt wird (vgl. nachfolgende Abbildung, weißer Bereich).

 

Geschwindigkeitsindex

Der Geschwindigkeitsindex beschreibt wiederum, wie schnell die einzelnen Elemente einer Webanwendung (Grafiken, Texte, Tabellen etc.) angezeigt werden. In Bezug auf die oben erläuterte optische Vollständigkeit macht es Sinn, auch den Geschwindigkeitsindex nicht auf die vollständig geladene Webseite, sondern eben nur auf den Bereich der optischen Vollständigkeit zu beziehen. Angegeben wird er in der Regel mit einem Prozentsatz (0 % bis 100 %) und einem zeitlichen Parameter (Millisekunden). Letztendlich gibt der Index also an, zu welchem Zeitpunkt wie viel Prozent des für den Benutzer sichtbaren Bereichs dargestellt werden. Der Geschwindigkeitsindex eignet sich darüber hinaus zum Vergleich unterschiedlicher Webseiten, wenn diese beispielsweise über dieselbe optische 
Vollständigkeit verfügen. Eine Webseite mit kleinerem Geschwindigkeitsindex bietet dann nämlich die bessere Benutzererfahrung, denn die Inhalte sind für den Benutzer schneller sichtbar.

Die „Performance-Pyramide“

Meiner Meinung nach bilden die Service-Level-Metriken für die Kennzahlen Verfügbarkeit, optische Vollständigkeit und Geschwindigkeitsindex eine solide Grundlage für die Bewertung der Anwendungsperformance in einem SLA. Die Grundlage bildet dabei die Verfügbarkeit, von der – wie bereits eingangs erwähnt – alle anderen Kennzahlen abhängig sind. Auf diesem Fundament setzt die Antwortzeit in Form der optischen Vollständigkeit und des Geschwindigkeitsindex auf. Dabei verfeinert der Geschwindigkeitsindex die Werte der optischen Vollständigkeit und stellt damit den dritten Baustein der Performance-Bewertung dar.

Soweit der dritte Teil der Beitragsserie zu meiner Bachelorarbeit, in dem ich den Ansatz eines Konzepts zur Beurteilung der Anwendungs-Performance skizziert habe. Im Mittelpunkt des vierten und letzten Beitrags der Reihe stehen das Anforderungsprofil für ein SLM-Tool und die Vorgehensweise bei der Auswahl. Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de.

]]>
news-17 Sun, 16 Aug 2020 12:59:00 +0000 Kennzahlen und Metriken: Konzept und richtige Anwendung https://www.amasol.de/blog/detail-page/test-beitrag Nachdem sich mein erster Beitrag der Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ mit den Grundlagen von Service Level Management (SLM) beschäftigte, stehen im zweiten Beitrag Kennzahlen und Metriken als wichtige Kriterien für die Bewertung des Leistungsnachweises von IT-Services im Mittelpunkt. Nachdem sich mein erster Beitrag der Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ mit den Grundlagen von Service Level Management (SLM) beschäftigte, stehen im zweiten Beitrag Kennzahlen und Metriken als wichtige Kriterien für die Bewertung des Leistungsnachweises von IT-Services im Mittelpunkt.

Anforderungen an Kennzahlen in Bezug auf deren Aussagekraft

Bereits im Einführungsbeitrag wurde kurz auf die Bedeutung von Kennzahlen und Metriken als Instrumentarium eingegangen, mit dem im Service Level Management ein Qualitätsnachweis für die vereinbarten SLAs erbracht werden kann.

Im Folgenden geht es nun um die Anforderungen, die Kennzahlen und Metriken erfüllen müssen, damit so ein Qualitätsnachweis überhaupt möglich ist. Um aber eine Kennzahl überhaupt erst einmal mit „Leben“ zu erfüllen, werden in der Regel die folgenden vier Beschreibungskriterien definiert:

Bezeichnung: ein klarer und eindeutiger Name (z. B. durchschnittliche Antwortzeit).
Bezugsobjekt: eindeutiger Bezug auf einen IT-Service (z. B. durchschnittliche Antwortzeit des ERP-Systems).
Bezugszeit: Dabei ist sowohl die Definition eines Zeitpunkts als auch eines Zeitraums möglich. In letzterem Fall muss dann aber auch ein eindeutiges Zeitintervall angegeben werden (z. B. durchschnittliche Antwortzeit des ERP-Systems während der Geschäftszeiten).
Berechnungsweg: z. B. durchschnittliche Antwortzeit des ERP-Systems während der Geschäftszeiten = Summe aller Antwortzeiten während der Geschäftszeiten/Anzahl der Messungen.


Die Eindeutigkeit spielt bei der Definition der Beschreibungskriterien eine ganz besondere Rolle. Nur wenn diese gewährleistet ist, können Verwechslungen und Missverständnisse bei der SLA-Gestaltung ausgeschlossen werden. Darüber hinaus wird so sichergestellt, dass alle Vertragsparteien jederzeit von denselben Bemessungs- und Bewertungsgrundlagen ausgehen.

Über das reine Definieren von Kennzahlen hinaus gibt es allerdings wichtige Anforderungen, die diese Kennzahlen erfüllen müssen, um überhaupt die von den Vertragsparteien benötigte Aussagekraft zu liefern:

  • Lückenlose Beschreibung: Den „Mut zur Lücke“ darf es bei einer Kennzahl nicht geben. Neben der Eindeutigkeit spielt nämlich die Vollständigkeit bei der Beschreibung einer Kennzahl eine zentrale Rolle, denn nur so wird eine Fehlinterpretation über die Aussage und Ermittlung der Kennzahl möglich.
  • Relevanz zum Dienstleistungsnutzen: Diese Relevanz ist nur dann gegeben, wenn die Kennzahl ein Attribut mit Bedeutung für den Kundennutzen des Service beschreibt. Dieser Nutzen wiederum wird in der Regel aus dem Wertbeitrag eines Dienstes zur Unterstützung der Geschäftsprozesse des Service-Kunden bestimmt. Der Kunde muss also in der Lage sein, aus der Kennzahl einen klaren Beitrag des Service zu seinem Nutzen ableiten können.
  • Funktionaler oder proportionaler Zusammenhang zum Sachverhalt: Dieser Zusammenhang ist wichtig, denn nur dann kann bei Veränderung der Kennzahl (steigen/fallen) auch eine direkte Aussage über die Veränderung (der Qualität) der Dienstleistung getroffen werden.
  • Aussagekraft für den Anwender: Dies ist unter Umständen gar nicht so einfach, insbesondere, wenn das technische Verständnis beim Anwender fehlt oder Begriffe gewählt werden, die er schlicht nicht versteht. Ziel muss es sein, eine Kennzahl mit höchstmöglicher Aussagekraft für den Anwender zu bestimmen. In der Regel ist es dabei notwendig, dass sich der IT-Dienstleister in die Situation des Anwenders vor seinem Endgerät versetzt.
  • Beherrschbarkeit durch den Dienstleister: Klingt banal, ist aber wichtig. Denn nur wenn der Dienstleister die Entwicklung der Kennzahl vollständig beherrschen kann, macht es Sinn, diese auch in ein SLA aufzunehmen.
  • Wirtschaftlichkeit: Das Kosten-Nutzen-Verhältnis spielt wie in vielen Bereichen auch hier eine zentrale Bedeutung. Eine Kennzahl wird generell dann als wirtschaftlich angesehen, wenn der damit gewonnene Nutzen die Kosten für deren Ermittlung zumindest ausgleicht. In der Praxis zeigt sich allerdings häufig, dass dieser Nutzen nur schwer kalkulatorisch bestimmt werden kann und deshalb eine subjektive Entscheidung erforderlich ist.

Von der Kennzahl zur Metrik

Bereits im letzten Beitrag bin ich kurz auf die Definition eingegangen, dass eine Metrik als Ermittlungsverfahren der Kennzahl zu verstehen ist. Genauer ausgedrückt ist die Metrik ein Schema, nach dem sich das Ergebnis einer Kennzahl, bezogen auf den korrespondierenden IT-Service, berechnen lässt.

Und auch in Bezug auf die inhaltlichen Anforderungen an eine Metrik gibt es eine klare Definition, die aus zwei Kernkomponenten besteht:

Generische Verwendbarkeit: Eine Metrik muss möglichst allgemeingültig sein, damit sie auf eine Vielzahl von Services anwendbar ist. Hierdurch ergibt sich für einen Serviceprovider ein hoher Grad der Wiederverwendung.
Mittels logischer Operatoren beschreibbar: Um eine Abbildung der Metriken im SLM-Tool zu ermöglichen, muss die Formulierung einer Metrik mit einer Menge an technischen Operatoren möglich sein. Hierzu zählen beispielsweise Operatoren von relationalen Datenbanken zur Datenmanipulation oder Filterung von Datensätzen nach gewissen Kriterien.
Damit endet Teil 2 der Beitragsserie zu meiner Bachelorarbeit mit dem Fokus auf die wichtigen Messgrößen Kennzahl und Metrik und deren Aussagekraft.

Der nächste Beitrag wird sich damit beschäftigen, wie auf Grundlage der definierten Kennzahlen und Metriken nun eine Beurteilung der Performance erfolgen kann. Als Beispiel aus der Praxis wird dabei ein Konzept zur Beurteilung der Anwendungsperformance beschrieben.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de

]]>
news-13 Sun, 02 Aug 2020 14:49:00 +0000 Service Level Management als Grundlage für den Leistungsnachweis von IT-Services https://www.amasol.de/blog/detail-page/service-level-management-als-grundlage-fuer-den-leistungsnachweis-von-it-services Im ersten Beitrag dieser Reihe geht es zuerst einmal grundsätzlich um die Definition von Service Level Management (SLM), Service Level Agreements (SLA) als vertragliche Grundlage für SLM sowie Kennzahlen und Metriken als Bewertungsgrundlage für SLAs und SLM. „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ – so lautete der Titel der Bachelorarbeit von amasol-Consultant Dominik Hecker im Rahmen seines Studiums der Wirtschaftsinformatik an der Hochschule München. Die Arbeit unterstreicht die Bedeutung, die die Kombination von Theorie und Praxis – Kollege Hecker ist bei amasol im Technology-Business-Management-Team tätig – heute für die moderne IT hat. Grund genug, die wichtigsten Aspekte der Arbeit in einer Beitragsserie zusammenzufassen und auch auf diese Weise den Bezug von Theorie und Praxis herzustellen.

Im ersten Beitrag dieser Reihe geht es zuerst einmal grundsätzlich um die Definition von Service Level Management (SLM), Service Level Agreements (SLA) als vertragliche Grundlage für SLM sowie Kennzahlen und Metriken als Bewertungsgrundlage für SLAs und SLM.

Service Level Management: Definition

Grundsätzlich versteht man unter Service Level Management (SLM) das Lenken und Gewährleisten von Service-Erbringungen in einer zuvor vereinbarten Qualität. Mit der Entwicklung moderner IT-Abteilungen weg vom Cost Center hin zum Profit-Center hat dieser Aspekt eine immer größere Bedeutung erlangt. Aufgabe der IT-Abteilung ist es heute, für den Endanwender als „internen Kunden“ bestimmte IT-Services zu leisten. Nun geht es im Vorfeld darum, diese Leistungen konkret festzulegen (Art, Umfang, Zeit, Kosten, Qualität). Ist dies geschehen, besteht die Herausforderung für die IT nun darin, zum einen diese Leistungen in der vereinbarten Qualität zu erbringen, zum anderen nachzuweisen, dass sie die vereinbarten Dienste in der vereinbarten Qualität wirklich erbracht hat. Genau dies geschieht im Rahmen des Service Level Managements. Denn erst wenn dieser Nachweis erbracht ist, können die Leistungen auch in Rechnung gestellt werden. Darüber hinaus liefern die SLM-Ergebnisse eine wichtige Grundlage zur Optimierung der IT-Services. Die wichtigsten Ziele dabei sind:

  • Verbesserung der Anwendererfahrung (die Anwenderfokussierung ist in den vergangenen Jahren
  • in den Mittelpunkt der Betrachtung der IT-Qualität gerückt)
  •  Optimieren bzw. Senken der IT-Kosten
  • Erfüllen der IT-Governance-Vorgaben

 

SLA: Vertragliche Grundlage für SLM

Als vertragliche Grundlage für das Service Level Management dienen die sogenannten Service Level Agreements (SLA). Dominik Hecker zitiert in seiner Arbeit die gängige ITIL-Definition: “An agreement between an IT service provider and a customer. The SLA describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer. A single SLA may cover multiple IT services or multiple customers.”

Generell geht es also um die eindeutige vertragliche Regelung über eine IT-Dienstleistung und die dadurch abgeleitete Beziehung zwischen IT-Dienstleister und Service-Kunde. Ein SLA wird in der Regel in Schriftform erstellt und für einen bestimmten Zeitraum geschlossen. Dabei ist es unerheblich, ob die Vertragspartner zum selben Unternehmen (interne Kunden) oder zu unterschiedlichen Firmen (externe Kunden) gehören. 

Die wichtigsten Bestandteile eines SLAs sind
•    die genau festgelegten Verantwortlichkeiten der beiden Vertragsseiten, 
•    die Art und Weise der Kommunikation bei Notfällen und Problemeskalationen,
•    finanzielle Bonus- und Malus-Regelungen für das Einhalten bzw. das Nicht-Einhalten der vereinbarten Service Levels

Genau an dieser Stelle kommt auch wieder der eingangs erwähnte „Nachweis“-Aspekt im Service Level Management zum Tragen, denn nur wenn dieser Nachweis erbracht wird, können auch die entsprechenden Bonus-/Malus-Vereinbarungen umgesetzt werden.

Kennzahlen und Metriken als Bewertungsgrundlage für SLA und SLM

Womit wir beim letzten Thema dieses Einführungsbeitrags wären: den Kennzahlen und Metriken. Sie liefern quasi das Instrumentarium für den im Service Level Management zentralen Aspekt des Qualitätsnachweises der im SLA vereinbarten IT-Services. Zuerst einmal ist es natürlich wichtig, die beiden Begriffe zu definieren und voneinander abzugrenzen bzw. in Beziehung zu setzen. In seiner Bachelorarbeit zitiert Dominik Hecker das Oxford English Dictionary mit der Definition des Begriffs Metrik als „a system or standard of measurement“. Das deutsche Synonym „Messgröße“ definiert itwissen.info als „Messverfahren von quantifizierbaren Werten im Kontext der Informationstechnologie“.

Beim Versuch, die beiden Begriffe in Relation zu bringen, kommt Dominik Hecker zu dem Schluss, dass eine Metrik als Ermittlungsverfahren der Kennzahl zu verstehen ist. Genauer ausgedrückt, ist die Metrik ein Schema, nach dem sich das Ergebnis einer Kennzahl, bezogen auf den korrespondierenden IT-Service, berechnen lässt. Bezugnehmend auf das Thema SLM bedeutet dies, dass beispielsweise der quantifizierbare Ergebniswert der Kennzahl „Verfügbarkeit“ durch die dazugehörige Metrik berechnet werden kann. Dies erfolgt durch eine definierte Verarbeitung und Aufbereitung der gemessenen Rohdaten aus dem Monitoring-Messsystem, bis schließlich ein numerischer Wert vorhanden ist, der den Sachverhalt der Kennzahl eindeutig bestimmt.

Soweit die Einführung in das Thema Service Level Management. Die besondere Bedeutung von Kennzahlen und Metriken und insbesondere deren richtige Anwendung wird Thema des nächsten Beitrags sein.

Wenn Sie sich mit Dominik Hecker über die Inhalte seiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie ihn unter dominik.hecker(at)amasol.de

]]>