Experten-Talk - Power Apps – Canvas oder Model-Driven: Die Architektur entscheidet

00:00:00: Du kennst diesen Moment, du sitzt in so einem typischen Projekt-Kickoff.

00:00:04: Der Fachbereich will unbedingt ein Prozess digitalisieren und dann klickt irgendjemand in der Powerplattform auf diesen echt verlockenden Button mit der Aufschrift

00:00:14: neu.

00:00:15: Ja genau!

00:00:16: Und in dem Moment ahnt noch niemand was das eigentlich bedeutet?

00:00:19: Absolut im Hintergrund passiert in dieser einen Sekunde scheinbar überhaupt nichts Dramatisches.

00:00:26: aber Auf architektonischer Ebene hast du da gerade einen massiven Kredit aufgenommen.

00:00:32: Wenn Du jetzt nämlich den falschen Apptyp wählst, dann zahlst Du ab heute Zinseszins auf unsichtbare technische Schulden.

00:00:39: Und

00:00:39: diese Schulden sind extrem teuer!

00:00:41: Richtig teuer – jede neue Datenquelle jeder unsauber integrierte Prozess wirkt dann quasi als Multiplikator.

00:00:49: Ein paar Jahre später wundest Du Dich warum jede noch so kleine Anpassung am System plötzlich Wochen dauert?

00:00:55: und die Wartungskosten dein komplettes IT-Budget verschlingen.

00:01:00: Okay, lass uns das mal aufschlüsseln!

00:01:02: Das ist wie das Durchschneiden eines Kabels an einer

00:01:04: Zeitbombe.".

00:01:05: Das ist ein sehr gutes Bild – wenn wir das einmal mit dem großen Ganzen verbinden….

00:01:10: diese unsichtbaren Schulden sind im Jahr zwanzig sechsundzwanzig der absolute Hauptgrund warum Mittelstandsprojekte stagnieren oder sogar scheitern?

00:01:19: Wir haben für unsere Analyse heute diesen Ziemlich genialen Artikel von Volker Bundrock auf dem Tisch, der genau diesen Schmerzpunkt sitziert.

00:01:27: Genau und da geht es ja um die fast schon philosophische Entscheidung oder?

00:01:31: Ja!

00:01:32: Die Entscheidung zwischen Canvas- und Model Driven Apps innerhalb dieser Microsoft Power Platform.

00:01:37: Denn rein technisch betrachtet können die Plattform heute ich sage mal eigentlich alles – Der wahre Flaschenhals ist wirklich die fundamentale Architekturentscheidung an Tag eins.

00:01:47: wer Unternehmensanwendungen in erster Linie durch die Linse des hübschen Designs betrachtet und nicht durch die Linse der Datenarchitektur, der baut sich schlichtweg sein eigenes Legacy-System von morgen.

00:01:59: Wahnsinn!

00:02:00: Und das zwingt uns ja im Grunde dazu, die Diskussion komplett von der bunten Benutzeroberfläche wegzuziehen – wir müssen dorthin schauen wo die Wahrheit liegt nämlich bei den Daten.

00:02:11: Volker Bundrock macht in seinem Artikel sehr deutlich dass der Startpunkt zwingend das Dataverse sein muss Aber da sehe ich in der Praxis echt den ersten massiven Widerstand.

00:02:22: Oh ja, denen gibt es ständig!

00:02:24: Oder weil viele Entwickler oder auch diese Power-User aus dem Fachbereich die weigern sich schlichtweg eine saubere Dataverse Architektur aufzusetzen Die klatschen dann lieber schnelle SharePoint Liste in die Cloud hängen ein Canvas App davor und nennen das Ganze dann stolz Digitalisierung.

00:02:41: Warum scheitert dieser schnelle Ansatz auf Enterprise Ebene eigentlich so gnadenlos?

00:02:47: Weil eine SharePoint-Liste am Ende des Tages nur ne flache Excel-Tabelle im Browser ist.

