ITIL Design as Business Architecture
2 likes294 views
The document discusses the complexities and challenges surrounding ITIL (Information Technology Infrastructure Library) adoption, highlighting the differing perspectives of 'religious' and 'business' views on its principles. It emphasizes the need for a clearer architectural understanding of ITIL to resolve confusion, as various terminologies can obscure its value in adapting to rapid changes in businesses. Additionally, it promotes the notion that frameworks, models, and standards within ITIL can help businesses effectively navigate complexity and improve service provision.
ITIL Design as Business Architecture
- 2. Archestra notebooks compile and organize decades of in-the-field empirical findings. The notes offer explanations of why things did happen or can happen in certain ways or to certain effects. The descriptions are determined mainly from the perspective of strategy and architecture. They comment on, and navigate between, the motives and potentials that predetermine the decisions and shapes of activity as discussed in the notes. All notebooks are subject to change. ©2016 Malcolm Ryder / Archestra Research
- 3. Seeing the Forest Faced with massive increases in the instigation, scope and origins of change in business use of I.T., ITIL adoption continues to be an idea that fosters confusion and debate despite its popularity. In two opposing strategies of justification: • The religious view of ITIL looks for, and argues for, “ITIL concepts”. • The business view looks for, and argues for, “concepts in ITIL”. One result of the differences is an ongoing inconsistency of references to ITIL blurring the understanding of what ITIL’s own design promises. It is alternately referred to as standards, frameworks, processes, requirements, models, strategies, and more, at the convenience of the speaker of the moment. But this happens also at the expense of audiences not familiar with the speaker or exposed to multiple speakers. The problem created by this inconsistency is that ITIL’s own perceived complexity discourages using it to tackle the increasing complexity of mid-to-large size businesses being driven by continual rapid change. Certified masters and practitioners are, of course, not discouraged. But what makes ITIL fundamentally useful does not require an engineering level of control of particulars. Business can understand, by seeing from a high level, how ITIL should intentionally affect something, and why that intention matters. It’s more of a design level. The high-level view is basically architectural, with the confusion of terminologies sorted out in a stable perspective applied to ITIL .
- 4. FRAMEWORK MODEL A framework outlines the intended relevance of efforts, thereby providing the logic of their inclusion. A model outlines a known type of integrated effort to be regulated. A pattern outlines the repeatedly selected attributes for an instance of effort. PATTERN Standards: Frameworks, models and patterns resolve the frustration of unmet expectations. As a structured library of knowledge, ITIL is seen differently by different interested parties, who often interact in organized hierarchies of influence or responsibility. The general interest is to find guidance, which supports decisions based on a status of being “consensus best practices”. Because of that, the common desire is that specific guidance should be available and “effective” at each level. But, often in discussions, there is significant ambiguity, if not debate, about what effectiveness is directly “available” on which given levels – from “conceptual” to “practical”, and from “strategic” to “operational”. Ambiguity and debate calls the value of ITIL into question, even as people want it to be their standard. An architectural perspective offers a way to sort out the common confusion about expectations.
- 5. GENERAL SPECIFIC EXTERNAL INTERNAL PRINCIPLE RULE STANDARD domains circumstances objectives NORM practices GUIDANCE: A standard can be general or specific, but not both. A family of standards, however, can collectively include a wide range of specificity. An important way to identify the specificity of standards is to distinguish principles, norms, and rules. • Standards apply to objectives (goals) • Principles apply to domains (disciplines) • Norms apply to practices (methods) • Rules apply to circumstances (permissions) discipline permission method ©2016 Malcolm Ryder / Archestra Research
- 6. discipline permission method A standard is most directly related to the objective(s) of effort. The purpose of a standard is to align the various aspects of the effort to a given objective. In that way, a standard has authority and supports governance. GENERAL SPECIFIC EXTERNAL INTERNAL STANDARD objectives DOMAIN PRACTICE CIRCUMSTANCE Otherwise, significant complexity can arise from: • Cross-disciplinary effort • Organically extended methods of procedure • Incidental exceptions to permissions ©2016 Malcolm Ryder / Archestra Research
- 7. Complexity is not inherently bad; rather, unresolved complexity is bad. Frameworks, models and patterns resolve the difficulties of complexity. FRAMEWORK MODEL DOMAIN PRACTICE CIRCUMSTANCE A framework outlines the intended relevance of efforts, thereby providing the logic of their inclusion. (for Practice within the discipline) A model outlines a known type of integrated effort to be regulated. (in Circumstance for the method) A pattern outlines the repeatedly selected attributes of an instance of effort. (for Domain of the permission) PATTERN Significant (but resolvable) complexity can arise from: cross-disciplinary effort; organically extended methods of procedure; and incidental exceptions to permissions. discipline permission method ©2016MalcolmRyder/ArchestraResearch
- 8. The available guidance in ITIL’s information constitutes a “system” of disciplines, methods and permissions that can be adopted as preferred inclusions, integrations and instances of efforts. INCLUSION INTEGRATION Domain expertise generates a body of knowledge about operational values and responsibilities. Practice management applies disciplinary knowledge to planning and requirements, supporting performance and quality. State monitoring compares intentions and current actuals, supporting compliance and improvement INSTANCE discipline permission method DOMAIN PRACTICE CIRCUMSTANCE Complexity is not inherently bad; rather, unresolved complexity is bad. ITIL guides decisions about the inclusion, integration and instances of efforts to make IT infrastructure useful by a business. ©2016MalcolmRyder/ArchestraResearch
- 9. Implementing ITIL means cultivating the opportunity for systemic resolutions of complexity by coordinating essential operational decisions about service provision, under given objectives accepted as standards. Coordination is most often imagined in terms of managed processes, but processes tend to prescribe tight coupling of activity that inherently can still be independently triggered. Loose coupling, based on compatibilities instead of on dependencies, is a more flexible approach to interactions that allows cultivation (implementation) to be incremental and “open-sourced”. Standards support loose coupling. This highly abstracted picture of operational coordination is too generic to account for the potential full effect of ITIL. But as a “mind map” of what can be at stake, it suggests why ITIL’s affects can be strategic. ©2016 Malcolm Ryder / Archestra Research
- 10. ©2016 Malcolm Ryder / Archestra Research www.archestra.com mryder@archestra.com