Keywords

1 Introduction

Currently, digital platforms are used and can be used in various spheres of economic and social activities, including manufacturing, entertainment, medicine, logistics, public administration, etc. [1]. Despite the costs associated with the transition from legacy and outdated information systems, digital platforms can not only reduce the financial costs of organizations, the products they create, and the services provided but also can provide fundamentally new opportunities for communication and cost reduction [2].

User information and aggregated data processing will provide a better understanding of the different digital platform user groups’ preferences and adapt services to suit their needs [3]. Digital services implemented on the digital platform basis can adapt to the needs of consumers and have broad prospects for scaling [4].

The transition to a digital platform will require the aggregation of data from disparate sources and the implementation of the transition to data shared access. There is also a clear need to change processes and integrate numerous inherited information systems [5].

The digital platform is a platform on the basis of which numerous digital services are provided to individual consumers, businesses, the state and non-profit organizations. Since the digital platform should initially be developed considering the presence of many subject areas, it is possible to virtualize a significant part of the main and auxiliary processes [6].

Such virtualization becomes a tool for creating an additional enterprise value for its counterparties and consumers since the process of virtualization implies sharing of digital services [7].

Digital platforms of large companies can be integrated with digital ecosystems of other enterprises. There are numerous examples of the areas of entertainment and commerce: Netflix, iTunes, Amazon, eBay, etc. Digital platforms are also successfully used by industry (Siemens’ MindSphere, General Electric’s Predix, Caterpillar’s Cat Connect, etc.).

There are various definitions for the digital platform. Accenture Technology Company defines it as: “Digital platform—is a group of technologies that are used as the basis for the creation of specific and specialized digital interaction system.”

A digital platform is a type of enterprise that provides mutually beneficial multilateral interaction for producers and consumers. The digital platform provides an open infrastructure for participants and establishes new rules for interaction [8].

A digital platform is a collection of digital technologies, products, or services that create the basis on which external companies can create their own complementary products, technologies, or services [9].

2 Related Work

Today there are numerous studies on the fundamental ontological conceptual modelling foundations [10]. The basic issues of conceptual modelling are also highlighted in the theory and methodology of enterprise ontology forming work [11]. Also of interest is the work on domain modelling of large and medium-sized enterprises [12].

An ontological analysis of abilities and resources that were added in later versions of the ArchiMate language was made in [13]. The paper presents a proposal of the metamodel formed on the basis of current language version. The author’s metamodel includes an additional Competence object, which can be considered as a specialization of the Resource object. Considering the specifics of the subject area, the metamodel also includes Risk objects (standard for ArchiMate Assessment object specialization) and Value.

In similar work, authors studied the issue of strategic planning applying methods in conjunction with an architectural approach based on conceptual modelling methods and proposed an enterprise strategy and strategic planning model [14].

In [15], the translating DEMO process models to ArchiMate is described. The study demonstrates the possibilities of translating DEMO models into ArchiMate models based on the mapping technique. The presented model demonstrates the DEMO methodology and the ArchiMate modelling language objects interconnection. In general the method of selecting abstraction levels in the simulation of socio-technical systems and the definition of the relationship between the levels are developed by the OMG group in the Meta Object Facility standard [16] and supplemented in research projects [17, 18].

The process of a meta-metamodel constructing and its connection to models at lower levels of abstraction corresponding with the ideas of modelling and design, developed in [19, 20], as well as published in the materials of research groups NEMO, EIL, OMiLab, CIAO!

3 An Example of the General Description Development of the Target Digital Platform

3.1 Implemented Architecture Digital Platform Metamodel

Presented metamodels with the required depth of covered architecture segments study were used in designing a company working in the service industry in a group of transport companies.

Figure 1 shows the enterprise architecture main layers, the used meta models, and the general connections between it. The metamodel of enterprise architecture modeling is based on ArchiMate, the process modeling metamodel is based on BPMN 2.0 notation.

Fig. 1
figure 1

Layers of enterprise architecture, metamodel, and links between it

Full size image

Figure 2 shows the author’s metamodel for modeling enterprise architecture. The metamodel is formed on the ArchiMate architecture modeling language elements basis and architecture representations that are proposed by the Open Group consortium [21]. The selected language elements and links between it are adapted to the subject area and the enterprise architecture management current level maturity.

Fig. 2
figure 2

Formed meta-model for modeling the enterprise architecture

Full size image