00:02:52: Das isst kein relationales Datenmodell.

00:02:54: Okay, also zu simpel gebaut?

00:02:55: Genau!

00:02:56: Wenn du komplexe Geschäftsprozesse abbilden willst – sagen wir mal ein mehrstufiges Anlagenmanagement wo Kunden Verträge Maschinen und Wartungstickets miteinander verknüpft sind dann brauchst Du referenzielle Integrität Und Dataverse bietet genau das.

00:03:12: Ändert sich der Name eines Kunden, dann kaskadiert das automatisch durch das gesamte System.

00:03:17: Das passiert bei SharePoint nicht?

00:03:18: Nein!

00:03:19: In einer flachen SharePoint-Architektur müsstest du dafür im Hintergrund extrem komplexe fehleranfällige Power Automate Flows bauen die diese Datensätze mühsam synchronisieren.

00:03:31: und dann kommt ja noch das Thema Application Lifecycle Management dazu.

00:03:35: kurz ALM.

00:03:36: Ah, ALM Genau da bricht das Konstrukt doch meistens komplett zusammen.

00:03:41: oder Wenn ich jetzt eine isolierte Canvas-App bauere, die auf SharePoint oder Excel basiert und diese dann von der Entwicklungs in die Testumgebung schieben will und irgendwann in die Produktion – da zerschiesse ich mir doch regelmäßig alle Datenverbindungen.

00:03:55: Exakt!

00:03:56: Bei Dataverse nutzt du dafür sogenannte Solutions.

00:04:00: Du kapselst quasi das Datenmodell, die Sicherheitsrollen, die Geschäftslogik und eben die Model Driven App in ein einziges sauberes Paket.

00:04:08: Das klingt nach einem stabilen Corsett.

00:04:10: Ist es

00:04:11: auch?

00:04:11: Du nutzt Umgebungsvariablen und Connection References.

00:04:15: Wenn du das denn über eine Pipeline in die Produktion ausrollst, passt sich das System automatisch an die neue Umgebung an.

00:04:22: Aber das vielleicht wichtigste Argument für Dataverse auf Enterprise-Ebene ist die Sicherheit!

00:04:28: Wir sprechen hier von Role Level Security

00:04:31: Also Sicherheit auf Zeilenebene.

00:04:33: Genau In Dataverse kannst du definieren, dass ein Vertriebsmitarbeiter aus München wirklich nur die Datensätze seiner spezifischen Region sehen und bearbeiten darf während der Abteilungsleiter alles sieht.

00:04:47: Und in so einer Reihen kann was SharePoint-Konstruktion?

00:04:50: Da gebe ich dem Nutzer im Grunde ja Lese und Schreibrechte auf die gesamte Liste oder?

00:04:54: Leider Ja!

00:04:55: Und dann versuche ich kramfhaft über irgendwelche versteckten Buttons und Filter in der Oberfläche zu verhindern... ...dass er Dinge sieht, die nichts angehen.

00:05:03: Das ist… Security by Obscurity.

00:05:06: Ein fasierter Nutzer umgeht das in Sekunden.

00:05:08: Absolut, das ist ein riesiges Sicherheitsrisiko!

00:05:11: Aber warmer... Lass uns mal den Elefant den Raum ansprechen was diese Model Driven Apps angeht.

00:05:16: Microsoft gibt da die Benutzeroberfläche ja zu fast neunzig Prozent hart vor.

00:05:20: Das Layout, die Navigation, die Formulare – das sieht alles aus wie so ein klassisches ich sag mal standardisiertes CRM.

00:05:28: Ist das im Jahr zwanzig nicht ein absoluter Usability-Albtraum oder auch einen Kreativitätskiller für Entwickler, die moderne Consumer Apps gewohnt sind?

00:05:37: Was hier wirklich faszinierend ist?

00:05:38: diese Kritik hört man ständig.

