Information Models/Business Object Models

[#1]

Many companies looking at implementing SAP and SOA/eSOA already have some information models/business object models based on the information/objects needed to drive the processes today. Probably SAP will play/are playing an important role/part of the landscape but there are and will be other solutions too. Are there any good documentation, e.g. entity relationship diagrams etc, that describes the SAP master data object models (Customer, Vendor, Material, Business Partner, Product etc) or the capabilities of the models (because they are configurable)?

Are there any good way of finding this information in the SAP system?

Related to this question, have anyone seen the detailed description of the Business Object which the SAP Enterprise Services are based on?

In the ES Workplace it seems like SAP have not released this information yet but I guess they have modeled it in the ESR to create the Enterprise Service definitions,do anybody know if this will be released and when?

Also related to this question, SAP NetWeaver MDM comes with predelivered data models based on the master data objects in the SAP busienss applications (ERP, CRM, SRM etc). How smiliar are these to the complete models in ERP, CRM, SRM etc?

Based on the question above, are/shouldn't these models be based on the eSOA/ES Business Object models in the ESR? Do anyone have any input on when or if there will be one common repository for this in the near future?

The last question related to this. When looking at general information modelling, for e.g. a whole enterprise, based on the needs of the business/processes, should you now, with SAP eSOA, try to map that to the Business Object models that come with the Enterprise Services or should you map to/start from the models that come with the SAP applications (ERP, CRM, SRM, SCM etc)?

From my knowledge there is not always a 1-1 mapping between these models. Any experiences/input?

Many questions in one go but I thought they where related so I posted them in one go. Feel free to only answer/give input on a subset.

[MendelKoerts]

Now these are the type of questions that belong in this forum, to my opinion!

I may be taking a short-circuit here, but the physical data-entity itself and the ES code will remain in the back-end for many many years. Therefore I'd say keep these as the basis reference for data modeling, provided the master record is maintained there (since you mention MDM). Regard the potential limited access to the BO-attributes via the ES as a constraint. My consideration here is that you can always extend the data-entity attributes in the back-end system and modify the ES to make it all work again.

[Former Member]

Hello Mendel,

I agree with your "short-circuit" and that is probably the correct approach right now, but the ES BO models are there some where inside SAP and as SAP is becoming more and more open, the external community should in my opinion get access to the models. This would benifit both SAP and the community and could also be the foundation to really moving to model based development.

Concerning SAP MDM, in a landscape where SAP is only a part I see a value of using solutions like SAP MDM but the it should be "one" logical repository for BO because you do not want to update or model your BO several times. By having one logical metadata repository you should be able to model (metadata wise, e.g. BO, processes, ES, Process Components, integration scenarios, GDT etc) your complete IT landscape. This would be a godd foundation for Governance :-).

This will also be even more interesting and important now when SAP (sometime this year) releses the "Project Galaxy" (the new Eclips based BPM environment). It is not really clear to me (or SAP at this stage perhaps ) what will be included but potentially (and in the presentatiosn from SAP) the will be a information/BO perspective that relates to the processes described in BPMN.

It will also be interesting to see how SAP have done in the new "Application Platform" (which the "SAP Business By Design" is based on) when it comes to process modelling. My understanding is that SAP have really used the "model to code" based approach which hopefully mean that the processes are not "hard coded" in ABAP or at least have easy to use models to extend the processes and functionality in SAP.

Regards,

Markus