RSSApplication Deployment 2.0
© All¡son J
Deploying new applications is among the most fraught duties of the CIO. Change in IT, despite its constancy, is always loaded with the potential for badness, and new applications make for a lot of change… new processes, new software, new support procedures, often a new vendor. Nor is the change generally confined to the IT department, where the CIO may be able to comfortably handle all these things. Instead, it's often extended throughout the business, indeed forced on staff who may be perfectly comfortable with their existing applications and processes and therefore resent the intrusion, or at the opposite end of the spectrum, who have elevated expectations which the software cannot possibly meet and who will be inevitably disappointed with its arrival.
To address all these difficulties, many CIOs have worked out elaborate application selection and deployment procedures, perhaps similar to those detailed here by John Halamka. But it wasn't his implementation procedure (which is fairly conventional, if thorough) that caught my eye but instead these lines describing an alternative method: "At one institution I visited, they purchased Peoplesoft, copied it to a server and then 'turned it on'. To their surprise, it was not used."
Obviously this isn't going to be a successful approach with something like Peoplesoft, which gets to John's point I believe. But it got me wondering whether the more conventional process we tend towards is overly complex for new enterprise application paradigms.
After all, the process list reads like a full-employment guarantee for the CIO, and between kick-off meetings and life cycle management it takes a tremendous amount of time and effort to accomplish. And as I pointed out above, most of this is to at once force users (I don't say departments, or managers, intentionally; their perceptions are often out of tune with those of the end users) onto IT's implementation timeline and simultaneously manage their expectations of the product. Even when done well, it frequently forms a sour experience. So what is wrong, then, with simply "turning on" a new application and letting users implement it at their own pace and in tune with their own demands?
Part of the problem is the applications. If you are rolling out a traditional enterprise wide cmdb or accounting package or similar, you can't simply allow people to pick it up at their own pace and use it when they see an advantage to doing so; everyone has to be on the same page, procedures have to be identical, or the point of the software goes right out the window.
But why are we still using applications like this? What happened to SOA, to the black box exposure of corporate data and processes to rapid development frameworks, perhaps managed outside the IT department proper? When information and processes are sufficiently containerized to ensure their consistency, do we need to hold on to our older paradigms of application selection and development? Or can we allow an internal flourishing of a model that has done well for Web 2.0 sites for years now: build it, and see if they will come?