00:05:40: Aber sie ignoriert die kognitive Psychologie von Unternehmenssoftware komplett!

00:05:44: Okay wie meinst du

00:05:45: das?!

00:05:45: Na ja, Consumer-Apps sind ja darauf ausgelegt dich zu fesseln.

00:05:48: Deine Aufmerksamkeit zu binden!

00:05:50: Eine Backoffice App im Unternehmen soll aber genau das Gegenteil tun.

00:05:54: Sie soll den Kognitifloat also diese geistige Beanspruchung des Nutzers drastisch reduzieren.

00:06:00: Ah, das macht Sinn...

00:06:01: Wenn die Rechnungsfreigabe das Vorparkmanagement und die HR-Urlaubsanträge alle exakt derselben model driven Logik folgen, entfällt der Lernaufwand einfach komplett.

00:06:11: Der Nutzer muss nicht auf jedem Screen neu evaluieren wo sich jetzt der Speichernbutton versteckt oder wie die Suchleiste funktioniert.

00:06:17: Verstehe!

00:06:19: Die Standardisierung ist also kein Gefängnis sondern eine Befreiung – ein Effizienzturbo.

00:06:24: Und die Quelle hebt in diesem Zusammenhang ja auch die Business Process Flows hervor, diese BPFs.

00:06:30: Das ist im Grunde dieses visuelle Prozessband am oberen Bildschirmrand, das den Mitarbeiter wie einen Piloten durch so eine strikte Checkliste führt.

00:06:37: Richtig?

00:06:38: Richtig!

00:06:39: Du zwingst den Prozess in einer harte Leitplanke.

00:06:42: Genau also Schritt drei kann gar nicht erst aktiviert werden solange in Schritt eins nicht das Pflicht fällt für sagen wir das Budget ausgefüllt wurde.

00:06:50: du verlagerst die Prozessdisziplin aus dem Kopf des Nutzers direkt in die Architektur

00:06:55: und was noch wichtiger ist Du entkoppelst die Logik von der Oberfläche.

00:07:00: Wenn die Geschäftsführung jetzt entscheidet, dass ab morgen ein zusätzlicher Freigabeschritt nötig ist – dann passt du im Dataverse zentral den Business Process Flow an!

00:07:11: Jede Model-Driven App, die auf diesem Datenmodell basiert, zieht sich diese Änderungen in Echtzeit.

00:07:17: Die Entwickler diskutieren nicht mehr wochenlang über die Schattenbildung von irgendwelchen Buttons sondern investieren ihre Zeit endlich in wertschöpfende Automatisierung.

00:07:26: Okay, das leuchtet ein.

00:07:28: Wir haben also dieses massive tief verankerte Architektur-Fundament.

00:07:32: Dataverse übernimmt die Sicherheit, die Relationen und diktiert über die Model Driven App den standardisierten Prozess.

00:07:39: Aber was passiert wenn dieses rigide System auf die harte physische Realität trifft?

00:07:45: Da wird's knifflig!

00:07:46: Ja, nehmen wir mal dieses Beispiel aus dem Artikel – Den Werker in der Produktionshalle.

00:07:51: Der steht an der Fräsmaschine, trägt dicke Sicherheitshandschuhe und hat vielleicht exakt fünf Sekunden Zeit um eine Störung zu melden.

00:07:58: Wenn du dem auf seinem Industrietablet so ein standardisiertes Model-Driven Drit mit winzigen Textfeldern und verschachtelten Dropdowns präsentierst, der boykottiert das System doch schlicht weg!

00:08:08: Da wird die Standardisierung vom Effizienzturbo zum kompletten

00:08:11: Prozessblocker.".

00:08:13: Und dass ist die exakte Bruchstelle, an der Model Driven Apps versagen?

00:08:18: und wo wir zwingend in die Welt der Canvas-Apps wechseln müssen.

