From ITSM to ESM: Why a Platform's Data Architecture Dictates Success in Scaling Corporate Services
Updated at: 9 June 2025
Companies adopting an ESM (Enterprise Service Management) approach — that is, extending IT Service Management (ITSM) practices to HR, Legal, Admin, and other departments — often hit roadblocks with traditional system architectures. These old setups can slow down digital transformation and put more strain on the IT department. A dynamic data model, however, opens up new ways to build flexible corporate service systems. In this article, experts from SimpleOne explain how a modern approach to organizing data can cut down the time it takes to implement changes and give business units more independence.
Why is ESM Transformation Stalling?
Turning an IT department into a service organization (ITSM) has already shown its worth — clear processes, service catalogs, and predictable results help work get done with maximum efficiency. However, when companies try to scale these service tools (like service portals, service catalogs, and automating end-to-end processes) to all service departments in the company (that's the ESM approach), things often get stuck because of fundamental limitations in the systems they're using.
Problems with the flexibility of ESM systems show up at several levels. For example, when working with the system, departments often have to fill out fields that have nothing to do with their business processes. At the same time, setting up request forms to meet each department's needs requires expensive resources. That's why companies find themselves depending on IT — in most organizations, you can't even change a simple service request form without getting programmers involved. As a result, adapting services to business needs happens slowly, and the IT department gets swamped with customization requests.
The root of the problem lies in the data architecture. Traditional ways of storing information, inherited from an era of static business processes, don't meet today's demands for flexibility and speed in adapting services. Changing a request form could be a simple job for a business user, not needing IT department resources.
The solution is the concept of a dynamic data model — an approach where the data structure can change or expand without altering the main database schema. This is put into practice using REM (Record Extended Model) technology. This architectural approach to organizing data lets you set up request types with the necessary attributes without touching the main system. When the HR department can add a new type of hiring request on its own, the legal department can create a contract approval form, and finance can make a payment approval request, the speed of implementing changes goes up dramatically. And all this happens without compromising data integrity or needing to rebuild the entire system structure.
The traditional way of building information systems is like designing a building with a fixed layout. If you need a new room tomorrow, you have to knock down walls. REM technology turns your ESM system into a transformer that can adapt to new needs without a major overhaul. This fundamentally changes how quickly a business can implement changes.
So, what approach to organizing data will let you successfully scale the service approach to all company departments? Let's look at how modern systems are built and why data architecture is becoming a key factor when choosing an ESM platform.
Approaches to Structuring Data in ESM Systems
When building an ESM system, a company usually chooses between three main ways to organize data. Each has its own features that directly affect how flexible the system is and how quickly changes can be made.
- Wide data tables
With this approach, all types of requests are stored in one big table with lots of fields. As new request types come up, new fields are added to the table. The good things about wide tables are: it's pretty simple to set up at first, you can keep all data in one place, and you don't need complex JOIN queries.
But this way of storing data has its limits:
- Performance drops as the number of fields increases.
- Information overload — system users see lots of unnecessary fields.
- High chance of errors when setting up filters and data views.
- Technical limits of the database management system (for example, PostgreSQL allows no more than 1600 columns per table).
- Administration gets more complicated as the system grows.
2. Table Inheritance
In this case, a base table is created with common fields, and many "child" tables are made for different request types. Each child table inherits fields from the parent and adds its own. This approach is more structured than wide tables — each request type only has the fields it needs, and data is logically separated.
The limitations include:
- To change the data structure, a user needs admin rights in the system, and sometimes even database access.
- It's hard to set up business logic that applies to different tables.
- It takes a lot of time to make changes to several related tables.
- As the number of tables grows, the system becomes less flexible.
Let's look at an example: for an equipment request, a separate table is created with fields like "Equipment Type," "Model," and "Inventory Number." For an access request, there's another table with fields like "System," "Access Level," and "Justification." If you need to add a "Due Date" field to all request types, you'd have to change each table separately.
3. Dynamic Data Model and REM Technology
The REM approach uses a base table with standard fields, to which additional attributes are dynamically connected through models and attribute collections. When you add new request types, you don't need to change the database structure. Departments can set up their own forms without IT's help, which means you get value from changes much faster (time-to-value). As attributes are clearly separated by models, there's less risk of errors, and users don't see a bunch of irrelevant fields — only the ones that matter to them.
For example: the accounting department independently creates a "Payment Approval" model with a "Payment Details" attribute collection. The HR department uses a "Recruitment" model with attributes like "Position," "Required Experience," and "Expected Salary." For both requests, a common "Due Dates" collection can be used without duplicating settings.
To create a dynamic model, you just need to understand the basic principles of REM. When building the model, you need to carefully design collections and attributes to avoid redundant data, duplicate information, and potential conflicts between models with overlapping attributes.
What is REM and How Does It Help Build Flexible ESM Systems?
The Record Extended Model (REM) is an architectural approach to organizing data that lets you dynamically expand the main structure without changing it. REM is based on the classic EAV (Entity-Attribute-Value) approach.
REM solves a fundamental problem of corporate information systems — the need to flexibly adapt to the diverse needs of different departments without making the data structure overly complicated.
Main Components of REM Architecture
REM consists of three main components that collectively ensure the system's flexibility and scalability:
- Model: Defines a set of additional fields that will be linked to records in the main table. For an ESM system, a model could be, for example, "Equipment Request" or "Supply Order."
- Attributes: Individual fields that store specific information. For an equipment request, these could be "Device Type," "Equipment Model," and "Quantity."
- Attribute Collections: Logically grouped sets of fields that can be used in different models. For example, a "Delivery" collection might contain attributes like "Delivery Address" and "Preferred Delivery Date."
How REM Transforms ESM Processes
With the traditional way of organizing data, each department gets a fixed set of forms that are expensive to change. REM changes this pattern and allows for decentralized service configuration in ESM systems — moving it from the IT department's responsibility to individual departments. This, in turn, shortens the development and implementation cycle for changes.
Furthermore, REM allows all requests to be stored in a single table. If needed, the request model (the set of attributes) can be changed after the request is logged, while keeping the original request number. This makes life easier for the end-user, who doesn't have to create new requests if they initially picked the wrong model.
A major advantage of REM is fine-grained access control. As information is clearly separated by models, the system allows for flexible management of rights at the level of individual attributes and collections. For example, the HR department can have access only to its models, finance to theirs, while common attributes can be accessible to everyone with different viewing and editing rights. This approach reduces the risk of confidential information leaks and follows the principle of least privilege.
REM is especially useful when creating complex services that require several departments to work together. For example, the new employee onboarding process involves steps from HR, IT, Admin, and Accounting. REM allows each department to set up its part of the process while keeping data consistent across the entire chain.
ESM platforms with REM technology have an edge over other systems due to higher performance, less need for development resources, and simpler scalability. REM turns an ESM platform from a rigid system with predefined processes into a flexible constructor for corporate services, which is especially valuable in the midst of digital transformation.
Comparing Approaches by Number of Steps
Choosing how to structure data is a strategic decision that will determine how successful you are at scaling the service approach beyond the IT department. To see the difference in the three approaches to structuring data, let's compare the process of adding a new request type to an ESM system:
| Step | Wide Table | Table Inheritance | REM |
|---|---|---|---|
| 1 | Get admin rights to change DB structure | Get admin rights to create a new table | Create a new model (business user can do this) |
| 2 | Add new fields to the main table | Create a new "child" table with inheritance | Add attributes or connect existing collections |
| 3 | Set up views to hide unnecessary fields | Set up views for the new table | Configure the request form (built-in functionality) |
| 4 | Create business rules considering all existing fields | Create business rules for the new table and/or override existing ones | Configure business rules within the specific model's context |
| 5 | Test how changes affect the whole system | Test the new table and integrations | Activate the model |
The REM process can be done by business users without deep technical knowledge, which speeds up the change implementation cycle and reduces costs for specialists.
Adopting the REM approach typically cuts down ESM process implementation time by 3-4 times. More importantly, it allows business users to self-configure many services, which profoundly changes how a service culture evolves in an organization.
Business Cases: REM for Business Departments
When an organization scales its service approach beyond the IT department, it encounters a variety of processes in different departments. Each department has its own specifics, unique data types, and requirements for processing them. Traditional approaches to structuring information lead to rigid, isolated systems that are hard to integrate and adapt. Let's look at examples from specific departments to see how REM technology transforms workflows and improves interaction efficiency.
HR Automation
The HR department deals with diverse processes, each requiring a unique set of fields:
- Absence requests need dates, type of absence (vacation, business trip, sick leave), and who will cover.
- Document requests list necessary documents, the purpose for getting them, and the delivery format.
- New employee onboarding includes fields for position data, salary, and required equipment.
If you put all these fields in one table, the system would become bulky and hard to manage. REM lets the HR department keep all requests in a single table, while each request type only gets the attributes it needs. It also allows them to quickly create new request types without changing the table structure and to set up forms for different roles — a manager sees one set of fields, an employee another, and an HR specialist a third.
Legal Department Automation
The legal department works with many types of documents that need different attributes and approval routes:
- Contracts with counterparties require data about the counterparty, amounts, terms, and special conditions.
- Legal opinions have a different set of attributes, including legal risks and recommendations.
- Powers of attorney contain information on terms, authorities, and representatives.
Using REM in the legal department allows for creating flexible document approval routes depending on their type, and using common attribute collections (like "Counterparty") for different document types.
REM makes it possible to adapt quickly when laws change. When new regulations come into effect, the legal department needs to quickly modify forms and approval processes. In a system with REM architecture, lawyers can add necessary fields (e.g., "Compliance Check for Data Privacy Law X") and implement new control points in the approval route without asking the IT department. This means the department can independently ensure the company's legal security and minimize risks related to the system not meeting current legal requirements.
Financial Processes
The finance department works with sensitive data that needs strict access control and different formats for various operations:
- Payment requests include details, amounts, budget items, and reasons for payment.
- Budget approvals contain planned figures, comparison with actuals, and explanations for deviations.
- Expense reports require itemized expenses, attached documents, and handling of different currencies.
REM gives the finance department extremely flexible access control at the model and attribute level. For example, information about amounts and counterparties in payment requests might only be visible to the CFO and chief accountant, while the overall request status is available to all process participants. When working with budgets, REM lets you set up access so that department heads see only their expense items, while top management sees consolidated data.
Department Integration: End-to-End Processes with a Unified Architecture
REM becomes especially valuable in end-to-end processes that span multiple departments. For instance, the new employee onboarding process involves steps from HR, IT, Admin, and Accounting:
- HR creates the employee profile and starts the process;
- IT prepares accounts and equipment;
- Admin organizes the workspace;
- Accounting sets up parameters for salary calculation.
Without REM, each department would have to create its own tables and processes. Integrating and tracking data would be harder because it would require developing and maintaining many data exchange interfaces between separate systems. This creates technical debt and increases the risk of errors when transferring information. Moreover, any change in an end-to-end process without REM affects multiple systems at once, making update coordination a complex task. With the REM approach, all departments work in a single system with a common data structure. Each sees only the attributes relevant to their work, and when one department's requirements change, the whole system doesn't need to be rebuilt.
Conclusion
A dynamic data model and REM technology are becoming not just a technical advantage, but a strategic factor for success when scaling the service approach across an entire enterprise. They help overcome the "silo culture," where departments are isolated from each other, and create a unified digital environment where different departments can work together effectively while still having the independence they need.
By choosing an ESM platform that supports REM, companies get a tool that grows with their needs and adapts to changes in business processes without significant investment in redevelopment. This is especially important in today's world, where the speed of implementing changes is a competitive advantage, and the workload on IT specialists is reaching critical levels. REM allows skilled technical specialists to be freed from routine customization tasks and redirect their potential to projects with high business value.
