EAM#36: Internationales Geschäft - Warum eine globale Architektur lokal funktionieren muss

Shownotes

Internationales Geschäft verändert die Gewichtung von Architekturentscheidungen. Gemeinsame Business Capabilities treffen auf regionale Vertriebsmodelle, unterschiedliche Datenanforderungen und lokale Betriebsbedingungen.

In dieser Folge betrachte ich meinen EAM-Ansatz für internationale Landschaften: von den geschäftlichen Anforderungen über Daten und Anwendungen bis zu Betriebsmodellen, Governance und TCO. Im Mittelpunkt steht die bewusste Entscheidung, welche Gemeinsamkeiten das Unternehmen braucht und welche regionalen Unterschiede sinnvoll bleiben.

Verweise auf frühere Folgen:

  • EAM#34: Produzierende Industrie – Warum funktioniert Enterprise Architecture hier anders?
  • EAM#35: Zulieferer als Architekturabhängigkeit – Wo endet eigentlich EAM?

Kernfrage der Folge: Wie ermöglicht eine globale Zielarchitektur regionale Unterschiede, ohne die gemeinsame Steuerbarkeit zu verlieren?

Der deutschsprachige EAM Podcast, überall wo es Podcast gibt.

Freue mich auf Dein Feedback, gerne jederzeit direkt auf https://eam.podigee.io/ oder direkt www.linkedin.com/in/david-hohl

David Hohl

Möge die Enterprise Architecture mit dir sein.

Transkript anzeigen

00:00:04: Architektur entscheidet über Komplexität, über Kosten und Übersteuerbarkeit.

00:00:09: Ich bin David Hohl und heiße Dich herzlich willkommen.

00:00:12: bei Enterprisearchitektura wirkt der Podcast zu ERM!

00:00:20: Servus grüßt ich und herzlich Willkommen zur neuen Folge.

00:00:25: In den letzten beiden Folgen waren wir vor allem in produzierenden Unternehmen unterwegs.

00:00:31: In der thirty vier ging es um Produkte Werke und unterschiedliche Lebenszykler in der letzten, also in der fünfundreißigsten um die Zulieferer und die Abhängigkeiten außerhalb des eigenen Unternehmens.

00:00:46: Für heute hatte ich eigentlich was anderes geplant und zwar wollte ich über Gesundheitswesen reden oder beziehungsweise Ich wollte ein Beispiel Krankenhaus aufbauen.

00:00:56: bei der Vorbereitung und nach eineinhalb Stunden mehrfachen Aufnahme Und von der Vorbreitung will ich jetzt gar nicht reden kann ich schnell zum Entschluss.

00:01:10: Da fehlt mir einfach die praktische Tiefe und die Erfahrung dahinter, vor allem um diese Branche richtig einordnen zu können und sie nicht da unters Patient zu sehen.

00:01:21: Deshalb möchte ich dieses Thema später oder irgendwann anders mal mit entsprechender fachlich Unterstützung aufgreifen.

00:01:27: und vielleicht bist grad du ein Enterprise-Architekt im Krankenhausumfeld und würdest darauf Darin mit Arbeit und mir zusammen diese Folge machen, würde ich natürlich an der Stelle wünschenswert finden.

00:01:40: Somit parke ich das Ganze.

00:01:42: Heute schauen wir etwas an, mit dem ich mich ein bisschen wohler fühle... ...und mit Gesundheitswesen an dieser Stelle überhaupt nichts zum Ton hat!

00:01:49: Wir schauen uns heute an wie sich Unternehmen im internationalen Umfeld agieren wenn sie expandieren möchten.

00:02:00: Denn sobald ein Unternehmen über mehrere Länder hinweg tätig ist, verändert sich auch meine Arbeit als Enterprise-Architekt.

00:02:06: Wobei ich auch das bei der Grundplanung eigentlich schon mit berücksichtige Gewächter von ausgehöhe.

00:02:11: Wie auch immer dabei habe ich halt immer meine Standardmethoden und also Entitäten mit mir, meine Capabilitys, meine Daten oder Data, meine Application und vor allem die Technologien.