00:08:22: Canvas-app sind dieses sprichwörtliche leere Blattpapier, du bestimmst jedes Pixel jeden Farbwert jede noch so kleine Interaktion?

00:08:31: Also genau das was der Werker braucht!

00:08:32: Genau für den Werker in der Halle baust Du ein Interface dass vielleicht nur aus drei gewaltigen farbkodierten Buttons besteht.

00:08:39: Das Problem ist nur der strategische Fehler den so viele Unternehmen hier begehen.

00:08:43: Sie nehmen an, dass diese visuelle Freiheit gleichzeitig architektonische Anarchie bedeutet.

00:09:13: Das ist die große Versuchung, ja?

00:09:14: Und da frage ich mich und das fragst du dich als Hörer vielleicht auch.

00:09:18: Wenn ich doch mit Canvas maximale Gestaltungsfreiheit habe und mich über tausend Konnektoren an jedes Backend hängen kann – wozu brauche ich dann das starre Dataverse überhaupt noch?

00:09:28: Warum nicht einfach munter Canvas-Apps bauen, die direkt mit den Datensilos des Unternehmens

00:09:33: plaudern?".

00:09:34: Das wirft eine extrem wichtige Frage auf!

00:09:37: Wer das macht, tappt unweigerlich in die sogenannte Delegationsfalle….

00:09:41: Okay, was genau ist das?

00:09:42: Das ist ein technischer Aspekt der bei dieser reinen UX-Betrachtung – also wenn man nur aufs Design schaut – oft völlig ignoriert wird.

00:09:51: Stell dir vor du hast eine SQL-Datenbank mit einer Million Datensätzen!

00:09:55: Okay…das ist ja mittelstand nicht ungewöhnlich.

00:09:57: Überhaupt nicht ….

00:09:59: Wenn jetzt eine Model Driven App auf Dataverse eine komplexe Filterung durchführt sagen wir «Du suchst nach ».

00:10:05: zeige mir alle offenen Wartungsaufträge für Maschinentyp X in Bayern aus dem letzten Quartal.

00:10:12: Dann passiert diese gesamte Rechenleistung serverseitig, die App auf dem Gerät bekommt nur die fertigen zehn Ergebnisse zurückgeliefert.

00:10:20: Krass!

00:10:20: Das ist effizient.

00:10:21: und bei einer unsauber angebundenen Canvas-App?

00:10:24: Da stößt du oft das Delegationslimit – wenn die Canvas-app eine Filterfunktion nutzt, die von der Datenquelle also zum Beispiel von einem veralteten SQL-Konnektor nicht unterstützt wird Zwingst du die App dazu, die Logik lokal auszuführen?

00:10:38: Local.

00:10:40: Auf dem Gerät selbst!

00:10:41: Genau – das System lädt dann stumpf die ersten fünfhundert bis maximal zweitausend Datensätze über das Netzwerk auf das Tablet des Werkers und versucht sie dort im Speicher zu feltern.

00:10:55: Die restlichen neunhundert-neunzigtausend datensätze von der Datenbank werden schlichtweg ignoriert.

00:11:01: Warte wirklich, das heißt der Nutzer bekommt ein völlig falsches Ergebnis und merkt es nicht mal.

00:11:06: Exakt!

00:11:07: Und parallel dazu geht das Tablet meistens komplett in die Knie weil der Arbeitsspeicher voll läuft – dass ist der absolute Totalabriss.

00:11:15: Wow… Ein klassisches Szenario von Schatten-IT auf Styroiden.

00:11:19: Du hast also eine wunderschöne hochfunktionale Oberfläche für den Nutzer gebaut aber die Datenintegrität darunter ist faktisch ein Schweizer Käse.

00:11:27: Und dann dezentralisierst du ja auch noch die Geschäftslogik in die OnSelect-Eigenschaften von Hunderten von Buttons, die über Dutzende Canvas-Apps verteilt sind.

00:11:36: Wenn sich ein Steuersatz oder eine Compliance-Regel ändert...

