Serviceskalierung durch Native Cloud Computing

In der Cloud präsent zu sein ist nur der erste Schritt. Die besonderen Möglichkeiten von Cloud Computing zu nutzen ist der wichtigere Schritt. Eine dieser Möglichkeiten ist die fast uneingeschränkte Skalierbarkeit der bereitgestellten Anwendungen bzw. Services. Dazu müssen die verwendeten Dienste jedoch cloud-native sein und Orchestrierungsservices wie Kubernetes verwenden. Unser Cloud Experte gibt einen Überblick über die Architektur eines solchen Systems.

Zur Vorbereitung müssen über Container die Software und die benötigten Bibliotheken auf der Ebene des Betriebssystems gebündelt werden. Container nutzen den Kernel des Host Betriebssystems, sind jedoch auf Prozess- und Datei-Ebene von anderen Containern und vom Host getrennt. Der Ressourcenverbrauch von Containern kann genau konfiguriert werden.

Um diese Container in einem Cluster von virtuellen oder physischen Rechnern zu betreiben, bedient man sich eines Container Orchestrators. Der dominierende Container Orchestrator mit einem Marktanteil (je nach Umfrage zwischen 80 und 90 Prozent) ist Kubernetes. Docker Swarm und Apache Mesos sind alternative Produkte, spielen jedoch am Markt nur eine geringe Rolle.

Kubernetes wurde ursprünglich von Google entwickelt und 2014 als Open Source Plattform zum automatischen Deployment, der Skalierung und dem Management von containerisierten Applikationen veröffentlicht. Heute wird Kubernetes von der Cloud Native Computing Foundation (CNCF) verwaltet. Die CNCF wurde 2015 als Nonprofit-Organisation gegründet und ist Teil der Linux Foundation. Damit sollte auch die Weiterentwicklung in der Zukunft gesichert sein.

