CIO 054 - Strategische Ausrichtung der IT-Architektur und Optionen für Software Migrationen - id cubic

Das IT-Architekturmanagement ist ein zentraler Baustein der IT-Strategie und auch ein wichtiger Bestandteil der Tätigkeit als CIO und IT-Manager. Es ist für das Unternehmen von hoher Bedeutung in Zeiten der Digitalisierung eine moderne IT-Architektur zu haben und diese stetig zu optimieren. In dieser Folge geht es um die strategische Ausrichtung Ihrer IT-Landschaft, also Infrastruktur, Hardware, Plattformen und Software, sowie den damit verbundenen Migrations-Szenarien und Optionen für etwaige Software Migrationen.

Podcast: Play in new window | Download (Duration: 20:46 — 17.4MB)

CIO Podcast jetzt bewerten

Folgende Aspekte werden in der Podcast-Folge besprochen:

Was ist IT-Architektur? (00:30)
Gründe für die strategische Ausrichtung der IT-Architektur (02:00)
Auswirkungen ohne aktives und strategisches IT-Architekturmanagement (04:30)
Möglichkeiten für CIOs und IT-Manager die IT-Architektur zu steuern und zu optimieren (07:30)
IT-Architekturtransformation – Greenfield- oder Brownfield-Ansatz? (10:30)
Herstellerunabhängigkeit in den IT-Architekturleitlinien und der IT-Strategie (12:00)
Komplexität managen und reduzieren in der IT-Architektur (17:00)

Viel Spaß beim Hören des Podcasts. Ich freue mich, wenn Sie ein kurzes Feedback hinterlassen, wie Ihnen die Folge gefallen hat und Sie mit diskutieren.

Was ist IT-Architektur?

In der heutigen Folge geht es um die strategische Ausrichtung der IT-Architektur und Optionen für die vielleicht dann folgenden Softwaremigrationen, die Sie dann identifiziert haben.

Zunächst einmal möchte ich aber auf die Begrifflichkeit eingehen. Was ist eigentlich IT-Architektur? Das ist so ein Überbegriff, können Sie sich vorstellen wie beim klassischen Hausbau, ist ja auch Architektur, das heißt, Sie planen die verschiedenen Komponenten eines Hauses. #00:01:02.4#

IT-Architektur ist im Grunde das Gleiche gemünzt auf IT. Sie planen also die verschiedenen Komponenten der IT, also in dem Fall Infrastruktur, Hardware, Software, Plattformen, die Sie im Einsatz haben. Das heißt also, dieses ganze Gefüge. Häufig wird das auch als IT-Bebauungsplanung tituliert. Wie gesagt, Begrifflichkeit ist egal wie Sie das nennen, aber es geht eigentlich um dieses Themenfeld, um dieses Themenspektrum.

Warum beschäftigen wir uns da diese Folge mit? Ist ganz einfach. Ich sehe das immer wieder, dass gerade dieses Thema zwar ganz, ganz häufig ein Schmerzpunkt ist in der IT, aber das auch ganz häufig nicht angegangen wird, weil das eben so ein großer Brocken ist. So ein System hat man nicht mal eben von rechts nach links gedreht. Und das irgendwie über die Jahre zu planen und aufzubauen, ist ganz schön viel Arbeit. Aber nichtsdestotrotz aus meiner Sicht ein wichtiger Schritt, vor allen Dingen, wenn Sie sich in der IT-Strategiephase damit beschäftigen, wie soll denn Ihre IT-Strategie für die nächste Jahre aussehen, dann ist das ein ganz wichtiger Block, auf den Sie schauen sollten. #00:02:05.9#

Gründe für die strategische Ausrichtung der IT-Architektur

Auslöser für IT-Architekturüberlegungen

Ja, warum macht es also Sinn sich mit IT-Architektur strategisch zu beschäftigen? Einmal ein ganz wichtiger Punkt, Software- und Hardware-Lebenszyklen, die verschnellern sich. Also was vielleicht an Software früher 5 bis 10 Jahre gehalten hat, hat jetzt halt noch eine geringere Halbwertszeit, weil einfach so schnell teilweise neue Versionen und Updates auf den Markt kommen von den Herstellern, dass sich das halt viel, viel schneller weiterentwickelt.