Object Management Group (Business Process Model and Notation 2.0) materials [22] were used next to form the business process modeling meta-model. The materials of the Object Management Group (Unified Modeling Language, version 2.5.1) [23] were also used to form the use case modeling metamodel.

3.2 Modeling Abstraction Levels

For enterprise architecture description, three levels of abstraction were identified. (Fig. 3): M1—the level of models describing the enterprise architecture; M2—the level of metamodels, which determine the possible level M1 models’ types; M3 is the meta-metamodels level, which interconnect all metamodels and creates the basis for an agreed multidimensional enterprise architecture description.

Fig. 3
figure 3

System models’ classification and communication

Full size image

The M2 level metamodels provide M1 level enterprise architecture models integration, describing their general characteristics and key concepts. In turn, M2 level metamodels allow a holistic look at M1 level models and provide the foundation necessary for their formation. Each element of the M2 level metamodel is an instance of some meta-metamodel element (M3), and each metamodel is a meta-metamodel instance.

A meta-metamodel (level M3) contains types—predicates that characterize all instances of a type with a certain set of inherent properties. Figure 4 shows the meta-model of LLC “Service company” architecture.

Fig. 4
figure 4

LLC “Service Company” architecture description meta-metamodel

Full size image

Meta-metamodel elements are LLC “Service Company” subject domain modeled basic abstractions which provide semantic links between the models of underlying levels.

All the meta-model elements were conditionally divided into four groups, reflecting various company aspects: strategic, organizational, applications and technology (Table 1). These enterprise aspects were formed basing on the described in detail in W. Frank works [24] model basis.

Table 1 Key concepts for the digital platform higher-level architecture description
Full size table

The TOGAF standard metamodel [25] was taken as the basis for the system conceptual meta-metamodel, since this framework is the most common for describing an enterprise architecture. Metamodel TOGAF allowed the creation of “Service Company” conceptual meta-metamodel, which was used for company architecture description, considering its specificity.

3.3 Selecting Patterns of Digital Platform Simulation

Figure 5 shows an example of the relationships visualization between elements of the M1, M2, M3 levels. Earlier, on the M1 level models, digital services of the platform were allocated. The digital services “Monitoring of data from sensors” are also related to the digital services of the platform. In the metamodel of the M2 level (see Fig. 2), several different services were distinguished, an instance of which is the group of digital services of the platform under consideration. Accordingly, the “Sensors Data Monitoring” service is an instance of the “Digital service” type, and the “Digital service” type is one of the services types allocated in the metamodel at the M2 level. In turn, the M3 meta-model level, on which the “Type of Service” is highlighted, defines the basic relationships that can hypothetically be observed among the “Service” category objects. And the services reflected on the M2 level models are Type of Service instances from the meta-model.

Fig. 5
figure 5

An example of Service concept use on the different levels of abstraction

Full size image

A meta-metamodel can be used to obtain repetitive modeling structures (or patterns). Figure 6 shows a simulation pattern example for Type of Process. This simulation pattern restricts and defines direct interaction of processes in the M2 and M1 level models. The links reflected in Fig. 6 correspond to the Process Type links reflected in the meta-model in Fig. 4.

Fig. 6
figure 6

Process type generalization

Full size image

Meta-metamodel (M3) allows you to get many other modeling patterns, and then specify them using the metamodel (M2). Figures 7 and 8 show the main modeling patterns that were later used in building M1 level models on the business layer, information systems layer, and the technology layer.

Fig. 7
figure 7

Business service modeling pattern

Full size image
Fig. 8
figure 8

Digital service modeling pattern

Full size image

In Fig. 7, two areas of the pattern are highlighted. Region (1) contains meta-metamodel elements. It is argued that, in the most general form, a Service Type is implemented by the Function Type or Process Type. At the same time, to execute a Process Type, some Role Type is assigned, and the Function Type is implemented by some Object Types intended to implement the function.

Region (2) illustrates the M2 metamodel level elements. This part of the modeling pattern demonstrates that the Business Service is implemented through a Business Process, for the execution of which a certain Role is assigned. At the same time, the Application Process is used to support the Business Process. The Application Service is implemented by the Application Function, which is implemented by the Application Component. The technology service supports (serves) the Application Component, and its implementation requires the Technological function of a specific Node.

Modeling Pattern has significant differences from the Business Service Modeling Pattern (see Fig. 8). Area (1) does not have significant differences from the modeling pattern presented earlier in Fig. 7. However, area (2) has several differences. It is stated that Digital Service is implemented by some Business Process to which some Role is assigned. In this case, the Business Process is implemented by the Application Process. In turn, the Application Process is implemented by the Application Component. The technology service supports (serves) the Application Component, and its implementation requires the Technology function of a certain Node.

