Bei der digitalen Transformation müssen Unternehmen bestehende Anwendungen überprüfen und sie den neuen Anforderungen der digitalen Welt anpassen. In meinen vorausgegangenen Blogs habe ich ein Modell für die Analyse des Applikationen-Portfolios und dessen Bedeutung für Organisationen vorgestellt. Nach der Erprobung mit einigen CIOs stellten wir fest, dass es sich nicht nur für das Application Retirement (Abschalten redundanter oder obsoleter Anwendungen) eignet, sondern Unternehmen auch bei der Frage unterstützt, wie sie ihr Application-Portfolio analysieren können, um das Unternehmen digitalfähig zu machen.

Um die Apps den Anforderungen an das digitale Business anzupassen gilt es, jede für sich zu überprüfen und dabei die künftige Infrastruktur, die Anforderungen an die Automatisierung und die Art der Applikations-Transformation für die neue Umgebung zu berücksichtigen. In meinem jüngsten Blog skizzierte ich zwei Entwicklungen, die dabei eine Rolle spielen: Zum einen wird Big Data immer stärker eingesetzt, um Einblicke zu gewinnen und das Marktverhalten besser zu verstehen sowie um Trends zu erkennen. Zum anderen verzeichnet die Automatisierung einen signifikanten Anstieg. Das führt dazu, dass die Entscheidungsfindung nicht mehr länger reaktiv erfolgt, sondern zunehmend proaktiv wird. Beispiel: Die Vielzahl eingebauter Sensoren unterstützt Analysen und Vorhersagen. Ein digitaler Fahrassistent im Auto vermeidet Unfälle, die Analyse von Börsendaten prognostiziert, wie man Vorteile von bestimmten Entwicklungen nutzen kann. In der neuen digitalen Welt sucht sich der Anwender die geeigneten Services. Seine Markentreue schwindet und Unternehmen müssen um ihre Bedeutung kämpfen und sich im Wettbewerb mit Start-ups darauf einstellen, um nicht vom Markt verdrängt zu werden.

Entwicklung von Applications

Was bedeutet das für die Anwendungen? Kernstück eines digitalen Unternehmens sind Prozesse mit digitaler Funktionalität für erstklassige Services, die auf intuitive Weise dem Kunden zur Verfügung gestellt werden. Solche Prozesse bestehen aus einer Reihe von Aktivitäten, die in einer gewissen Reihenfolge ausgeführt werden. Viele davon sind automatisiert und üben ihre Funktion aus. Jede Funktion ist einzeln zu betrachten und zu prüfen, wie sie in den Business-Prozess integriert werden kann. Ein zu berücksichtigender Aspekt ist das Granularitäts-Level der Microservices (mehr dazu lesen Sie hier).

System of Record (SOR)

Zunächst gilt es, das SOR zu betrachten. Das System zeichnet die Transaktionen auf und managt die Masterdaten des Unternehmens. Diese Systeme sind oft veraltet und die Funktionen in den Anwendungen sind nicht auf Endanwender und Kunden ausgelegt. Dennoch sind diese Anwendungen wichtig, weil sie die Arbeitsweise des Unternehmens unterstützen. Manche davon differenzieren das Unternehmen, wir sprechen von Kernanwendungen. Was soll mit diesen Systemen geschehen? Wo sollten sie gehostet werden? Hier hilft die Frage nach den Nutzungsmustern weiter. Anwendungen, die täglich zum Einsatz kommen, können einfach in ihrer gewohnten Umgebung bleiben. Man muss sie nicht in die Cloud oder andere Technologien migrieren. Andere, die nur selten genutzt werden, sollten in die Cloud verschoben werden, damit sie die Infrastruktur nur dann belasten, wenn sie benötigt werden. Kosten lassen sich sparen, wenn man diese abschaltet, sofern sie nicht genutzt werden.

Wenn die Funktion nicht als Kernelement bezeichnet wird, gehört sie zum Kontext. Wenn sie keine Differenzierung bietet, kann man sie als SaaS-Service oder als COTS (commercial off-the-shelf)-Package betreiben.

System of Engagement

Im nächsten Schritt betrachten wir das System of Engagement, darunter wird die Interaktion und Zusammenarbeit zwischen Angestellten, Partner, Lieferanten und Kunden verstanden. Diese wechseln öfters und deren Verhaltensmuster sind in der digitalen Welt weithin ungekannt und unvorhersehbar. Das bedeutet, dass die Anwendungsbereitstellung eine Reihe von Aufgaben bewältigen muss. Angesichts der hohen Bedeutung der Nutzererfahrung im digitalen Unternehmen, müssen Anwendungen in konstanter Qualität funktionieren, unabhängig von der Anzahl der aktiven Nutzer. Das führt direkt zu Cloud-Technologien, die Teile der Anwendungen direkt im Kontakt mit dem Nutzer bedarfsgerecht hoch- bzw. herunterskalieren können. D.h., die Anwendungen müssen Cloud-fähig sein.

Auch hier gilt: Core-Anwendungen sollten in einer vom Unternehmen selbst kontrollierten Umgebung (private Cloud) bleiben. Kontext-Anwendungen gehören in die public Cloud. Zwei Elemente könnten die Anwendung in der public Cloud erschweren: Die Empfindlichkeit der Daten und die Interaktion mit anderen Anwendungen.

System-Innovationen

Bei System-Innovationen handelt es sich um ad-hoc-Entwicklungen für neue Geschäftsmöglichkeiten, die sich aus der Digitalisierungsbewegung ergeben haben. Hier gilt der gleiche Ansatz wie beim System of Engagement: Die Anwendungen benötigen Agilität und Reaktivität einer Cloud, sofern sie für neue, disruptive Geschäftsansätze vorgesehen sind. Kontext-Anwendungen gehören in die public Cloud.

Einordnung jeder einzelnen Anwendung

Jede Anwendung sollte einem Rechteck in der unten stehenden Grafik zugeordnet werden. Das erfordert ein klares Verständnis darüber, was als Kern- und was als Kontext-Anwendung bezeichnet wird. Ist diese Zuordnung erst einmal erfolgt, fällt es leichter, sich mit allen Beteiligten über die Entscheidung zu einigen.

Im meinem nächsten Blog betrachte ich das Thema Automatisierung von Anwendungen und deren Zuordnung in die Grafik.

Den Original-Blog in englischer Sprache lesen Sie hier.

Christian Verstraete, Advisory Services Cloud Application Lead, DXC Technology.

Christian specializes in the use of information technology to support business processes within the enterprise and across eco-systems in Europe and with global clients. His expertise includes consulting, project management, marketing, business and people management. Currently, Christian is a cloud evangelist for DXC, helping to develop a consistent offering crossing organizational boundaries.