Ein Punkt ist sicherlich da auch die Entwicklung in Richtung Cloud, da hat der Hersteller ja direkt die Möglichkeit, auch neue Updates einfach direkt den Kunden zur Verfügung zu stellen. Und häufig ist es halt auch so, dass Neuentwicklungen nötig sind. Das eine war, wie gesagt, die Cloud-Themen, das andere sind aber auch Herstellervorgaben, dass zum Beispiel Software aus der Wartung läuft, dass Sie da keine Updates mehr bekommen, im Zweifelsfall sich damit eben Sicherheitsrisiken einfangen. #00:02:57.9#

Das heißt, solche Sachen sind halt Auslöser.

Geänderte Anforderungen machen andere IT-Architekturen notwendig

Das andere ist vielleicht auch, geänderte Anforderungen aus den Fachbereichen und aus dem Business. Das heißt, die sagen, naja, für diese und jene Tätigkeit brauchen wir vielleicht auch Software zukünftig strategisch, die wir heute gar nicht haben. Das kann auch durchaus ein Grund sein, warum es Sinn macht sich damit strategisch zu beschäftigen.

Oder Sie haben zum Beispiel heute vielleicht neue Möglichkeiten durch Technologien, die es vorher noch gar nicht gab oder deren Einsatz vorher sehr, sehr kostenintensiv war, wo man dann vielleicht gesagt hat, ah, das rechnet sich nicht im Kosten-Nutzen-Verhältnis, sieht aber heute vielleicht schon ganz anders aus.

Zeithorizont für den IT-Architektur-Umbau

Und was ich anfangs gesagt habe, ist, es ist natürlich eine längere Transformation. Das heißt, es ist jetzt nichts, was Sie von heute auf morgen ändern können. Deswegen ist es aus meiner Sicht umso wichtiger, dieses ganze Thema strategisch anzugehen, auch zu planen, was macht Sinn, was will ich eigentlich, will ich die Komplexität verringern? All diese Faktoren sollten aus meiner Sicht strategisch vorbereitet und auch geplant werden. #00:04:01.5#

Also ist aus meiner Sicht ein ganz wichtiger Baustein auch der IT-Strategie. Die Bausteine der IT-Strategie habe ich mal in Folge 12 für Sie zusammengefasst, da können Sie gerne mal reinhören, falls Sie die Folge noch nicht kennen. Das also sind einige Gründe, sind sicherlich nicht abschließend Gründe, aber warum man sich mit IT-Strategie und IT-Architektur im strategischen Sinne beschäftigen sollte aus meiner Sicht.

Auswirkungen ohne aktives und strategisches IT-Architekturmanagement

Jetzt könnte man ja sagen, naja gut, brauche ich mich ja nicht mit beschäftigen. Also habe ich die letzten Jahre nicht gemacht, brauche ich jetzt auch nicht machen.

Auswirkung 1 ohne IT-Architekturmanagement: Veraltete Systeme

Was passiert, wenn Sie sich nicht mit IT-Architektur beschäftigen und Sie das mehr oder weniger sich selbst überlassen? Sie haben im Zweifelsfall vielleicht veraltete Systeme, vielleicht haben Sie die auch, weil Sie das von irgendwie einem Vorgänger übernommen haben. Sie sind jetzt damit beauftragt wurden, die IT so ein bisschen umzukrempeln, auf Vordermann zu bringen. Sie haben vielleicht noch Systeme wie Mainframe-Großrechner, ganz alte ERP-Systeme, Eigenprogrammierungen mit was weiß ich was für Programmiersprachen. #00:05:03.2#

Mir fällt jetzt spontan COBOL ein oder ganz, ganz alte Sachen, die Sie noch irgendwo haben, Assembler oder was weiß ich, was da vielleicht irgendwo noch schlummert bei Ihnen im Server-Raum.

Auswirkung 2 ohne IT-Architekturmanagement: Attraktivität für IT-Fachkräfte sinkt

