What is Dynamics 365?

Microsoft Office is the name of the suite of common business productivity applications that includes Word for word processing, Excel for spreadsheets, Outlook for email and scheduling, PowerPoint for presentations, and SharePoint for document management, among other applications. This suite of applications has become a common standard: Most people in the business world now use at least some part of Microsoft Office — especially Outlook — every day, 365 days a year. Microsoft has migrated Office to the cloud, as a subscription-based online Software as a Service suite of applications, and has branded it Office 365.

This move of Microsoft Office from on premise to in the cloud has proven to be extremely popular, as many organizations have now already transitioned their users from the desktop version of Office to Office 365. The computer network managers at most organizations prefer the online version because it’s much easier to manage a link to a website than to install and troubleshoot applications on the individual desktop PCs and laptops of users.

As a follow-up to Office 365, Microsoft came out with a cloud version of its ERP (again, enterprise resource management), which is financial, accounting, and operational software, and combined it with its CRM (again, customer relationship management), which is sales, marketing, and customer service software. It has branded this combination of ERP and CRM in the cloud as Dynamics 365.

The 365 in Dynamics 365 emphasizes that the software plays nicely with Office 365, and it sure does — it’s highly compatible and integrated with Excel, Outlook, and SharePoint, especially. Of course, 365 is the number of days in a typical year, so the name also imparts the constant availability of the software, every single day (even on the 366th day of a leap year).

A little historical perspective behind Dynamics 365

The Dynamics part of the name Dynamics 365 has quite an interesting history. Once upon a time, two college buddies, Steve Ballmer and Doug Burgum, were roommates at Stanford University. Steve went on to become the CEO of Microsoft, replacing Bill Gates, and Doug founded his own accounting software company in North Dakota called Great Plains. Doug would eventually become the governor of North Dakota. Great Plains started out with a popular character-based (in other words, nongraphical) version that ran on IBM compatible PCs on the old DOS operating system.

When the Windows operating system was first introduced in the early 1990s, Great Plains created a new software called Dynamics, which was a graphical-based software (you used a mouse and clicked graphical icons) that ran on Windows and, believe it or not, also on Apple Macintosh at the time. (Today’s version no longer runs on Apple.)

The original Great Plains Dynamics was written in a proprietary computer language invented by the Great Plains developers called Dexterity. Dexterity was written in the C programming language and was invented to speed up the creation of Dynamics. As it turned out, Dexterity was never used for anything other than Great Plains Dynamics and add-on products designed specifically for Great Plains Dynamics. Therefore, Microsoft has no future plans to continue developing new products using it.

Years later, Great Plains was acquired by Microsoft for over a billion dollars. When Microsoft acquired Great Plains, it picked up Solomon, another popular accounting package. Solomon, well regarded for its project accounting and job costing features, had been previously acquired by Great Plains, before Microsoft acquired Great Plains. Acquiring Great Plains along with Solomon gave Microsoft a strong domestic presence in the ERP market in the United States.

To gain a foothold in the ERP market in Europe, Microsoft acquired Navision, a highly modifiable ERP package with strong manufacturing features. Navision, founded in Denmark, had previously acquired Axapta, another more robust ERP package, also with extensive manufacturing features, from Damgaard, another Danish software developer.

Microsoft’s marketing department, which was quite fond of the Dynamics brand name, extended the brand to other Microsoft software products, including Microsoft’s CRM package, originally called Microsoft CRM, and later rebranded as Dynamics CRM. This CRM package wasn’t acquired from another company, but rather was developed by Microsoft internally. Microsoft CRM was one of the first packages that Microsoft migrated to the cloud, calling it CRM Online, in order to stay competitive with Salesforce.com, its main CRM rival. Microsoft CRM has captured a large share of the CRM market and is a successful and widely used product.

Microsoft’s marketing folks kept using the Dynamics name, eventually rebranding as Dynamics the other three ERP packages that the company acquired and adding a short acronym to distinguish among them.

Microsoft ended up with these four ERP packages — and one CRM:

