Most large enterprises have built sophisticated corporate support organizations to handle tasks that can be consolidated and executed from a degree of standard. The goal of the centralization is to create consistency and operationalize the services being delivered. They aren’t wrong to desire this and much of this work is good. Seeking this end, many organizations will vilify the function of “Shadow IT”, which represents when corporate functions are delivered by individuals in business units, OpCos, or application teams that the corporate IT team believes should be delivered centrally. In some cases they are right, that Shadow IT represents a significant risk to the organization’s security and efficiency. I’m however going to suggest that Shadow IT isn’t the enemy. In fact, Shadow IT represents an un-met need in the business and a vacuum of service or delivery approach that needs to be improved. In many cases, Shadow IT represents the commoditization of IT and the extent to which delivery should and must get closer to the business agent vs. further from it.

Why is centralization a good thing?

The most IT models are built with centralization in mind for core functions. The primary goal is to handle activities as centrally as possible, with a high degree of delivery being based on groups of team members in the IT organization that could execute on business needs. This is especially the case in more normalized settings like desktops, email, password resets, etc. This all brings a degree of efficiency to the business, as well as optimization of the security ecosystem. The benefits of centralization of these core functions are:

• Increased security as a result of end-to-end SecOps process
• Improved efficiency of commodity device or collaboration deployment
• Less difference in tools the business uses, resulting in more effective workforce
• Faster decision making for corporate-wide execution
• Simpler roll-outs corporate-wide of new technology
• Ability to have less people doing the same function

So, why does Shadow IT exist then?

The existence of Shadow IT is communicating there is an un-met need at the corporate level. In other words, the business is stepping up to serve a need they have. Instead of calling it “Shadow IT”, which is a term intended to vilify it, let’s call it Distributed IT. The business is saying, I’m not getting what I need to be successful, so I’m going to do it myself. In a sense, Shadow IT is a signal that a need exists and that need could potentially be done centrally if its worth while. A bad assumption is that it is always worth having that function be delivered centrally. An equally bad assumption would be that it is always better with the function being delivered in a distributed fashion. The truth is somewhere in between. A few reasons Shadow IT might exist (hint: to help the business deliver its core function, grow revenue, or save money):

• The business isn’t getting what they need from IT (solving a problem)
• The business is innovating despite IT (doing what it needs to do)
• The business is enabled with IT’s help (intentional distribution)

The cases of Shadow IT that exist because of IT’s slow, blocking, or complicated behavior are the business trying to achieve outcomes despite IT’s lack of engagement and partnership The last case, intentional distribution, is where IT is partnering to actually EXPAND the engagement of the business in technology ends. In many cases, we want to encourage, not discourage Shadow IT.

What are things that Shadow (or Distributed IT) shouldn’t do?

It is difficult for distributed IT to be used for things that require standardization because they don’t have a mandate to affect change more broadly. This is why historically centralized IT has been frustrated with many of the ways it has materialized in the business, as often distributed IT can be done in very different ways. If focus is placed on it, distributed IT can form chapters and guilds (see Spotify Model), but self-organization can be challenging. In many cases there are things that distributed IT should simply avoid, unless structure is placed to bring all the various groups together. These would be examples of things distributed IT should avoid without some level of centering structure, like a corporate group, Center of Excellence, or guild:

• Security NOCs
• Security Standards
• Cloud Governance
• Device Deployment Standardization
• Communication and Collaboration (like Office 365)
• Identity Governance
• Architecture Standards
• Data Platform Standards
• Development Standards

The common theme is that centralized IT functions are responsible for standards, governance, and adoption. They drive the adoption of the right things, but don’t need to be responsible for their execution, only the establishment of organizational standards, working to ensure they are adopted, and validating they are the right ones, at the right depth, and aren’t over-reaching.

So, what could Shadow (or Distributed IT) take on?

Every business is becoming a technology business in order to survive. The fabric of every business now includes technology infused into the products being built, the capabilities being delivered, etc. The distributed “IT” or technology capabilities are necessary in any creative or execution function of the business. For instance, instead of having central IT responsible for all the reporting functions, the business can build its own data competency. Instead of central IT responsible for all device deployment, it can standardize devices and anyone can order their own device. Instead of central IT building every custom application it can distribute the development design, build, and operations into business application teams. The concern around safety, security, cost, etc. are resolvable by standards, infra/app-as-code, and cloud governance. Here are examples that I’d distributed in a modern business:

• Device deployment (under a Zero Trust model)
• Application development (under a governed cloud)
• Power BI report writing (under a governed data environment)
• Data science (under a governed data environment)
• App configuration (under governed apps and identity)
• Test environments (under governed cloud)
• SaaS business-function apps (under governed identity)
• LowCode/NoCode development, such as PowerApps (under governed app env)

The theme you can see is that the business taking on these functions distributes ownership. It also distributes impact. Instead of a limited number of people in IT having capabilities in the above areas, we’ve scaled the function. I recently worked with a 15,000 user organization that scaled PowerApps to 25% of their employees and as a result automated countless activities. Another had a similar number with data fluency. Another had employees ordering devices from three vendors and shipped the box directly to the user.

A closing thought is that Shadow IT is just like any relationship. It tells you that the business needs something. In some cases its ok, even preferred, for the business to do it themselves. It isn’t the job of IT to take control of every function of the business. It is instead the function of IT to standardize where possible, enable, and govern.

St. Thomas Aquinas has a saying, “rarely affirm, seldom deny, always distinguish”… and in many cases in IT I think that is a useful reminder.

Nathan Lasnoski