Dynamics 365 Plattform

Folgende Fragestellung zu Dynamics 365

Derzeit entwickeln wir Lösungen für Dynamics 365 und Power Apps, insbesondere als Erweiterungen für Dynamics 365 Sales Enterprise, Field Service, Customer Service und Customer Insights. Wir möchten gerne erfahren, wie sich die Microsoft-Lösungen weiterentwickeln werden. Dynamics 365 Business Central ist eine eigenständige Anwendung mit einer abweichenden Programmiersprache. Auch Dynamics 365 Finance operiert in einer anderen Umgebung, verwendet es weiterhin X++?

Wir beabsichtigen, alle Entwicklungen unter Verwendung von Visual Studio als Entwicklungsumgebung, GitHub für die Sicherung und Versionierung des Sourcecodes sowie C# als Programmiersprache durchzuführen. Zudem möchten wir gerne im bestehenden Programmiersprachenumfeld für Power Apps und Dynamics 365 CRM bleiben. Wird Microsoft seine ERP-Software für Buchhaltungsprozesse modernisieren und weiter in die Azure Cloud überführen, sodass diese nativen DataVerse-Anwendungen werden, auf die wir integriert zugreifen können?

Aktuell gibt es besonders in Business Central separate Tabellen für Lieferanten (Kreditor = Vendor) und Kunden (Debitor = Customer). Im Gegensatz dazu existiert im Dynamics 365 CRM lediglich die Kategorie Firmen (Accounts). Diese unterschiedlichen Datenstrukturen müssen langfristig zu einer einheitlichen Datenbasis zusammengeführt werden, um redundante Datenhaltungen zu vermeiden. Wie sieht die Zukunft für diese Anwendungen aus? Werden sie getrennt bleiben oder besteht die Absicht, auch Buchhaltungsfunktionen in die CRM-Welt von Dynamics 365 zu integrieren?

 

 

Inhalt:

Recherche Fragestellung zu Dynamics 365. 1

Antwort der Recherche: 2

  1. Aktuelle Systemlandschaft und technische Basis. 5
  2. Zukunftsstrategie von Microsoft – Kernaspekte. 6
  3. Konsequenzen für Entwickler: Programmiersprachen & Tools. 7
  4. Mögliche Roadmap-Punkte & Weiterführende Entwicklungen. 8
  5. Fazit und Antworten auf die Kernfragen. 9
  6. Quellen und weiterführende Links. 10

Überprüfung mit Copilot hat folgendes ergeben: 12

1: Aktueller Stand der Dynmics 365 Produktfamilie. 12

2: Dynamics 365 Business Central 13

3: Dynamics 365 Finance und Supply Chain Management 13

4: Fazit: 13

5: Microsoft Strategie. 13

 

 

Rechercheergebnis vom 22.01.2025 zur Fragestellung:

Stand heute betreibt Microsoft die Dynamics-365-Produktfamilie zwar unter einem gemeinsamen Markendach, allerdings sind die darunterliegenden Lösungen – insbesondere in Bezug auf ERP (Finance, Supply Chain Management und Business Central) – technisch auf unterschiedlichen Fundamenten aufgebaut. Parallel dazu existiert die Power-Platform-Welt, mit Dataverse (ehemals Common Data Service) als zentrale Datenbank für Dynamics 365 Sales, Customer Service, Marketing usw.

  1. Technische Grundlagen der unterschiedlichen Anwendungen
  2. Dynamics 365 Sales, Customer Service, Field Service, Marketing, Customer Insights
    • Basieren auf der Power Platform und verwenden Dataverse als Datenbank.
    • Anpassungen und Erweiterungen erfolgen in der Regel über Power Apps (Canvas / Model-Driven Apps), Power Automate, Plug-Ins (in .NET/C#), Power FX (Formeln in Canvas Apps) und JavaScript (Clientseitig) sowie PCF-Komponenten (Power Apps Component Framework).
    •  
  3. Dynamics 365 Finance und Supply Chain Management
    • Basiert auf der Finance and Operations-Plattform.
    • Entwicklungsumgebung: Visual Studio (speziell angepasst), die Programmiersprache ist vorwiegend X++.
    • Datenspeicherung in einer Azure SQL-Datenbank – jedoch nicht in Dataverse.
    • Man kann über Dual-Write Daten mit Dataverse synchronisieren, um z. B. Kunden und Lieferanten mit Accounts/Contacts im Dataverse zu spiegeln.
  4. Dynamics 365 Business Central
    • Technisch eigenständig, basiert auf dem AL-Sprachstack (ehemals C/AL), läuft in einer Azure-Umgebung, die jedoch ebenfalls nicht Dataverse ist.
    • Development erfolgt in Visual Studio Code (plus AL Language Extension), GitHub kann als Versionskontrolle genutzt werden.
    • Integriert sich mit Dataverse beispielsweise über den Business Central Connector oder über Standard-Schnittstellen (API, OData), aber die Datentabellen (z. B. Customer, Vendor) liegen auf einer eigenen Datenbasis.
  5. Wie wird sich das weiterentwickeln?

 a) Einheitliche Datenmodelle und Datenhaltung

  • Microsoft hat mit dem Common Data Model (CDM) und Dataverse versucht, eine standardisierte Datenstruktur bereitzustellen, damit ERP- und CRM-Daten enger zusammenrücken.
  • Dual-Write für Dynamics 365 Finance & SCM ist ein Beispiel dafür, dass man Stamm- und Bewegungsdaten (z. B. Kunden, Lieferanten) mit Dataverse (und damit den „CRM-Apps“) synchron hält.
  • Business Central hat eine tiefe Integration mit Dataverse (z. B. Synchronisierung von Customer ↔ Account). Allerdings ist dies keine „1:1-Gleichschaltung“ – es sind weiterhin eigenständige Tabellen, die gemappt werden.

Aktuell ist keine unmittelbare Roadmap bekannt, die alle Datenbanken in eine einzige zusammenführt. Stattdessen setzt Microsoft verstärkt auf:

  • Synapse Link, Azure Data Lake und ähnliche Technologien, um Datenintegration und -analyse über verschiedene Systeme hinweg zu erleichtern.
  • Standardisierte Datenmodelle (Dataverse/CDM), um den Integrationsaufwand zu verringern.

Fazit:

Völliges „Verschmelzen“ von Business Central, Finance/SCM und CRM in eine einzige Datenbank ist in näherer Zukunft eher unwahrscheinlich – zu groß sind die bestehenden Installationen, zu unterschiedlich sind die Use Cases und Technologie-Stacks. Die Tendenz geht eher zu einer immer engeren Integration über Standard-Konnektoren und -Modelle.

  1. b) Vereinheitlichung der Programmiersprachen
  • Dynamics 365 Finance & SCM (X++) hat einen großen, gewachsenen Code-Bestand und eine starke Spezialisierung auf komplexe ERP-Prozesse. Ein kompletter Rebuild in C# würde immense Ressourcen verschlingen und Kundeninstallationen bremsen.
  • Business Central hat sich vom klassischen C/SIDE und C/AL auf AL mit VS Code umgestellt. Für den ERP-Mittelstandsbereich ist das sehr erfolgreich.
  • CRM / Customer Engagement (Sales, Service usw.) setzt stark auf .NET/C#, JavaScript, TypeScript (PCF) und Power-FX in Canvas Apps.

Fazit:

Microsoft investiert zwar in konvergierende Entwicklungswerkzeuge (z. B. durchgängig VS Code, GitHub, DevOps-Pipelines), aber dass alles in einer einzigen „ERP & CRM“-Lösung in C# entwickelt wird, ist nicht absehbar. Die Spezialentwicklungen (X++, AL, Power FX) sind stark in die jeweilige Plattform verankert.

 

  1. c) Cloud-First, Azure und Power Platform
  • Microsoft verfolgt eine klare Cloud-First-Strategie: Alle ERP-Lösungen (Business Central, Finance, Supply Chain Management) laufen in Azure. On-Premise-Versionen gibt es zwar weiterhin, aber der Innovationsschub ist in der Cloud.
  • Power Platform wird für Automatisierung, Analysen (Power BI) und App-Entwicklung in allen Bereichen (CRM, ERP, IoT, Portale etc.) immer wichtiger.
  • Eine stärkere „Native-Integration“ in Dataverse, sodass z. B. Stammdaten nur noch einmal gepflegt werden, ist schon in Arbeit (Dual-Write, Konnektoren, Virtual Tables etc.).