Dann ist die große Frage, wo bekommen Sie denn zukünftig die Fachkräfte her? Das sind alles so die Programmiersprachen, wo die Leute jetzt so auf kurz oder lang tatsächlich dann mal irgendwann auch in Rente gehen, und die jüngeren Leute, ob die das noch an der Uni gelernt haben, das wage ich mal zu bezweifeln in vielen Fällen.

Das heißt, es wird relativ schwer für solche alten Systeme dann tatsächlich Mitarbeiter zu bekommen. Das ist dann so eine Sache, habe ich auch schon erlebt, wo dann tatsächlich Mitarbeiter wieder aus der Rente zurückgerufen werden, zumindest für Spezialthemen, um dann gewisse Sachen wieder zu betreiben oder zumindest irgendwo ein Problemchen, was aufgetreten ist, zu beheben. Das ist ja auch nichts, was Sie auf Dauer wollen. Also insofern macht das durchaus Sinn, sich damit zu beschäftigen. #00:05:58.6#

Auswirkung 3 ohne IT-Architekturmanagement: Moderne Systeme können nicht oder nicht gut angebunden werden

Ein ganz großer Faktor aus meiner Sicht, warum auch das wichtig ist, sich damit zu beschäftigen oder was passiert, wenn Sie sich nicht damit beschäftigen, ist, neue Systeme, die Sie vielleicht einführen wollen, die können gar nicht angedockt werden oder Sie müssen erst mal IT-Zwischenschichten einführen, wo sich einfach bestimmte Systeme koppeln können, damit Sie eben diese alten Systeme noch an moderne, internetfähige Software anbinden können.

Sie haben dann natürlich mit dieser Zwischenlösung oder Zwischenschicht, die Sie schaffen, auch verschieden schnelle Update-Zyklen. Also das heißt jetzt zum Beispiel, Ihr altes System, was Sie vielleicht einfach auch noch gut und stabil betreiben können, das können Sie aber jetzt nicht alle 2 Wochen updaten. Wohingegen Sie zum Beispiel vielleicht ein CRM-System, was webbasiert ist, super schnell updaten können, oder irgendwie eine andere Lösung, die halt eben auf einer Web-Schicht vorne vorgelagert ist, die ist halt viel, viel flexibler.

Was ich eingangs sagte, auch die Cloud-Lösungen, Sie haben dann zunehmend die Thematik, dass Sie an der ein oder anderen Stelle schon auf Cloud-Lösungen setzen, andersrum aber ganz alte Backend-Systeme noch irgendwo haben. #00:07:09.0#

Die müssen ja auch schnittstellenmäßig angepasst werden. Also wie kriegt man das hin, dass eben, wenn der Hersteller der Cloud-Lösung Updates in den Markt bringt, dass Sie da nicht ständig Ihre Schnittstellen aktualisieren müssen.

Alles wahnsinnig spannende Themen und wichtige Themen, die es sich auch lohnt, da strategisch zu durchdenken.

Möglichkeiten für CIOs und IT-Manager die IT-Architektur zu steuern und zu optimieren

Jetzt nehme wir an, Sie sagen, jawoll, ich will das strategisch ausrichten. Habe ich vielleicht bisher nicht gemacht oder habe ich vielleicht bisher gemacht, aber ich sehe da noch diese oder jene Tätigkeit, wie kann ich das denn angehen? Dazu mag ich Ihnen einen kurzen Überblick, ein paar Anregungen, ein paar Impulse geben, dass Sie einfach darüber nachdenken können, wie Sie das für sich ausrichten.

1. Schritt: Bestandsaufnahme der aktuellen IT-Architektur

1. Schritt ist immer, was haben Sie eigentlich im Unternehmen an IT-Architektur? Wenn Sie das schon alles kennen, ist das total klasse. Viele müssen da auch erst mal auf die Suche gehen und sagen, ja, was haben wir eigentlich alles für Komponenten? #00:08:00.2#

2. Schritt: IT-Architektur-Komponenten clustern

Dann die Komponenten mal zu clustern, zu schauen, was sind die wesentlichen Elemente Ihrer IT-Architektur?

Wo läuft eigentlich das Kerngeschäft drüber, was sind so die wesentlichen Punkte, die wir eigentlich betreuen? Und dann mal noch diese ganzen Schatten-ITs, Insellösungen und was man sonst noch so alles in seinem Architekturportfolio hat, das einfach alles erst mal aufnehmen.

