Download full articleIn this blog, I discuss an ITSM tool development approach that may help aspiring ITSM tool developers and tool vendors to accelerate the development of tools that address some critical enterprise requirements and expectations from ITSM tools.
Three Seats at the Same Table
Over the three decades of my career, I have sat on multiple sides of the ITSM tool conversation, and each perspective has reshaped how I interpret the others.
Early in my career, working as a pre-sales solution expert for Enterprise Management tools, I saw how enterprise platforms are positioned. What gets highlighted, what stays understated, and how demonstration environments are often engineered to present a level of coherence towards which the product is still evolving.
Later, as a delivery leader in global organizations, the reality became harder to ignore. The gap between promise and practice is not theoretical. It shows up in integration debt, fragmented security models, reporting that depends on specialist intervention and AI/ML features that, if present at all, impress in presentations but struggle to deliver clarity in live operations.
More recently, as a formal ITSM tool assessor aligned to the PeopleCert ATV programme, I have seen how early architectural decisions echo over time. Choices made in year one rarely disappear. They compound, often limiting what later innovation can realistically fix.
Thus, in this blog, my perspective is not drawn from a single role. It comes from moving across them. That combination is what makes certain patterns impossible to ignore once you have seen them.
The pattern that persists
The global ITSM market is estimated at approximately USD 14.95–17.1 billion in 2026 and is projected to reach USD 28–30 billion by 2030, growing at a CAGR of 13.9–14.4%. ServiceNow alone commands approximately 44% of the ITSM software market, with the top four vendors collectively holding around 50% market share, thereby leaving the remaining share actively contested by smaller, regional and emerging players.
For any vendor aspiring to credibility beyond niche deployments, differentiation through coherent engineering is no longer a competitive advantage — it is the price of entry.
Yet the pattern I have observed across three decades and three vantage points remains stubbornly consistent: lopsided development.
Emerging vendors frequently deliver functionally capable modules such as strong incident management, respectable change workflows and serviceable asset tracking, yet struggle with architectural fragmentation, inconsistent data models, security treated as a final sprint rather than a foundational layer and AI/ML features added for market positioning rather than governed production use.
Tools sometimes also get built from open-source origins into broader platforms, accumulating capability organically rather than architecturally. Others have been assembled through acquisition or rapid iteration, with integration seams that become visible only under enterprise scrutiny.
These are not failures of ambition or intelligence. They are the predictable result of resource-constrained product development in a market that rewards rapid feature delivery over structural coherence. The problem is not what was built. It is the order and philosophy in which it was built.
This Eight-Dimension Development approach – let’s call it “The coherence framework” – is proposed to address that.
What this framework is — and what it is not
PeopleCert’s Accredited Tool Vendor programme (ATV) provides rigorous, independent evaluation of ITSM tools against ITIL practice alignment across more than 650 functional criteria. It is the most credible external validation available to vendors in this space, and I would encourage any serious vendor to understand it, prepare for it and pursue it.
What ATVA does not assess — because it is not designed to — are the non-functional architectural foundations that determine whether a tool can sustain that functional alignment over time, at enterprise scale, under real operational conditions.
The Eight-Dimensional Framework addresses precisely that layer. It is not a competitor to the ATV programme. It is a development accelerator — a structured lens for building the architectural foundations that make ATV accreditation achievable on the first attempt, and enterprise trust sustainable beyond it.
It is also worth stating plainly: this framework introduces nothing that is entirely new. Established disciplines — from TOGAF’s architectural governance principles and ISO/IEC 25010’s software quality characteristics, to DevSecOps practices and CMMI’s maturity models — have long addressed many of these concerns individually and with considerable rigour. The Eight-Dimensional
Framework makes no claim to replace or supersede any of them. It is, rather, a purposeful synthesis: a practitioner’s lens that brings these well-proven disciplines into coherent alignment specifically for the ITSM tool development context — where, in my experience, they are too seldom applied together.
It is also, if I may take the liberty of adding, not addressed exclusively to ITSM tool vendors. The concepts are generic enough to be useful to any software product development endeavour operating in the IT management space.
If you are a delivery leader evaluating tools, an architect designing platform selection criteria or a leader for a team developing a promising tool — these eight dimensions provide a useful diagnostic language.
And if any of these dimensions read as stating the obvious to your seasoned teams — I ask only for your generosity of spirit. The obvious, in my experience, is far more rarely practised than it is understood.
The eight dimensions for coherence
Dimension 1: architectural homogeneity
Core requirement: All modules must share a common architectural blueprint — consistent data handling, a shared service layer, unified authentication and predictable behaviour across the entire product surface.
What I have seen go wrong: The most common failure mode is starting with a strong monolithic core and adding microservices, acquired components or partner integrations without architectural governance. The result is a product that demonstrates well in isolation and fragments under integration. Data flows become inconsistent. Reporting becomes unreliable. Behaviour becomes unpredictable at the edges — which is precisely where enterprise users spend most of their time.
Practical criteria:
- A single reference architecture document is defined for the product or solution and is consistently applied and verified prior to the development or acquisition of any modules
- Apply shared domain-driven design patterns and a central service layer from the outset
- Conduct periodic homogeneity audits using automated dependency mapping
ATV relevance: Homogeneous architecture is the foundation on which consistent ITIL practice implementation across modules becomes demonstrable rather than claimed.
Dimension 2: security embedded by design
Core requirement: Security must be non-negotiable at every layer, from the first line of code — not a compliance exercise conducted before launch.
What I have seen go wrong: Security treated as a final sprint, or an external audit item, generates remediation debt that is disproportionately expensive to resolve and disproportionately visible during enterprise pilots and formal assessments. The bolted-on security pattern is recognizable within minutes of architectural review.
Practical criteria:
- Mandate encryption at rest and in transit, plus secrets management, in every backlog item from the outset
- Adopt zero trust principles — continuous verification, least privilege access, and an assume-breach mindset — as architectural defaults rather than optional configurations
- Automate security scanning within CI/CD pipelines and maintain immutable audit trails throughout
ATV relevance: Embedded security directly strengthens compliance with Information Security Management practice requirements and removes one of the most common blockers to accreditation.
Dimension 3: secure and standards-based integration
Core requirement: The tool must integrate cleanly and transparently as a trusted participant in any enterprise ecosystem — not as a proprietary island that requires custom engineering to connect.
What I have seen go wrong: Proprietary connectors, undocumented APIs, and non-standard authentication mechanisms are sometimes among the common causes of failed enterprise proofs of concept. They signal architectural immaturity to any experienced evaluator immediately.
Practical criteria:
- All platform capabilities are exposed via documented, secure, and industry-standard APIs, with published interface specifications and standard authentication protocols
- Prioritize event-driven architecture and configurable, auditable webhooks for real-time integration
- Document and version every integration contract; test against common enterprise platforms early and continuously
ATV relevance: Standards-based integration directly supports the data flow and interoperability principles that underpin multiple ITIL practices.
Dimension 4: insight architecture — reporting, dashboards and visual intelligence
Core requirement: Provide role-specific, customizable visibility into operational data without requiring developer intervention for every new view.
What I have seen go wrong: One-size-fits-all reporting that serves nobody particularly well, or advanced analytics locked behind custom development work, significantly limits adoption at every level of the organization. The executive who cannot get their dashboard without raising a ticket will stop using the tool. The process owner who cannot see their practice metrics without calling support will stop trusting it.
Practical criteria:
- Build a self-service analytics layer that allows operational and executive views to be configured by users, not developers
- Predefine role-appropriate views — executive, operational, and practice-owner — on the same underlying data model
- Ensure all dashboards are exportable, schedulable, and, where appropriate, embeddable in other surfaces
ATV relevance: Robust insight architecture enhances support for Measurement and Reporting practice requirements across the assessment.
Dimension 5: AI and Machine Learning — impactful, adaptive, and explainable
Core requirement: AI/ML capabilities must learn from the customer’s specific operational environment, explain their reasoning transparently, and operate within defined human governance boundaries.
What I have seen go wrong: Generic models that cannot adapt to customer data, recommendations that cannot be interrogated or explained, and automated actions that cannot be reversed create trust erosion that is very difficult to recover from. AI added for marketing positioning rather than operational value is identifiable within a single week of production use.
Practical Criteria:
- Implement continuous learning pipelines that allow customer-environment fine-tuning over time
- Surface model reasoning for every recommendation – priority scoring, risk assessment, and knowledge suggestions – in language that operational users can understand and challenge
- Enforce mandatory human oversight thresholds and ensure all automated actions are reversible with a full audit trail
- Resist the temptation to add a bolt on AI feature, just for marketing reasons
- Pay attention to AI governance – explainability, model drift, data privacy, and guardrails – right from the beginning
ATV relevance: Governed, explainable AI directly supports emerging AI-related assessment criteria across ITIL practices and positions the tool credibly for the AI-native enterprise environment ITIL (Version 5) addresses.
Dimension 6: operational observability — built-in telemetry and maintainability
Core requirement: The platform must expose its own operational health transparently — to its operators, to its customers, and where appropriate, to its assessors.
What I have seen go wrong: Tools deployed without internal monitoring capability force reliance on customer infrastructure or vendor support for basic operational visibility. This creates dependency, reduces trust, and becomes a significant liability during enterprise operations at scale.
Practical criteria:
- Embed real-time telemetry, health dashboards, and structured logging from the initial release not as a later addition
- Provide automated maintenance routines and non-disruptive upgrade paths that do not require customer downtime or vendor intervention
- Document common failure modes, recovery procedures, and self-healing mechanisms as part of standard product documentation
ATV relevance: Operational observability demonstrates the long-term maintainability and reliability that sustained accreditation requires.
Dimension 7: semantic and experiential consistency — data models and user experience
Core requirement: The tool must speak one language and behave predictably across its entire surface — in terminology, in data structure, and in interaction patterns.
What I have seen go wrong: Module-specific terminology that conflicts with the product’s own glossary, UI patterns that differ between sections, and data models that diverge across features all create user confusion that accumulates into adoption failure. They also corrupt the data quality on which AI features and reporting depend — a problem that compounds over time.
Practical criteria:
- Maintain a single, ITIL-aligned glossary enforced at the code level — not just documented in a style guide
- Adopt a unified design system for all UI components and interaction patterns, applied consistently across every release
- Conduct cross-module user testing in every release cycle, not only for new features
ATV relevance: Semantic consistency ensures that ITIL practice support does not drift across modules over time — one of the more subtle but consequential assessment dimensions.
Dimension 8: alignment with ITIL and other industry best practices: the validation imperative
Core requirement: If the tool (vendor) is aspiring to ATVA accreditation or operates in an industry context where accreditation or compliant tools are valued by clients, ITIL alignment must be embedded structurally in how the tool is designed and built — not applied cosmetically to pass an assessment.
What I have seen go wrong: Not always but sometimes, I see vendors who claim ITIL alignment based on feature presence rather than architectural support. They are identifiable within the first hour of formal assessment. The difference between a tool that supports ITIL practices and a tool that has labelled its features with ITIL terminology is substantial, and experienced assessors know it immediately. Merely having a screen or a button on a dashboard will not deliver the outcomes the ATVA program is designed to assess.
Practical criteria:
- Map every architectural decision to relevant ITIL guiding principles during design reviews, not retrospectively during assessment preparation
- Use this framework as a pre-ATV self-assessment before formal submission, identifying gaps while they are still inexpensive to address
- Treat ATV accreditation as the independent validation of what the architecture already demonstrates — not as the exercise through which alignment is first established
ATV relevance: This dimension is, in essence, the integration of all seven preceding dimensions into the formal accreditation context. A tool that has built coherently across all eight dimensions will find ATV a confirmation. A tool that has not will find it a reckoning.
Conclusion: coherence is a craft decision, made early
The ITSM market does not lack ambition, feature investment, or marketing sophistication. What it often lacks is coherence — the quality that emerges when every architectural decision, from the first sprint to the hundredth release, is made with the whole product in mind rather than the next demonstration.
I have seen tools that impressed everyone in the boardroom and disappointed everyone in production. I have seen tools that looked modest in a demo and performed with quiet, sustained reliability across years of enterprise operation. The difference was almost never features. It was almost always architecture — the decisions made early, under pressure, when it would have been faster and cheaper to cut corners.
This framework will not write your code, resolve your technical debt, or prepare your ATV submission. What it offers is a structured way of thinking about coherence before the costs of incoherence become visible — which, in enterprise software, they always eventually do.
Build differently. Build from day one. And when you are ready for independent validation, let ATVA confirm what your architecture already demonstrates.
Final note: The Eight-Dimensional ITSM Tool Accelerator Framework is an original contribution by the author, distilled from global assessment, delivery and pre-sales experience across three decades. It is designed to complement — not duplicate — PeopleCert’s ATV programme.