Keywords

1 Introduction

Digital transformation is likely to have a profound impact in the mobility sector, leading to better services to the citizen. Initial ideas for a European-wide payment system for collaborative multimodal mobility services were introduced in [13]. The base concept relies on a payment service covering public transportation, tolling in highways and bridges, parking lots, bicycle rental, and fuel payment, all under a single contract involving direct bank debit. A new type of operator, the Collaborative Mobility Service Provider (CMSP) emerges as the entity that offers integrated services to the customer and ensures that providers of individual services follow the contractual provisions. The technological support to such services requires an open complex informatics systems of systems (ISoS) [7].

Many existing approaches throughout Europe, such as the model recently adopted in Lisbon and Porto, offer a partial solution (e.g. an intermodal transportation pass for citizens against the payment of a monthly fixed fee). However, such approaches are typically limited to a regional level, are not comprehensive enough in terms of the offered services, and the infrastructure operators maintain control of their clients. Such partial adoption is as an intermediate step for the proposed service mobility model, but further research towards a European unified mobility service is needed.

Progressing towards more integrated mobility services is aligned with a number of general policies aims at European level:

  • Improving quality of service, namely in terms of convenience and experience, without geographical borders, can contribute to re-enforce a European identity.

  • Facilitation of mobility policies, facilitating different business models, e.g. discounts above certain level of usage, variable prices depending on the period of the day, reduced prices for seniors and students.

  • Facilitate increased use of public transportation through smooth integration with tolling and parking payment services.

  • Contributing to SEPA vision (Single Euro Payments Area) and cost reduction through increased openness to more operators.

  • Contributing to the European ICT industry by actively promoting “replaceability” of systems/sub-systems/services. By eliminating vendor lock-in constraints, this strategy also reduces the risks of adopting solutions from smaller companies, thus facilitating their access to this market.

One important challenge relates to the implementation of an accreditation framework:

  • Payment services need that the corresponding providers are accredited/recognized by regulating authorities, namely in order to provide guarantees to the customer.

  • Considering wide geographical spaces, involves large numbers of customers and transactions, which represents a significant level of complexity.

  • The whole mobility services provision requires supervision and auditing mechanisms to be performed digitally by regulators. This is particularly challenging in case of a large diversity and heterogeneity of technological infrastructures. Adherence to an open reference infrastructure model could thus be a crucial facilitator and a requirement for the process of operators’ certification by authorities.

  • The need for an open reference infrastructure comes also from the need for collaboration among the various service providers, which use different infrastructures and different identification mechanisms (cards, mobile phones, car identification devices, automatic car plate identification, etc.). All mobility service usage events need to the properly communicated to the payment service operators. Detected failures need a clear and easy to apply resolution procedure, while conflicts can be mediated by authorities if access to real data can be guaranteed. Furthermore, a distributed responsibility among operators/service providers also needs to rely on an open infrastructure framework.

This context requires a high-level of automation and thus a collaboration among technological sub-systems of the different stakeholders, which should interact without or reduced human intervention.

Currently, regulators/supervision authorities face big obstacles as it is not easy for them to cope with a large diversity of infrastructures and implementations. Changes in policies may also lead to an increasing dependency on a few stakeholders that can afford large investments.

The maturing of the digital networked society requires that technology artifacts are developed and managed under unified frameworks and regulated public policies. However, the state of legacy and current implementations often establishes dependencies from single-vendor or single integrator. Public European decision-makers too often apply “exceptions” to the public tendering, which leads to continuously contracting the same supplier with the argument that assets are not replaceable by competing alternatives. Such (over)used exceptions motivate our research for agile vendor-agnostic distributed infrastructures, which should be simple to develop, to maintain, and evolve. The notion of “openness” is used as a principle that any technological artifact, being a system or an element of a system, must be replaceable [7] under a safe migration process preserving the underlying responsibility. Open also means that in the limit, any European public tender shall be free to decide among competing products (technology artifacts or services).

As shown by previous research, the “imposition” of an open technology framework proved to be a mechanism to reduce costs resulting from an increase in competition. This was observed, for instance, in the Brisa case which adopted a service-oriented electronic toll collection such that roadside equipment elements no longer were depending on a single provider [11].