00:02:23: aber ich muss zusätzlich verstehen welche Teile davon gemeinsam funktionieren können und welche regionale unterschiedliche funktionieren müssen.

00:02:31: Genau dort liegt für mich die große Spannung vergraben, ein Unternehmen möchte global auch zusammenarbeiten natürlich um seine Märkte funktioniert aber nicht überall gleich und deshalb beginnt internationale Architektur für mich schon deutlich vor der Frage nach dem Hosting.

00:02:55: Kapitel eins das Geschäft gibt die Unterschiede vor.

00:03:01: gerade regionale Architekturen Da entsteht aus Bedingungen, aus dem Bedingung des Geschäfts natürlich.

00:03:11: Also mein erster Blick auf der geht zuerst da natürlich nicht in den Applikationen sondern geht Richtung Strategie und die Fähigkeiten, die das Unternehmen in seinen Märkten benötigt oder vor allem was wir jetzt aktuell schon einsetzen.

00:03:28: Ein gemeinsames Unternehmensziel bedeutet noch nicht, dass es überall auf derselben Weise erreicht wird.

00:03:36: Gerade wenn's um Vertrieb geht oder gerade Grundbetreuung, Service und Zusammenarbeit.

00:03:41: Und mit Partnern können regionalen wirklich total unterschiedlich organisiert sein.

00:03:46: Damit verändert sich die beteiligten Rollen und vor allem die Abläufe unter der Datenfluss, der benötigt wird.

00:03:55: Diese Unterschiede muss ich natürlich zuerst verstehen Bevor ich Anwendungen für einheitliche oder beziehungsweise harmonisieren kann, oder eine globale Plattform empfehle.

00:04:07: Eine Capability-Map hilft mir dabei und die gemeinsame fachliche Grundlage sichtbar zu machen.

00:04:13: Anschließend kann ich betrachten wie diese Fähigkeiten regional ausgeprägt sind und welche Unterstützung sie tatsächlich benötigen.

00:04:22: Und ja, Capability Maps sind essentiell und wichtig!

00:04:29: Darauf verzichten sehr viele Unternehmen einfach von Haus aus, aber ohne die wird es keinen Wachstum geben oder übrigens kein stabiler Enterprise Architektur.

00:04:41: Wenn wir uns mal ein Beispiel nochmal weiter tief erlegen mit einem Direktvertrieb anschauen und zusätzlich machen wir noch ein bisschen komplizierter jetzt haben wir noch einen Händler Vertrieb oben drauf und die unterstützen beide natürlich den Verkauf.

00:04:57: Diese Händlerzuordnung und diese Preisverantwortung, vor allem diese Kundenbeziehungen und Auftragsabwicklung können unterschiedlich aussehen.

00:05:05: Diese Unterschiede wirken sich v.a.

00:05:07: als erstes nicht immer gleich auf die Anwendung rumhacken, das sind genau richtig die Data Entities oder Daten dann in die Integration und dann vor allem in den Anwendungen.

00:05:22: Somit möchte ich zuerst einfach verstehen welche Unterschiede geschäftlich notwendig sind Und daraus ergibt sich welche Gemeinsamkeiten ich architektonisch nutzen kann.

00:05:32: Wir reden dann natürlich immer von einem Master, oder bspw.

00:05:35: von einer Master-Architektur und die breche ich dann runter Wenn ich zu früh eine technische Einheitlichkeit vorgebe Dann verschiebe ich die ungelösten fachlichen Unterschiede häufig in manueller Arbeit oder Sonderlösungen.

00:05:52: Sobald ich diese regionale Ausprägung verstanden habe lande ich ziemlich schnell bei einem zentralen Thema.

00:06:00: Das sind die Daten.

00:06:05: Kapitel zwei, gemeinsame Daten brauchen einen regionalen Kontext.

00:06:11: eine gemeinsame fachliche Definition muss auch ihre regionale Gültigkeit ausdrücken können.