Fazit:

ERP-Funktionalitäten werden nicht komplett in den CRM-Teil von Dynamics 365 „umziehen“, sondern die Lösungen wachsen über die Power Platform und Dataverse enger zusammen. Dazu kommen immer mehr Standard-Konnektoren, -Integrationen, -API-Schnittstellen und Tools wie Dual-Write.

 

1. Aktuelle Systemlandschaft und technische Basis

1.1 Dynamics 365 (CRM-/CE-Apps) & Power Platform

  • Anwendungen: Sales, Customer Service, Field Service, Marketing, Customer Insights etc.
  • Datenbank: Dataverse (ehem. Common Data Service)
  • Erweiterungsmöglichkeiten:
    • Plugins in C# (.NET)
    • Power Automate (Workflows), Canvas und Model-Driven Apps
    • PCF (Power Apps Component Framework) mit TypeScript/React
    • JavaScript (Client-seitig)
    • Power FX für Canvas Apps und Logik in Dataverse-orientierten Apps

1.2 Dynamics 365 Finance & Supply Chain Management (ehem. Finance and Operations)

  • Technische Basis: eigener Plattform-Stack mit X++ als Hauptsprache und (aktualisierter) Entwicklungsumgebung auf Basis von Visual Studio.
  • Datenhaltung: Azure SQL (nicht Dataverse)
  • Integration:
    • Dual-Write-Funktionen ermöglichen bidirektionalen Datenaustausch mit Dataverse.
    • Power Platform-Integration über Konnektoren, virtuelle Tabellen und Power Automate.

1.3 Dynamics 365 Business Central

  • Technische Basis: AL (Weiterentwicklung der früheren C/AL), Entwicklungsumgebung in Visual Studio Code (via AL-Extension).
  • Datenhaltung: Separat in Azure SQL, jedoch nicht nativ Dataverse.
  • Integration:
    • Standard-API (OData/REST), Konnektoren in Power Automate/Power Apps, Business Central-VS-Code-Extension.
    • Teilweise Dataverse-Schnittstellen (z. B. Synchronisierung Customer ↔ Account).

2. Zukunftsstrategie von Microsoft – Kernaspekte

 2.1 Cloud-First & Modernisierung

  • Durchgängige Cloud-Architektur: Sowohl Finance & Supply Chain Management als auch Business Central sind vollständig in Azure lauffähig. On-Premises-Versionen bestehen weiter, aber Innovationen erscheinen i. d. R. zuerst in der Cloud.
  • Weiterentwicklung der Plattformen:
    • Finance & SCM bleiben auf dem X++-Stack (mit .NET-Elementen).
    • Business Central modernisiert den AL-Stack kontinuierlich, bietet VS Code-Integration, automatisierte Builds/Pipelines (u. a. über GitHub Actions oder Azure DevOps).
    • CRM/CE (Dataverse) bekommt immer wieder neue Features (z. B. Copilot für CRM und Power Platform, erweiterte Power FX-Funktionalitäten).

 

2.2 Gemeinsame Datenmodelle & Integration

  • Common Data Model (CDM): Microsoft pusht eine einheitliche Datenmodell-Definition, insbesondere für Kern-Entitäten (Kunden, Produkte, Lieferanten, Transaktionen etc.).
  • Dual-Write (Finance & Operations + Dataverse): Ermöglicht, z. B. Debitoren (Kunden) und Kreditoren (Lieferanten) in Finance & SCM mit Accounts/Contacts in Dataverse zu synchronisieren.
  • Integrationskonzepte: Power Automate, Logic Apps, Dataflows, Virtual Tables (um ERP-Daten in Dataverse anzuzeigen, ohne redundante Speicherung).
  • Ziel: Reduzierung von Datensilos, Schaffung eines „Single Source of Truth“ für bestimmte Stammdaten, ohne jedoch die zugrundeliegenden ERP-Plattformen „abzulösen“.

 

