I was overstating the point for effect :-) Actually, since I stumbled across your blog a few years ago, I think that you're one of the people that I'd like to thrash through my thoughts with.
Of course your examples continue to be important. My point is more that consideration of these elements need to be owned by the applications people (who should understand the wider context of how the apps are used - by app, I mean things like whatever's meaningful to a business user). My experience is that the separation between building apps and running them is counter-productive and, I believe, a major source of additional costs in operating the IT function.
Although ITIL's made a land grab for IT governance, I'm not convinced that it's actually a useful direction to come from. This point of view may come from my background, but I don't think so. My background is in large scale architecture, and our biggest challenge in transformations or putting in place actionable governance was getting a view of how the IT systems hang together on a continuing basis with a view to any form of improvement.
Let me try to restate my pov, better:
I've seen ITIL used as an approach to get control of infrastructure, production set up of applications and how the whole supports the business. A significant emphasis is on reducing operating costs (75% of the IT budget). I don't think that the common approach of a 'bottom up' approach to trying to understand the IT landscape is tractable. The opacity of how IT supports the business and poor alignment of incentives across the IT function with business objectives makes it all but impossible to get effective control (eg you cannot have effective vendor management unless you understand the costs and benefits of what each vendor delivers to the organisation; much of the IT budget is wasted on products and services that actually destroy value - and I've got lots of examples of that).
My contention is that (IT) application owners should be given lifetime responsibility for the applications. The model that I encounter, those responsible for building enterprise apps usually quickly scope out the main issues relevant to the operation of the system as they strive to meet project deadlines and costs. In the worst examples, they ignore non-functional requirements for business processes and apps altogether (eg RTO, RPT, expected rate of change). What they build is then not what is implemented in production, and much effort and cash is wasted post implementation trying to meet non-functional expectations from the business, based on a poor understanding of how the application should or does consume resources. I've measured 98% capex wastage on such efforts. Eventually, some underlying component falls out of support and a major re-implementation must be undertaken.
I believe that the lessons from internet scale apps of ensuring that the app can be deployed automatically, and that automated test coverage is sufficient does enable a new way of working.
I completely agree with your point about understanding what you've got before outsourcing - I've got several very expensive counter examples - but, I also think that it's more productive to get control of apps from the development end and throw out the rest as fast as possible. This is not simple, nor cheap (the original development phase - 30% of an app build cost - is likely to increase by 30%, but all subsequent refactorings are simple and cheap, which is crucial as requirements change (including the changing requirements of the underlying infrastructure like COTS components going out of support.)
Based on my measurements and some collaboration from major systems integrators and benchmarkers, I believe that the change in emphasis should save 50% of the 75% of IT costs spent on keeping the lights on, and be self financing.
If you're interested, I'm keen to discuss this offline, as I value your pov. It may just be that your organisation is already more sensibly set up than those that I've encountered.
Tim