00:06:18: nebenbei dieses Thema Regionalisierung bei Daten.

00:06:22: das ist nicht so einfach denn oft werden Daten Äh, so gesehen.

00:06:28: genauso habe ich auch bei der Serum die Datenentitäten.

00:06:33: Bei der Folge siebzehn und glaube achtzehn haben vor allem beschrieben mit den Level eins Entitäten.

00:06:42: Dennoch bei der Regionalisierung muss man das ein bisschen vorsichtig runterbrechen.

00:06:47: Wie auch immer ähm... Die Datenentiteten bilden auch internationale wichtige gemeinsame Grundlage, das darf man nie vergessen!

00:06:55: Und vor allem Wenn wir uns halt die Produkte und Kunden, die Jungs Aktion oder auch die Aufträge anschauen.

00:07:04: Die müssen fachlich einfach verständlich sein.

00:07:07: Halt gerade wenn man in mehreren Regionen damit arbeitet.

00:07:11: Kompliziert wird es.

00:07:12: nebenbei, wenn noch diese Themen international geschert werden dann haben wir ein anderes Thema.

00:07:18: das lassen wir mal aussen vor.

00:07:21: aber gleichzeitig besitzt nicht jede Information überall dieselbe Gültigkeit.

00:07:25: Grad Produktionsintitäten und Beschreibungen, die sind halt pro Markt unterschiedlich.

00:07:32: Die Marktverfügbarkeit und Preis sind auch unterschiedlich.

00:07:36: Und was noch unterschiedlich ist, ist die Verantwortlichkeiten Wenn man sich auch die Produktion zu Ketten anschaut, woher die Informationen kommen.

00:07:49: Auch Sprachen und Regionen muss man strikt auseinanderhalten.

00:07:56: Eine englische Beschreibung sagt noch nichts darüber aus, in welchen Markt ein Produkt verfügbar ist oder welche Vertrieb dazu dafür zuständig ist.

00:08:06: Deshalb betrachte ich dabei globale Informationen und regionale Ergänzung gemeinsam.

00:08:13: Das ist manchmal nicht ganz einfach das auch zu vermitteln um ehrlich zu sein.

00:08:19: Dabei muss man nämlich Erkennbar bleiben, wo eine Information entsteht und wo sie verändert werden darf.

00:08:28: Und für welchen Kontextes gilt?

00:08:30: Einmal wieder ähnliches Verhalten wie man es glaube ich bei der Folge... Jetzt müssen wir mal nachschauen.

00:08:38: Genau!

00:08:39: Zweiunddreißig haben auch über EI Kontext gesprochen.

00:08:43: Ich finde das passt doch gar recht gut rein, weil dasselbe Verhalten haben wir dort auch Wenn wir uns kurz das Beispiel anschauen.

00:08:50: Also ein Produktbesitz gemeinsam mit technischer Eigenschaften, check.

00:08:54: Aber seine Beschreibung kann in mehreren Sprachen vorliegen.

00:08:58: Während Sortiment und Verkaufsfreigabe regional gepflegt sind.

00:09:01: also das ist dann wieder nochmal unterschiedlich.

00:09:03: Das heißt man hat halt einen gewissen Master an Produktinformationen bricht sie aber danach regional runter.

00:09:11: Aber diese Informationen gehören zusammen und haben aber unterschiedliche Zuständigkeiten Und da sind wir genau auf diesem Thema angekommen, was ich immer wieder für Probleme habe.

00:09:25: Es geht um diese Zentralisierung der Datenhaltung und ersetzt halt keine fachliche Verantwortung.

00:09:33: Für mich entsteht eine gemeinsame Datenbasis durch klare Definitionen, Zuständigkeiten und Regeln für Änderungen.

00:09:41: Klar kann ich jetzt von Racki reden, das ist so alt.

00:09:44: backen macht jeder.

00:09:46: Gerade bei Daten ist das Raki-Modell relativ unübersichtlich, man muss es ein bisschen anders angehen.

