Is it Time for Decentralized IT?

The emergence of an IT department in many organizations in the 1980s and 1990s indicated that a centralized, company-wide technology function was the “correct” way to deploy and manage technology at most organizations. Technology was generally expensive and complex, and most workers in this era didn’t grow up using tech in their everyday lives.

In many cases, the beige boxes that descended on their desks were an unwelcome or barely tolerated addition. Certainly, their inner workings and the software therein were better left to the experts in another department.

As new generations entered the workforce and brought additional tech-savvy, the centralized tech functions at most organizations continued. Hardware procurement benefited from centralization while acquiring application development expertise remained too complex and challenging for most business lines.

Similarly, a broad push for standardization was underway at most companies. IT departments became “Dell shops” or “Oracle shops,” using a limited set of hardware and software to drive interoperability and reduce costs. With software development and maintenance such a significant expense, a small group of experts in a handful of tools made it easier to acquire new tools.

More recently, the desire for standardization and cost savings has underpinned the business case for centralization. Expensive and complex areas like cybersecurity benefit technically from centralized management as well as financially. Many technology leaders have applied these assumptions to their application development approach as well, attempting to gather and manage the company’s technologists to exert control over company standards and reduce costs.

APIs and Bottlenecks: The Case for Decentralization

While cost savings and a push for common standards are noble endeavors, IT has become a chokepoint for innovation at too many organizations. After being told that IT would happily execute her request to build a new customer-facing app after the appropriate group cleared their 18-month backlog, the leader of a business unit I worked with quipped that “IT is where dreams go to die.”

Furthermore, one of the biggest drivers for centralized technology has essentially become obsolete. For years, a pillar of the centralization argument was that it allowed for enforcement of common standards of how applications were developed, which toolsets were used, and how they were supported.

This was a noble objective in an era where software and hardware rarely worked together, even when purchased from the same vendor, and integration efforts were costly and time-consuming. The rise of RESTful APIs has largely eliminated that concern for modern software, allowing applications and services to communicate through standard interfaces regardless of the underlying technology.

Just as anything from a consumer drone to an industrial diagnostic tool can plug into a laptop through the now-ubiquitous USB port, diverse technologies and applications can interoperate through a common interface.

Using this technique, IT is no longer a gatekeeper for technology builds and can shift into the role of a strategic advisor.

Centralized Service Catalogs, not Centralized Management

Perhaps the most significant technical innovation at companies like Amazon has been exploiting this interoperability to an extreme level. As Amazon grew, its technology leaders bucked the trend of standardizing on a limited set of tech vendors. Instead, the company insisted that any new technology provide a published collection of interfaces.

Initially, this policy decision allowed business units within Amazon to make their own technical decisions, as long as they provided a well-documented interface and maintained that interface as it evolved. Ultimately, this focus on standard interfaces rather than common technology developed into Amazon Web Services.

These days, companies don’t need to have Amazon-level sophistication or budget to benefit from building technology services with standard interfaces. This shift allows individual business units to design and deploy services that best meet their business needs while also providing integration points into the larger organization.

These units can acquire technical competence or leverage a partner and eliminate the costly work of having IT select, vet, and manage every technology-related endeavor. The corporate tech department can continue providing all manner of services, but focusing on integration offers other options for business units and puts IT in the role of facilitator and guide rather than being a bottleneck.

The key to the success of this shift is maintaining a centralized catalog of the services that exist across the organization. After all, you likely don’t need each business unit to develop its own financial management services or remain completely disconnected from the broader organization. Provide guidelines for both internal and external services focused on things like security, authentication, and validation.

Once a service is vetted and published, IT should add it to a readily accessible service catalog. Done well, this catalog serves as a marketplace of sorts, allowing anyone in the organization to identify and integrate existing technology in new and useful ways. For instance, if you provide a standard order status service that’s well-documented in a catalog, your marketing team can create an interesting new campaign without any IT intervention, while your customer service team can build a new “self-help” app that uses order data.

If you’re a smaller organization, investing your scarce resources into providing a service catalog and helping select partners to build new services multiplies your value significantly. A junior software developer can likely integrate a set of well-defined services into a useful new tool far more quickly than the best team in the world can start from scratch with requirements gathering, analysis, and build of a new tool.

While many tech leaders fancy themselves as advisors, the shift to decentralized design and build accelerates the process. IT can transition from an organization that manages scarce and high-demand resources to a shopping mall of pre-built services and expert guidance on how to work with an internal or external partner to get work done.

If you enjoyed this, be sure to check out our other DevOps articles.