One of the balances to maintain in the IT division is that has been referenced as "big cog, little cog". The big cog represented by ITS global services and the associated servcies; the little cog represented by the DL's/LITS and the services they offer.
First, some definition. A global service would be defined to run 24x7 with redundancy, a service level agreement and process supporting the service. You might think of this as the central email service or the campus network or the telephone service. A local service is different in the scope of clients it serves, the service level and the resilency of the hardware environment. They are all less than what we would design for a global system; and that's ok since our local clients typically understand the limitations of the local service. And, sometimes not so forgiving for service issues arising from a global service.
Early on in the forming of the IT division, we had hoped to use the many local services developed by the DL's and LITS and incubate them to become more established servcies; maybe even taking them global. On the whole, this hasn't materialized. What has happened is that robust local services have become proofs-of-concept and in a few examples become the pseudo-global service. Here I'd point out the SoE VPN service, the Bacula back up to UCSD, and Drupal implementations (SoE, BAS, Library, Arts).
So, how do we incubate and grow the ideas, systems or software meeting a local need into something bigger or better? That's the trick we haven't figured out yet. We struggle with a NIMBY like behavior between our global and local technical groups. What we're missing is how to change the conversation away from a values-based where each side feels the other doesn't value or understand their interests and positions to something less dysfunctional and more collegial. Perhaps peer review, perhaps world café.
The Design Review Board approach has had a number of success. It brings together a lot of smart people to review the technical designs of systems as they relate to the enterprise architecture. It can be grueling to submit your ideas and documentation to colleagues who may or may not have an interest in your project and then have to defend why you've taken one approach or another.
I mention the world café approach since we've used it for facilitated meetings on a few occasions. It typically generates a shared vision or roadmap of the discussion. I'm not clear on how it might help with incubation, but I'll keep thinking about it.