00:09:51: Wie auch immer für einen Einstieg hilft's dir sicher.

00:09:55: Erst danach kann ich entscheiden welche Anwendungen und welche Informationen führt und welcher andere Bereiche sie erhalten dürfen.

00:10:02: Und du siehst dass Raki Modelle hilft an den Punkt dann wenig.

00:10:07: Damit wird aus der fachlichen Betrachtung eine Architektur der Datenbereitstellung.

00:10:19: Die Region wirkt durch die gesamte Architektur.

00:10:26: Also regionale Anforderungen reichen von fachlichen Informationen bis zur technischen Bereitstellung.

00:10:35: In internationalen Landschaften betrachte ich diese Verbindung zwischen Regionsprache, Datenverfügbarkeit, Datenservice und der Application sehr panibel.

00:10:47: Diese Verbindung muss durchgängig funktionieren.

00:10:51: Wenn ihr das nicht schafft, dann müsst sie wieder von neuem Anfang an.

00:10:54: Das ist ein Journey die unterhalb der Architektur laufen muss.

00:11:00: Da haben wir einen Mechernmix aus Markten oder Daten, die über Märkte hinweggehen mit Sprachen und Verfügbarkeiten den Sources, die dran gekopft sind und den Applikationen natürlich.

00:11:15: Wenn es nicht pfeift, dann haben wir echt ein Problem.

00:11:20: Ein regionales Fronten braucht die richtigen Inhalte natürlich.

00:11:24: Wenn ich jetzt in Brasilien was Publisher und ich dort ein Inhalt aus Portugal widerspiegeln oder dort mit derselben Sprache habe, dann habe ich da einen schneller Problem mit dem Vertrieb.

00:11:36: Produkte und Funktionen müssen natürlich im jeweiligen Kontext klappen.

00:11:41: Dafür müssen sie den angenehmen Services diesen Kontext ebenfalls verstehen und unterstützen.

00:11:48: Eine regionale Anwendung kann trotzdem von Beid entfernten oder ungeeigneten bereitgestellten Sails abhängig sein.

00:11:56: Also wenn ich jetzt in Portugal das ganze Hoste, die Sails ist dort ein Aufbauer und sie nach Brasilien über eine CDN ausrollen dann habe ich danach direkt diese Abhängigkeiten dahin.

00:12:07: Deshalb reicht es mir nicht einzelne Anwendungen oder Infosudo-Komponenten ins Isoliert zu betrachten.

00:12:13: Ich verfolge und es ist wichtig, diese Abhängigkeiten durch die gesamte Landschaft.

00:12:19: Und das sind bei mir nicht nur die Applikationen sondern auch die Entitäten, die API, natürlich die Inhalte wobei ich mit Ihnen in der Tiefe nicht anschaue, die Produktdaten, die Suche und die Transaktionssysteme wenn es eine e-commerce oder beziehungsweise eine transaktionale Plattform ist.

00:12:37: Daraus ergibt sich welche Komponenten gemeinsam genutzt begreitgestellt werden sollten.

00:12:47: Und zum Beispiel dazu anschauen, ein Website zeigt halt regionale Produktinformationen.

00:12:53: Der Suchindex muss dieselbe Regeln im Sortiment und Freigaben berücksichtigen.

00:12:58: Sonst passen zwei sichtbare Funktionen der selben Anwendung fachlich einfach nicht zusammen.

00:13:04: Somit ist es auch so dass halt Globalität Muss sich an den Verbindungen zwischen den Komponenten zeigen.

00:13:13: Ein gemeinsamer Plattform braucht eine nachvollziehbare Logik für regionale Daten und Funktionen.

00:13:20: Diese Logik gehört in die Architektur, und darf nicht über verschiedene Teams hinweg zufällig entstehen.

00:13:27: Sobald ich diese Abkündigkeiten sehe kann ich auch das Pridipsmodell sinnvoll bewerten.

00:13:45: Wenn man international Architekturen hochzieht, dann kommen zusätzlich Anforderungen bezüglich Erreichbarkeit diese Latenzen der Datenverarbeitung und Betrieb hinzu.

