Classical ABAP -- Is the END in sight -- I think so

Question

Going on again from the posts on "Persistent Objects" it seems to me it's only a matter of time before "Classical ABAP" is dead in the water.
For example take a sales order. Once it's been created why on earth should transactions like VA02 / Va03 etc have to execute  a whole lot of code to display it / manipulate it.
If its stored as a "Real Persistent Object" then it just needs to be retrieved via its instance or ("key")  and manipulations should be simple.
You'd have all the info you need encapsulated within the object such as Partners, delivery information etc etc so you would only need minimal coding to do anything with the order.
Object management would be responsible for maintining the "physical data store"'.
All you would need to do say if the delivery address changed would be to do something like this
<b>Get.Order xxxxxxxxxx
Change. delivery.address =   new  address
save object.
No more complex ABAP etc.
Just have a lok at the code in program SAPMV45A which has to be executed each time you do a VAXX transaction.
Would be much simpler to have a basic standard code Get.Object=saleorder.salesorder.num
display.object=object key.</b>
Implementation of this I agree would be difficult considering the amount of legacy code in the system but given the usefulness of Object Orientated coding this has to be the end logical outcome.
Data storage would probably need to be much greater but given the fact that disks of around 1TB can be had for less than 300 USD these days I don't think that's an issue any more.
Anyway I've just mulling around some ideas which I've been thinking about since reading an initial post on "Persistent Objects".
I'd be interested on other views on this development whatever you think.
Cheers
Jimbo

Answer 1

Hi Guys,
just to put in my take on some of this.
I find it interesting that SAP have "helped us out" by committing to not releasing a new ERP release for five years. They tell us that the reason for this is to give customers some certainty and minimise TCO.
My view is that the move to SOA and OO principles means they have to go back and rewrite all the old Dynpros that mix UI code and Business Logic together. Not only is this a huge job, but now they are going to be touching all the old ABAP code that hasn't changed in years. This will create a QA and support challenge for them as I suspect that some of the old code in GL and SD would have hardly been changed for a decade or more.
CRM is interesting. While there is extensive use of OO concepts, including persistent object services, it is by no means consistently implemented. Most frustratingly there is still very little documentation to help the developer. It is still a case of wandering along with the debugger to see how stuff hangs together, and this is much harder in OO code than procedural.
Of course the emerging development regime is "Model Driven". So maybe application development might involve using a BPML tool to model the process, then extend the model down to incorporate the underlying business objects. The modelling tool then assigns attributes and the standard CRUD ( create, read, update and delete) methods to each business object and describes the rules that exist between business objects. This is all done in the modelling tool, not by writing code. In theory it is all language independent.
Now we employ a developer for a few days to write the language specific pieces, which only consists of the CRUD methods. Maybe we employ two developers because we want some of our business objects on one platform and some on another. Or maybe we don't need any developers because our modelling tool is clever enough to generate the persitency layer and the defined rules take care of everything else.
Now we need a user interface ( the service interfaces are already supplied by the platform). Well that could be pretty easy if we used a tool like Visual Composer. Link a few Business Processes, or Business Objects, together and move the UI elements around the screen a bit and away we go!
If we need to change something we adjust the model and regenerate. (I'd like to see that on a production system)
Sounds easy! Now all we need is a modelling tool to generate the BPML tool - that is where the real opportunity lies.
Cheers
Graham