00:11:39: ...und manuell in jede einzelne App gehen.

00:11:42: Genau!

00:11:43: Du musst den Code umschreiben, alles neu testen und deployn – das ist doch überhaupt nicht wartbar.

00:11:48: Deswegen lautet die eiserne architektonische Prämisse.

00:11:51: Canvas-Apps sind die Kür, aber sie dürfen niemals die Pflicht der zentralen Datenarchitektur ersetzen.

00:11:58: Die einzig saubere Lösung ist dass auch diese maßgeschneiderte bunte Canvas Oberfläche für den Werker ihre Daten primär aus dem zentralen Dataverse zieht.

00:12:08: Die App ist quasi nur eine spezifische Linse auf dieselbe Single Source of Truth.

00:12:15: Okay das leuchtet ein Gut, wir haben jetzt den optimalen Zustand skizziert.

00:12:21: Dataverse als Eisernis Backend, Model Driven für das standardisierte Backoffice, Canvas für die hochspezifischen Edge-Cases – also die Ausnahmen an der Frontline!

00:12:31: Aber diese schöne Theorie setzt ihr voraus dass wir alle Unternehmensdaten modern, API fähig und cloud ready vorliegen haben.

00:12:40: Was selten der Fall ist?

00:12:42: Die Realität in neunzig Prozent der mittelständischen Betriebe sieht doch ganz anders aus.

00:12:47: Da steht auch oft noch ein zwanzig Jahre altes ERP-System im Keller, es gibt keine Arpies und keine Webhooks – es gibt nur diesen schwarz-grünen Terminal Screen über den seit zwei Jahrzehnten die komplette Buchhaltung läuft!

00:12:59: Wie zur Hölle binden wir so einen technologischen Dinosaurier in unsere moderne Powerplattform ein ohne das ERP System für Millionen austauschen zu müssen?

00:13:08: Hier kommt Power Automate Desktop ins Spiel oder kurz PAD.

00:13:13: Wir sprechen hier von Robotic Process Automation, also RPA kombiniert mit moderner UI Automation.

00:13:22: Anstatt zu versuchen auf Datenbank-Ebene eine risikoreiche unglaublich teure und fehleranfällige Schnittstelle in ein System zu programmieren das dafür einfach nie ausgelegt wurde Greifen wir die Daten an der einzigen Stelle ab, die garantiert funktioniert.

00:13:39: Der Benutzeroberfläche.

00:13:50: RPA ist nur ein glorifiziertes Flaster.

00:13:53: Du machst da dieses sogenannte Screen Scraping, wo der Bot Stur auf Pixelkoordinaten klickt.

00:13:59: Sobald der Hersteller des alten ERP-Systems einen Update ausrollt und den Speichernbutton nur um fünf Pixel nach links verschiebt, greift der Bot ins Leere – der Prozess bricht ab und die ganze moderne Cloudarchitektur steht still!

00:14:13: Bauen wir uns hier nicht eine extrem fragile Abhängigkeit

00:14:16: auf….

00:14:16: Was hier wirklich faszinierend ist, wenn wir von veralteter OCR-Technologie sprechen bei der ein BOT Stur auf Koordinaten klickt hast du völlig recht.

00:14:24: Das ist fragil!

00:14:26: Aber moderne UI Automation mit Part funktioniert völlig anders.

00:14:30: Der BOT liest die strukturellen Elemente der Anwendung aus im Webbereich vergleichbar mit dem DOM, dem Document Object Model.

00:14:38: Er sucht nicht nach einem blauen Button an Position X und Y, sondern er sucht nach dem logischen UI-Element mit der internen ID sagen wir Save Invoice BTN.

00:14:50: Selbst wenn sich das visuelle Layout komplett ändert bleibt dieser Selektor absolut stabil!

00:14:55: Okay, das entschärft das Risiko enorm aber das ändert doch nichts an der Tatsache dass das Legacy System trotzdem ein Floschenhals bleibt oder?

