People in organizations often look to "get process out of the way" as the path to meetings the critical business need to move ever quicker with quality when introducing change into ecosystems that are massive in scale and complexity to the point that they cannot be comprehended by one mind. The (well intentioned, but flawed) thinking is that less process overhead will reduced the time required to make changes. But this is the wrong path to that outcome, and often has its subscribers running in the opposite direction of meeting the business need. What is the right path? Rooting out dependencies! Think about it: why do groups of people need to meet at all to discuss a change? Why do you have to package changes into large monolithic releases? Dependencies! Dependencies drive the need for process overhead. No dependencies, no overhead. This includes both dependencies inherent in our technology infrastructures, platforms, applications, and services, but also dependencies introduce by way of our working practice and our mental model for managing services. Technology examples of dependencies are easy to find, so I’ll skip discussing them here, noting that that does not make them any less important to root out (As you may recall from your early IT studies, the lower in the OSI stack a problem can be solved, the better J). An example of our work practices creating dependencies: we can eliminate breaking changes by using data contracts with web services instead of accessing the schema directly, but are we doing it? We can use versioned APIs to allow others to move with their changes that use our service--but are we doing it? Just because it is technically possible doesn't mean we're doing it. As for our mental models creating dependencies: think about it—a “mental model” is a gestalt of planning and operating assumptions—if it fits the current IT environment as well as a century old map of New York City fits the modern city—you are in trouble. Your “classic” thinking may be your biggest obstacle to achieving the aims of modern service management. And that is the point: a new “modern” service management model is emerging as the ecosystems of service providers—their services, platforms, and the infrastructure and organizations that underpin them—are inevitably marching towards a more modern footing. As the technology modernizes, the skills, knowledge, and mindset required to effectively run it have changed. Basic operating assumptions, basic “whats”, “whys” and “hows” different in this new model, and sometimes in direct opposition to the “classic” enterprise IT/”box productized”) service management model. This transformation is causing churn in service providers when the organization’s thinking, skills, knowledge, mindset and work practices lag behind the capabilities of modern technologies and the demands of modern customers and users. Characteristics of the Modern service management model include:
- Agility
- capable of moving quickly with quality
- capable of being continuously changed asynchronously without disruption or delay
- capable of at-will deployment and rollback without the need for dependency-driven monolithic releases
- capable of self-healing or, failing that, quick issue resolution
- capable of graceful handling peak bursts of demand
- capable of better and more predictable and often massive scale
- Continuous availability (near-zero customer-impacting downtime)
- Responsiveness
- Capable of sustaining these characteristics as technical architecture, work practices and personnel change
To enable these characteristics, service providers must get to work:
- Systematically reducing or eliminating factors that block these characteristics: especially unnecessary dependencies introduced by technical (network / infrastructure, platform, service and data) architecture and work practices; human factors, manual processes, technology architectures, standards, components, and configurations; tools and data.
- Organizing work practices and tools around a “trust and verify” ethic
- Embedding process and knowledge in the architecture itself, including health models and data to support automation and fact-based decision-making
- The organization working as a federated set of small focused teams, to optimize for growth and leverage of ground knowledge, networked together with systematic means for cross-group communication and collaboration
- Engendering modern versus “enterprise IT / boxed productized”” skills, knowledge and mindsets
- Explicitly defining and driving towards a Modern technical and organizational operating model on an announced timetable, and moving quickly to close the organizational transition lag gap
- Educating the organization on the difference between the Classic and Modern operating models, and laying out a roadmap for getting from the one to the other, with leadership socializing this new model and plan.
I believe the first item on this list—the systematic elimination of unnecessary dependencies introduced both by the technologies and by working practices—is the central tenant of modern service management. I suggest a “theory of dependencies” as the way forward for modern service management, akin to Eli Goldratt’s theory of constraints, except in this case the goal is not eliminating constraints to improve process efficiencies; it reducing dependencies to eliminate breaking changes and improve process elasticity. There is much more to write and discuss on this topic. The organizations I am working with are grappling with these issues with real, hard consequences for getting this right or wrong. New ways of thinking and new actionable tactics are needed. I future posts I’d like to: 1) explore the technology transition we are in, and with specific technology examples, shows why our mindset and operating and planning assumptions need to change to a new paradigm: modern service management. 2) Outline the characteristics of the emergent modern technology platform, including key differences between it and what came before, to demonstrate that the new landscape require new ways of thinking and doing 3) outline the characteristics of modern service management, shows how this new operating model is suited to modern technologies, and contrasts the modern model with what came before (classic / enterprise IT / box productized service management) 4) Explore the central idea of “the theory of dependencies”—routing out dependencies systematically as a means to service management efficiency and effectiveness 5) Other tactics for enabling modern service management. 6) Strategic matters: planning and executing the transition from classic to modern service management. Throughout this discussion, I’d like to use technical and organizational examples are used to ground the principles in reality. My hope is to provide practical advice and to challenge you to “change your thinking to change your results” and root out dependencies in your organization as a means to achieving a quantum leap in organizational and process efficiency.
David Pultorak 
English
Dutch
French
German
Hungarian
Italian
Latvian
Polish
Russian
Sesotho
Spanish