The following is an excerpt from an upcoming research report on "Modern Operations" by IT Revolution (publishers of The Phoenix Project, The DevOps Handbook; producers of DevOps Enterprise Summit).
For decades, the traditional IT organizational model has been based on grouping people by job function or similar skill sets.
The most noticeable functional groupings have been major divisions like Developers, QA, and Operations. If you look inside those divisions, you’ll find that functional grouping is also the dominant organizational pattern. For example, it is common to find groupings inside Operations like Linux SysAdmins, Windows SysAdmins, Storage, Network, Firewalls, NOC, DBAs, Security, and more.
A major downside of grouping by job function is that these groups tend to adopt a siloed way of working. In simple terms, a group is said to be "working in a silo" when its members find themselves working in a disconnected manner from other groups. These teams end up working from different backlogs with different incentives or priorities (and often a different management chain).
If work could remain within a single silo, there wouldn't be an issue. Unfortunately, this isn't how work happens. In an enterprise, work has to flow across multiple functional silos to satisfy customers. Silos lead to increased bottlenecks, slow handoffs, miscommunication, tooling mismatches, delivery errors, excess rework, and conflict (usually the finger-pointing type).
When teams are working in functional silos, they tend to become siloed specialist labor pools. Requests are made of these specialists via ticket queues (a common source of bottlenecks and miscommunication). Requests are fulfilled as one-offs through semi-manual or manual efforts. Variability is high. Priorities and context are difficult to gauge. Primary management focus is on protecting team capacity (not the needs of the broader organization). The presence of these functional silos working as specialist labor pools undermines DevOps transformations and leads to today's all too familiar symptom of "everything costs too much and takes too long."
Today, high-performing organizations are moving away from siloed specialist labor pools. The new model is to both remove handoffs wherever possible (e.g., cross-functional product-aligned teams) and create internal service providers wherever handoffs remain.
Internal service providers are focused on creating on-demand pull-based self-service for others in their organization who need their specialist services. In an operations context, examples of this could be environment management, network tasks, database tasks, on-demand health checks, monitoring/metrics setup, incident response capabilities, and more. The key is that these internal service providers aren't doing the work for the requestors. Rather, they are building and scaling services so they can stay out of the other teams' way.
Requests to these internal service providers are not dissimilar to those made to externally run cloud services. Requests are made via self-service API, CLI, or GUI and fulfillment are automatic and close to real-time.
Organizations that use this new method are seeing quantifiable improvements in response times and ticket queue reduction.