Business Applications and their associated Modules

[aducci]

From my understanding the Essential Meta-model, the Application provider class is used to represent the logical Business Systems in place within the organisation, however, I would like to know how the Modules of a particular application are defined, An example SAP Financials contains modules Supply Chain, Financial Accounting, Management Accounting and Corporate Governance, would I be correct to assume that SAP Financials is, in fact a composite application provider, containing the Providers SAP SCM, SAP FIN, SAP MA, SAP CG?
This works well with large autonomous modules such as SAP FIN (which can be procured separately to any other module)

The issue I find is that, when taking a bottom up approach to application modelling you often identify a list of applications, some of those may actually be modules of an associated parent(composite) application, meaning that in essential you will need to migrate from a application provider class to a composite provider slot.

On other occasions, you may find that an application is fairly small, and you dont care to identify the modules (until a need arises)

Am I modelling the applications correctly? if so, i can continue with the process (knowing that only when I reach a certain maturity will the application portfolio start to look correct)

[neil.walsh]

Hi,

The approach you've described is correct.

It's actually quite easy to manually migrate Application Providers to be Composites. You literally just drag the Application to the Composite class in the Instance Browser. This doesn't affect anything that's already been modelled as Composite is a sub-class of Application Provider.

Cheers

Neil

[aducci]

Thanks Neil.

Thanks, its good to know that I was under the correct assumption, my concern is that we would probably have to do a little more than change the object type, I am thinking that composite application providers will have different maintained attributes to the application providers i.e in the case of process linkages the composite is not really interacting in a process, it would be the actual module (application provider) in this case, hence we would need to change attributes (Slots) when migrating.

[jonathan.carter]

I think you and Neil are talking about slightly different things.

Neil is correct, the Composite Application Provider inherits all the attributes (slots) of the Application Provider. This means that we can drag the Application Provider instances to Composite Application Provider in order to re-factor it as a composite. All the relationships that it had as an Application Provider are preserved as a composite.

However, you are quite correct that now we are modelling at a coarser grain, the actual processes that it supports etc. may well be different. This isn't something that the tool can manage automatically for you. It may well be that the composite does support all the processes but equally we might need to re-model this to reflect the refactoring. However, no tool can make assumptions about how any of the dependencies change when we take an Application Provider to become a Composite Application Provider. The tool makes the refactoring of the instance itself simple but we must then re-factor the model accordingly based on our understanding of the way the organisation works.

Jonathan