00:13:57: Diese Anforderung die beeinflussen die gesamte Bereitstellung meiner Anwendung oder meines neues Landschafts.

00:14:05: Deshalb kann eine gemeinsame Architektor regional unterschiedliche Infrasturen benötigen.

00:14:11: gerade gemeinsame fachliche Modelle und Schnittstellen und Software können dabei weiterhin natürlich erhalten bleiben.

00:14:18: Diese Verteilung erzeugt allerdings neue Aufgaben, es geht vor allem wieder um die Daten und die Aktualisierung und vor allem danach das Monitoring der Support und wenn man schiefgeht die Wiederherstellung.

00:14:31: Diese Aufgaben muss von Anfang an Teil der Architektur sein.

00:14:36: Aktuell ist es auch bei meinen Projekten so dass das von Ende zu Ende von mir auch mitgetragen wird Immer wieder Frage, wo ist der Markt am stärksten?

00:14:47: Brauchen wir da auch eine Auslieferung?

00:14:49: Habe ich da drinnen separate Betriebsmodelle, eigene Applikationen

00:14:55: etc.,

00:14:55: etc.

00:14:56: Meine Aufgabe ist es hier diese Auswirkungen von Datenflüssen und Saisonbetriebsgrenzen nachvollziehbar zu machen.

00:15:03: Wenn ich das Beispiel jetzt nochmal wenn ich einen eigenen regionalen Betriebesbereich vor sehe muss ich auch die Datenversorgung und die Betriebsverantwortlich dafür gestalten.

00:15:18: Mit dem zusichtlichen Deployment allein ist damit die Architekturarbeit natürlich nicht abgeschlossen.

00:15:25: Die Auswahl der Betriebmodelle folgt aus den Anforderungen und Abhängigkeiten, wenn sie verfügbar sind also gerade die Anforderung dahinter sind nochmal ein Kunstwerk herauszufinden.

00:15:38: Ich möchte dabei denn diesen laufenden Betrieb genauso gut zu verstehen wie wie die Einführung des neuen Systems.

00:15:46: Eine Architektur muss über ihren Lebenszyklus funktionieren, also einschließlich Änderungen und vor allem Verstörungen.

00:15:55: Und je mehr regionale Ausprägungen ich habe desto wichtiger wird diese gemeinsame Entscheidungsstruktur.

00:16:07: Und Kapitel V und lokale Entscheidungen haben eine globale Wirkung.

00:16:14: Regionale Freiheit braucht klare Verantwortlichkeiten und gemeinsame Architekturregeln, wie ich finde.

00:16:20: Wenn wir uns halt regionale Teams anschauen kennen die kennen natürlich ihre Märkte und müssen heute handlungsfähig sein.

00:16:28: Gleichzeitig können Ihre Entscheidungen auf andere Regionen und zentrale Funktionen Wirkung zeigen.

00:16:35: Eine zusätzliche Anwendung bringt natürlich Daten Schnittstellen Knowledge und Betriebsaufwände in die gemeinsame Landschaft.

00:16:43: Deshalb muss sichtbar sein, welche Entscheidungen regional getroffen werden können und welche eine gemeinsame Bewertung benötigen.

00:16:51: Gemeinsame Regeln betreffen beispielsweise diese fachlichen Definitionen – um die IPIs und die Security- und Betriebsverantwortlichsten Tum.

00:17:03: Abweichungen brauchen eine Begründung und eine nachvollziehbare Wirkung wie ich finde.

00:17:08: Diese Abweicherungen gehören natürlich auch auf die Rotmap.

00:17:12: Sonst planee ich gemeinsam Ein gemeinsames Zielbild.

00:17:16: wären regionale Veränderungen unermicht davon weiterlaufen.

00:17:20: Das ist natürlich wichtig!

00:17:23: Wenn wir uns ein Beispiel dazu noch mal anschauen, eine Region führt eine neue Lösung zur Kundenbetreuung an.