2.3 Verschmelzung vs. Spezialisierung

  • Wird Finance/BC komplett in Dataverse migrieren?
    • Nach aktuellem Stand nein. Die Investitionen in Dual-Write und Schnittstellen zeigen, dass Microsoft auf Integration statt vollständiger Zusammenführung setzt.
    • Die spezialisierten ERP-Funktionalitäten (Finanzbuchhaltung, Supply Chain, Produktionsprozesse etc.) bleiben in den jeweiligen Plattformen (X++ bzw. AL).
  • Einheitliche Datenbasis für Kunden/Lieferanten vs. Firmen (Accounts)?
    • Langfristig sollen gemeinsame Stammdatenkonzepte über Dual-Write/Standard-Konnektoren im Dataverse abgebildet werden.
    • Business Central und Finance & SCM haben jeweils eigene Tabellen für Kunden/Lieferanten, aber es gibt mittlerweile zahlreiche Konfigurationsmöglichkeiten, diese synchron zu Dataverse zu halten.
    • Ein vollständig einheitliches Datenmodell (z. B. nur noch Account in Dataverse) wird es kurzfristig kaum geben, weil sehr viele Kundeninstallationen, Add-Ons und Branchenlösungen auf den existierenden Strukturen aufsetzen.
    • Die Strategie ist eher, über Standard-APIs und Dual-Write „nahtlose“ Integrationsszenarien zu ermöglichen, so dass die Datenpflege möglichst zentral erfolgen kann.

 

3. Konsequenzen für Entwickler: Programmiersprachen & Tools

 3.1 Visual Studio, GitHub und C#

  • Im CRM-/Power-Platform-Umfeld ist C# (bzw. .NET) für Plug-Ins, Azure Functions oder REST-Integrationen eine zentrale Sprache. Visual Studio und GitHub passen hier ausgezeichnet als Dev-Tooling.
  • Für Finance & SCM-Anpassungen benötigen Sie X++ in einer spezialisierten Visual-Studio-Instanz. Zwar können Sie auch hier Quellcode in GitHub ablegen, aber die Entwicklungsumgebung bleibt separat (Dynamics 365 F&O Dev-Tools).
  • Für Business Central (AL) verwenden Sie Visual Studio Code und können ebenfalls GitHub (oder Azure DevOps) zur Verwaltung nutzen. C# ist hier kein Standard für In-App-Anpassungen, sondern AL. Externe Services kann man natürlich in C# entwickeln und via APIs integrieren.