3. Schritt: IT-Architektur bewerten

Dann bewerten, wie passt das noch zu Ihrem Geschäftsmodell und auch zu Ihrem zukünftigen Geschäftsmodell, und, wie zukunftsfähig ist das Ganze? Ist das mit einer IT-Architektur kompatibel, die Sie zukünftig planen? Hat das vielleicht entsprechende Schnittstellen-Logiken? Ist das in der entsprechenden Programmiersprache? Haben sie das Know-how im Haus? Können Sie das Know-how zukaufen? Und so weiter.

Also ist diese Lösung zukunftsfähig oder ist das was, wo Sie zukünftig Probleme bekommen?

4. Schritt: IT-Architekturziele festlegen

Dann wichtig, IT-Architekturziele festlegen. Was ist das eigentlich, was Sie kurzfristig und langfristig in der IT-Architektur erreichen wollen? #00:08:59.5#

Wie sieht dann zum Beispiel auch so ein Zielbild aus, so eine Ziel-IT-Architektur? Einfach schon mal aufzeichnen, skizzieren.

5. Schritt: IT-Architektur Leitlinien erarbeiten / Fit-Gap Fahrplan

Und auch ganz wichtig, der Weg dahin, dass Sie zu diesem Ziel kommen, das habe ich ja gesagt, der ist nicht von heute auf morgen, deswegen ist ganz wichtig, dass Sie so strategische Leitlinien erarbeiten.

Also wonach suchen Sie Software aus, wenn Sie neue aussuchen? Was muss diese Software für Kriterien erfüllen, damit die zu Ihrer Strategie passt? Das sind so ein paar Sachen, die können Sie auf jeden Fall gut vorbereiten, strategisch auch vorbereiten und dann in die Organisation bringen.

Nutzen für Ihre IT-Organisation durch aktives IT-Architekturmanagement

Den Nutzen, den Sie davon haben, ist aus meiner Sicht eben, wenn Sie dieses neue IT-Architektur-Zielbild oder diese Zielbebauungsplanung, wie man das häufig auch nennt, haben Sie die Möglichkeit, eben agiler vorzugehen mit bestimmten Komponenten. Sie haben natürlich dann entsprechend auch als Ziel eine moderne Architektur, Sie haben schnellere Entwicklungs- und Anpassungsmöglichkeiten in der Regel. #00:09:59.0#

Risiken für Ihre IT-Organisation wenn Sie jetzt aktives IT-Architekturmanagement beginnen

Risiken haben Sie aber natürlich auch, das muss man auch ganz ehrlich sagen.

Sie können natürlich bei Systemen, die Sie aktuell im Einsatz haben, zum Beispiel ausgelaufene Systeme haben, die aus der Herstellerwartung rausgefallen sind, Sie können, was ich eben sagte, Fachkräftemangel schon in alten Programmiersprachen haben, und dann wird das ganze Thema knifflig. Weil wenn Sie ein altes System migrieren wollen, wo Sie eigentlich schon gar nicht mehr wissen, na, was haben die da eigentlich reinprogrammiert? So klassischerweise bei Individualsoftware, die mal irgendwann in den 70er, 80er Jahren programmiert wurde oder 90er vielleicht noch, und die Leute sind schon gar nicht mehr verfügbar.

Das heißt, Sie müssen erst mal diesen Code analysieren und gucken, was machen die da eigentlich? Wenn sie jetzt zum Beispiel keine Prozessbeschreibung oder sowas haben. Wenn das alles gut dokumentiert ist, ist das kein Thema.

IT-Architekturtransformation – Greenfield- oder Brownfield-Ansatz?

Die Praxis sieht leider häufig anders aus, dass man da erst mal so ein bisschen forschen muss. Da ist halt häufig auch die Frage, kann ich mir das leisten als Unternehmen zu sagen, nee, ich guck da gar nicht mehr rein, ich bau das komplett neu auf [Greenfield-Approach]? #00:11:00.3# Das machen einige Firmen.

