This notebook illustrates how confusion and disagreement about ITIL's status as a Knowledge Type and Tool Type is cleared up in a simple way if approached in an architect's perspective, making it more readily understood by Business Decision makers.

1. 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