How to Organize Business Applications and Application Services?

[Erick18]

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

[Vishal Savajia1]

Hi Erick, 

We can consider Two enterprises Company A and Company B, Though B is child Organization we can consider it as separate unit. In my view scenario 2 may be complex and will not provide holistic view of services spanning in different organization. 

Business Application  consumes Application Services. 

if you  want to go with Scenario two  then you can think in this way,  one  company then you can bifurcate  with different  business unit. 

Business units may have different  may have different Business Applications which consumes applications Services. 

[Daniel Carvalho · Accepted solution]

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

[SebastianKunzke]

I would agree to your scenario, if you work on separate instances with their own infrastructure. In this case I would probably use the business capability to summarize the SAP systems.

However, if the SAP instances are running on the same infrastructure and we just talk about different domains, I would suggest to run with scenario two. Because than we also have under the SAP Company 1 and SAP Company 2 a central infrastructure.

But without knowing the complete system we can not give you a clear answer. I would always try to lead me with those questions:

1. What do I have and what do I want to achieve? What process or use case will consume the data I try to build? 

Based on this answer also scenario 1 could be correct. Don't overbuild something in your system to just to follow CSDM, if you are not aware, why you want to use it. I will just cost you money. 

[David104]

I would be leaning toward option 2 given that they sounds like distinct application services, and by using a Parent/Child Business Application structure, you can provide the ord separation required but also keep them linked.

As you mature, you may be able to begin using Business Service Offerings to distinguish between which parts of the org are using the various Application Services.