From innovation to enterprise

It’s generally true that innovation happens at the “edge” of organizations. That often is the case when small groups create a new project - pushing boundaries and exploring new possibilities. That isn’t to say that central IT or enterprise IT doesn’t innovate, but an enterprise IT organization may not be set up to explore new avenues as readily as local IT. That’s often the value that small, local IT teams can provide.

The process usually breaks down like this:

Local: A small group identifies a unique need, something not currently provided or met by existing IT services. Someone at the local level develops a new model or concept, an innovative solution that fits just that problem.

Shared: Other, similar teams in the organization recognize the achievements made by the first group, and recognize the value it could bring them. These teams partner up to collaborate in the new service, creating a shared solution for them to use.

Enterprise: As the service grows, it may evolve into a high profile application, with lots of different users. The organization as a whole may decide to adopt the new service. This is where the central IT unit turns the system into an enterprise offering.

In other words, IT system growth tends to follow this model:

Local ⇒ Shared ⇒ Enterprise

Some also refer to enterprise as “common good” IT services. That is because when delivered at scale, it doesn’t make sense for individual departments to maintain a separate cost pool to support redundant services when those same services can be provided for everyone (the common good) by the enterprise IT organization.

Local versus global

Local IT services are fine when there’s a unique need that’s not filled by enterprise IT offerings. And shared services are acceptable when the enterprise isn’t ready to adopt a single solution. But the big question is: how to balance between “local” and “enterprise” services on this spectrum?

I like to use this guide:

Enterprise: If you can answer “Yes” to most or all of these questions, then you should centralize the service:

1. Does the service support multiple units?
2. Would an interruption negatively impact the larger organization?
3. Is there existing demand for an enterprise offering?
4. Is the technology mature and stabilized?
5. Is the service a commodity?
6. Does the service require a high level of expertise to support it?
7. Does the service support a broad organizational need?
8. Does the service require a single point of organizational accountability?

Local: If you can answer “Yes” to most of all of these questions, then the service is more likely be a local offering:

1. Does the service support only a few units or just one unit?
2. Would an interruption only impact a few departments?
3. Is there limited demand for the service?
4. Is the technology still immature or emerging?
5. Does the service fit a unique need?
6. Does the service require limited knowledge to support?
7. Does the service address a niche priority?

Local and enterprise

For example, most IT organizations have divested their web services to some form of managed hosts and shared web services. In 2024, it is very unlikely that a CIO will allow departments to manage their own web servers; web hosting became a commodity service years ago. It’s more likely the enterprise IT brokers a web hosting service for departments to leverage for websites and other web services. The local IT team doesn’t bring additional value to the organization by running their own web servers; instead, they add value through content and applications. In cases like this, let enterprise IT manage the servers and let local IT teams focus on content.

What will your next innovation be? Enterprise IT will do well to look to distributed IT units to see what innovations they are working on. Identify and adapt shared solutions to create enterprise offerings. Providing central systems in this way can support departments to focus on the business, not the technology.