Kubernetes kann man entweder selbst On-Premise oder in der Cloud installieren beziehungsweise einen gemanagten Kubernetes Cluster nutzen.  Laut Marktforschung (https://security.stackrox.com/state-of-containers-and-kubernetes-security-report-winter-2020.html, nicht mehr online) sind selbst-gemanagte Kubernetes Installationen rückläufig und die Nutzung der gemanagten Kubernetes Cluster Angebote wächst stark.

Architektur eines gemanagten Kubernetes Clusters

Ein Kubernetes Cluster (K8s) besteht aus 2 Komponenten:

Quelle: Microsoft Azure Dokumentation
  • Die Control Plane übernimmt die Steuerung des K8s. Sie wird vom Provider gemanagt und oftmals sogar kostenlos zur Verfügung gestellt.
  • Nodes, auf denen die in Container verpackten Applikationen ablaufen. Die Nodes, auf die die Applikationen deployt werden, werden vom Kunden gemanagt und wie virtuelle Maschinen abhängig vom Prozessortyp, der Anzahl der virtuellen VPUs und dem RAM verrechnet. Nodes werden in Nodepools zusammengefasst.

Implementierung eines gemanagten Kubernetes Clusters (K8s)

Die Installation des K8s kann zum Beispiel über die Command Line bzw. das Portal des Cloud-Providers oder Werkzeuge wie zum Beispiel Rancher oder Terraform durchgeführt werden.

Bei der Installation wird die Anzahl der Nodes und die Kubernetes Version angegeben. Anhängigkeit vom Provider kann eine höhere Verfügbarkeit für die Control Plane angegeben werden, Nach 5 bis 15 Minuten steht dann der K8s zur Verfügung. Die Leistung des K8s kann durch Hinzufügen bzw. Wegnehmen von Nodes jederzeit verändert werden. Die im K8s konfigurierten Nodes werden wie VMs unabhängig von ihrer Auslastung vom Provider verrechnet. Autoskalierung ist eine Möglichkeit, um die Kosten zu optimieren.

Autoskalierung in der Cloud

Über die Autoskalierung können einer Applikation bei Bedarf automatisch zusätzliche Ressourcen (CPU und RAM) zur Verfügung gestellt werden. Die Regeln dazu können mit Parametern wie z.B Anzahl der Requests, CPU- bzw. RAM-Auslastung vom Administrator vorab konfiguriert werden. Damit entfallen manuelle Schritte in der Betriebsführung und es kann blitzschnell reagiert werden. Sowohl das Hochskalieren als auch das Reduzieren von Ressourcen können automatisch durchgeführt werden.

Dabei werden sowohl die Anzahl der Nodes  je nach Konfiguration automatisch angepasst, als auch die Applikationen/Services in zusätzlichen Instanzen gestartet bzw. gestoppt. Dies erfolgt über sogenannte Pods.

Ein Pod ist das einfachste ausführbare Objekt in einem Kubernetes Cluster. In einem Pod können ein oder mehrere Container ablaufen. Ein Pod stellt eine Instanz einer Applikation dar. Durch das Starten von zusätzlichen Pods wird die Applikation hochskaliert (= horizontale Skalierung).

Praktisches Beispiel für autoscaling in der Cloud

Am obigen Beispiel sieht man sehr schön, wie der Autoscaler bei Erreichen einer vom Administrator definierten kritischen Prozessorlast beginnt, zusätzliche Pods zu starten (rechte untere Grafik). Da die bestehenden Nodes jedoch über dem Lastlimit sind und keine zusätzlichen Pods starten können (ersichtlich an den kleinen roten Peaks in der rechten unteren Grafik), müssen zuerst zusätzliche Nodes hochgefahren werden. Mit Hilfe der zusätzlichen Nodes und Pods kann die Applikation das erhöhte Nutzungsvolumen bewältigen.

Das Ziel: Eine Cloud-Strategie für Ihr Unternehmen

Um eine vollständige Cloud-Strategie und eine sinnvolle Umsetzung für Ihr Business zu entwickeln ist es wichtig, sich mit Cloud-Native Methoden auseinanderzusetzen. Ein Grundverständnis für die Funktionsweise von Skalierung in der Cloud kann Ihnen helfen, Anwendungsfälle und Prozesse, die dadurch profitieren, besser zu identifizieren. Die einfache und umfassende Skalierbarkeit ist eine der vielen Möglichkeiten, die man dabei gewinnen kann. In unseren Kursen und bei unserer Beratung unterstützen wir Sie dabei, die Möglichkeiten von Cloud-Computing für Ihr Unternehmen zu nutzen.


UNSERE TRAININGSANGEBOTE INNOVATIONSTECHNOLOGIEN:

Cloud-Management – Chancen und Erfolgsfaktoren

Der Umzug von IT-Services in die Cloud ist für viele Unternehmen ein aktuelles Thema. Entscheidend dabei ist, nicht nur die jeweiligen Applikationen, Datenbanken und Netzwerkstrukturen fit für die Cloud zu machen. Man muss auch darüber nachdenken, wie die Cloud Services zukünftig administriert werden sollen! Wir berichten aus unserer praktischen Erfahrung über Chancen und Erfolgsfaktoren für gutes Cloud Management.

Die Nutzung von Cloud-Angeboten, wie sie z.B. die bekannten Public Clouds von AWS, Azure oder Google bereitstellen, hat für Unternehmen folgende Vorteile: 

  • Skalierbarkeit der benötigten Ressourcen 
  • Transparenz und Nachvollziehbarkeit bei Kosten und Administration 
  • Einfacher Zugriff und Nutzung von speziellen Services wie z. B. Angeboten zu AI, Blockchain oder spezialisierten Caches. 

Fallbeispiel: Umzug eines Unternehmens in die Cloud 

Greifen wir das Beispiel eines international agierenden, österreichischen Unternehmens heraus, das bisher seine Server im Rechenzentrum eines externen Providers stehen hat. Dieser nimmt gleichzeitig die Administration der Server und die Installation der dort genutzten Applikationen vor. Mit der monatlichen Bezahlung werden Service und IT-Leistungen abgerechnet. Vor der Umstellung auf Cloud-Services, stellt sich die Frage, wie dieses Verhältnis zukünftig geregelt werden soll. Für erfolgreiches Cloud-Management sind für den Anfang folgende drei Punkte wichtig: 

  • Die Rolle des Cloud-Administrators klar abgrenzen
  • Containertechnologien wie Docker nutzen 
  • Skalierbarkeit optimal nutzen 

Die Rolle des Cloud-Administrators klar abgrenzen 

Beim Umstieg auf die Cloud ist es sinnvoll, die Schnittstellen zwischen Applikationsentwicklern, Infrastrukturprovider (Cloudprovider) und dem zukünftigen Cloud-Administrator klar abzugrenzen und ggf. neu aufzustellen. 

Die Rolle des Cloud Administrators kann entweder intern oder durch einen externen Dienstleister erfüllt werden. Im Falle eines externen Dienstleisters sollte die Subscription nicht auf den Namen des Cloud Administrators laufen, sondern den Auftraggeber zugeordnet sein, womit auch klar der tatsächliche Nutzer der Ressourcen geregelt ist. Dadurch erhält der Auftraggeber direkt die Rechnung über die genutzten Ressourcen und damit über die detaillierte Aufstellung die volle Transparenz zur Struktur der tatsächlich angefallenen Kosten. 

Der Cloud Administrator erhält Zugang zu den Ressourcen in der Subscription des Auftraggebers, jedoch nicht das Recht die Subscription selbst zu ändern (z.B. Zahlungsmethoden). Wenn es notwendig ist, die Administration zu wechseln (z.B. aufgrund von Insolvenz des Dienstleisters oder mangelnder Leistung), kann dies einfach über die Autorisierung (Benutzer und Rechtevergabe) erfolgen. 

Containertechnologien wie Docker nutzen 

Die Schnittstelle zwischen Applikationsentwicklung und der Administration ist aufgrund der Schwierigkeiten bei der Installation von Softwareapplikationen oftmals komplex, . Gerade bei der Nutzung von Cloud Services bieten sich Containertechnologien wie Docker als Lösung an. 

Durch die Nutzung von Containertechnologien wie Docker kann sich die Cloud Administration auf die wesentlichen Aufgaben konzentrieren, nämlich auf die Schaffung einer sicheren, skalierbaren, performanten und kostengünstigen Systemumgebung mittels Cloud Ressourcen (Prozessor, Storage, Load Balancing, CDN, verwaltete Datenbanken etc.). 

Die Applikationsentwickler sind für die fertige Bereitstellung der Software auf Basis von Containern verantwortlich. Eine Anwendungsinstallation entfällt, da der Container die vollständig konfigurierte Laufzeitumgebung enthält. Dadurch werden auch Fehler bei der Installation ausgeschlossen. 

Skalierbarkeit optimal nutzen 

Derzeit können virtuelle Maschinen, die kontinuierlich und konstant ausgelastet werden, in einem klassischen Rechenzentrum noch kostengünstiger als über die Cloud bereitgestellt werden. Ein wesentlicher Charme von Cloud-Angeboten liegt jedoch in der einfachen und ggf. weltweiten Skalierbarkeit der genutzten Services, die in einer eigenen RZ-Infrastruktur nicht vergleichbar kostengünstig aufgebaut werden können. 

Durch den Einsatz skalierbarer Docker Container kann der Cloud Administrator rasch auf zusätzlichen Bedarf reagieren und die Anzahl der gleichzeitig gestarteten Containerinstanzen mit wenigen Kommandos hochfahren und auch wieder reduzieren. Mit dem Einsatz von Containermanagement wie Kubernetes kann dieser Vorgang sogar automatisiert werden. 

Um die Skalierung effizient zu nutzen, muss die Verantwortung dafür zwischen Applikationsentwicklung und Administration klar bestimmt sein, wobei die Nutzung von Containern eine Voraussetzung ist. Die Aufgabe der Entwicklung ist es skalierbare Applikationen bereitzustellen. 

Cloud-Potentiale Nutzen 

Mit Cloud Services stehen Unternehmen mächtige, skalierbare Infrastrukturwerkzeuge zur Verfügung. Durch den gezielten Einsatz und gutes Cloud Management ergeben sich jeden Menge Potentiale – und das nicht nur für Großunternehmen. 

Die Beschaffung von Cloud Ressourcen muss die geänderten technischen und organisatorischen Rahmenbedingungen im Vergleich zu klassischen IT-Beschaffungen berücksichtigen. Spirit in projects ist ein Spezialist für die Erstellung von Cloud Konzepten und technischen Unterlagen in Beschaffungsvorgängen bzw. bei Ausschreibungen. Wir erstellen mit unseren Kunden tragfähige und zukunftssichere Konzepte, erstellen die Unterlagen und unterstützen im Beschaffungsvorgang mit unserem technischen Hintergrundwissen. 


UNSERE TRAININGSANGEBOTE ZU INNOVATIONSTECHNOLOGIEN:

Agiles Requirements Engineering – Erfolgsfaktoren für agile Methoden

Lastenhefte und Pflichtenhefte sind Ihnen zu schwerfällig und langweilig? Agilität ist das Schlagwort der Stunde! Projekte sollen schnell umgesetzt werden. Von der Erhebung der Anforderungen bis zur Umsetzung sind agile Methoden daher in aller Munde. Wir haben 6 Erfolgsfaktoren für agile Methoden im Requirements Engineering und der Implementierung von Projekten identifiziert.

Agile Methoden erfreuen sich immer größerer Beliebtheit. Innovative Projekte zur Digitalisierung benötigen Flexibilität in der Umsetzung aber auch in den Anforderungen. Um die Herausforderung der Agilität bei der Erhebung und Klärung von Anforderungen zu stemmen, stützen sich Projekte gerne auf die Techniken des agilen Requirements Engineering.

Was ist agiles Requirements Engineering?

Die bevorzugten agilen Methoden zum Erfassen und Verwalten der Anforderungen im Zuge eines agilen Requirements Engineering Prozesses sind:

  • Workshops
  • Die Spezifikation der Ergebnisse mittels User Stories bzw. Epics, Technical Stories etc.
  • Backlogs und Kanban-Boards zum Verwalten der Anforderungen im Zuge der Implementierung. Diese werden entweder physisch (zentrale Tafeln) oder elektronisch (in Tools wie Jira etc.) realisiert.

Die Erfolgsfaktoren für agiles Requirements Engineering

Diese Methoden sind richtig und wichtig. Ihr Einsatz führt bei vielen Projekten zu hervorragenden Ergebnissen – bei vielen anderen Projekten aber auch zu großen Problemen. Dabei sind die Standpunkte teils sehr extrem: In manchen Organisationen ist Agilität das Zauberwort schlechthin. Andere haben nach schlechten Erfahrungen die Benutzung des Wortes im Zusammenhang mit Projekten geradezu verboten.

Agilität ist nicht nur eine Technik, sondern im Zusammenhang mit Projekten und Unternehmen auch eine Managementphilosophie. Die reine Nutzung der Prozesse und Techniken ist nicht ausreichend, um erfolgreich zu sein. Nach unserer Beobachtung gibt es grundlegendere Erfolgsfaktoren.

Wolfgang Hiermann, CEO und agile Coach

Als Erfolgsfaktoren haben sich aus unserer Erfahrung in Projekten und der Beratung folgende 6 Punkte herauskristallisiert:

  • Product Leader statt Product Owner
  • Kurze Feedbackzyklen tatsächlich durchführen
  • Produktaffine Entwickler
  • Expeditionsfreudige Organisation
  • Offenheit und Transparenz
  • Entwicklung an die Brust holen

Diese Faktoren sind Puzzlesteine für den Erfolg von agilem Requirements Engineering und agilen Projekten. Im Zusammenspiel ergeben sie ein funktionierendes Ganzes, in dem agile Methoden und Techniken sinnvoll eingesetzt werden können.

Erfolgsfaktor 1: Product Leader statt Product Owner

Agilität bedeutet Flexibilität. Flexibilität wird unterstützt durch den Willen und die Möglichkeit der Stakeholder, Ziele (und hier vor allem die Nutzungsziele) zu hinterfragen, Entscheidungen anzupassen und Prioritäten zu verändern. Am allerwichtigsten ist allerdings die Begeisterung und der aktive Gestaltungswille der Stakeholder für das Produkt.

Erfolgreiche agile Projekte benötigen daher weniger einen (oftmals leider) rein administrativen Product Owner, sondern eine Gruppe an eng zusammenarbeitenden Product Leaders, die mit Weitsicht und Energie das Projekt als Stakeholder vorantreiben.

Erfolgsfaktor 2: Kurze Feedbackzyklen tatsächlich durchführen

Leider scheitern manche agile Projekte genau daran, dass die Interaktion zwischen Stakeholdern und agilem Team nach dem initialen Workshop auf ein Minimum reduziert wird. Um agile Projekte erfolgreich umzusetzen, ist es nicht genug, die Anforderungen über User Stories zu beschreiben und in Backlogs zu verwalten.

Kurze Sprints müssen tatsächlich durchgeführt werden. Am Ende eines Sprints muss ein herzeigbares Ergebnis stehen und am allerwichtigsten, die relevantesten Stakeholder der Anforderungen müssen dieses Ergebnis tatsächlich zu Gesicht bekommen, sich damit beschäftigen und gegebenenfalls Anforderungen und Ziele anpassen können.

Erfolgsfaktor 3: Produktaffine Entwickler

Die Mitarbeit der Entwickler wird leider oft aus Angst vor Goldplating vernachlässigt. Doch das Gegenteil ist der Fall: Begeisterte Entwickler wollen nichts programmieren, was niemand benutzen wird – sie wollen Benutzer erleben, die das Produkt mit Freude einsetzen und hin- und wieder mal ein ehrlich gemeintes „Danke“ für ihren Einsatz hören.

Denn agile Flexibilität in der Entwicklung ist schwierig, wenn die Entwickler keinen echten Bezug zum Ergebnis herstellen können. Eine besonders gelungene Umsetzung von Anforderungen und Technologie wird nur erreicht, wenn Entwickler vom Nutzen des Produktes überzeugt sind und die Gelegenheit haben, die Anforderungen aktiv mitzugestalten.

Erfolgsfaktor 4: Expeditionsfreudige Organisation

“Veränderungen strengen an. Durch Veränderungen ist noch nie etwas besser geworden. Wir warten einmal ab, was da auf uns zukommt, dann werden wir uns das ansehen.” – Wenn das die Lebensphilosophie der Organisation des Auftraggebers ist, dann fühlen sich die Teammitglieder eines agilen Projekts wie Außerirdische kurz nach der Landung. Das Frustpotential im Projekt ist groß.

Denn hier gilt das Prinzip: “Wer A sagt, muss auch B sagen.” Stakeholder und Organisationen, die sich für agile Vorgangsweisen nicht im vollen Umfang begeistern und einsetzen können, sollten lieber die Finger davon lassen und konservative Methoden einsetzen – damit aber auch auf die Vorteile der flexiblen Entwicklung verzichten.

Erfolgsfaktor 5: Offenheit und Transparenz

“Es ist nicht klar, warum wir diese Aufgabe so durchführen. Es wurde aber schon immer so gemacht, also muss das auch in Zukunft so sein” – solche Aussagen haben Sie sicher schon gehört. Manchmal wird das Hinterfragen eines Vorgangs als Anmaßung oder sogar als Beleidigung empfunden. Manche Fragen dürfen nicht überall bzw. nur im richtigen Kontext gestellt werden. Und viel zu oft müssen Vorschläge abgestimmt und Entscheidungen im kleinen Kreis vorbereitet werden, bevor sie „offen“ mit allen Stakeholdern diskutiert werden können.

Hier gilt der berühmte Satz Peter Druckers: “Culture eats strategy for breakfast.” An dieser Stelle stirbt die Agilität (und die Projektdemokratie gleich mit). Effiziente Agilität benötigt offene Zusammenarbeit und gegenseitige Wertschätzung.

Erfolgsfaktor 6: Entwicklung an die Brust holen

Ja – man kann agile Entwicklung auch outsourcen. Je größer die Distanz, desto höher wird der Aufwand für die Steuerung und die Kommunikation in agilen Projekten. Die immer besser werdenden Mittel für Videokonferenzen bzw. die Livebearbeitung von Dokumenten erleichtern die Arbeit zwar enorm, sind aber kein Ersatz für echte kurze Wege.

Bei agilen Projekten wird daher Nearshoring gerne vor Offshoring eingesetzt. Die höchste Effizienz und Effektivität für agile Projekte wird allerdings dadurch erreicht, dass die Distanzen zwischen Stakeholdern und der Entwicklung so klein wie möglich gehalten werden. Onshoring agiler Projekte oder manchmal noch besser Onboarding des agilen Teams für die Projektlaufzeit sind erfolgreiche Methoden.

Fazit: Kultur und Know-how

Betrachtet man die 6 Erfolgsfaktoren, haben sie viel mit der Unternehmenskultur und dem Aufbau internen Know-hows zu tun. Um Agilität im Requirements Engineering und in Projekten anzuwenden, benötigt es Zeit sowie Wissen über agile Methoden. Die Projektbeteiligten benötigen profundes Produktwissen und ein gutes technisches Grundverständnis.

Dies in einem Team aufzubauen ist also ein wesentlicher Schritt in Richtung einer agilen Organisation. Wir von Spirit in Projects unterstützen Sie mit unserem Kursprogramm und mittels Beratungen dabei, Agilität auch in Ihrer Organisation zu verankern!


UNSERE TRAININGSANGEBOTE ZU INNOVATION & AGILITÄT:

Trends im Requirements Engineering – Digitale Transformation mit Methode

“Wozu brauchen wir noch Anforderungen? Wir sind doch agil!” – Haben sie diesen Satz schon einmal gehört? In Zeiten rasanter Innovation klingt allein der Begriff Anforderungsmanagement schon schwerfällig. Doch gerade angesichts des radikalen Wandels von Unternehmen und Business-Modellen kommt dem Requirements Engineering eine zentrale Rolle bei der Steuerung der digitalen Transformation zu. Um dies zu leisten, müssen sich aber auch die angewandten Methoden ändern. Wir bringen Ihnen die aktuellen Requirements Engineering Trends näher!

Aus dem realen oder gedachten Innovationsdruck (“Wir brauchen Innovation!”) heraus entstehen viel zu oft Projekte, die auf halbem Weg versanden und horrende Kosten verursachen. Warum? Weil die Anforderungen nicht konkret und genau genug erhoben wurden. Denn Requirements Engineering ist einer der wichtigsten Faktoren für das Gelingen eines Projektes. Das ist in der IT schon lange akzeptiert. Viele Organisationen haben deshalb große Anstrengungen unternommen, um die richtigen Anforderungen, gut abgestimmt und zur richtigen Zeit in Ihre Projekte einfließen zu lassen. Neben klassischen Methoden wird dabei immer stärker auf agile Vorgehensweisen gesetzt.

Herausforderung digitale Transformation

Wo liegt dann die Herausforderung? Trotz guter methodischer Grundlagen empfinden Projekte, die stark auf die digitale Transformation großer Unternehmen oder Organisationen ausgerichtet sind, die klassischen Methoden des Requirements Engineering oft als unzureichend. Sie werden mitunter als nicht zielführend und oftmals auch als zu langsam und überbordend wahrgenommen. Dabei ist offenbar auch Agilität nicht immer eine ausreichende Antwort: Denn agile Methoden des Requirements Engineering werden mitunter nur in der Entwicklung als relevant wahrgenommen. Oder sie werden als zu oberflächlich und nicht für komplexe Aufgabenstellungen geeignet empfunden. Fazit: Die etablierten Werkzeuge des Requirements Engineering greifen für die Steuerung des digitalen Wandels zu kurz.

„Der Requirements Engineer steht aktuell großen Änderungen gegenüber. Die Vorgehensweisen in diesem Bereich werden grundlegend geändert und teilweise auf den Kopf gestellt werden.“

Karl Schott, CEO Spirit in Projects

Trend: Das bewegliche Ziel

Niemand, der im Bereich des Anforderungsmanagements tätig ist und dessen Unternehmen sich den digitalen Wandel verschrieben hat, wird Projekte so wie bisher durchführen können und trotzdem erfolgreich sein. Der Grund dafür ist, dass sich die Rolle des Requirements Engineers fundamental verändert:

„Requirements Engineers finden sich immer mehr in Projekten zur digitalen Transformation wieder. Diese werden zwar von einer Vision und strategischen Zielen getragen – der einzuschlagende Weg, der tatsächliche Nutzen oder die strategische Technologie zur Umsetzung liegen jedoch nicht konkret vor und müssen erst im Projekt erarbeitet werden.“

Karl Schott, CEO Spirit in Projects

Die Probleme der Branche und die aktuelle Diskussion der Forschung zum Thema ubiquitous requirements engineering spiegelt das wider. Das Thema Anforderungsanalyse bildet in Innovationsprozessen eine Klammer über das gesamte Projekt

Aspekte des ubiquitous requirements engineering

So schwer uns im deutschen die Aussprache von “ubiquitous” auch fällt (die Lösung: yoo-bi-kwuh-tuhs), meint der Begriff die Allgegenwärtigkeit vom Requirements Engineering in Innovationsprojekten. Dabei ergibt sich eine Reihe von Problemstellungen und Veränderungen, die aus unserer Sicht die aktuellen Requirements Engineering Trends ausmachen:

  • offener Abschluss: Analyseprojekte zum Aufbau von technischen Ökosystemen müssen ohne klarem Endekriterium durchgeführt werden.
  • Ganzheitlichkeit: Ganzheitlichkeit rückt in den Fokus, wenn die Lösung ihr Umfeld technisch und organisatorisch so stark beeinflusst, dass für die Analyse keine klaren Grenzen gezogen werden können.
  • grenzenlose Systeme: Systeme überschreiten Grenzen, wenn die Lösung überregional oder global entwickelt und eingesetzt wird und die Beteiligten orts- und zeitbezogen schwer zu greifen sind.
  • Jedermann: Viele Stimmen sprechen mit, wenn durch die digitale Transformation immer stärker auch Stakeholder einbezogen werden, die keine Expertise bei der Entwicklung von Lösungsideen einbringen können.
  • Crowd: Wenn die Benutzer als wichtige Stakeholder nicht mehr erfassbar sind oder nicht einmal mehr klar ist, ob diese reale Personen sind, muss die Erhebung der Anforderungen automatisiert erfolgen.
  • außerhalb der Komfortzone: Wenn die zu lösende Problemstellung nicht nur durch eigenes Wissen und Fähigkeiten analysiert werden kann, sondern Zusammenarbeit über Domain-, Organisations- und Unternehmensgrenzen zur Problemlösung erforderlich ist – dann heißt es “raus aus der Komfortzone”.

Ein wichtiger Trend ist auch der Wandel in der Rolle von Requirements Engineering für das Unternehmen selbst: Es geht nicht mehr “nur” darum Anforderungen zu erheben. Sondern darum, bereits frühzeitig mögliche Technologien und Lösungsansätze einzubringen. Der Trend geht dahin, dass der Requirements Engineering auch noch zusätzliches leistet:

  • Strategieberatung: Da die Unternehmensstrategien immer stärker von der Nutzung von Technologien zur Lösungsfindung und -umsetzung abhängen.
  • Business Enabler: Wenn die Möglichkeit zur Nutzung von Technologien den Erfolg am Markt bestimmt.
  • Orientierung zu disruptiven Technologien: Wenn neue Technologie eingebracht werden, um neue Anforderungen für das Unternehmen überhaupt erst entstehen zu lassen.

Diese Trends zeichnen eine Entwicklung, die wir als “neues Requirements Engineering” bezeichnen. Unsere praktischen Erfahrungen aus Projekten können Sie in Detailartikeln lesen. Hier können Sie übrigens mehr zu unserem Beratungsansatz zum Thema Requirements Management lesen.


Unsere Trainingsangebote zu Innovation & Digitaler Transformation:

Agilität

Ausschreibungen

Digitalisierung

Innovation