tag:blogger.com,1999:blog-12948038.post6618735219497837637..comments2023-07-29T09:15:17.416+01:00Comments on allan's blog - Agile & Digital Business: BPM - is it just programming the corporation? (And the SAP Irony)allan kellyhttp://www.blogger.com/profile/06262139490250478379noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-12948038.post-68752529061683796322009-10-23T23:37:26.056+01:002009-10-23T23:37:26.056+01:00Allan
There is indeed the idea to regard the orga...Allan<br /><br />There is indeed the idea to regard the organization as a programmable. While the customization <> programming argument is idiotic as you rightly point out, there is a crucial difference between a program and a process. BPM people often, though not always, take "end-to-end" further than some programmers in that they regard human involvement as conceptually the same as machine activity, merely a different means to an end.<br /><br />A person knowledgeable in HR may not tread on FI/CO turf just as well as a Java person may not tread on the DB2 admin's turf. It is a matter of project context and configuration management in how far you diverge from it. SAP is a 3rd party application with APIs, release schedule and upgrade policies just as well as Eclipse is to developers delivering extensions to the platform. You don't see too many developers using RCP that have much of a clue of the inner workings of OSGI or the compiler or syntax coloring frameworks. The reason to stick to this model and the somewhat implied though never *required* separation of duties is economical, not organizational or personal. There is no implied restriction on SAP people that they can't work on different modules - it's just too darn risky to have them do that, just as well as you would normally not have all your team tamper with the complete details of Eclipse.<br /><br />This is the one place where I have found a *real* difference between the, classical you may say, agile/XP/... understanding of the word "agile" and the BPM/SAP folks is the picture of human beings and testing. Agility in the BPM context, as I see it, is most often understood as "agile in execution on top of" but not "agile in changing." A corporation is considered agile if it can rapidly execute the routine parts of its operations, hence react quickly in higher-level activities. However, it does not mean rapidly changing these routine parts, and that is something where the classical interpretation perhaps adds a richer view.<br /><br />But again, I don't regard this as a product-specific property. SAP is, for example, just as open as Eclipse or any custom-made Java product. You can re-code all the ABAP there is, but don't expect too much the next time a release upgrade comes along.<br /><br />Hence, I think you are interpreting "end-to-end" and "agile" in a way that was never intended by these folks, but that also does not really matter. The perhaps implied view that the grunting, bearded SAP trolls are not able to be agile is more a function of semantics and perception than one of ability. As we all know, once the scale of the problem (and indeed I'd argue that FI/CO is well beyond the scale of Eclipse) goes out of hand, it is hard to stay agile. But that is not something that one should take against them.<br /><br />HansAnonymousnoreply@blogger.com