Last week I was on the second week of the App Vision World Tour and met with the press in Milan, Paris and London (funny story here for a later post perhaps).
In Italy the press seemed very interested and the interview lasted almost an hour. After the interview the reporter sent me these six questions. I replied with these answers. I’d be interested to hear how you would answer them. So get commenting.
Reporter: How is the timeline changing, if it is changing, for app development in consideration of Web 2.0 and cloud? Kevin: In many ways it is Web 2.0/3.0, the Cloud, Virtualization that is driving the changes we are seeing in IT. The ability to deploy quickly and cheaply means that the business can get the changes they want deployed inexpensively. But, the real cost is not in the deployment targets: it is in the methodology of deployment. With hundreds of changes being distributed daily: change has become a significant configuration management and release management problem that has to be solved. The velocity of change and the volume of change mean that human management of these is no longer possible, or desirable, and systems need to be put in place that give the visibility, control and repeatable automation to ensure perfect delivery every time.
Reporter: How does the new situation fit into the existing applications in a company? Kevin: Given the siloed nature of IT today the first thing we have to address is the connections, the handoffs, between the various silos. Orchestrating the interactions between the technology groups will make it possible to have full visibility into where projects are in the lifecycle. Adding automation to the existing manual process essentially changes nothing but the by-products of doing this are immense. First we get insight to the status of projects real-time. Next we get control of the process and empowerment of stakeholders; this increases the velocity of change and the quality of the decisions. And finally we get to see where the process bottlenecks are, where the wasted process steps are and eliminate them. No sending of memos – just new paths through the process.
Reporter: Considering the cloud: does it make sense to update an old application or should it be re-developed? Kevin: The build, buy, borrow decision for any application is always an interesting one. The ROI (Return On Investment) calculation is not as scientific as we would like to think: too many of the savings are always subjective and few people ever test their ROI numbers after the project has been implemented. So replacing an old system with an entirely new one, or adding new technology on top of the old, or switching to a hosted solution that already exists is very difficult. In my experience the choice often falls to what the decision maker is most comfortable doing rather than what is necessarily the best choice. Alas, lately, the Cloud has become fashionable and that has been the determining factor. So all of this is not an answer to your question: does it make sense to update, yes, re-develop, yes, replace with a hosted solution, yes. When I consider these questions my primary concerns are – how long will it take because time-to-market is the critical factor – how easy will it be to update in the future because time-to-market will continue to be the critical factor – and what will it cost in the future because IT budgets will continue to be squeezed and we all know 80% of the cost of any application is in the application’s future maintenance.
Reporter: Could you please provide a “portrait” of whom is in charge with the app development for companies? Kevin: Application development leadership is usually a VP level or Director level executive. The VP of App Dev’s peers are the CTO, the Director of the PMO, the VP of Operations. Reporting into the VP of App Dev are usually Business Analysts, Requirements Engineers, Systems Architects, Database Architects, Usability Experts as well as the Software Development teams and the Quality teams and Release Management teams. Change control may report into App Dev but is more likely to be in the Operations area these days. The typical VP of App Dev is in their 40’s, has a technical back ground, probably from software engineering, has strong methodology skills and experience both traditional and more modern. They tend to be compensated on meeting delivery dates but increasingly they are measured on a broad spectrum of metrics including quality, responsiveness to business needs, budgetary control, throughput of projects, post-deployment failures and downtime as well as on-time delivery of solutions. Many VP’s of App Dev have to compete in the open market for projects from their own business units who have been empowered to go outside the organization to source technology solutions.
Reporter: Who should be interested in business applications? CIO, CEO or business manager? If all three, what is the hierarchy? Kevin: There is comment that comes up all the time about “aligning IT with the business” and while this seems like it should be obvious it completely misses the point. IT should not be aligned with the business – the business should align IT to it. The difference is subtle but important. IT’s job is to deliver solutions to the business – it is not IT’s job to decide which solutions they are. It is the businesses task to express their priorities, provide the funding to IT for the projects that need to be done in the next time frame and it is IT’s job to provide technical commentary on the businesses ideas, needs and wants. Ultimately it must be the business that decides on the priorities for IT. So it is the business that must be invested first in the solution and they must have the support of the CEO as it needs to fit in with the corporation’s strategic direction. The CIO needs to make the CEO’s and the businesses’ ideas into realities.
Reporter: Taking 100% of the IT budget, what is the percentage of investment in ALM? Kevin: Because ALM is such a broad term it is very difficult to say what people are spending on it. If ALM includes everything from demand management though deployment, which is the broadest definition, we’re looking at a much bigger percentage than if we define ALM more narrowly as everything from requirements to testing.