In this paper we farther discuss an approach for the service payment provider model by adopting and extending previous research contributions considering two main dimensions: (i) structuring the intra-organization infrastructure by adopting the ISoS framework [7], and (ii) pursuing the collaborative networked perspective by adopting Enterprise Collaborative Network (ECoNet) [15].

In the next section, we briefly present and discuss the difficulty of realizing innovation under a philosophy of replaceable technical systems. The difficulties are discussed considering both scientific research and industry contributions towards vendor agnostic solutions. In Sect. 3 we revisit previous research on the Model-driven Engineering Open Systems (MDEOS) initiative and in particular the ISoS (organization) and ECoNet (networked organizations) frameworks, which provide the base for the proposed approach. In Sect. 4 we discuss the proposed paradigm shift from a software engineering to a systems engineering thinking when addressing complex application problems. Section 5 summarizes the discussion and presents further research needs.

2 Brief Overview of Industry Trends

There is increasing awareness about liability, security, and even brand image risks associated to the development of integrated informatics solutions for complex application domains. Given the lack of vendor-neutral development and operation frameworks, most existing technology landscapes are maintained and evolved under proprietary technology setups. The frequent need for unplanned changes as a consequence urgent business challenges is a reason for deepening specificities and therefore dependencies. Furthermore, the trend for establishing collaborative networks also contributes for an additional complexity. For both dimensions, there is a need for reference models on how to structure the involved integration. Additionally, there is a difficulty associated with the adoption of innovations supported by unique “opportunity windows” since “technology and its context of use tend to congeal” [18]. The question is thus: how to elaborate in advance a suitable mobility service provider model that can guide a strategy to generate opportunities for the European industry by “imposing” an open digital technology framework led by the need of collaboration, digital auditing and service quality enforcement?

It seems that in this sector we are facing an opportunity similar to that of the Korean leapfrog on digital TV and mobile phones that happened when the government “imposed” a digital communication standard [6]. The leadership role of public investment seems the key, not only through investing in R&D but also by “imposing” the public interest towards valuing a potential competing industry.

The acquisition of technology companies by major organizations as a strategy to address the development of such complex composites of technology artifacts is an indicator of the problem. The recent decision of Ikea [2], a large ready-to-assemble furniture retailer, of buying the innovative software development TaskRabbit is paradigmatic. This acquisition results from the need to develop a new concept of managing professional services to guarantee quality craft in assembling products. The relationship started with an initial subcontract to develop a mobile application with augmented reality for clients to match products in client’s homes. The problem, in this case, is the difficulty of developing a call for tenders since the vision exists but not complete specifications and technical decisions. Technical decisions are not easy to make in advance since they depend on the technological culture of the contractor. The Brisa case we have been following for years [11] followed a similar approach, in this case through the creation of a technology company, Brisa Innovation and Technology (BIT, now A-To-Be). But in spite of their investment in R&D and innovation, and its commitment to MDEOS [12] initiative, current BIT products still do not follow-up any open source software dynamics.

Other approaches exist, like the inference of complex development patterns from analysis of change in logs, as proposed in [3]. Research on modularity dates back to 1970’s with a work about software complexity questioning how to modularize software making components testable and maintainable [8]. Despite important developments for about half a century, this and other questions concerning how to structure software developments remain an issue. In [9] it was recognized some years ago that “with respect to current large software-intensive systems, our aspiration to establish software development as an engineering discipline is, to a significant extent, still an aspiration”. This book discusses the need for abstraction mechanisms, modularity, and composition as a strategy to cope with large software systems. Another example, [16] discusses a component strategy to cope with resilience but without exploring the computing system part. However, along the discussion, terms such as system, dependable system, resilient system, operating system, and distributed system, are used without a clear definition.

It seems that an abstract (implementation independent) conceptual framework, able to cope with the growing networked complexity and following an independent vendor framework, is still a need.

3 Revisiting ISoS, ECoNet and CEDE Concepts

3.1 Base Concepts

