Platform Hosts and Platform Applications - How to map these?

[Tom104]

Hi All,

I'm trying to get some clarity regarding how we should be mapping our Platform Hosts and Platform Applications.

What I'd like to address specifically, is what we classify as a platform host/platform application.

As an example, my current firm use Microsoft Dynamics extensively. This is hosted within Microsoft Azure (Which they have modelled as a Business Application).

However, a number of custom "Business Applications" have been built within Microsoft Dynamics.

As such, which of the following should be listed as the Platform Host (Microsoft Azure, or Microsoft Dynamics)?


If, we determine that Microsoft Azure is the Platform Host, and Microsoft Dynamics is a "Platform Application", what then should be the relationship between Microsoft Dynamics and the "Business Applications" built using this?

[CFrandsen]

Hi @Tom104

Good question...
This scenario has been discussed quite alot during our implementation of  CSDM 4.0, especially when you’re dealing with SaaS/PaaS services and then building business apps on top of them.
I would approach it like this:

Platform Host: Is the infrastructure layer that supports platform applications. In your example, Microsoft Azure would be modeled as the Platform Host because it provides the underlying hosting capability.

Platform Application: the technical platform that customers use to build or configure solutions.
Here, Microsoft Dynamics 365 would be your Platform Application, since it sits on top of Azure and is the foundation for business applications built inside it.

Business Application: the consumable applications that the enterprise uses for business outcomes. So the custom solutions built inside Dynamics would be modeled as Business Applications.

Following the CSDM hierarchy wheb building the relations:

Platform Host (Azure) -> hosts → Platform Application (Dynamics 365)

Platform Application (Dynamics 365) → hosts → Business Applications (your custom Dynamics solutions)

I think this could be a way to go about it.

[Mathew Hillyard]

Hi @Tom104 

ServiceNow recommends that you don't nest Business Applications in a hierarchy. The EA application does not allow multiple Platform Host applications - there is one Platform Host and one or more Platform Applications. This can be tricky when you have complex platforms that can contain applications that are themselves a host for other applications (e.g. SAP, Azure, GCP etc.)

There are two choices:

1: Use Application Family

ServiceNow's description is: "An application family is an attribute to group a set of related applications based on manufacturer classification of their products." The demo data that comes with EA seems to support this as it contains (for example) SAP BI, SAP CRM, ERM, HCM and SCM. This is also a reference to the Application Family table so is data-driven and easily maintainable.

2: Use the Platform field

This is a little less data-driven as it is a choice field, but Azure is actually one of the OOTB options. I don't think this option fits your use case as I think it hides the true relationships.

With option 1, and your example you could have

• Application Family: Azure
• Platform Host: Dynamics 365
• Platform Applications: The apps that run on Dynamics 365
• All of them set to Platform = Microsoft Azure (optional)

It is open to interpretation however as in the EA product demo data, Azure and ServiceNow are Platforms, and ServiceNow ITSM is an Application Family - so there would be no Platform Host Business Application - just Business Apps that include a Platform and an Application Family. This seems a little confusing to me so whichever option you pick, be consistent across EA. I would go with Option 2 above - you can still tag platforms with the Platform field if you need to but I suspect it is overkill (and the fewer attributes we have the populate, the better!)

Using option 2, another example could be:

• Application Family: ServiceNow
• Platform Host: ServiceNow ITSM
• Platform Application: Incident Management, Problem Management, Change Management etc.

Note that in this option there is no Microsoft Azure Business application, so you will need to ensure that you are consistent across all platforms and ensure business processes can handle platforms (e.g. retirement).

I hope this helps!

Mat