Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

DevOps vs. ITSM Maturity

29 Nov 2022 🔖 devops
💬 EN

Table of Contents

DevOps maturity is important, but might it be secondary to other technology maturity models?


I like ICF’s 6-stage model of DevSecOps maturity along axes of:

  • Organizational traits
  • Feature delivery
  • Automation
  • Testing
  • Security
  • Monitoring
  • Operations
  1. No DevOps principles applied yet
  2. DevOps principles applied in strategic pockets of the organization
    • Infrastructure as code beginning to automate software deployment.
    • Test-driven development adoption beginning.
    • Improved operational monitoring.
  3. Automation increasing
    • Agile delivery beginning to be feasible.
    • Infosec beginning to be included in test-driven development.
  4. Continuous integration pipeline use increasing
    • Applications refactored to leverage “immutable infrastructure.”
    • Infrastructure as code trusted enough to treat “immutable infrastructure” servers as paper plates, not fine china.
    • Feature-release practices are automated and rehearsed enough that there’s not much psychological difference to staff between a feature release and a security patch.
    • Increased automation to scan libraries and other dependencies for vulnerabilities.
    • Even better monitoring.
    • Developers not only write docs, bit the docs they write include operational / release considerations.
  5. Blending DevOps practices into IT service delivery
    • Agile delivery beginning to mature into Lean practices.
    • Infrastructure as code and CI/CD pipelines maturing into “hey developer, wanna spin up an environment? click this simple button!” tooling.
    • Addressing technical debt.
  6. Continuous deployment
    • Teams work cross-functionally by default.
    • Experimentation and proof-of-concepts are common.
    • Automated regression testing, automated load testing, rollback practices, chaos engineering, and other operational concerns are so well integrated into CI/CD pipelines that, by default, new contributions to codebases are trusted to be released into production without human intervention.
    • Security and monitoring are everyone’s responsibility, and everyone is empowered appropriately.
    • Codebase developers are well-integrated into user support shifts.

In my opinion, DevSecOps principles are easiest to apply in a purist sense – “in a bubble” – with software products that have a broad, relatively homogenous, external userbase such as:


ITSM Tools has a nice model for measuring the maturity of an organization’s information technology service management (“ITSM” for short) practices:

  1. IT is an ad-hoc firefighting cost center to the organization.
  2. IT begins to systematically control the services the organization offers.
    • Service catalogs.
    • Supplier contract management.
  3. IT becomes increasingly customer-centric.
    • Proactive business-productivity development with technology.
    • Technology supported with shared services.
    • Support of inter-departmental collaboration increases.
  4. IT aligns to the organization’s business.
    • Automation of service delivery improves.
    • Benchmarks and data-driven improvements.
    • Knowledge-centered support (Knowledge Base / documentation) improves.
    • Technology solution co-creation with customers continues to increase proactiveness.
  5. IT is a business partner in the organization.
    • Agile/Lean delivery of real business value to “customers” within the organization.
    • Automation of service delivery improves further.
    • Quality of IT service delivery is recognized as a key differentiator of the organization from other organizations.
    • IT and non-IT departments function as business partners.

With software products that have a complex internal userbase, IT teams may find that they’re best able to deliver business value by thinking primarily about their IT service delivery maturity, and letting their DevSecOps maturity serve that goal secondarily.

  • Automation that is very “beginner-level” to a web developer could be level-4 / level-5 maturity to a Helpdesk or Identity and Access Management team.
    • Does your IAM team know how to use the Azure CLI tool, or are they completely dependent upon old PowerShell scripts?
    • Could a PowerShell pair-programming session between a “traditional developer” and a Desktop Software Configuration Management specialist improve packaging into the Windows Software Center to keep enterprise application desktop clients up-to-date with server versions? (Could your web server software developers even learn PowerShell from the SCCM experts and completely take over packaging updated Windows-ready client packages as part and parcel of feature releases?)
  • Test-driven development is “beginner DevSecOps,” but letting a helpdesk drive the development of unit tests for software used by an organization’s staff is high-level holistic IT service management.
--- ---