00:15:04: Strategisch gesehen passiert hier aber etwas viel entscheidenderes.

00:15:08: PAD ist kein Plaster, sondern ein Enabler der Modernisierung.

00:15:13: Es entkoppelt den Modernisierungszyklus der Benutzeroberfläche vom Modernisierungsyklus de alten Kernsysteme.

00:15:20: Wie meint sie das konkret?

00:15:21: Stell

00:15:22: dir vor du willst einen durchgängigen digitalen Freigabe-Prozess in einer Model Driven App bauen.

00:15:28: Wenn Du auf die klassische API Integration warten musst heißt es im Management oft Wir können diesen Prozess leider erst in vier Jahren digitalisieren, wenn das große ERP-Migrationsprojekt endlich abgeschlossen ist.

00:15:40: Der Klassiker?

00:15:41: Genau!

00:15:42: Mit PET baust du aber einfach einen Cloudflow der einen unattended bot triggert.

00:15:48: Der Bot lockt sich völlig unsichtbar im Hintergrund auf einer virtuellen Maschine in das alte ERP ein – extrahiert die benötigten Rechnungsdaten in Lichtgeschwindigkeit Puscht sie in Echtzeit, in dein Gatorverse und ein Mitarbeiter kann Sie sofort in seiner modernen Model-Driven App bearbeiten.

00:16:05: Datenbefreiung ohne Totalabriss!

00:16:07: Das ist ja wie ein unermüdlicher digitaler Praktikant die im Keller sitzt und abtippt – das bedeutet ich kann dem Nutzer heute schon die perfekte durchgängige UX bieten völlig unabhängig davon was für einen technologischer Trümmerhaufen im Hintergrund noch am Leben gehalten werden muss.

00:16:25: Ganz genau.

00:16:26: Und wenn das Unternehmen dann in vier Jahren das alte ERP endlich durch eine moderne Saas-Lösung mit echten Apis ersetzt, tausche ich im Hintergrund einfach den Power Automate Flow aus.

00:16:36: Richtig!

00:16:37: Der Nutzer in seiner ModelDriven App merkt von dieser gigantischen Backend-Migration überhaupt nichts – sein Interface bleibt stabil.

00:16:44: Exakt…

00:16:46: Du machst die alten Systeme durch die Brücke modern.

00:16:50: Durch Pat wird die Entscheidung zwischen Canvas und Model Driven überhaupt erst wirklich frei.

00:16:56: Und wenn wir all diese Komponenten, also das solide Data Whisperer kennt – die Standardisierung der Model-Driven-Apps, die Flexibilität der Canvas Apps und die Legacy Integration über Pad.

00:17:07: Wenn wir das alles zusammenführen, landen wir bei dem Konzept, dass Buntrock als den heiligen Graal der Prozess-Souveränität beschreibt!

00:17:16: Die Hybridarchitektur.

00:17:18: Lass uns das mal ganz konkret machen.

00:17:20: Microsoft nennt es ja Custom Pages oder Embedded Canvas Apps.

00:17:23: Wir müssen diesen veralteten Dualismus aufbrechen.

00:17:27: Es ist im Jahr zwanzig, einfach keine Entweder- oder Entscheidung mehr, oder?

00:17:32: Überhaupt

00:17:32: nicht!

00:17:33: Die Pflicht küst hier quasi die Kühe.

00:17:35: Die spannendsten architektonischen Lösungen entstehen genau dort wo wir Model Driven und Canvas nahtlos ineinander verschmelzen.

00:17:43: Das ist der Moment in dem du die kognitive Entlastung der Standardoberfläche mit der hochspezifischen Funktionalität der Canvas Technologie kombinierst.

00:17:54: Die Quelle hat ein Superbeispiel.

00:17:55: Ein Außendienstechniker arbeitet in einer extrem sicheren, striktailational aufgebauten Model-Driven App.