Das andere ist natürlich, dass man versucht, was ist da eigentlich erst mal gebaut worden? Ist da vielleicht noch irgendwas total Unternehmenskritisches drin, über das wir vielleicht alle gar nicht nachdenken? Das heißt, da müssen Sie selber so ein bisschen auch mit Ihren Kollegen abwägen, wie wertvoll ist das jetzt eigentlich, so einen Code-Review da zu machen oder da irgendwie Leute hinzuschicken, zu schauen, was da eigentlich in der Software drin ist?

Das ist in den meisten Fällen halt wahnsinnig aufwendig und teuer, und da muss man überlegen, ob das ein einem Kosten-Nutzen-Verhältnis steht oder ob Sie das eben, wie man so schön sagt, im Greenfield Approach, also auf der grünen Wiese dann neu aufbauen. Das ist aber wie gesagt, total individuell. Sollte man aber dann überlegen.

Es kann durchaus Sinn machen, das dann auf das zukünftige Geschäftsmodell auszurichten, weil häufig sind natürlich solche Systeme über die Jahre gewachsen und haben natürlich auch teilweise Programmierroutinen drin, die sind mal irgendwann nützlich gewesen, aber ob die heute noch eingesetzt werden oder gebraucht werden, ist in manchen Fällen dann vielleicht gar nicht mehr so. #00:12:03.6#

Herstellerunabhängigkeit in den IT-Architekurleitlinien und der IT-Strategie

Vorsicht möchte ich an der Stelle auch sagen, wo wir jetzt bei IT-Strategie und IT-Architektur sind, viele schreiben an der Stelle schon in der IT-Architektur ihre Wunschhersteller fest. Also wir möchten dies und jenes IT-Architekturmäßig umsetzen und mit Hersteller XY.

Da warne ich immer so ein bisschen vor, das sehe ich leider allzu häufig. Oder andere Sachen wie, wir haben jetzt zum Beispiel Software vom Hersteller XY, die bringen eine neue Lösung raus, deswegen kaufen wir die, deswegen schreiben wir das in die Strategie. So oder so ähnlich hört sich das dann an.

Da frage ich mich immer und frage ich auch die CIOs und IT-Manager dann immer, wer macht denn Ihre IT-Architektur-Strategie? Sie oder der jeweilige Hersteller? Das ist mir immer ganz wichtig, es ist natürlich klar, dass die Hersteller ihre eigene Agenda haben, ihre eigene Roadmap haben, das ist auch gut und richtig, aber Sie müssen ja für sich, für Ihr Unternehmen, für das Sie tätig sind, prüfen, ob das auch zu Ihrer Strategie passt und zu ihrer Ausrichtung passt. #00:13:01.1#

Deswegen immer meine Empfehlung, lassen Sie sich da nicht treiben vom Hersteller, handeln Sie selber proaktiv und überdenken Sie die Konsequenzen bei der jeweiligen Option. Ich rate immer die Strategie, herstellerunabhängig zu verfassen, und da auch wirklich zu sagen, wir wollen uns auf diese und jene Themen fokussieren, die kann man ja auch durchaus ohne Herstellernamen formulieren, und das Thema im Nachgang in der Roadmap dann konkret zu machen, dann konkret zu schauen, welche Software passt konkret am besten, was sind die Lösungsoptionen, die ich habe und welche möchte ich auswählen?

Also an der Stelle rate ich immer dazu, gehen Sie den Schritt zurück, schauen Sie sich das große Ganze noch mal aus der Vogelperspektive an. Was sind die Optionen, die für Sie wichtig sind als Unternehmen und die auch Ihrem Unternehmen Nutzen bringen? Das ist ganz, ganz, ganz wichtig. Der Hersteller hat ja seine eigene Zielrichtung. Wenn die mit Ihrer übereinpasst, wunderbar, wenn das nicht so ist, noch mal überlegen, ob es da nicht was Besseres gibt. #00:13:58.8#

Beispiel: Standardsoftware-Upgrade

Das mal am Beispiel festgemacht. Nehmen wir mal an, Sie identifizieren, dass Sie eine bestehende Lösung haben, größere Standardsoftware oder sowas, die müssen Sie jetzt im größeren Stil upgraden. So, und Sie haben jetzt festgestellt, diese Lösung, die läuft zum Beispiel aus dem Support raus, was ich eben sagte, und da gibt es jetzt verschiedene Optionen.

