ALM as a Barometer of Customer MaturityBy Michael Vizard | Posted 2012-06-05 Email Print
WEBINAR: Event Date: Tues, December 5, 2017 at 1:00 p.m. ET/10:00 a.m. PT
How Real-World Numbers Make the Case for SSDs in the Data Center REGISTER >
Customers that don't address DevOps issue may be more trouble than they're worth
Everyone likes to talk about the divide between IT and the business but there are lots of divides within the IT organization that can trip up the unwary solution provider.
One of the most contentious areas in IT right now is anything to do with "DevOps." As a catch phrase that covers anything to do with the handing off of an application to an IT operations team, the term seems innocuous enough. But by and large there is a not a lot of love lost between application developers and the people that manage IT operations. Developers often feel that the IT operations team is too inflexible and the folks that run IT operations of ignoring the limitations of the production environment that has to run the application they just created.
This tension is driving a lot of interest in application lifecycle management (ALM), which is a set of management tools that is designed to give developers and IT operations people more insight into the application being developed and the environment they are expected to run on. The basic idea is that by making it easier for developers and IT operations people to collaborate, the overall IT environment will run smoother. The trouble is that ALM can be a tough sell when the two parties that need to come together to fund the project think that the issue is basically the other guy’s problem.
In order to successful sell ALM a solution provider really has to get above the noise in the IT department. That means, says Gina Poole, vice president of marketing for IBM Rational Software, finding the CIO or CFO that really understands how all the dysfunction in the IT department is really costing the organization money. Fixing applications late in the development cycle is incredibly expensive. When that happens because the developer made some assumptions about the production environment that turned out to untrue, the cost of creating that application skyrockets, or the organization is forced to upgrade their IT infrastructure.
Of course, there’s probably a lot of money to be made by providing therapy to those dysfunctional IT organizations. But the real end goal should be to install a set of management technologies that allow the developers and IT operations people to get out of each other’s way. The more time developers spend collaborating with IT operations people the less time they spend actually coding. The more applications that get developed the more IT infrastructure that will be required, and that’s invariably a good thing for the channel.
The whole DevOps debate definitely creates an opportunity for the channel. The challenge is to not get sucked up in the internal infighting that wants up parallelizing far too many IT projects. In fact, if the customer is resistant to the whole ALM concept it’s a pretty good indicator of a lack of maturity when it comes to managing IT. That alone might suggest that a solution provider might want to steer clear of that account because the chances are high that customer is going to turn out to be a whole lot more trouble than they’re actually worth.