The promise of local innovation

Traditional organizational theory positions software development as a centralized IT capability distinct from the business, bridged by interfaces. This essay argues that for domain-specific, high-velocity logic, the separation of business and IT must completely be dissolved in favor of a model where innovation is a local, autonomous capability, facilitated by a frictionless, central utility.

The knowledge bounded context

The fundamental argument for embedding software development within the business rests on the Sticky Information theory pioneered by Eric von Hippel (MIT). Von Hippel posits that the information required to iterate on an innovation is often “sticky”. It is context-bound, tacit, and costly to transfer. In niche sectors like System Operators, process knowledge is so deeply interwoven with daily operations that attempts to translate it into functional designs for a distant IT department results in catastrophic information loss and lag.

In these environments, we must recognize that software logic and operational reality are an inseparable unity. Take operational decision support: we are not describing a business process that is supported by IT. Instead, we are describing a business process that exists as code. The physics of the grid and the logic of the simulation are so immediately intertwined that they cannot be bifurcated into “business requirements” and “technical implementation.” The latency between an operational insight and its codification translates directly into higher operational costs. By organizing software engineering as a local capability, we eliminate “hand-over friction.” The developer becomes a co-author of the business process, ensuring that the software evolves as a living organ of the operation.

The typology of development

Not all software development calls for a position within the business. A rigorous model requires a distinction based on the dynamics of the underlying logic, similar to Gartner’s Pace-Layered Application Strategy:

  1. Dynamic Process Logic: When the code is the primary process, inseparable from the work itself, it must reside within the business. Here velocity of adaptation is paramount.
  2. Stable Process Logic: Once a process matures, such as regulatory compliance or standardized process flows, the requirement shifts from innovation to robustness. Here, the central IT-organization must relieve the business of “cognitive load.”
  3. Platform & Infrastructure: This is the bedrock. Here, the central IT-organisation must act as the “plumber.”

The central IT-organization as plumber

When the central IT-organization shifts from IT-as-a-Service to IT-as-a-Platform, it is no longer the supplier of solutions, but the facilitator of innovation. The goal is frictionlessness. Just as electricity is a commodity, the platform must feel invisible to the developer: ever-present, resilient, and plentiful. Data and events must be able to flow without obstacles.

This concept is supported by the principles of Platform Engineering and the Team Topologies framework by Skelton and Pais. The primary task of central IT is to minimize the cognitive load for development teams. This involves providing a “Paved Road”, a set of tools and standards so effective that the path of least resistance is also the path of highest quality. When this level is reached, it is the ultimate expression of the focus on “Developer Experience”.

The fallacy of proprietary control

A persistent failure in platform development is the assumption that control supersedes developer experience. Niche solutions, often via proprietary or heavily modified versions of open source products, are pushed, while the global developer community has embraced “the real deal”. This creates immediate technological debt that stifles innovation.

Google’s DevOps Research and Assessment demonstrates that autonomy in tooling is a direct predictor of software delivery performance. Developers are responsible for the output and must therefore have authority over the input. Imposing divergent standards limits velocity and leads to costly rework. The central IT-organization should not fight market standards but facilitate them frictionlessly.

Focus on developer experience might be in direct competition with internal standards and compliance. Managing these contradictions to perfection is precisely where the central IT-organization realizes its value. Do the hard thing today, to make tomorrow easy.

Conclusion

Value is created where domain expertise meets technical execution. I propose organizing innovation - the capacity to create - as a local capability within the business, while repositioning central IT as a frictionless utility focused on developer experience. This shift generates an organic pull. The business drives innovation to resolve its own “pain,” while IT facilitates by providing the necessary resources.

The result is an organization that does not merely react to the future but actively shapes it.

License & Attribution

This essay is licensed under the Creative Commons Attribution 4.0 International License.

You are free to share and adapt this material, provided that appropriate credit is given to Hugo Pfister and a link to the original source on hugopfister.gitlab.io is included.