• Dynamics GP (formerly, Great Plains) ERP – not moved to 365
• Dynamics SL (formerly, Solomon) ERP – not moved to 365
• Dynamics NAV (formerly, Navision) ERP – Business edition in 365
• Dynamics AX (formerly, Axapta) ERP – Enterprise edition in 365
• Dynamics CRM (formerly, CRM Online) – Sales/Service/more in 365

Microsoft realized that maintaining four separate ERP packages with four separate programming code bases, and a CRM package that didn’t natively talk to any of the four ERP packages didn’t make a whole lot of sense, and certainly didn’t provide for a long-term roadmap. Something would have to be done to simplify and unify its business software offerings.

To make matters worse, most of the components in these ERP packages weren’t web-based applications, but rather were the old-style client/server applications, which don’t run on web pages, and instead either need to be installed on each user’s computer or else require the users to log in to remote desktops or Citrix sessions, which is rather inconvenient and cumbersome to maintain for the IT department. The Microsoft ERP software needed to be migrated from client/server to web based. Fortunately, Microsoft CRM had been built from the ground up as a web-based application, so at least that didn’t need as much revision as the ERP software.

Reading the roadmap for Microsoft ERP and CRM

Microsoft needed to come up with a strategy for their business software solutions that would address the problem of having four unrelated, redundant, on-premise ERP offerings, with insufficient interoperability between their CRM and ERP solutions to boot. To address these problems Microsoft devised a fourfold strategy:

1. Move to the cloud because everybody is moving to the cloud, for many compelling advantages, especially the easier start-up.

   Customers want the ease of setting up and maintaining a software infrastructure for their ERP and CRM systems, and of course it’s much easier if the software vendor — in this case, Microsoft — handles all that for them. In other words, the systems are hosted by Microsoft, so you just surf to a web page, which is so much easier than buying servers, configuring them, installing software, creating backup plans, and on and on. Customers also prefer to rent instead of buy the software, because they can avoid having to shell out lots of money up front, even if it may end up costing them more money in the long run, which isn’t necessarily the case, either.

2. Modify several existing Microsoft applications to be web enabled rather than client/server, if they weren’t already web enabled, and then combine them into a large, unified offering with a common look and feel, and a common brand name, Dynamics 365.

   Microsoft already had several good applications, so rewriting an ERP and CRM from scratch would have been reinventing the wheel (not to mention that it would be impractical to do so). ERP and CRM systems are so packed with features and capabilities that they take many years, even decades, to develop and evolve to the level where they can address the needs of complex organizations.

3. Provide a simplified license that allows you to get all (or at least, most of) this combined software for one combined cost per user, as a subscription SaaS offering.

   The advantage to Microsoft here is that subscription-based revenue is preferred by stockholders because it tends to even out the revenue, providing steady and reliable profits year after year. The advantage to customers, dealers, and Microsoft is that obtaining Dynamics 365 involves less upfront cost and avoids the complexity of customers and dealers having to pick through a confusing menu of available modules to determine a price. Instead, a few basic plans include almost all the software.

4. Program these applications to have tight integration to other, more general Microsoft applications, tools, and technologies, such as Microsoft Office 365, Power BI, PowerApps, Common Data Service, and the like.

   Doing so increases the usefulness of the software and makes it more appealing to customers who already have a large investment in Microsoft products.

What’s in Dynamics 365?

Microsoft’s solution to its CRM/ERP roadmap problem was to create a SaaS subscription-based offering, available exclusively on Microsoft’s cloud service, Azure. It combines CRM with ERP along with tight integration to Office applications such as Excel, Outlook, and SharePoint as well as a few other applications, plus other, newer Microsoft tools and technologies such as PowerApps for building mobile and web apps, and Power BI for business intelligence reporting.

Dynamics 365 is a true SaaS solution; in other words, it’s not available on-premise; you can only run it in the cloud, just like Salesforce.com, Workday, Oracle’s NetSuite, and many other, newer competing CRM and ERP choices now prevalent in the marketplace.

