When did coding become a dirty word?

Nobody ever said that writing integration code was fun, but maybe it's time that vendors recognised that it's still an important task in most IT departments.

This morning, I went to a Sydney breakfast seminar for Software AG, which was spruiking its Crossvision service-oriented architecture platform. Visiting tech evangelist Bjoern Brauel presented an all-too-familiar message -- namely, that the decision to implement SOA should all be about business benefits, rather than a technically-motivated choice.

Reinforcing that theme, Brauel then demonstrated how to build an application utilising Crossvision tools, all without (you guessed it!) writing a single line of code.

The notion that development can be completed without specialist knowledge way is a staple in these kinds of presentations. However, it's essentially not true. Granted, Brauel built the application without entering any actual code, but any process that involves naming and invoking methods looks to me more like traditional development than, say, creating a PowerPoint presentation.

Notably, when it came to question time, the queries from the audience took a decidedly technical bent. Could the system handle the import and export of BPMN documents? How did it integrate with ApplinX? What alternatives were available to Eclipse for web service coding within Crossvision? And how much effort would that coding take? "I'm assuming it's a big job to create those services," one audience member commented.

To be fair to Brauel, he handled such questions with aplomb, and acknowledged that someone is ultimately going to have to do the dirty work of service-enabling aged COBOL applications. Given the nature of the queries, and the obvious hunger by attendees for detailed technical information, that kind of acknowledgement deserves to be much more widespread.

We all know technology needs to deliver business benefits. We still need to know how to make it work at grunt level.