00:17:29: Check!

00:17:30: Sobald diese Kundendaten überregional genutzt werden sollen betrifft ihre Entscheidung auch die gemeinsame Datenarchitektur der und deren Verantwortliche.

00:17:40: Okay?

00:17:42: Hier kann ich natürlich wieder auf Datengarbonenz tindieren, aber kennt die jeder wahrscheinlich nicht.

00:17:48: Somit ist auch hier meine Position klar.

00:17:52: RM muss regionale Entscheidungen mit der gemeinsamen Entwicklung und Unternehmen verbinden.

00:17:59: Dafür brauche ich genug Struktur damit lokale Freiheiten dauerhaft tragbar bleibt.

00:18:05: Das knüpft wieder an meiner Folge thirty four.

00:18:08: Unterschiedlichkeit kann sinnvoll sein, ihre Auswirkungen müssen bewusst getragen werden.

00:18:14: Diese Auswirkung haben natürlich auch einen wirtschaftliche Seite und die schauen uns jetzt mal an.

00:18:24: Kapitel VI Regionalisierung verändert den TCO.

00:18:29: Die Kosten entstehen durch Pflege- und Veränderung der regionalen Unterschiede.

00:18:35: Nebenbei.

00:18:35: TCO mit Regionalisierung ist eine gewisse Herausforderung, an dem ich selbst immer wieder staune wie komplex das sein kann.

00:18:44: Zusätzliche Infos tu es häufig gut sichtbar und relativ einfach zu kalkulieren, wobei das relativ einfach kommt immer darauf an wenn man wirklich den gesamten Skrupf von oben bis unten kennt und weiß auch was alles reinkommt.

00:18:58: dahinter liegt halt weitere Aufwände und vor allem die Integration diese Datenverteilung Data Sharding nennt sich das ganze, die Testsupportdokundation und Abstimmung.

00:19:11: Und jede regionale Ausbringung muss bei späteren Änderungen berufsticht werden.

00:19:16: Damit entstehen Kosten?

00:19:18: Klar!

00:19:19: Aber die sieht man nicht aus erster.

00:19:21: Jetzt weißt du es über den gesamten Lebenszyklus und den musst du mit rein kalkulieren.

00:19:25: Gleichzeitig versuch verursacht auch diese Vereinheitlichung Aufwand Und kann regionale Abläufe verändern und die Business Architektur vor allem.

00:19:35: Deshalb lässt sich die Entscheidung nicht allein aus der Anzahl des Systemen ableiten, sei deswegen ein bisschen vorsichtig!

00:19:42: Ich verbinde da immer diese Kostenbetrachtung mit den geschäftlichen Nutzen unter Anforderungen des jeweiligen Marktes.

00:19:51: Eine zusätzliche regionale Lösung kann wirtschaftlich sinnvoll sein wenn sie eine notwendige Fähigkeit wirklich ermöglicht.

00:20:02: Eine Gemeinsamlösung kann wertvoll sein, wenn Ihre Wiederverwendung tatsächlich auch funktioniert.

00:20:09: Das sind immer so zwei Themen die du dir immer bisher gegenüberhalten solltest.

00:20:14: Meine Position dazu ist eigentlich relativ klar.

00:20:17: mich interessiert welche Entscheidungen die Kosten erzeugt und welche Wirkung das Unternehmen dafür erhält.

00:20:24: also Kosten wirken Rechnung oder genau.

00:20:29: TISIO unterstützt diese Bewertung für mich und bringt immer einen guten Nenner mit sich, denn über Geld lässt sich bekanntlich immer streiten.

00:20:38: Die Architektur zeigt zusätzlich welche Abhängigkeiten und Risiken und Veränderungen mit dieser Entscheidung verbunden sind.

00:20:48: Genau deshalb gehört diese grossen Rechnung für mich in eine große Entscheidungskontext.

00:20:56: Und damit sind wir wieder bei der Frage was International internationales Geschäft mit meiner Arbeit als Enterprise Architekt macht.