00:18:03: Er verwaltet seine Einsatzpläne die Anlagenhistorien – das System diktiert sauber den Prozess.

00:18:08: Genau!

00:18:09: Aber genau in dem Moment, indem er vor Ort beim Kunden auf dem Tablet eine detaillierte technische Skizze eines defekten Bauteils anfertigen muss oder eine komplexe digitale Unterschrift erfassen soll….

00:18:21: Das sind ja Aufgaben für die ein Model Driven Grid völlig ungeeignet ist, ändert sich das Verhalten der App.

00:18:27: Hier öffnet sich dann innerhalb dieser starren Model-Driven Umgebung plötzlich ein hoch flexibles Canvas Fenster.

00:18:33: Richtig!

00:18:34: Und der technische Clue dabei ist das sogenannte Context Passing über das Power Apps Component Framework – das PCF.

00:18:42: Okay,

00:18:42: d.h.,

00:18:43: dass Fenster weiß wo es ist?

00:18:45: Ganz genau….

00:18:46: Die Canvas Komponente ist nicht einfach blind.

00:18:49: Das umgebende Dataverse-Formular übergibt die GURT, also die eindeutige Identifikationsnummer des aktuellen Wartungsauftrags nahtlos an die Canvas App.

00:19:00: Der Techniker muss keine Auftragsnummer doppelt abtippen – er muss nicht das System wechseln oder irgendwie in einer Suchleiste navigieren.

00:19:08: Die Canvas App weiß durch diese kontextbezogene Intelligenz exakt welcher Datensatz offen ist?

00:19:16: erfasst die Unterschrift, klickt auf Speichern.

00:19:19: Die Canvas-Komponente schreibt die Daten direkt über den Kontext in den richtigen Dataverse-Datensatz zurück und schließt sich wieder.

00:19:26: Und der Techniker befindet sich sofort wieder in seiner strukturierten Leitplanke!

00:19:31: Ich finde diese Hybridlösung lässt sich wunderbar verbildlichen – also was bedeutet das alles für dich als Zuhörer?

00:19:37: Es ist, als hättest du einen hochsicheren perfekt sortierten Aktenschrank im Büro.

00:19:43: Das ist deine Model Driven App mit Dataverse.

00:19:45: Alles hat eine strikte Ordnung, nichts geht verloren.

00:19:48: Die Sicherheit ist zu hundert Prozent

00:19:50: garantiert.".

00:19:51: Ein sehr schöner Vergleich.

00:19:53: Und genau in dem Moment wo du eine kreative Idee visualisieren musst ziehst Du aus diesem strengen Aktenschrank ein völlig freies unlinierte Skizzenbuch Deine Canvas App!

00:20:04: Du zeichnest deine Skizze Heftest das Blatt wieder exakt an den vorgegebenen Platz ab und die Gesamtsstruktur bleibt komplett gewahrt.

00:20:12: Die wahren Meister der Architektur bauen eben kein reines UI-Monster und auch kein reine Datengrab, sondern eine echte Präzisionsmaschine.

00:20:20: Absolut!

00:20:21: Und um diese Hybridstrategie für IT-Entscheider greifbar zu machen formuliert der Artikel eine sehr klare architektonische Leitlinie quasi die Matrix – die

00:20:33: Achtzigzwanzigregel.

00:20:34: Die

00:20:35: strategische Empfehlung für den Mittelstand lautet, dass etwa achtzig Prozent der gesamten administrativen Datenintensiven Backoffice-Prozesse in Model Driven Apps auf Basis von Dataverse laufen sollten.

00:20:46: Hier ordnest du alles den Prinzipien von Sicherheit, Stabilität und Skalierbarkeit unter.

00:20:52: Und die Zwanzigprozent?

00:20:54: Die restlichen zwanzig Prozent deines Ökosystems reservierst du ganz bewusst für Canvas-Apps oder Custom Pages, bei denen spezifische Nutzerrollen einfach eine maßgeschneuderte intuitive Oberfläche brauchen.

