Let's look at Finance and Operations from the cloud city.

I got a question about how one would describe Finance and Operations to someone that isn't technical but has a basic understand of some IT terminology and I thought that would be a fun excursion to discuss let's dig in.

Cloud First

Microsoft Dynamics 365 for Finance and Operations is a cloud first product. Microsoft is a cloud first company. Service offerings will always be cloud focussed. But what does that really mean? It means that while other deployment styles may be available, such as On-Premises, cloud will be the preferred and suggested deployment topology from Microsoft for most end users. This comes with several advantages such as is a Software As A Service (SaaS) so you can just pay and the application is there. There are no servers to maintain, no databases to administer, and everything that is client-owned, such as updated, have supporting technologies so clients can take ownership of the process or ask for help from their partners.

Real World Meaning of Cloud First

Because there is no server and no database to administer, that means you don't have to worry about uptime or OS level updates or any of the standard on premise server headaches that have to be managed. However, because there is no server or database for you to own, you don't have access to it directly. Unlike older versions of AX / D365 F&O, you don't have access to the database, code or any management utility built for application development. Consider AX 2012 in Production; you could go directly into the database if you wanted, view the code for a form if you wanted or even write code in production in the case of an emergency. Those days are over.

But, Wait! I need access to the database!

No, you don't. Microsoft has given you several tools built into the D365 Application to administer the DB, if needed, as well as supporting tools in Life Cycle Services, or LCS. LCS is a tool to help with administration tasks for D365 in a simple and streamlined fashion with an emphasis on simplicity. There are now zero instances in which you should be directly in the database to "fix" something. The product has matured greatly in the past 3 years. Additionally, if an issue occurs that does require some kind of SQL server level intervention, you can create a ticket with Microsoft to evaluate the issue, collect some data on the issue for the product group for root cause analysis and Microsoft will help address the presenting issue. Additionally, there are several supporting technologies to help with reporting on your data such as Power BI, the Entity Store, Bring Your Own Database, Analytics Workspaces, Azure Data Lake, Dual Write / Dataverse Integration, and Azure Synapse. Additionally Microsoft manages the database for you so your standard commodity type database admin stuff just gets handled automagically by back-end automation.

Where are My Servers Then?

D365 for Finance and Operations is largely a server-less application now. New non-development environments that are in the cloud are deployed using Azure Service Fabric. Additionally, for all environments that were deployed in the past, Microsoft is going back through and converting VM based environments to be service fabric based environments. So, the deployed app doesn't exist on just one server, it exists securely on potentially hundreds of servers. Because it is deployed on a fabric, "where" it is in that fabric doesn't really matter so long as the app keeps on processing requests. Microsoft manages all the pieces of the D365 App, the Service Fabric environment and the database connected to each part of the app. I could talk more about Azure Service Fabric as its a technology that I'm a big fan of but that would be another articles. For cloud deployments, Microsoft manages lots of server related stuff for you. For On-Premise deployments, those use a different version of the Service Fabric designed for use in your own data center. When creating a new environment, you select your preferred region in Azure but thats still in a service fabric cluster in that location that is geo-replicated elsewhere for DR/BC scenarios.

How Can I Integrate with it? How Can I get In and Out?

Microsoft has coverage for this too. There are several technologies and methodologies for getting data in and out as a transactional operation or a bulk operation. We'll cover each by use case.

I want to bulk import / Export Data

You can use the DMF to Import and Export Data. Depending on the scenario, Excel Integration may also work.

I want to Integrate with an Outside App

Depending on the specific use case, OData, a Custom Service or use of Dual Write / Dataverse Integration are worth looking out and making a selection based on what makes the most sense. Let's also not forget about Recurring Integrations.

I want to integrate Items on a schedule

Recurring integrations are great for items that are generated in batch from an outside system that we want to import into F&O for further action. This builds on data entities and the data management framework to support batched integrations. This would  An example would be EDI documents created nightly by a third party such as Invoices.

I want to use F&O as a back-end for another App

Using OData or custom services for all master and transaction related data for an outside applicaiton can work fairly well. This would use data entities or custom services to process all CRUD operations inside F&O at the request of an outside system. For instance, if you wanted to have a customer portal where they could create or update their account, place orders and view invoices, that's entirely possible with OData. The ouside app wouldn't need to know anything other than how to do basic CRUD operations with OData entities. OData is most suited for master and worksheet data - "List" management in general such as create a customer, create an order, update an order or similar. Custom Services are more suited for transacting upon worksheet data such as posting a sales order confirmation or sales order packing slip.

I want to maintain some master data outside of F&O and periodically sync it

Again, OData is a good candidate as this is, in general, "List Management".

I want to have data from F&O in an outside system for read only

Depending on the frequency on when data would be synced as well as the relative size of the data we are discussing, OData may be a good candidate but business events may also good a good candidate. OData can be used to provide data on a schedule based on a last updated date or something along those lines. Business events can notify outside systems that something has changed inside F&O and the consumer of the event may use that to run some process or update related to that specific event. Lastly, recurring integrations could produce an output payload with everything for the outside system "poll and troll" through just processing all records for that entity and posting updates as needed. Lastly, F&O can consume outside APIs too so as changes occur, hooks to that record update in F&O could be added to push the specific update outside as the update occurs.

I want to use the Power Platform

Dual Write is a great for enabling the use of the Power Platform to support extension of the core offerings of F&O. This will help create tightly coupled, real-time bi-directional integration between F&O and a Model-Driven Power AppsBut I have a Unique Scenario

There are many integration strategies available inside Finance and Operations. Select the ones (yes, plural) that make the most sense for your given scenario and it's constraints. Each strategy may have a specific use case and your entire process scenario may use different strategies based on directionality.

Bringing it all Together

Compared to a standard on-premise application like AX 2012, D365 for Finance and operations is a significant shift in thinking. You lose some freedoms such as direct DB access but you also aren't "on the hook" for the infrastructure either. In D365, you...

• Don't have DB access but you don't have to administer it either. 
• Don't have access to code in production 
• There is no client to install / update
• Use LCS and other tools to interact with the application and supporting system to do common tasks
• Use a web interface almost exclusively for non-development related tasks ( either F&O or LCS )