3.2 Power Platform und Low-Code-/Pro-Code-Kombination

  • Die Power Platform (Power Apps, Power Automate, Power BI) dient als „Integrationsschicht“ zwischen den verschiedenen Systemen (CRM/Dataverse, F&O, BC).
  • Pro-Code-Entwicklungen (C#, TypeScript für PCF) werden zunehmend mit Low-Code-Bausteinen (Power FX, Canvas Apps) kombiniert.
  • Microsoft propagiert das „Fusion Development“-Konzept: Fachbereiche nutzen Low-Code, während professionelle Entwickler komplexe Logik und Integrationen in C# / .NET realisieren.

 

4. Mögliche Roadmap-Punkte & Weiterführende Entwicklungen

  1. Dual-Write: weitere Entitäten, stabilere Synchronisation, vereinfachte Konfiguration (vgl. Microsoft Docs: Dual-write overview).
  2. Dataverse + Virtual Tables: Noch mehr Szenarien, um ERP-Daten in Dataverse „durchzureichen“, ohne Kopien zu erzeugen.
  3. Project „Copilot“: KI-basierte Assistenten werden in CRM und ERP ausgerollt (s. Release Wave Notes) und greifen ebenfalls auf gemeinsame Daten zu.
  4. Teams-Integration: „Tabelle einmal anlegen, in verschiedenen Business-Apps verwenden“ via Dataverse for Teams (vgl. Microsoft Learn: Dataverse for Teams).
  5. Erweiterte Use Cases für Power Automate: Standardisierte Templates für ERP-/CRM-End-to-End-Prozesse (z. B. Lead-to-Cash, Order-to-Invoice).

 

 

5. Fazit und Antworten auf die Kernfragen

  • Werden Business Central, Finance & SCM sowie die CRM-Apps zu einer einzigen Anwendung verschmelzen?
    • Kurzfristig nein. Microsoft setzt auf eigenständige, spezialisierte Lösungen für unterschiedliche Anforderungen (KMU vs. Enterprise, komplexe Produktion/Finanzprozesse vs. Standard-Buchhaltung etc.).
    • Die Integration wird aber weiter ausgebaut: Gemeinsame Datenmodelle, Dual-Write, Virtual Tables, Konnektoren und Power Platform als übergreifende Klammer.

 

  • Wird Microsoft Buchhaltungsfunktionen in die CRM-Welt (Dataverse) integrieren?
    • Nicht im Sinne einer kompletten Verlagerung. Vielmehr sollen Finanzprozesse (etwa in Finance & SCM, BC) eng mit Sales/Service-Daten vernetzt werden.
    • Es bleibt aber ein Getrenntsein von ERP-/Finanz-Lösungen und CRM-Lösungen, nur mit deutlich stärkerer Verzahnung.
  • Programmiersprachen und Entwicklungsumgebungen
    • CRM/Power Platform: C#, JavaScript/TypeScript (PCF), Power FX, Low-Code-Tools.
    • Finance & SCM: X++ (weiterhin), eigenständiges VS-Projekt mit .NET-Bezug.
    • Business Central: AL in VS Code.
    • Gemeinsame Versionskontrolle über GitHub oder Azure DevOps ist möglich, aber die Tooling-Silos bleiben zum Teil bestehen.
  • Gemeinsame Stammdaten (z. B. Vendor vs. Account)?
    • Über Dual-Write und Konnektoren kann man Debitoren/Lieferanten synchronisieren oder abbilden. Eine echte „1:1-Fusion“ all dieser Tabellen in Dataverse ist aber nicht in Sicht.
    • Ziel: Redundanz verringern, gemeinsame 360°-Sicht auf Kunden/Lieferanten – aber weiterhin getrennte ERP- und CRM-Systemlogik.

 

6. Quellen und weiterführende Links

Insgesamt geht Microsoft nicht den Weg, die einzelnen ERP-Lösungen (Finance/SCM, Business Central) vollständig in den CRM-/Dataverse-Stack zu integrieren oder komplett auf C# umzustellen. Vielmehr gibt es verstärkte Investitionen in Schnittstellen, Synchronisationsmechanismen und die Power Platform. Damit soll einheitliches Stammdaten-Management und durchgängige Prozessketten (z. B. vom Lead in Sales bis zum Zahlungseingang in Finance) realisiert werden – ohne die Eigenständigkeit der Plattformen vollständig aufzuheben.

 

 

Aus der Sicht eines Microsoft-IT-Spezialisten lässt sich also festhalten:

 

  1. Kurz- bis mittelfristig:
    • Weiterhin separate Applikationsplattformen, aber stark verbesserte Integrationsmöglichkeiten.
    • Mehr einheitliche Konfigurationen und Out-of-the-box-Konnektoren (z. B. Dual-Write, Virtual Tables).
  2. Langfristig:
    • Tendenz zu einem „Single Source of Truth“ für Stammdaten dank Dataverse/CDM, ohne dass ERP-Anwendungen ihre eigenen Datenbanken komplett aufgeben.
    • Fokus auf die Power Platform als verbindendes Element für Low-Code, Pro-Code und KI-basierte Szenarien.
  3. Empfehlung für die Entwicklung:
    • C# und .NET bleiben führend für CRM-nahen Code (Plug-Ins, Azure Functions).
    • Business Central- und Finance-/SCM-Projekte benötigen weiterhin AL bzw. X++.
    • Gemeinsame DevOps-Prozesse können in GitHub oder Azure DevOps gebündelt werden, allerdings mit Plattform-spezifischen Build-Prozessen/Pipelines.

Damit solltet ihr gut aufgestellt sein, um eure Lösungen in die Zukunft zu führen, auch wenn „eine einzige“ Codebasis für alle Dynamics-365-Produkte derzeit nicht geplant ist.

 

 

Überprüfung mit Copilot hat folgendes ergeben:

 

  1. Dynamics 365 CRM: Diese Umgebung basiert auf der Power Platform und verwendet Dataverse als zentrale Datenbank. Anpassungen und Erweiterungen erfolgen über Power Apps, Power Automate, Plug-Ins in .NET/C#, Power FX und JavaScript
  2. Dynamics 365 Business Central (BC): Diese Anwendung ist technisch eigenständig und basiert auf dem AL-Sprachstack. Sie läuft in einer Azure-Umgebung, die jedoch nicht Dataverse ist. Die Integration mit Dataverse erfolgt über den Business Central Connector oder Standard-Schnittstellen wie API und OData
  3. Dynamics 365 Finance: Diese Umgebung basiert auf der Finance and Operations-Plattform und verwendet X++ als Hauptprogrammiersprache. Die Datenspeicherung erfolgt in einer Azure SQL-Datenbank, jedoch nicht in Dataverse. Es gibt jedoch Möglichkeiten zur Synchronisation von Daten mit Dataverse über Dual-Write

 

Entwicklung und Integration:

  • Microsoft setzt verstärkt auf die Integration der verschiedenen Systeme über Standard-Konnektoren und -Modelle. Ein vollständiges Verschmelzen der Datenbanken ist jedoch in naher Zukunft unwahrscheinlich4.
  • Die Power Platform spielt eine zentrale Rolle bei der Integration und Automatisierung von Prozessen zwischen den verschiedenen Dynamics 365 Anwendungen5.

Produktfamilien in den USA:

  • In den USA gibt es keine zusätzlichen Produktfamilien in der Dynamics 365 Welt, die nicht auch in Europa verfügbar wären. Die Dynamics 365 Produktpalette ist global einheitlich und umfasst die gleichen Anwendungen und Funktionen.

 

1: Aktueller Stand der Dynmics 365 Produktfamilie

Stand heute betreibt Microsoft die Dynamics-365-Produktfamilie zwar unter einem gemeinsamen Markendach, allerdings sind die darunterliegenden Lösungen – insbesondere in Bezug auf ERP (Finance, Supply Chain Management und Business Central) – technisch auf unterschiedlichen Fundamenten aufgebaut. Parallel dazu existiert die Power-Platform-Welt, mit Dataverse (ehemals Common Data Service) als zentrale Datenbank für Dynamics 365 Sales, Customer Service, Marketing usw.

 

2: Dynamics 365 Business Central

Dynamics 365 Business Central ist technisch eigenständig, basiert auf dem AL-Sprachstack (ehemals C/AL), läuft in einer Azure-Umgebung, die jedoch ebenfalls nicht Dataverse ist. Development erfolgt in Visual Studio Code (plus AL Language Extension), GitHub kann als Versionskontrolle genutzt werden. Integriert sich mit Dataverse beispielsweise über den Business Central Connector oder über Standard-Schnittstellen (API, OData), aber die Datentabellen (z. B. Customer, Vendor) liegen auf einer eigenen Datenbasis.

 

3: Dynamics 365 Finance und Supply Chain Management

Dynamics 365 Finance und Supply Chain Management basiert auf der Finance and Operations-Plattform. Entwicklungsumgebung: Visual Studio (speziell angepasst), die Programmiersprache ist vorwiegend X++. Datenspeicherung in einer Azure SQL-Datenbank – jedoch nicht in Dataverse. Man kann über Dual-Write Daten mit Dataverse synchronisieren, um z. B. Kunden und Lieferanten mit Accounts/Contacts im Dataverse zu spiegeln.

 

4: Fazit zur Microsoft Strategie zu Dynamics 365

Völliges „Verschmelzen“ von Business Central, Finance/SCM und CRM in eine einzige Datenbank ist in näherer Zukunft eher unwahrscheinlich – zu groß sind die bestehenden Installationen, zu unterschiedlich sind die Use Cases und Technologie-Stacks. Die Tendenz geht eher zu einer immer engeren Integration über Standard-Konnektoren und -Modelle.

 

5: Microsoft Strategie

Microsoft verfolgt eine klare Cloud-First-Strategie: Alle ERP-Lösungen (Business Central, Finance, Supply Chain Management) laufen in Azure. On-Premise-Versionen gibt es zwar weiterhin, aber der Innovationsschub ist in der Cloud. Power Platform wird für Automatisierung, Analysen (Power BI) und App-Entwicklung in allen Bereichen (CRM, ERP, IoT, Portale etc.) immer wichtiger. Eine stärkere „Native-Integration“ in Dataverse, sodass z. B. Stammdaten nur noch einmal gepflegt werden, ist schon in Arbeit (Dual-Write, Konnektoren, Virtual Tables etc.).

Dynamics 365 Plattform
Dynamics 365 Plattform

Comments are closed

Seiten