Much less confusing than the hundreds of overlapping and competing descriptions from technologists, a business bird's-eye view of DevOps shows several big parts of IT management catching up to the whole.

1. From ITOM to DevOps
An archestra notebook.
© 2013 Malcolm Ryder / archestra

2. How It’s Working Out
“DevOps” is a service production approach
discovering itself within an existing larger
landscape of management for agility. It supports
sustained agility of service delivery to the business.
MANAGEMENT
AGILITY
APPS DEVELOPMENT
AGILE
REQUIREMENTS
ARCHITECTURE
IT SERVICES
SERVICE DELIVERY
PORTFOLIO
RELEASE
ORCHESTRATION
INFRASTRUCTURE OPERATIONS
AUTOMATION

3. Business Problem: Build for effective Run
“Ops” is expected to receive
releases and be the custodian
of the successful business use
of the releases. But logically,
this means that releases must
also meet Ops requirements,
not just User requirements.
requirements
environments
delivery
RELEASE
usability
DEVELOP
compatibility
DEPLOY
integrity
MANAGE
integration
quality
supportability
Completeness
Complexity
sustainability
© 2013 Malcolm Ryder / archestra
Effective Scope
Users want to have any features
important to them, as soon as
possible. Trade-offs between
familiarity and innovation are
accepted but with high
sensitivity to the “expected user
experience” promised.

4. Solution: integrated management
Collaborative
management of
objectives and
resources
Capability Goals
Business Process
Management
USERS
OPS
Collaborative
management of
requirements and
releases
Business Analysis
Agility Goals
DEV
Solution Goals
© 2013 Malcolm Ryder / archestra
EXECS
Performance Goals

5. Ops Responsibility is making demands
on Dev Accountability
What is IT operations management - ITOM?
IT operations management (or more commonly, just "operations")
is generally agreed to encompass the day-to-day tasks related to
the management of technology infrastructure components and the
more granular needs of individual applications, services, storage,
networking and connectivity elements of a total IT stack in any
given deployment scenario.
-- CWDN: The Computer Weekly Application Developer Network

6. Business combines User and Ops Requirements
Business now predicates its competitiveness, and thereby its success,
on visibility, speed, and maneuverability.
Knowing where it is going, getting there quickly, and not losing control
is the summary agenda for the business reliance on IT.
This simplifies the management messages that matter, and IT
management follows up on the message received.
If IT will be the vehicle for business success, then the design of the
vehicle must have an appropriate architecture for the purpose.

7. DevOps designs against Risk to ROI
Without actual sustained capability being produced and maintained, Agility
is just an idea.
Forcing agility requirements into inadequately managed deployment
dramatically increases the complexity and risk of change.
Operational risk is minimized by the practice of design: using architecture
principles to assure that construction meets environmental constraints on
usability.
Architecture works both on the plan before, and on the sign-off after, the
production of a solution.
• The DevOps approach brings environmental requirements and support
dependencies into the front end of the development process.
• Orchestrating future-oriented releases for deployment aligns them to the
current environment.

8. Production Design
But if the business will avoid driving
off the tracks with it, the combination
of Dev and Ops must reconcile the
functions and risks of the enabler.
This means that for actual usability of
the enabler, a BUSINESS DESIGN of
the enabler is required that is
comprehensive across builds,
deployments, and support.
© 2013 Malcolm Ryder / archestra
The business presumes that
capabilities needed for performing
will be in place as needed. The easy
expectation is that to cause this, DEV
(development) will make the enabler,
and OPS (operations) will assure it
runs adequately.
PLANNED
RELEVANCE
performance
function
MEANINGFUL
SCOPE
risk
ARCHITECTURE
EXPERIENCED
QUALITY
IMPLEMENT IT CORRECTLY
Clockwise:
Acknowledge real
world constraints
Counterclockwise:
Adapt to new
business needs

9. “Make it Quickly”:
Going from RAD to Agile is… from Product to Value
Product-oriented RAD
Value-oriented AGILE
• Focus on rational decrease in risk
of defects
• Reusable software components
• Fixed specs
• Dev teams and test teams
• Parallel work
• Prototypes
• Eventual single release
• Focus on rational increase in
readiness for usage
• Architecture & interfaces
• Evolving requirements
• Hybrid teams
• Collaboration
• “Done” feature subsets
• Frequent “Iteration” releases

10. “Implement it Correctly”:
Extending from Agile to DevOps is …from Value to ROI
Quality/Purpose of function
via Agile
Risk/Benefit of deployment
via DevOps
• Provide deployables relevant to
current requirements of the
business
• Functionalities
• Evolve user solution
• Release to Portfolio
• Manage deployments
appropriately for business
continuity
• Systems
• Evolve business capability
• Release to Environment

11. Strategy
Benefit
Benefit
Event
Impact
Output
Systemically
stable?
Impact
Event
Output
Conditions
Functionally
coherent?
Output
Event
Returns: Progress towards objective
MANAGE
Benefit
Impact
DEPLOY
DEVELOP
Investments: Resources for Activity
Understanding ROI
Sustainable
Capability
Structurally
sound?
© 2013 Malcolm Ryder / archestra