How to Organize Business Applications and Application Services?

Erick18 · ‎06-27-2022

Hello,

We are starting to create Business Applications and Application Services at our company. Our company has many different child companies that run the same business applications however they are owned and maintained by people at those child companies. For example, lets take SAP.

Should we structure our Applications like scenario 1 or scenario 2?

Scenario 1:

Business Application = SAP

Application Service = Company 1 SAP PROD

Application Service = Company 1 SAP Test

Application Service = Company 2 SAP PROD

Application Service = Company 2 SAP Test

Scenario 2:

Business Application Parent= SAP

Business Application Child = Company 1 SAP

Business Application Child = Company 2 SAP

Application Service = Company 1 SAP PROD

Application Service = Company 1 SAP Test

Application Service = Company 2 SAP PROD

Application Service = Company 2 SAP Test

Thanks,

Erick

Daniel Carvalho · ‎06-28-2022

Hi Erick

In my perception of CSDM, I would NOT choose option 1, never.

I also perceive option 2 as not perfect, but still better than 1.

The way I have understood Business Applications, this register/item reflects the "concept" of an information system in a company (not simply a "naming aggregation").

Let´s take your SAP example to a stretch of a multi-country organization. Here in Brazil tax and accounting are so very different from US, that I really feel the need to ask you if you would agree to the view in which the concept of Company 1 (USA) SAP is for sure equal to the concept of Company 2 (Brazil) SAP?

I would not. It seems to me that they may share the same attributes of Vendor and even perhaps model/version (baseline source-code), but past the 2nd day of implementation/customization, they are not the same concept of application anymore. They become separated Entities.

Unfortunately (but only at first sight in my opinion) any other field/attribute that could be used to stablish this difference (based on geographic naming, for example) would not fix the usability (UX) complexity of having 2 BA´s with the same native name ("SAP"). Therefore, it becomes imperative to add the geography name (or company name if it fit´s better the whole organizational culture) to the Business Application Name.

So, I would defend this scenario 3:

Scenario 3:

Business Application Parent = NONE => Business Application NAME = "SAP USA" (or Company 1 SAP)
Application Service = "SAP USA PROD" (or Company 1 SAP PROD)
Application Service = "SAP USA Test" (or Company 1 SAP Test)

Business Application Parent = NONE => Business Application NAME = "SAP Brazil" (or Company 2 SAP)
Application Service = "SAP Brazil PROD" (or Company 2 SAP PROD)
Application Service = "SAP Brazil Test" (or Company 2 SAP Test)

To me, this implements more “respect” to the independency level of each application.

Hope it helps you.

Cordial

Daniel

View solution in original post

matt barrett1 · ‎06-29-2022

We have taken it a step further to support this type of approach, to support a similar use case, the CI name field has become a calculated field, this has its drawback but makes it easier to understand on tasks and on reports;

Used By - USA / Brazil etc

Category - Finance / HR etc

App Name - SAP / Salesforce

Environment - Production / Development etc < on the service

So the CI name would be USA - Finance - SAP - Production <though if production the environment value is not shown as we consider production the default value.

Jacques Clement · ‎08-03-2022

I am wondering whether using a Business Service with two Business Service Offerings, one for Company 1 and one for Company 2, would not help. Then connect Business Service, Business Service Offerings and Application Services using the CSDM prescribed relationships.

This way you can still keep one Business App and one App Service per environment, but differentiate the support groups using the two distinct Business Service Offerings. The same could be done with Technical Services and Technical Service Offerings, depending on the type of support I presume.