00:21:10: Zumitt sind wir auch schon wieder am Ende dieser Folge angelangt, die gemeinsame Architektur muss Unterschiede tragen können.

00:21:19: Wir haben uns halt angeschaut.

00:21:20: Internationales Geschäft erweitert die Betrachtung um regionale Fähigkeiten Datenkontexten und Betriebsbedingungen.

00:21:27: Diese Unterschiede wirken natürlich durch die gesamte Architektor.

00:21:32: Ich muss sie halt verstehen, ich muss sie einordnen können und mit den gemeinsamen Entwicklungen des Unternehmens verbinden.

00:21:39: Vor allem in thirty-fünfunddreißig von Enterprise Architektur wirkt habe ich das ergänzt.

00:21:47: heute haben wir betrachtet wie verschiedene Märkte die gemeinsam Architektor verändern können was du dir daraus ein bisschen ziehen kannst.

00:21:58: Eine globale Zielarchitektur muss begründet lokale unterschiedliche ermöglichen und dieses Unternehmen trotzdem gemeinsam Steuer behalten.

00:22:06: Auch wenn es oft so scheint, es gibt hier keinen Wachstum, irgendwann kommt das, oft kommt eine Veränderung ran die man nicht betrachtet.

00:22:15: Damit lasst ihr da immer eine Tür offen.

00:22:18: Dafür verbinde ich einfach immer die Strategie, die Business Capability ist die Data, die Application und vor allem die Technologie.

00:22:27: Die Methode bleibt dieselbe.

00:22:29: Das internationale Umfeld verändert ihre Anwendungen und die Gewichtung der Entscheidungen.

00:22:41: Bevor ich diese Folge abschließe... Also, ich habe noch nie so lange für eine Folge gearbeitet.

00:22:48: Zuerst dieses Gesundheitswesen-Disaster.

00:22:51: Diese Folge habe ich dann nachher nochmal kommentum geschrieben weil es eigentlich Teil von einer anderen Folge sein sollte.

00:22:59: Dennoch Hoffe ich natürlich, dass man damit ein bisschen verstanden hat wie wichtig es ist internationales Business in der Architektur richtig zu verankern und vor allem die Regionalisierung zu betrachten.

00:23:11: Ich habe sie in dieser Folge wirklich sehr high-level angekratzt.

00:23:15: Die Komplexität ist in der Tat vor allem in zwei Faktoren.

00:23:20: Der ersten sind die Prozesse und die Vielfalt der regionalen Ausprägungen Und das naheliegende natürlich dann auch die Daten.

00:23:31: Dann hat man noch die größte Herausforderungen ist immer, dass die Sichtweise wenn man für große Konzerne arbeitet, dass man immer eine Zentralisierung arbeiten möchte, d.h.

00:23:43: Sie zentralisieren Applikationen.

00:23:45: Das heißt alle Business-Applikationer bzw.

00:23:48: Business Prozesse müssen diese Applikations irgendwie einspielen.

00:23:55: Diese Sichtweisen habe ich jetzt natürlich nicht in diese gesamte Folge reingepackt, weil es ein bisschen den Rahmen sprengen würde.

00:24:03: Dennoch hast du glaube ich relativ gut mitbekommen wie wichtig ist es gerade in solchen Umfällen wo die Komplexität erhöht wird mit Methodik vorzugehen und nicht auf Käse zu Käse und auch das Bauchgefühl zu hoher achten.

00:24:23: Nächste Ankündigung.

00:24:24: Ich hoffe, ich halte es für die Folge siebenunddreißig.

00:24:28: Möchte ich mir Transport und Logistik mal ansehen?

00:24:31: Auch hier ist mein Erfahrungsumfeld leider nicht so stark aber stärker wie im Gesundheitswesen auf alle Fälle.

00:24:40: Dort betrachten wir die Bewegung und Zeit und aktuelle Statusinformationen, die Architektur prägen.

00:24:48: Ja das war's Mal Servus und Papa und bis auf bald!

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.