In this thread here: Preparing for SMLT ("Was dem einen recht ist, ist dem anderen billig", Part II) Wolfgang (Valtin) used the phrase "reliable data models for SAP applications", and I am very grateful to him for doing so. The reason I'm grateful is that he correctly "read between the lines" of my post about SMLT. That is, the reason I brought up the topic of preparing for SMLT was because SMLT-preparation would be a lot easier if there were "reliable data models for SAP applications". And as I have said before, the absence of such data models will prove to be a real hindrance in SAP's attempt to convince its customers to come along on the long march toward Enterprise SOA. To provide a concrete example of why this is so, let me share a "hypothetical" experience which I had during a "hypothetical" OTC initiative. A very senior and experienced FI/CO consultant (and I mean VERY) asked me to see if it would be possible to intercept F-28 processing between this selection screen: Figure 1: 
and this screen: Figure 2: 
Not being familiar with F-28, it took me a "little" while to find out that: a) yes, there is an intercept in the "right place": open_fi_perform_00000900_e b) but this intercept will not allow a customer to change what displays on the screen in Figure 2 (the two fields in red) because a copy of postab is all that is passed to the exit, not the "real" postab. And don't even ask how much longer it took me to find the code that is filling postab from the underlying tables. So - suppose someone wants to write a service that does what currently can't be done in F-28. Then to be cost-effective, whoever writes this service will have to know all about the code and data model underlying F-28 already. Otherwise, the learning curve will be too expensive. But does the SAP community really think that it can realize the Enterprise SOA vision using only consultants who already know all about the code and data model underlying any particular transaction, such as F-28 in the case above? And if not, what does the SAP community think is more dangerous: c) divulging the data models relating structures to tables or d) delaying the time-frame for realization of SAP's Enterprise SOA vision (because currently, there aren't enough consultants with reasonable rates who know enough about SAP internals)?
and this screen: Figure 2: Not being familiar with F-28, it took me a "little" while to find out that: a) yes, there is an intercept in the "right place": open_fi_perform_00000900_e b) but this intercept will not allow a customer to change what displays on the screen in Figure 2 (the two fields in red) because a copy of postab is all that is passed to the exit, not the "real" postab. And don't even ask how much longer it took me to find the code that is filling postab from the underlying tables. So - suppose someone wants to write a service that does what currently can't be done in F-28. Then to be cost-effective, whoever writes this service will have to know all about the code and data model underlying F-28 already. Otherwise, the learning curve will be too expensive. But does the SAP community really think that it can realize the Enterprise SOA vision using only consultants who already know all about the code and data model underlying any particular transaction, such as F-28 in the case above? And if not, what does the SAP community think is more dangerous: c) divulging the data models relating structures to tables or d) delaying the time-frame for realization of SAP's Enterprise SOA vision (because currently, there aren't enough consultants with reasonable rates who know enough about SAP internals)?
2 Comments