Option 1: Die erste wäre natürlich, die eben schon auf der Hand lag. Sie machen erst mal nichts, ruhen sich aus und sagen, naja, das wird schon nicht so schlimm, die werden den Support schon noch irgendwie erweitern, da werde ich vielleicht irgendwie, ist dann vielleicht was teurer, aber werde ich schon irgendwie noch ein Support-Package kriegen. Kann man machen, aber Sie verschieben das Problem nur nach hinten. Also das löst sich nicht von alleine.

Wenn Sie nächstes Jahr in Rente gehen, geht das vielleicht, aber sonst, schwierig. Also insofern rate ich immer nicht zu, muss ich ganz ehrlich sagen. Das verschiebt Probleme nur, hilft Ihnen aber nicht.

Option 2: Sie kaufen eine neue Software, führen Sie ein, also Sie kaufen die neue Softwareoption vom Hersteller. Da sage ich immer, das kann man alles machen, wenn das zu Ihrer IT-Strategie passt. #00:15:01.8#

Also wenn Sie da sagen, wir haben das geprüft, das passt, wir können das Upgrade machen oder wir können diese großen Aufwände, die dann vielleicht mit der einen oder anderen Standardsoftware-Umstellung einhergehen, die können wir stemmen und das passt auch zu uns, wunderbar. Wenn es auch zum zukünftigen Geschäftsmodell passt, umso besser.

Die 3. Option: Das ist durchaus ein gängiger Punkt, wenn man eine große IT-Investition macht, dass man erstmal sagt, ich schau mir die Lösungsoptionen, die ich am Markt habe, an und evaluiere dann die Optionen. Ist ja nicht unbedingt der einzige Hersteller, den Sie da haben.

Vielleicht ist das zwar einer der großen, aber die anderen haben ja vielleicht auch noch Software, die ganz geschickt ist. Da sage ich immer, machen Sie eine unabhängige Auswahl, gucken Sie zum Status quo, zum Stand heute, was das Richtige für Sie ist. Viele sagen dann immer, ja, aber das haben wir doch damals schon ausgesucht. Es ist ja immer zu jedem Zeitpunkt vielleicht auch eine andere Entscheidung richtig. Also wenn Sie was vor 5 oder 10 Jahren ausgesucht haben, dann war das mit Sicherheit vor 5 oder 10 Jahren richtig. #00:16:02.8#

Wenn Sie sagen, das hat uns in der Zeit gute Dienste getan, wunderbar. Dann war es zu der Zeit die richtige Entscheidung. Aber die muss ja nicht notwendigerweise heute auch noch richtig sein.

Die Sachen haben sich geändert, viele, viele Gegebenheiten, viele Marktumstände haben sich geändert. Das heißt, man muss ja dann, wenn man das jetzt eh noch mal neu anfasst das Thema und eh noch mal neu bewertet, dann kann man auch schauen, ist das richtig, passt das zu uns, wie macht man sowas?

Da kann ich vielleicht auch noch mal auf die Folge 35 verweisen, das Thema Softwareauswahl habe ich da besprochen. Einfach mal reinhören, wenn Sie das Thema interessiert. Ich kann nur den Tipp mitgeben, planen Sie die Aktivitäten auch in Ihrer strategischen Roadmap ein. Also wenn Sie die IT-Strategie formuliert haben, planen Sie gerade das Thema IT-Architektur, weil das eben so ein Langläufer-Thema ist, auch in der strategischen Roadmap rein. Wann wollen Sie zum Beispiel ein Konzept erstellt haben? Wann wollen Sie eine Entscheidung getroffen haben, über welche Software Sie jetzt weiterverfahren? Und wie soll das Ganze von statten gehen? #00:17:02.8#

Komplexität managen und reduzieren in der IT-Architektur

Also das kann ich wirklich nur empfehlen. Es kann ja durchaus sein, dass Sie feststellen oder wenn Sie dann mal die ganze IT-Architektur aufnehmen und sammeln, was Sie da alles so haben, dass Sie feststellen, das ist wahnsinnig komplex geworden über die Jahre.