The example of developing a mobile service provider concept as discussed in [13] provides a promising endeavor for progressively aggregating research contributions involving technology, engineering, business, economic, and sociological viewpoints. The approach considers the development of replaceable informatics systems (Isystems) as a target goal. As an underlying initiative, the Model Driven Engineering of Open Systems (MDEOS) is a coordinated effort focusing both an open structuration for the computing-related artifacts (ISoS) and some “unification” or alignment of the development “culture” (CEDE), as depicted in Fig. 1.

Fig. 1.
figure 1

Open Replaceable Informatics Systems in MDEOS framework

Full size image

The mobility service provider case is an opportunity to “impose” convergence mechanisms, led by European authorities, in order to facilitate the development and adoption of novel smart solutions, contributing to value creation. As initially proposed in [13], the Collaborative Mobility Service Provider concept foresees a pan-European payment of mobility services. This case offers interesting research challenges considering the multidimensional risks involved in materializing the single euro payment area and the direct debits scheme for the collaborative service provision model. To bring further clarification, the initial formulation in [13] can be expanded by considering the following additional challenges:

  • The mobility service provider needs to consider collaboration with complementary industry or services sectors and its standardization dynamics: banks, payment mediation providers, transports and mobility, and government (regulation authorities);

  • The need for reducing mediation, as stated by the single European payment initiative, which is hampered by technology interoperation difficulties and debt risks associated with direct interactions between service providers and banks;

  • The diversity of infrastructure operators across Europe, which requires to find common mechanisms to make clients perform the payment of mobility related infrastructures. Validation and enforcement mechanisms need to be designed to cope with the diversity of cases, from small transport companies in a small village, to large transport systems in large cities;

  • Involved stakeholders need to be prepared to scale up and to manage failure situations since the reliance on the overall solution depends on its availability and recovery mechanisms. For instance, an attendance help-desk mechanism is needed for clients with difficulty in using the service;

  • Considering the inhabitants of the EU-28, 509.4 millionFootnote 1, as potential service users, just one percent share represents five million clients, and if in average a client makes five transactions a day, a service provider must manage 25 million transactions (utilization events) a day. The corresponding technological solution thus needs to scale up, maintaining the quality of services.

The proposed mobility service provider scenario is thus a complex engineering system of systems. The stakeholders, service provider, infrastructure operators, mobility and bank authorities, as depicted in Fig. 2, involve complex distributed collaborative services, which are operationalized through complex collaborative business processes [14]. The transport and mobility authorities should be able to interact through auditing events (a-events) with the infrastructure operator and mobility service provider. The infrastructure operator and service provider interact through usage events (u-events). The mobility service provider interacts with banks through debit and transfer events (d-events or t-events). The bank authorities interact with this environment through electronic auditing events (e-audit), a form of “digital auditing”.

Fig. 2.
figure 2

Collaborative Networked Stakeholders in the mobility service provision case

Full size image

3.2 Common Organization’s Technology Framework

The mobility service provider case requires the participating stakeholders to implement common auditing and enforcement services. The propose ISoS framework, depicted in Fig. 3 considers the organization’s computing landscape formed by one or more Isystems.

Fig. 3.
figure 3

The SysML model of the ISoS Isystem concept

Full size image

The ISoS framework suggests the need to develop reference models validated through reference implementations, which contribute to make Isystems replaceable. The development of reference models follows the proposed Reference Implementation concept of the FIWARE framework [20]. The ISoS framework facilitates the investment on reference models and respective validation implementations since formal technology independence is guaranteed through the Cooperation Enabled Services (CES) concept [10]. An Isystem is a composite of one or more CES, as depicted in Fig. 4. The CES abstraction is a composite of one or more services and like an Isystem can also have an associated Reference Model to support replaceability.

Fig. 4.
figure 4

The SysML model of Isystem and its relation to CES

Full size image

The CES composite is the atomic concept to cope with legacy or novel technologies. CES follows the new trend of microservices while elementary functionalities and as Isystem’s element hiding different implementations. The microservices [1] “emphasize lightweight virtual machines” and point to autonomous computing entities. There are other contributions under SOA very similar to microservices. The example of the JINI framework [19], adopted by the ITSIBus [11], in the construction of open autonomous modularity can be considered aligned to the microservices trend. As discussed in [1], the fast-growing role of virtualization and in particular the approach followed by docker, reusing an old mechanism natively available in the Linux kernel (cgroups and namespaces), establishing efficient, lightweight, isolated execution environments [17], is already used in SOA contexts. In our model, CES’s services can deploy to a lightweight container and, in this way, establish an isolated, autonomous computing entity. CES is, therefore, a composite of one or more Services, as depicted in Fig. 5. Like an Isystem, also a CES can have a Reference Model, making it a replaceable implementation. The key feature of an ISoS Service that makes it different from related works is the independence from a specific technology.