Thus, Figs. 7 and 8 illustrate the differences in Business Service modeling and Digital Service patterns and are used in the formation of M1 LLC “Service Company” enterprise architecture models.

The modeling patterns presented in Figs. 7 and 8 can be translated within the framework of ArchiMate notation as follows (see Fig. 9).

Fig. 9
figure 9

Business service and digital service implementation description in ArchiMate notation

Full size image

4 Demonstration and Approbation of the Proposed Methodology

4.1 Enterprise Architecture Layered Model

Digital platform modelling patterns were used in the service company digital platform development. Currently, the developed and implemented digital platform has been in operation for over 3 years. Over the past time, more than a dozen digital services were additionally implemented within the platform framework, the development of which was also carried out on the initially formed patterns basis [26].

The considered enterprise LLC “Service Company” works with the following categories of counterparties: customers; transport companies (more than 100 companies, park of each includes up to 20–50 cargo vehicles); sensor suppliers (about 10 suppliers of GPS trackers, tachographs and other sensors); service companies (more than 120 contractors who are engaged in the equipment maintenance).

In order of further company development, LLC “Service Company” top management has decided to switch into “business platform as a service” format. As a result, each group of counterparties gained access to specialized digital services.

Transport companies got access to the digital sensor data monitoring, digital analytical reports, digital order receipt, digital payments, digital support services, etc.

Sensor suppliers got access to the digital diagnostics service, remote diagnostics, digital maintenance notification service, digital technical support service.

Delivery customers have gained access to the digital order payment, digital reports generation, digital support, digital delivery monitoring, and digital ordering services.

These digital services have replaced part of the main business processes that were previously performed by the LLC “Service Company”, transport companies or sensors suppliers specialists. Auxiliary processes have undergone minimal changes and are still performed primarily by company employees.

The key digital platform IT services can be considered logistics and planning; mobile application; software development and integration; personal area; analysis and visualization; assets integration and management; sensors and devices digital twins; access to aggregated data IT-services, etc.

Digital platform portal includes the following components: official website, accounting system, mobile data system, data storage system, monitoring system, development system, AI system and ERP-system, which includes logistics system, accounting system and CRM-system. All components interact through the enterprise service bus.

The digital platform portal components function at the expense of basic technological services. The digital platform portal components are deployed at the corresponding nodes. For software development by the company contractors and its subsequent integration, a software development environment has been developed, deployed on a virtualization server.

Figure 10 shows the LLC “Service Company” layered architecture model.

Fig. 10
figure 10

LLC “Service Company” layered architecture model

Full size image

4.2 Pattern-Based Digital Services Modelling

Let us give an example of the digital service «Maintenance notification» implementation. The service is provided to customer—sensors suppliers and is implemented by sensors and equipment wear-off factors proactive analysis business process.

The sensor monitoring system in proactive mode implements three processes: sensor operation data acquisition and processing; the need for maintenance proactive analysis; notification sending. The data is automatically analyzed once a day by a need for maintenance proactive analysis. This process considers not only the received and processed data, but also some external data, loaded sensor and equipment specifications, statistical models. If the probability of failure in the next two weeks for some sensor exceeds the threshold value, then the notification is sent to sensor supplier employees.

Figure 11 shows the “Maintenance notification” digital service implementation model.

Fig. 11
figure 11

“Maintenance notification” digital service implementation model

Full size image

5 Conclusion

Practical experience has demonstrated the high efficiency of using the developed digital platform modelling patterns. Formed models were used to implement a digital platform and later became the foundation for the development of new digital services. At the same time, the architectural approach provided an opportunity for the enterprise to further scale up the digital platform.

As part of this study:

  • The relationship between the enterprise architecture layers and used digital platform metamodels is demonstrated. An enterprise digital platform architecture modelling metamodel is formed.

  • A three-level enterprise architecture abstractions modelling model is presented.

  • An enterprise digital platform architecture modelling meta-meta-model has been formed.

  • Digital platform modelling patterns and digital services implemented by this platform, with details to the level of the modelling language used, general formation logic is presented.

  • An example of successful implementation of a digital platform in a service company (including the presentation of the enterprise architecture layered model, including the created digital platform high-level architecture) and the experience of using a digital service modelling pattern is demonstrated.