There's an interesting thread going on over at InfoQ regarding the relationship between BPM and Software Engineering.
One subtext of this discussion raises a wider question - When is it "Programming" and when is it "Software Engineering"?
I'm not sure that the distinction really matters... it's kind of like trying to nail down a definition for "Scripting Languages" rather than "Real" programming languages... but I'd like to share my thoughts.
I think that it's Software Engineering when your primary focus is on the relationships and interactions between software components. Programming is when your primary focus is on implementing specific requirements.
I know that's a pretty mushy distinction, but it's the best I can come up with for now...
To build on this distinction a bit more: It is my very strong belief that everyone should be taught how to Program. Reading, Writing, and Arithmetic just aren't enough for the 21st Century - Everybody should be able to write simple programs.
In contrast, Software Engineering is a very specialized field and way beyond the needs of most people. Like Electrical, Mechanical, Civil and the other Engineering disciplines, it takes years of preparation to master. In my experience all Engineering boils down to math and metrics (How else can you measure the effectiveness of an algorithm?).
Bringing ths back to the BPM/Software Engineering discussion going on at InfoQ... I agree that BPM is not Software Engineering (it's more akin to Process Engineering). There's a huge amount of Software Engineering that goes into building a BPM suite, but that doesn't generally concern those who are actually using those suites.
When implementing a Managed Business Process you must employ good Programming skills - but in most cases you are building within the dictates of your BPM suite's Software Architecture. To me that's not really Software Engineering, it's Programming.
What do you think?
No comments:
Post a Comment