Fig. 5.
figure 5

The SysML model of CES and composite services

Full size image

As depicted in Fig. 5, by calling the CES selfAwareness() method, the set of implemented Services are obtained, beyond other attributes. Each Service has an associated couplingData, represented by the Generic Modeling Entity (GME) type. GME abstracts specificities of the Service implementation. The decoding of the couplingData content depends on the MIME-Type tag, as depicted in Fig. 6.

Fig. 6.
figure 6

The SysML model of the Service Generic Modeling Entity (GME)

Full size image

The MIME-Type uses the Multipurpose Internet Mail Extensions (MIME) concept, an IETF standard used here to discriminate available technology implementations. The MIME-Type values classify (identify) specific technology implementation as a pre-established convention for the model of the dataObject attribute, an instance of the GME entity. Beyond the contentType and other attributes, the metaData object also contains a digitalSignature to trust the Service through some certifying organization. For security and responsibility reasons, it is important to guarantee the integrity of the adopted Service implementation. As the model is applied in products developments by the industry, further open specifications are expected to be detailed or proposed.

After establishing the organization’s technology framework based on Isystem/CES/service and the selfAwareness() method of both Isystem and CES, which we designate by Adaptive Coupling Infrastructure (OACI) [7], the next section discusses the interaction between Isystems in the Collaborative Networks context.

3.3 Collaborative Networked Organizations Technology Framework

The ECoNet framework and platform [15] is proposed as a contribution to structure the underlying collaborative environment and make it easier for an organization to get prepared to join a collaborative network. An issue is the diversity of adapters that nowadays are necessary to establish interactions between Isystems of different organizations as discussed in [13]. In this paper, we detail the ECoNet framework and the proposed ECoM as the Isystem that into each networked organization is responsible for managing business exchanges between Isystems of different Organizations. To discuss the need of the ECoNet for the mobility service provider, we revise the ECoNet architecture based on its SysML model as depicted in Fig. 7.

Fig. 7.
figure 7

The SysML model of the ECoNet organization’s network

Full size image

Each service provider stakeholder needs to install an ECoM Isystem obtained from the ECoNet coordination. As proposed in [15], an organization can register at ECoNet coordinator and select a business provider of a supported ECoM implementation. With an ECoM Isystem, specialized in managing collaborative network interactions, a service provider stakeholder is prepared to interact with business partners, based on the required Collaboration Contexts (CoC). Any organization’s Isystem can integrate with the ECoM through the ISoS logical integration bus [7], i.e., through the CoC selfAwareness() method since a Collaborative Context is, in fact, a CES composed of the Services necessary to operate and manage the required business exchanges. Figure 8 depicts the SysML model of the ECoM Isystem.

Fig. 8.
figure 8

The SysML model of the ECoM Isystem

Full size image

A collaboration context is equivalent to the existing adapters used to manage specific interactions between Isystems of business partners. However, by adopting ECoNet, i.e., by installing an ECoM, the adapters are wrapped into services of a collaboration context (CoC). A specific collaboration context establishes a virtual collaboration context with virtually all business partners that join a specific collaboration context. The Virtula Collaboration Context zero (VCC0) is a kind of shared space among all organizations sharing a common collaboration context. Any business partner can create its own VCC and invite business partners to join the created virtual collaboration context. Each VCC establishes a multi-tenant secure collaboration space. The services implemented by the collaboration context establish the interaction mechanisms to be accessed by the organization’s Isystems that need to exchange data or coordination information among ECoNet nodes.

4 From Software to System’s Paradigm Shift