00:21:05: Wobei ich sage mal diese zwanzich Prozent in der Realität oft der härteste Kampf sind, oder?

00:21:11: Der Fachbereich kommt ja fast immer mit dem Anspruch um die Ecke das sein spezificer Prozess zu hundert Prozent individuell abgebildet werden muss.

00:21:18: Da wird dann echt jeder Buttonklick stundenlang diskutiert, nach dem Motto weil wir das schon immer so gemacht haben.

00:21:25: Die Kunst des IT-Architekten ist es doch diesen Drang nach reiner UI Individualisierung abzuwehren!

00:21:31: Er muss erkennen, wann ein Prozess wirklich so spezifisch ist wie eben der Werker in der Halle oder der Techniker mit der Skizze dass er in diese kleine zwanzig Prozent Canvas Kategorie fällt.

00:21:41: Das es exakt der Punkt an dem Architektur auf Change Management trifft!

00:21:46: Wer bei jedem Backoffice-Prozess den Druck nachgebt und wilde Canvas Lösungen für absolute Standardprobleme baut, der verliert schlichtweg die Kontrolle über seine Daten.

00:21:55: Ware-Souveränität bedeutet im Jahr für die eigenen Datenmodelle zu beherrschen, anstatt sich von der bloßen Komplexität und den visuellen Verlockungen der Werkzeuge beherrschend zu lassen.

00:22:07: Ganz genau!

00:22:08: Und das bringt uns eigentlich direkt zur Zusammenfassung unserer Analyse heute.

00:22:13: Wir haben auf dieser Reise gesehen dass nachhaltige Digitalisierung im Mittelstand eine glasklare Trennung von Datenarchitektur und Nutzererlebnis erfordert.

00:22:21: Absolut

00:22:22: Vom eisernen Fundament des Dataversus über das Wissen, wann man diese pixelgenaue Freiheit der Canvas-Apps einsetzen muss – hin zur Datenbefreiung unserer alten Kellersysteme durch PAD und schließlich zur perfekten Harmonie in dieser Hybridlösung nach der Achtzigzwanzigregel.

00:22:38: Wer heute alt IT-Architekt oder prozessverantwortlicher Strategie gestenkt anstatt nur blind irgendwelche Tools zusammenzubasteln, der sichert seinem Unternehmen die Skalierbarkeit für das komplette nächste Jahrzehnt!

00:22:53: Ein perfektes Schlusswort.

00:22:54: Aber bevor wir diesen Deep Dive beenden, möchte ich dir ja genau dir an den Kopfhörern noch einen finalen provokanten Gedanken mit in den Tag geben Wenn wir diese Achtzig-Zwanzig-Regel mal konsequent zu Ende denken.

00:23:08: Wir sehen ja gerade wie rasant sich KI-Systeme in die Powerplattform integrieren.

00:23:12: Wenn diese Achtzig Prozent der standardisierten Model-Driven Backoffice Prozesse in naher Zukunft ohnehin fast vollautomatisiert durch Co-Pilot und autonome Agenten abgewickelt werden, wird die eigentliche menschliche Arbeit der Zukunft dann nicht fast ausschließlich in diesen verbleibenden zwanzig Prozent der Canva's Welt stattfinden?

00:23:30: Ein extrem spannender Gedanke.

00:23:32: Genau an jenen hochkreativen, spezifischen und auch chaotischen Schnittstellen der Realität.

00:23:39: An denen die reine Standardlogik versagt – und wo menschliche Intuition gefragt ist!

00:23:46: Ein Gedanke, der definitiv zum Weiterdenken einlädt.

00:23:50: Behalte das mal im Hinterkopf wenn du das nächste Mal davor stehst auf diesen winzigen Button mit der Aufschrift Neu zu klicken.

00:23:57: Bis zum nächsten Mal.