There are good arguments for both centralized and decentralized corporate technology departments. However, recent trends may indicate that it is time for less centralization.
The emergence of an IT department in many organizations in the 1980s and 1990s indicated that a centralized enterprise-wide technology function was the “correct” way to deploy and manage technology in most organizations. Technology was generally expensive and complex and most workers of this era did not grow up using technology in their everyday lives.
In many cases, the beige boxes that fell on their desks were an unwelcome or poorly tolerated addition. Of course, it would be better to leave its inner workings and the software contained within it to experts in another department.
As new generations entered the workforce and brought additional technological expertise, the centralized technology functions in most organizations continued. Hardware procurement benefited from centralization, while acquiring application development expertise remained too complex and challenging for most lines of business.
Likewise, a broad push for standardization was underway in most companies . IT departments have become “Dell shops” or “Oracle shops,” using a limited set of hardware and software to drive interoperability and reduce costs. With software development and maintenance being such a significant expense, a small group of experts in a handful of tools made acquiring new tools easier.
More recently, the desire for standardization and cost reduction has underpinned the business case for centralization. Expensive and complex areas, such as cybersecurity, benefit both technically from centralized management and financially. Many technology leaders have also applied these assumptions to their app development approach, trying to bring together and manage the company's technologists to exert control over company standards and reduce costs.
APIs and bottlenecks: the case for decentralization
While reducing costs and promoting common standards are noble endeavors, IT has become a bottleneck for innovation in many organizations. After being told that IT would gladly execute his request to create a new customer-facing application after the appropriate group resolved its 18-month backlog, the leader of a business unit I worked with joked that “That's where dreams will die. ”
Furthermore, one of the biggest drivers of centralized technology has become essentially obsolete. For years, a pillar of the centralization argument was that it allowed common standards to be applied to how applications were developed, which toolsets were used, and how they were supported.
This was a noble goal at a time when software and hardware rarely worked together, even when purchased from the same vendor, and integration efforts were expensive and time-consuming. The rise of RESTful APIs has largely eliminated the worry about 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 be connected to a laptop via the now-ubiquitous USB port, diverse technologies and applications can interoperate through a common interface.
Using this technique, IT is no longer a gatekeeper to technology development and can now take on the role of strategic consultant.
Centralized service catalogs, not centralized management
Perhaps the most significant technical innovation at companies like Amazon has been the exploitation of this interoperability to an extreme level. As Amazon grew, its technology leaders bucked the trend toward standardization across a limited set of technology providers. Instead, the company insisted that any new technology provides a published collection of interfaces .
Initially, this policy decision allowed Amazon's business units 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 is on standard interfaces rather than common technology built on Amazon Web Services.
Today, 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 implement services that best meet their business needs, while also providing integration points into the larger organization.
These units can acquire technical expertise or leverage a partner and eliminate the expensive work of having IT select, vet and manage all technology-related ventures. The corporate technology department can continue to provide all types 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 change is maintaining a centralized catalog of services that exist throughout the organization. After all, you probably won't need each business unit to develop its own financial management services or remain completely disconnected from the organization as a whole. Provides guidelines for internal and external services focusing on things like security, authentication, and validation.
After a service is evaluated and published, IT must 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 example, if you provide a standard order status service that is well documented in a catalogue, your marketing team can create a cool new campaign without any IT intervention, while your customer service team can create a new “self-help” app. ” which uses order data.
If you are a smaller organization, investing your scarce resources in providing a catalog of services and helping selected partners create new services multiplies your value significantly . A junior software developer can probably integrate a set of well-defined services into a useful new tool much faster than the best team in the world can start from scratch with requirements gathering, analysis, and building a new tool.
While many technology leaders consider themselves consultants, the shift to decentralized design and construction accelerates the process. IT can transition from an organization managing scarce, 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 the job done.
If you liked this, be sure to check out our other DevOps articles.
- Why Businesses Are Moving to 'IT as a Service'
- What your developers need to know before they start working with Kubernetes
- What is website reliability engineering and how can it positively impact DevOps?
- How to accelerate software development by adopting the DevOps culture
- The wave of MLOps (machine learning and Devops)