Computer science and engineering need to evolve from a software to a systems-centric approach. Even if the SCRUM methodologies [5] are important in organizing software development, the diversity of computing paradigm used by different organizations establishes complex interdependencies difficult to manage. Such complexity suggests the term software system can be abstracted by the informatics system (Isystem) concept, which combines ideas from areas like information systems, distributed systems, database systems, operating systems, web systems, and so forth. In our formulation, the notion of informatics system is central in abstracting computing related paradigms under a unified approach. It establishes a responsibility centered on computing elements, but it can include other specializations or elements from other knowledge bodies. Therefore, by adopting the Isystem concept a move from software to system’s thinking is promoted in mapping business requirements and formal high-level concepts with clear responsibility boundaries. Systems thinking is considered a key approach to the study and development of System of Systems and SoS Engineering where interactions among system elements are of paramount importance [4]. Developing complex and reliable systems is difficult since dependencies among a large number of software modules without formal isolation mechanisms make difficult the identification of potential problems.

Moreover, there is a recurrent difficulty in making a clear separation between (business) processes or the “what” is intended, and the structuration of the technology landscape or the “how” to proceed. The difficulty results from the lack of a general framework able to cope with the complex interdependencies among the required computing elements.

The mobility service context requires an automated organization where persons and technology fit well under pleasant and cost-effective (sustainable) symbiosis. An approach where any person “sees” the mechanisms he/she need to fulfill social and professional activities and be manageable under a sustainable model. User’s expectation is to hold the right tools and facilities to pursue activities under “perfect” operation and fulfillment. However, the problem is that existing technology artifacts have been evolving, pushed by fierce market competition and without a well-defined open and independent supplier model able to position each artifact independently of its dimension/complexity in cooperation and under a unified managed (coordinated) technology landscape.

To the question if state of the art is ready for the mobility service provider challenge, the answer is no. However, if the question is about the readiness of technology the answer would be yes. The difference is that with state of the art the approach to such a mobility service provider challenge would follow proprietary approaches and a suite of adapters to integrate the participating technology systems. Following the MDEOS strategy, both ISoS and ECoNet have been evolving, under an open specification and co-financed by projects with the industry and Public Authorities (Brisa/A-To-Be, Galp, BP, Road Authority, Ports Authority) converging smoothly for adoption in production.

We argue that the European Public interest, represented by the mobility and bank authorities, shall lead a project to support the mobility service provider vision based on a strong commitment from the research community, and with the participation of interested companies. It is of paramount importance the establishment of ontologies establishing reference models based on standard Isystem or CES in promoting multiple supplying. The social value by pushing the multi-supplier paradigm based on the replaceability principle shall be the investment motivation. From the cases studied in previous research leading to the proposed framework, a recurrent result was the cost reduction resulting from the promotion of market competition [7, 13].

5 Conclusions and Further Research

This paper further explores previous research on ISoS and ECoNet frameworks to support a collaborative mobility service provider. This involved detailing the strategy to develop open reference models, guided by digital auditing from transport and mobility and bank authorities. The potential failure and performance (scalability) risks of current distributed computing technology systems suggest the adoption of an independent technology approach. The proposed ISoS framework was demonstrated in various projects to make viable the adoption of different technology paradigms. The proposed Isystem, CES, and Service concepts make it possible to develop adaptive modular informatics systems and, in this way, offer promising solutions for the identified business processes. For the networked dimension, the ECoNet platform is proposed to unify collaborative business exchanges of both data and control. The collaborative contexts and virtual Collaborative Contexts, managed by the ECoM Isystem, are part of a unified strategy to manage business interactions under a common framework. The organization’s Isystems integrate with ECoM to automate collaboration processes and, in the mobility service provider case, to establish the base for a common digital auditing strategy for both transport and mobility and bank authorities.

The complexity of the discussed endeavor requires further research answering several open questions, namely, how to:

  1. i.

    Implement fault tolerance mechanisms for interactions mediated by a collaboration context (a CoC of the ECoM Isystem);

  2. ii.

    Coordinate monitoring systems responsible for the generation of explanations for complex exceptions and errors that might happen;

  3. iii.

    Maintain and evolve the proposed MDEOS open specifications, and reference implementations on the assumption that operational and business risks need to be assumed by a clear leadership; and

  4. iv.

    Balance the pressure of innovation, frequently led by the market motivated by the advantage to maintain a “windows of opportunity” [18], and the need to converge for replaceable solutions or parts of solutions.