X
Business

Crossing the chasm: from DBAs to Developers

Large IT vendors are fond of trying to use the breadth of their ‘technology stack’ to convince us that they can bridge the divide between the development team and the operations function. This gap, as we know, results in the all-too-common scenario where applications are simply thrown over the wall in whatever form they exist.
Written by Adrian Bridgwater, Contributor

Large IT vendors are fond of trying to use the breadth of their ‘technology stack’ to convince us that they can bridge the divide between the development team and the operations function. This gap, as we know, results in the all-too-common scenario where applications are simply thrown over the wall in whatever form they exist.

NB: with the push for Agile and Rapid development necessitating a, “many releases little and often” state of affairs – it’s tough to know who to blame here… so let’s blame the customer for now.

Speed is everything these days; time is money after all – so now we must also consider rapid application deployment alongside rapid application development. Also called remote control software deployment, news out of Moscow in Russia yesterday from Famatech is evidence of the company’s efforts to coin yet another phrase to describe rapid admin with, you guessed it, the Radmin deployment tool.

System administrators and/or DBAs using heterogeneous network infrastructure, have typically had to install and activate a large number of licenses manually. This is almost redolent of the virtualised application management that I talked about last week. These are tools to automate and manage and try to cross the chasm.

Technology big boys like IBM will talk about products such as Rational ClearQuest and the role they have to play in bug tracking to stop shoddy applications being thrown over the wall – but at the same time, they bill these as process automation tools or reporting and lifecycle traceability offerings.

I’m trying to convey the fact that there is some fuzz on the airwaves here. What kind of development process do we want? What kind of deployment process do we want? What kind of application update process do we want? What kind of process do we want to track these deployments through the lifecycle?

Crucially though, do we need ALL these steps?

Possible answer = we probably need a degree of each but not as much as we’re being told we do.

It’s for sure that we’re all being over-branded and over-sold in the application management space. Cutting through this fog is going to be tough and is only likely to get harder.

Editorial standards