Das ist bei vielen Firmen tatsächlich so, das ist über die Jahre gewachsen, es ist mittlerweile ein wahnsinniges Sammelsurium an Lösungen, die ist extrem komplex geworden. Manche Firmen stellen sich halt auch zum Ziel auf, Sie wollen das Ganze schlanker aufstellen, Sie wollen das Ganze entsprechend in der Komplexität senken und eben auch entsprechend zukunftsfähiger machen.

Was halt in der Vergangenheit häufig war, man hat diese monolithischen Systeme, also ein ganz großes System, und man sieht heute eher, dass die Firmen und Anbieter auch dazu übergehen eher, modulare Systeme zu nehmen, also für verschiedene Bausteine wieder eine eigene kleine Software-Lösung, die sich aber super gut konnektieren lässt, also verbinden lässt zu anderen Softwarelösungen über Schnittstellen oder Plattformansätze. #00:18:02.5#

Das heißt, auch da kann man eben noch mal schauen, was passt für Ihr Unternehmen am besten?

Schauen Sie da auch am besten noch da drauf, dass Sie nicht zusätzlich noch Komplexität schaffen, indem Sie noch weitere Insellösungen irgendwo hinzufügen. Da habe ich auch noch mal eine Folge zu gemacht, weil das mal eine Hörerfrage war, wie kann man die IT-Strategie umsetzen, ohne weitere Insellösungen zu schaffen? Ist die Folge 28. Das ist halt auch ein wichtiger Punkt, dass Sie nicht, während Sie quasi Ihre ganze IT-Architektur versuchen zu transformieren, wieder weitere naja so Übergangslösungen zu schaffen.

Das ist ja, nichts ist beständiger als die beste Übergangslösung. Da muss man wirklich ein bisschen mit Augenmaß dran gehen an diese Sache. Also insofern hören Sie sich da die Folge gerne noch mal an. Wenn Sie Sachen neu eingeführt haben, schalten Sie auch alte Systeme ab, wenn sie nicht mehr gebraucht werden. #00:18:57.6#

Manchmal gibt’s halt Aufbewahrungspflichten, ganz klar, dann archiviert man das System, speichert alles entsprechend so ab wie man es denn auch vorhalten muss. Das ist natürlich keine Frage. Aber wenn das wirklich operativ nicht mehr benötigt wird das System, schalten Sie es ab. Man sieht das leider allzu oft, dass die Systeme dann noch Jahre weiterlaufen. Der ein oder andere benutzt die dann tatsächlich auch noch. Also insofern da auch entsprechend konsequent.

Wenn man wirklich die IT-Architektur nach vorne entwickeln will, müssen Sie auch an der einen oder anderen Schnittstelle alte Zöpfe abschneiden, wie das so schön heißt. Das ist wirklich auch ein Thema, was man auch dann überlegen sollte. Wann macht man für sich diesen Supporttermin? Wann setzen Sie den intern für ihre Firma? Dann sagen Sie, okay, ab dann wird diese Software oder diese Komponente, manchmal ist es ja auch Betriebssystem, nicht mehr eingesetzt. Wann darf es auf keinen Rechner mehr drauf sein?

Ich hoffe, ich konnte Ihnen ein paar Anregungen geben zu dem Thema. Wie sehen Sie das ganze? Planen Sie Ihre IT-Architektur schon strategisch? Ich freue mich da wie immer über Feedback und sag, auf Wiederhören. #00:20:00.4#

Weiterführende Links

Ihr Feedback

Wir freuen uns über eine Bewertung des CIO Podcasts bei Apple Podcasts und den anderen Portalen!
Fünf Sterne stehen für „gefällt mir sehr gut“. Herzlichen Dank!

Wie gefällt Ihnen diese Folge des CIO Podcasts? Senden Sie Ihr Feedback, Anregungen und Wünsche einfach über das Kontaktformular direkt an die Redaktion des CIO Podcasts (nicht öffentlich):

[contact-form-7 id=“189″ title=“CIO Podcast“]

Weitere Podcast Folgen finden Sie hier.