Product IT vs. Enterprise IT
Who owns your website?
In the old days, corporate websites and externally facing web applications used to be managed by the only group that knew anything about technology: corporate (or enterprise) IT - along with email, phones, and printers. However, as companies are incorporating websites and web applications as part of their product strategy, externally facing applications are starting to run into limitations from being managed by enterprise IT. They need more product oriented ownership. You could argue that if a piece of technology is externally facing (be it a customer extranet that supports customers use of the product, a marketing campaign website that brings brand value, or a service that a product plugs into), the technology is part of the product.
Product and enterprise technology are like yin and yang. Product technology requires constant innovation like the product it supports. Product technology is in a state of constant motion as it reaches for new opportunities to differentiate from competitors and serve customers better. Enterprise technology, most of the time, is the opposite. Enterprise technology needs to be as fixed as possible so that it can serve as a solid foundation to support various business processes. It is a cost center and money saved goes directly to the bottom line. A good enterprise technology manager looks at requests for change with skepticism. "Why is the change necessary?" "What are the risks if we do it?" "What are the risks if we don't do it?" "What is the ROI?" If enterprise IT didn't think this way, they would be rolling out a new phone system every week and that would be bad.
A best practice is having technology groups that report to the business unit that their technology serves - not to the centralized CIO who is responsible for everything from buying desktops and printers to email servers. The companies that are structured this way can be more agile and there is less tension in getting things done. The trend is definitely moving in this direction. By comparison, companies that lump all computer oriented technology together remind me of people who think that, because I work in "something related to computers," I must know why there's is broken.
The big problem with this decentralized technology strategy is that it can be highly inefficient. There will be redundancies in software, development, and people if every department has its own IT group. The role of the CTO (or the CIO if there is no CTO) should be balance efficiency and opportunity by setting parameters on the freedoms of technology choices of the different technology groups and establishing mechanisms for deploying and running these systems efficiently. The model may be similar to the manufacturing industries where the product designer has freedom within parameters set by engineering and manufacturing. In software, the business unit would build applications in a sanctioned (and supportable) set of tools. At Google, that is C++, Java, Python, and JavaScript. There may be a server platform and database that enterprise IT is good at managing. The business unit's product-oriented IT organization builds the application, tests it, and then hosts it on enterprise-managed infrastructure (or, better yet, a 3rd party data center). The business unit is responsible for fixing and enhancing the application. Enterprise IT keeps the servers running.
In practice, many companies work this way by having business units and departments hire outside systems integrators to be their own product oriented IT. That usually works well except for two problem areas: enterprise IT staff feel like they were circumvented on a project they should own and, when the consultants leave, no one knows how to maintain the application. The latter problem is worse if former is not solved - enterprise IT will be even less likely to step up and fix problems in an application that they resent. I think to be successful in the outsourcing model, the department that owns the product needs to have technical people to maintain and extend the application. Or, at least, work with a systems integrator that they can keep on retainer for maintenance.
This has big implications for the business units and departments. They will have more autonomy but they will also have more responsibility. They will need to know how to hire technical people, execute projects, and own technology. This is new ground for many and it will be hard work to get up to speed. But, as business models become more digital, these skills will become harder for business owners to live without.