Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181923
Active Participant
0 Kudos
Original "lead-in" blurb (added in to clarify why the post has the title it has) Those of us lucky enough to be exposed to SAP's evolving vision here at TechEd2006 cannot help but wonder whether SAP will succeed in ridding our workplaces of those nasty developers, just as the Pied Piper of storybook fame was able to do with the rats of Hamelin. My own guess is that SAP WILL eventually succeed in this effort, but that to do so, it must find good ways to help developers disappear on their own ... by becoming Business Process Experts. Permit me to say at the outset that I am all in favor of a future in which Business Process Experts use Visual Composer and its descendants to do "code-free" IT. And also, that I think SAP will succeed in helping to shape and create this future. Anyone who thinks that a model-driven code-free IT is not "in the cards" is simply too young to remember when COBOL programmers had to use escape sequences to drive their screens, or when Powerbuilder programmers had to code their own arrays for handling multiple instances of frames, or when IBM systems programmers had to bring NCP down in order to add or delete a tube. At the same time, I think that SAP will only succeed in realizing its vision if it finds ways to help the developers of today become the Business Process Experts of tomorrow. In other words, I personally do not think that the Business Process Experts of tomorrow will arise from the ranks of the "business process (re)-engineers" of today, nor from any other community which seriously thinks that the "T" part of "IT" is a trivial undertaking. Suppose for the sake of discussion that I'm correct in this claim - that the Business Process Experts of tomorrow will evolve from the developers of today. (I ask for your assent to this proposition simply to avoid having to take the time to state up front my reasons for believing this - if anyone is curious why I believe this claim to be correct, I'll be happy to elaborate.) Then one very simple - deceptively simple- way in which SAP can help the developers of today evolve into the Business Process Experts of tomorrow is to: enable exports from Visual Composer to Developer Studio. At first glance, this may seem exactly "backwards". Why bother enabling exports which seem to proceed in exactly the opposite direction that SAP wants to go? The answer to this question is the same as it's always been: you've got to take folks from what they know to what they don't yet know. And for developers, this means showing them the future (code generated in VisComp) by translating it back into the present (code that looks, feels, and handles just as if honest-to-goodness developers had built it in DevStudio to begin with.) In particular, suppose a developer was able to use DevStudio to examine code originally generated in VisComp and exported into DevStudio afterwards. One of two things is going to happen, or both. The developer is going to say that the code sucks, or that the code is pretty damn good, or both, i.e. that some of the code is OK and some of the code is just terrible. (It will take a while for any developer to say that code generated in VisComp is actually more than just "OK".) But either way it's a win. If the developer is correct in saying that some of the code is bad, then he or she should be able to demonstrate this by making improvements to it in DevStudio ... and these improvements can then be factored into the code-generation mechanisms of VisComp. Vice-versa, if the developer finds that VisComp generates some pretty respectable code, then this will increase his or her trust in VisComp as way of doing his or her job well. As I said, it's a win either way - SAP has provided a mechanism for co-opting developers into their own re-invention as Business Process Experts. But equally importantly, by allowing developers to fine-tune VisComp code in DevStudio, SAP would be providing a "base camp" in its trek up Everest. What I mean by this is that it's foolish for SAP to think that it's going to get VisComp "right" the first time around, or the second, or the third. In the beginning, VisComp will generate little better than caricatures for all but the simplest business processes. And the simplest way to turn these caricatures into some semblance of IT reality is to let developers finish the job in DevStudio. Plus, as I said above, these efforts by developers in DevStudio can be fed back into the code-generation processes of VisComp, so that gradually, with each iteration of this feedback loop, there is less and less that the developers have to do, and therefore more and more of a finished product coming out of VisComp the first time around. For those of you who are wondering what developers could possibly find so wrong with code generated out of VisComp, I'm thinking primarily of the correct class/interface/method infrastructure for retrievals from non-BW back-ends - a problem which everyone except developers tends to hand-wave as having been solved by Codd and His prophet Larry. (Hey - that's a pun I didn't realize I was making when I wrote it ... honest!)

1 Comment