I recently had the chance to listen in on a roundtable discussion involving a software developer's R&D group, discussing some of their thoughts on architecture. Some interesting ideas around "innovation" ...
Innovation vs. Cost Control
A question from the floor - how sensitive are the R&D arms of major vendors to existing investments in infrastructure for their installed base? The response was framed with a pair of quotes: "Innovation without disruption" is apparently one of their goals. However, is that just fancy talk? Doesn't true innovation only come from disruptive technology? And "Invention only happens once or twice, in the lab. Innovation is about taking Invention up to scale". This last one, I think, is the powerful bridge to reality; good ideas are just that, until you can make it a reality for the whole corporation, given limitations of scale plus existing policies / standards.
Innovation vs. Resistance to Change
This line of discussion also made me think that new IT tools / initiatives should be sensitive to our internal user's existing investments in knowledge / understanding. For internal IT, maybe an important, required conversation would be to agree on the layer / level down to which you will allow "disruption from innovation". A sensitive balance, and a tough level to identify.
Measuring Success
How does an R&D lab at a software developer measure success? "Productive end-customer adoption" - how many current customers adopting this stuff in production? It's one of their KPI's, and a potential learning for corporate IT - could an internal development group's KPIs include metrics for internal rate of adoption / use of new stuff we put out into production? They also quoted "Crossing the Chasm", saying that 80% of innovation is "wasted" - never gets into production, sees the light of day. Is this bad? Nope, the nature of R&D is that a majority of the interesting ideas "fail".
Corporate IT rarely thinks of themselves like a software developer, but there are many lessons to be learned from those folks.