ITSM (IT Service Management) implementation is typically viewed as a simple process of designing several core ITIL processes and employing a ticket system to handle process approvals and workflows. This approach is often the initial choice for most enterprises to meet compliance requirements in IT O&M management, ensuring that work processes include approval workflows and traceable records. Under such requirements, an ITSM system only needs basic process functions such as ticket submission, approval, and handling, essentially serving as an electronic ticket system.
However, as enterprises advance their digital transformation, the demand for efficiency in IT O&M and services continues to rise. If enterprises continue to build ITSM with a traditional ticketing-system mindset and focus solely on compliance without considering efficiency, they are likely to find themselves in a passive position over the long term. It is therefore crucial to establish a solid ITSM foundation during the initial implementation phase so that the system can respond flexibly to the challenges created by ongoing business digitalization.
This section explains platform-based thinking and how to apply it to ITSM so that service management can be developed more effectively in the digital era.
01 Platform-Based Thinking
What is Platform-Based Thinking?
In simple terms, platform-based thinking means building the “stage” before developing business scenarios rather than piling on scenario-specific functions from the outset.
A platform should provide two core capabilities:
Enable horizontal expansion of business scenarios without modifying the core system code.
Support the abstraction of common capabilities into an underlying layer for reuse by upper-layer scenarios.
This concept is neither new nor unique; it is widely used. Operating systems, PaaS, business capability platforms, and many other terms reflect the same underlying logic: the software-engineering principle of high cohesion and low coupling, which supports modular, maintainable, and scalable systems.
Figure 1
Why Should ITSM Be Platform-Based?
1. System Complexity Factors
If a software system supports simple business scenarios and functions, there is no need to make it platform-based. Historically, the complexity of ITSM implementation lay in formulating and implementing management standards rather than in the tool itself. The challenge for managers was to design processes based on ITIL practices that matched their management needs and could operate effectively. Consulting teams produced extensive documentation and rules, most of which did not need to be implemented in the system. ITSM tool requirements were similar to those for a ticketing system: submit tickets, keep records, and support compliance audits. Many enterprises did not even deploy a dedicated ITSM system; they used paper-based processes or ran IT O&M workflows in OA and other workflow-capable systems. Overall, ITSM tool requirements were simple, and the complexity lay elsewhere.
In the digital era, digital transformation is essential not only for business functions but also for IT O&M. Business system architectures are becoming increasingly agile, while the widespread adoption of internet services is reshaping employees’ perceptions of work and expectations for user experience. These changes are accelerating the transformation of IT O&M. A straightforward example is that an ITSM system without mobile access can no longer meet current user needs. As a critical component of IT O&M management, ITSM must also undergo digital transformation. The emergence of industry practices such as ITIL 4 and VeriSM further confirms this trend.
Cover of VeriSM: A Service Management Approach for the Digital Age
Therefore, amid the digitalization, agility, automation, and intelligence of IT O&M, ITSM tools have become essential, and their implementation is far more complex than in the past. Before building a hundred-story skyscraper, the platform foundation must first be put in place.
2. Collaboration Factors Between Clients and Vendors
There has always been a tension between clients and vendors. Vendors, as service providers, prefer standardized delivery, whereas clients, as service consumers, prefer personalized service. This tension is especially evident in management software such as ITSM. Each enterprise has a different development stage, team culture, and management needs. Even with authoritative guidance from best practices such as ITIL, implementation details vary greatly, creating significant collaboration challenges.
Customized software versions developed to meet a client’s specific needs often cannot keep pace with ongoing upgrades to the product’s main version. Beyond the inability to reuse feature updates, difficult defects can impose high maintenance costs on both parties. For example, an old version may contain a serious latent defect; when it surfaces, the vendor must spend resources fixing the same problem again. Even if the client does not pay for the fix, it may still suffer business disruption and lower user satisfaction. The likely outcome is a lose-lose situation.
Therefore, we propose the following recommendations:
From a technical perspective：
Software design has a classic “Open/Closed Principle”: software should be open for extension but closed for modification. This provides an effective balance among stability, quality, and customized extension. Closing the core code to modification ensures stability, while opening the system to extension supports personalized scenarios. Platform-based design aligns well with this principle.
From a business perspective:
Technology and platforms are universal across the industry. Thus, enterprises do not need to reinvent the wheel, nor do they usually possess the corresponding resources and capabilities to build them independently. By contrast, business scenarios are personalized. Enterprises can either build them independently or seek third-party solutions without being bound to a single vendor.
Therefore, from the perspective of market demand and development, ITSM should also adopt a platform-based approach.
Figure 3
02 Reference Architecture for Platform-Based ITSM
After understanding platform-based thinking and its importance for ITSM, the following section introduces an architectural reference for platform-based ITSM.
Reference Architecture
Figure 4：Reference Architecture
Based on the previous discussions, we have gained some understanding of the platform-based concept and its necessity. But how should such a platform be built in practice? As shown in Figure 4, the key feature of this reference architecture is that it not only considers scenario scalability and capability reuse, but also incorporates a low-code engine to further enhance the flexibility of the platform.
Core Engine Capabilities of Platform: This layer abstracts highly reusable capabilities of "management scenarios" to the lower level of the platform, enabling faster and more cost-effective construction of management scenarios in the upper layers.
Scenario Layer Decoupled from Platform Layer: An extended development framework at the application module level is provided to support the expansion of complex business scenarios or integration with third-party systems.
Plugin Store: Serves as a repository for continuously accumulating a vast number of integration plugins, allowing users to install or uninstall them on demand.
Extension Mode
The ultimate focus of the above architecture is exceptional extensibility and flexibility. These characteristics are abstracted into three modes. Table 5 can be used to evaluate the maturity of an ITSM platform's capabilities.
Figure 5
03 Complex Application Scenarios of ITSM
As discussed above, the ITSM platform is designed to support more complex service-management scenarios. The following before-and-after comparisons of typical scenarios illustrate its value.
Service-Oriented IT O&M Requests
Figure 6
Using an ITSM platform, a single request process can be split into scenario-specific processes and exposed through a structured service catalog. This makes IT O&M services clear and enables users to find the services they need more easily. The complexity shifts from “one process” to “hundreds or thousands of processes.”
Figure 7
Another critical aspect is that after breaking down processes into scenarios, as illustrated in Figure 7, requests such as storage expansion can evolve from unstructured descriptions into structured forms. This transformation also lays the groundwork for automating request fulfillment. The complexity shifts from "manually filled simple forms" to "more integrated and complex forms."
End-to-End Workflow Automation
End-to-end workflow refers to connecting people and systems involved in achieving a specific goal to deliver value efficiently. In a traditional ticket system, the focus is primarily on manual steps like approvals and handling, as shown in Figure 8, merely fulfilling management compliance requirements.
Figure 8
To illustrate how a platform enables end-to-end processes, consider the storage expansion scenario shown in Figure 9. The process uses the extensibility and integration capabilities of the ITSM platform to connect the CMDB (to retrieve host information), IT O&M personnel (to enter host information), and the storage system (to create and provision storage). This delivers an end-to-end storage expansion scenario and avoids process silos. The process complexity increases from a few steps to dozens of interconnected steps.
Figure 9
Digitization of Management Strategies
Management processes involve not only fixed workflows but also human judgment and decision-making. For example, risk assessment in change management, impact analysis in incident management, and task assignment in request management require IT O&M personnel to communicate, assess, and make decisions offline. Previously, moving these activities online in ITSM ticketing systems was difficult or costly. IT departments either maintained internal development teams or relied on expensive vendor customization, resulting in high implementation and ongoing maintenance costs.
With a platform-based architecture, we can extend capabilities at a lower cost to support these management details. For change risk assessment, we can embed expert knowledge into the system to enable automatic risk calculation.
Figure 10
For incident assignment, we can codify rules into the system to automate the dispatch of incident handling.
Figure 11
04 Conclusion
In the digital era, service-management requirements have changed significantly, raising expectations for ITSM tools. Organizations can no longer be satisfied with moving only a few activities, such as approvals and collaboration, online. More service-management activities—including task assignment, problem tracking, and knowledge sharing—must be digitized comprehensively to reduce reliance on traditional documents and human memory, improve efficiency, reduce errors, and adapt better to rapidly changing business needs.
Therefore, if organizations continue to build ITSM with a traditional ticketing system mindset and focus only on basic management-compliance requirements, such systems will struggle to meet the growing demands for efficiency and user experience. Integrating platform-based thinking into ITSM implementation is a more sensible and forward-looking choice that can support business growth, improve IT O&M efficiency, and deliver a better user experience.