In an effort to be all things to all people, Microsoft has jam-packed the capabilities that are included under the Dynamics 365 umbrella, extending the reach from ERP and CRM to FSA, PSA, HR, and POS.

Check out this table for a clarification of what all this alphabet soup of acronyms actually means.

Dynamics 365 is composed of the following major pieces:

• Dynamics AX ERP: Rebranded as Dynamics 365 for Finance and Operations, Enterprise edition (for larger organizations)

Or, alternatively, for ERP you can choose a simplified version of Dynamics NAV ERP, rebranded as Dynamics 365 Finance and Operations Business edition (for smaller organizations)

• Dynamics CRM: Rebranded as Dynamics 365 for Sales, including Sales Force Automation, Customer Service, and Marketing
• FieldOne: A CRM add-on that was acquired by Microsoft and became CRM Field Service and CRM Resource Scheduling
• Project Service: Another CRM module that is a project accounting/time-and-billing application
• Talent: A separate application that is human resources (HR) software for employee onboarding and has a self-service portal, employee benefits management, and so on
• Retail: Another separate application that is a point-of-sale (POS) system used for retail store operations

Dynamics 365 also has tight integration with a whole host of Microsoft technologies, including SharePoint, Excel, Outlook, PowerApps, Power BI, and the Common Data Service.

Dynamics GP (formerly Great Plains) and Dynamics SL (formerly Solomon) are both widely adopted ERP packages, especially in the United States. Microsoft is still maintaining, and to some limited degree, enhancing these products due to continued customer demand.

Though it’s true that many customers do not want to migrate from these products because of the large investment of time and money spent in the complex configuration and modifications they have made to the core systems, Microsoft’s R&D dollars and focus are clearly skewed toward favoring Dynamics AX (now Dynamics 365 Finance and Operations Enterprise editions). Microsoft’s vision is that AX is the future product to compete with its main rivals, such as Oracle and SAP. GP and SL are sometimes referred to as sunset products because they will eventually be phased out by Microsoft. However, the ERP world moves at a glacial pace because of the complexity and the mission-critical nature of the beast. In all likelihood, GP and SL will be around for many years to come, because of customers refusing to migrate.

Microsoft keeps rebranding its business software, and frankly, that can become confusing to the consumer. Of course, the seemingly endless rounds of renaming are for the purpose of staying current with buzzwords and trends, and are an honest attempt to clarify what the software is designed to do. To help you see clearly through this foggy haze, this table lists the major software applications that have evolved into Dynamics 365.

Standardizing tools and terminology in Dynamics 365

As the software that comprises the origin of Dynamics 365, such as Damgaard Axapta, has evolved over decades, and eventually became part of Dynamics 365, Microsoft has spent a tremendous amount of time, effort, and money to modernize it on the one hand and to standardize it to fit into the overall Microsoft environment of operating systems, databases, and development tools on the other so that Microsoft offerings would have a consistent look and feel. The work of thousands of software engineers has transformed the software to a point where it’s barely recognizable from what it started out as.

For example, Axapta (which become Dynamics AX) is customized using a proprietary tool unique to AX called the Application Object Tree (referred to as the AOT). Mastering the AOT was essential to becoming skilled in the customization of Dynamics AX. In Dynamics 365, the proprietary AOT has been done away with. Instead, Microsoft has substituted a more mainstream standard Microsoft tool — namely, Visual Studio. In Dynamics 365, you use the Application Explorer in Visual Studio to look under the hood of AX and manipulate the programming objects that make up the new Dynamics 365 cloud-enabled version of AX, Dynamics 365 for Finance and Operations Enterprise edition.

Microsoft has changed the proprietary terminology of the AOT to the standard terminology of Visual Studio, the application used by programmers to code computer programs using Microsoft programming languages, such as .NET. In other words, as Microsoft has taken existing applications, such as Dynamics AX, and transitioned them into Dynamics 365 components, the applications have been made to conform to overall Microsoft terminology and technology standards.

This table lists the terminology standardizations Microsoft made when migrating the Dynamics AX Application Object Tree (AOT) from AX to Dynamics 365 Finance and Operations Enterprise edition.