Keywords

1 Introduction

The role and value of informatics science and engineering can be significantly improved if the gap between the technology landscape and the business processes domain is reduced [24]. Current informatics solutions are often difficult to be substituted, paving the way for vendor lock-in cases, which weakens their value [27]. This problem has been studied in the context of multi-sectorial standards, network effects, and the impact of lock-in patterns in informatics systems industry, often leading to the conclusion that “lock-ins are not in general avoidable” [8]. It is thus necessary to develop strategies to reduce such dependencies. The challenge cannot, however, be addressed exclusively from an informatics point of view. It requires a common strategy including the business and administration areas in order to reach a common understanding of the complexity of integrating informatics systems in the enterprise/organization and the need to induce competition among solution providers. One approach is the moderation of innovation strategies based on consensus agreements, associated with the consolidation of open specifications leading to a wider, coordinated, and complete suite of standards. A proposal of an open infrastructure as a facilitator to integrate legacy systems, and developed under an open community goes into this direction [29]. Nevertheless, the complexity of the challenge is demonstrated by the crescent recognition that a holistic model for systems integration is lacking.

The software engineering discipline, while key for the development of informatics systems (I-systems) has pursued various alternative development strategies. For instance, the agile methodologies are an evolution of the waterfall model, later converging to hybrid approaches, and more recently to the formalization of the OMG’s Kernel and Language for Software Engineering Methods (Essence) specification [21]. Research work on software engineering feasibility discusses the management driven decision by adopting an agile or plan-driven (waterfall) approach, guided by value creation management decision [18]. However, even if a systematic approach is considered, the focus is on software development and not how to integrate different I-systems and its components, and to cope with the substitutability principle [24]. A first attempt to solve the lock-in problem was proposed with the Collaborative Enterprise Development Environment (CEDE) platform as a way to structure the software development landscape [24].

This paper presents and discusses an approach to reduce the above-mentioned vendor dependency risks and the gap between processes and the I-systems technology environment. The proposed approach is a step further on our previous research aiming at contributing towards an open informatics systems modularity and framework for organizations. By the end of 2002, in the early days of service-oriented paradigm (SOA), we formulated an autonomous system abstract implementing services, which was then applied to the Intelligent Transport Systems Interoperability Bus (ITSIBus) [25]. Later in 2011, we enhanced the modularity of the design based on the experience acquired with other projects (Horus and SINCRO) targeted to develop open architectures for nation-wide informatics systems, leading to the concept of Cooperation Enable System (CES) [22]. This paper proposes the formalization of the Informatics System of Systems (ISoS) framework as a conceptualization based on the CES modularity abstraction. The proposed I-system notion ranges from simple to complex entities made of CES elements, and able to answer one or more requirements sets. As an application example, the enterprise collaboration network (ECoNet) [26] infrastructure and platform, operationalized by the enterprise collaboration manager (ECoM) I-system is discussed as a validation of the ISoS adaptive integration framework.

2 Problem Domain and the State of Research

Achieving an effective organization’s agnostic ISoS technology landscape is an open problem without a known and well-founded approach. This problem is commonly addressed from two main research streams: (i) system’s development and operation cycles, and (ii) organization’s informatics systems architecture, in conjunction with processes and services models [9]. A convergence of approaches is, however, needed. Establishing the foundations for integrated I-systems at the level of organizations (enterprises and other) requires, in fact, multidisciplinary research contributions. As such, state of the art is at the level of “islands of automation”, where different I-systems, developed under different specific industry cultures, are difficult to manage, integrate and extend [15]. More recently, the collaborative dimension needed to support interactions between organizations added further structuration requirements for the involved computational responsibilities. Besides interoperability requirements, the challenge is to reach an adaptive and cooperative system of systems whose components are provided by multi-suppliers. The need to cope with the evolution of systems requires the capability of smoothly replacing I-systems by other (new generation) I-systems, which represents an even more complex challenge.

A number of recent and ongoing initiatives have tried to contribute to partial solutions to some of these challenges. For instance, the ISO/IEC/IEEE 42010:2011 systems and software engineering standardization proposal, an evolution of the IEEE 1471:2000 architectural description of software-intensive systems, embeds a systemic approach. The efforts to map existing enterprise architecture frameworks (e.g. Zachman Framework, TOGAF, RM-ODP, GERA, and ArchiMate) demonstrate a general concern on how to formalize enterprise informatics systems modeling [10]. From another direction, the Engineering Service Bus suggests an approach addressing the integration of heterogeneous engineering and modeling tools, contributing to resolving some technical and semantic gaps [3]. Another academic contribution is represented by the collaborative enterprise development environment (CEDE) platform [24], focuses on the reduction of vendor dependencies regarding services development. The enterprise service bus (ESB) concept was introduced as an adaptation layer for the integration of monolithic enterprise systems. The model-driven data independence, efficiency and functional flexibility using feature-oriented software engineering (DIEFOS) is an example of the trend towards an efficient model-driven adapter framework [15]. In a more recent initiative, and in line with the idea of microservices [13], a model for a mini enterprise application description (EA-Mini-Descriptions) was proposed. This is an interesting modeling strategy based on the OMG’s MOFFootnote 1 [20], establishing a layered meta-data modeling framework, and based on M0 (Run-Time Data), M1 (Architectural Model, Meta-Data), M2 (Integration Rules, Architectural Ontology, Architectural Meta-Model), and M3 (ArchiMate, OWL) [4]. Further developments of the microservice model, such as in the Microservices Inner and Outer Architecture as defined in [19] and its relation to the Enterprise Services Architecture Reference Cube, seem promising although requiring further clarification.

Modularity has been a research topic for a long time. E.g. [11] applies modular systems theory to the SOA paradigm. Based on an empirical study the same authors conclude that “Implementing new, dedicated decision-making bodies for SOA hampers organizations in achieving higher degrees of IT flexibility and reuse”, pointing to the need for new decision-making and governance approaches regarding technological strategies in the organizations. However, most existing research work does not include any discussion about the multi-supplier issue and its impact in the organizations’ I-systems. As an exception, in [16, 17] a mathematical model for the dynamics and modularity degree analysis of an elevator system is proposed and discussed. A similar research discusses the fact that Airbus abandoned a proprietary modular cabinet from Honeywell, replacing it by the ARINC 600 open Integrated Modular Avionic (IMA), an open modularity specification that was applied in the design of the A380 airplane [5]. It is quite interesting that the main motivations for this move were to guarantee alternative suppliers for the same components and as a side effect (also important aspect) cost reduction. Also interesting is the fact that IMA was founded by Honeywell, the supplier that used to be unique to offer the mentioned proprietary component.

Nevertheless, in spite of these efforts from the research and practice communities, a well-founded strategy to deal with the growing complexity of I-systems is lacking.

The Collaborative Network Dimension.

Beyond the intra-organization dimension (vertical integration), the integration of I-systems has to answer the growing number of interactions between informatics systems of business partners (horizontal integration along the value chain). Existing technological approaches to support Collaborative Networks (CNs) do not seem to address the needs of inter-systems collaboration properly.

Seen from the informatics science and engineering point of view a CN [1] establishes a directed graph of nodes and edges, where nodes correspond to organizations with their own process and specific technological culture. In practice, these graphs can involve a complex mesh of dedicated connections, based on different transport and payload message formats. In order to cope with this complexity the grid community has suggested the grid infrastructure to support Virtual Organizations (VO) which require “unique authentication, authorization, resource, access, resource discovery, and other challenges” answered by the grid technology [7]. A more recent work on cloud computing extends the idea, proposing an application driven network (ADN) to establish the quality of service links between business applications (our I-systems) under the quality of service (QoS) constraints [28]. Nevertheless, the CN abstraction requires more than using distributed workstations to share and interchange resources [6]. Another initiative, the KeyVOMS server as a VO Management System (VOMS), suggests that application services share a common infrastructure to manage virtual organizations [12]. But one key problem is that no unified approach is able to cope with all requirements, making potential frameworks only partially successful; “there will always be tools, which are unique for specific use cases” [3]. In spite of the many efforts to establish a robust network infrastructure to support CNs, a major problem is a cost associated with instantiating and maintaining the services [6].

Therefore, an open framework is needed to induce a move from current proprietary approaches in enterprise systems (e.g. SAP, Oracle, IBM, and Microsoft) towards establishing a collaborative-oriented informatics system landscape with substitutable components. The proposed ISoS framework presented in the next section goes in this direction.

3 ISoS Model and Framework

In this paper, we formalize the open I-system of systems (ISoS), extending previous research on Cooperation Enabled System (CES) [22]. The proposed framework is based on two main entities: (i) the I-system, as an organization’s level autonomous computational responsibility under some business model, and (ii) the Cooperation Enabled System (CES), as an atomic component integrating an I-system.

For a CES to be used in an organization’s informatics landscape, it has to be integrated into an I-system. Therefore we can say that the informatics environment of an organization is made of I-systems which in turn are composites of CES. The CES model establishes an atomic modularity abstraction able to support substitutability. A CESx has a substitutable CESy from a competing supplier if the services implemented by CESx are structurally and semantically equivalent to the services implemented by CESy. Moreover, the substituted and substitute need to implement migration mechanisms able to recover current and historic state data. This requires that a CES implements specialized migration services to be called by the substitute when assuming the roles of the substituted CES. The substitution process might be complex enough to require human intervention. Nevertheless, the model assumes the development of standard mechanisms for each class of CES, making competing products substitutable. Therefore, a CES abstraction is defined as:

Definition 1. CES:

A Cooperation Enabled System (CES) is an autonomous computational entity with an independent deployment and operation lifecycle, and defined as a tuple: CES = (I0, SA, CS), where:

  • I0 is the system Interface, a standard entry point used by peers to access metadata and CES services;

  • SA is the embedded self-awareness meta-data making CES aware to peers; the SA capabilities are accessed through I0;

  • CS is the set of implemented services, formalized through the interfaces CS = {I0, I1, …, IN}, where N ≥ 1, being each interface a point of interaction or a cooperation point.

This model maintains the essence of the concept introduced in [22] considering that security, monitoring, events and resources management are part of the CS interfaces.

Definition 2. I-system:

An I-system is defined as a tuple: I-system = (I0, SA, MC), where:

  1. i.

    I0 is the entry point service for the self-awareness mechanism responsible for adaptability;

  2. ii.

    SA is the Self-Awareness element, following the CES definition;

  3. iii.

    MC is a modular composite that can be based on CES (CESc) or other equivalent structure. If a CES composite, CESc = {CES0, CES1, …, CESN} where N ≥ 0; and the CES0 is the system CES, responsible for managing the composite and its I0 the entry-point (self-awareness); to deal with legacy assets the model does not impose a strict CES implementation. However, the SA(I0) entry point needs to conform the service I0 of the CES model specification.

This framework is adaptive considering that implementation is free to adopt any existing competence, components and technology assets. Only the availability of an equivalent I0 (awareness entry point) is mandatory for ISoS structural compliance. The openness of an I-system can range from fully open to close, crossing possible hybrid situations, depending on the substitutability of its atoms (a CES or any other modularity framework) since the I-system complies with the ISoS mandatory specifications. The general structure of an I-system and its relation to the CES atom are depicted in the Fig. 1.

Fig. 1.
figure 1

Model of an Informatics system (I-system)

Full size image

The proposed I-system model is transparent regarding the adopted implementation technologies. An adaptive virtual execution environment, supported by the respective CES0, manages heterogeneity and execution location (cloud or on-premises). Furthermore, the model aims to simplify the integration of legacy I-systems by considering the respective CES0 as a wrapper. The integration of I-systems such as (i) federated data sharing, and data management (data lifecycle management; backups/recovery, historical data); (ii) unified authentication and role-based access control; (iii) unified administration of deployed I-systems; (iv) unification of the user interface considering the participation of each I-system in user interactions; (v) unified security strategy for data privacy, data integrity and (programmatic) access to computational services; is aimed.

Definition 3. ISoS:

An I-system of systems (ISoS) is defined as a tuple: ISoS = (I0, SA, ISC), where:

  1. i.

    The I0 is the entry point service, supporting the self-awareness mechanism, following the I0 service of a CES and I-system;

  2. ii.

    The Self-Awareness (SA) follows the I-system and CES definitions;

  3. iii.

    The I-system composite (ISC) is defined as a set ISC = {I-system0, I-system1, …, I-systemM}, where M ≥ 0; for simplicity the ISC is also represented by S = ISC.

Following the strategy adopted for an I-system, the minimal requirement for an organization to be considered conforming to the ISoS framework is to implement an equivalent I-system0 and the respective I0.

The I-system0 plays an enterprise integration, coordination, operationalization, and mediation role. Through the I-system0 the proposed ISoS framework establishes an open adaptive coupling infrastructure (OACI) as a generic logical bus connecting the enterprise I-systems, as illustrated in Fig. 2. Comparing with the practiced enterprise service bus (ESB) where one or more informatics systems mediate the required interconnections, the OACI is based on the simple I-system0, CES0, and I0 mechanisms to establish peer-to-peer adaptive interconnections among I-systems. The integration mediators (integration hubs) that establish additional dependencies are not requited in the proposed ISoS framework. Every shared informatics capability has to be formalized under the I-system concept.

Fig. 2.
figure 2

The organization’s I-system of systems (ISoS)

Full size image

As an example, one of the I-systems can be the ECoM if the ECoNet [26] collaborative platform is adopted, as depicted in Fig. 2. The other I-systems can look-up for and obtain access credentials to the ECoM services from the organization’s I-system0, CES0, service I0. The ISoS framework makes possible for the organization’s informatics landscape to evolve for a coordinated composite of I-systems potentially substitutable if developed under open specifications.

Therefore, the I-system0 is a kind of meta-system responsible for coordinating the remaining deployed I-systems. It is the responsibility of I-system0 to implement common governance functions, e.g. a unified security, services discovery mechanisms, and user authentication and authoring. The I-system model is flexible enough to support component’s I-systems distributed across on-premises or cloud computational resources. Such flexibility is possible because the CES0 component is responsible for the management of the I-system composite as a consistent, unity entity, and the computational responsibility (Fig. 3).

Fig. 3.
figure 3

Management of heterogeneous execution environments

Full size image

Furthermore, we define openness of an I-system, substitutability, equivalence between I-systems and I-system’s openness:

Definition 4. Openness:

An I - system is open ∀x (CESx) if ∃y: CESy ⇔ CESx. Two CES components are equivalents if CSx ⊆ CSy and the services are structural and semantically equivalent. An open I-system is also said to have all its CES under external modularity [24]. If not all CES are substitutable, the I-system is said to be partially open. It is closed if none is substitutable. In this case, the I-system is said to be developed under an internal modularity strategy. A CES under an external modularity is said to be open.

Definition 5. Substitutability:

An I-system is substitutable ∀x (I-system x ∈ S) if ∃y: I-system y ⇔ I-system x . is the capability of a CES or an I-system that makes possible to replace them by an equivalent through a migration process. Substitutability can happen at two different levels: (i) I-system level (substitutable CES), and (ii) ISoS level (substitutable I-systems).

Definition 5.1. Equivalence:

Two I-systems are equivalent, or I-system x ⇔ I-system y , if MCx ⊆ MCy and the services are structural and semantically equivalent (where MC is a modular composite as formalized by definition 2).

Definition.5.2. Openness:

An ISoS is open (ISoS ∈ O), if ∀x, ∃y: I-system y ⇔ I-systemx. If ∃x: I-system x ∉ S then the ISoS is said to be partially open (ISoS ∈ Op). If ∀x: I-system x ∉ S then the ISoS is said to be closed (ISoS ∈ C).

A validation of the proposed model in the context of the EU European MIELE project to the ports administration ecosystems was applied to develop the logistics single window vision. This case is briefly described below.

The Logistics Single Window Collaborative Network.

The Logistics Single Window (LSW) [2] and Port Community System (PCS) [14] research granted by the European MIELE project aimed at establishing a European-wide collaborative framework for door-to-door freight and logistics management [23, 26]. The number of connected stakeholders, the involved heterogeneity (processes and technology) and the complexity of business data and services exchanges, establishes a web of I-systems difficult to develop and maintain. The LSW services provided by business organizations interact through the ECoNet infrastructure (as depicted in Fig. 4) [26].

Fig. 4.
figure 4

The collaborative network established by the LSW services

Full size image

The LSW I-system offers transport and logistics services or composites of services involving a number of stakeholders participating in the door-to-door freight offerings. The I-system approach formalizes the current point-to-point model based on adapters for the data interchanges, using a common and open infrastructure where adapters are formalized as collaboration contexts (CoC) [23]. However, for organizations that have not yet adopted ECoNet neither the ISoS framework, they can continue to use adapters, providing that their peers make the necessary changes to cope with legacy practices, see Fig. 5.

Fig. 5.
figure 5

Adaptive collaborative network based on ECoNet, ISoS, and CES

Full size image

The proposed I-system approach is adaptive as it makes possible for legacy environments to follow a progressive adoption of the proposed models (ISoS, ECoNet, and CES). The user-organizations need that suppliers that they trust adopt these frameworks, commonly constrained by the need to acquire new competencies and change product’s lifecycle management processes. The adoption process can be accelerated if the specifications and reference implementations are developed under some open-source model. The advantage for user-organizations is the potential to reduce costs resulting from an increased competitiveness induced by the substitutability principle of the adopted I-systems.

As far as a structural dimension is concerned, the proposed models are flexible enough to accommodate different implementations. An I-system is not mandatory to be implemented based on a composite of CES. In fact, an I-system is a black-box with a single well-known entry point, the (or equivalent) I0 service of the CES0 component. What is important is that any peer can introspect implemented functionalities and technology constraints for a dynamic coupling between I-systems. For simplicity, the sharing of functionalities implemented by different computational responsibilities (different suppliers) are restricted to I-systems. This means that if a CES component has value beyond a single I-system, its services can be available through a new I-system. The example of a CES implementing a wide organization’s persistence service configures a specialized I-system with that specific responsibility.

For a user-organization to evolve to an agnostic (or dependence free) informatics landscape, a semantics consolidation is necessary. We propose to develop reference models for I-systems targeted to specific application domains. Considering the need to promote substitutability of LSW provider, the challenge is to develop a reference implementation - LSWreference - establishing common interfaces for all derived implementations (market LSW I-system products offerings). Furthermore, considering that different logistics stakeholders might adopt different LSW providers, the proposed model makes possible for them to join a virtual collaboration context [26].

4 Impact on Existing Practices

The proposed ISoS challenges current practices considering it introduces an application level modularity framework requiring a novel structuration of existing approaches. It promotes the adoption of open models and technical specifications whose products are verified through a conformance certification process. This means that existing market competition based on unique product features or development services for specific I-systems is expected to move towards standardized computational responsibilities capable of being substituted. This can, however, happen under a smooth changing process without disturbance of complex operating legacy I-system. In fact, the proposed framework makes possible a partial migration of existing I-systems considering that no constraint exist to incorporate existing technologies. The ISoS framework considers an adaptive coupling among I-systems making possible the convergence for patterned computational responsibilities. Such standard computational responsibilities as I-systems can even wrap legacy systems in order to cope with the recognized difficulty from industry to change their development processes and technologies.

Furthermore, a novel collaborative governance model is required considering there is a need for an integrated monitoring and maintenance management strategy. As I-systems tend to be more interdependent/cooperative, malfunction detection and diagnostic needs to be performed by a unified I-system. Such I-system shall be responsible for the first monitoring line and dispatch the maintenance responsibility for each I-system according to the identified problems.

5 Conclusions and Further Research

The informatics system of systems (ISoS) framework in conjunction with the cooperation enabled system (CES) establish an adaptive strategy for evolving organizations to dependency-free technology landscapes. The CES abstraction makes possible for an informatics system (I-system) to adopt different implementations of an equivalent suit of computational capabilities, promoting in this way substitutability at the component level. The I-system as a composite of CES or any agglomeration of computational capabilities is the organization’s modularity level able to make the technology landscape to converge for cooperative and substitutable informatics systems. The proposed ISoS framework establishes a unique I-system, the I-system0 as the unique responsibility to coordinate and manage the other I-systems.

A validation scenario considering the development of the logistics single window (LSW) concept was developed to make possible user organizations and other stakeholders collaborate even if they subscribe LSW services from different providers. This is made possible by adopting the ECoNet collaborative platform, and its ECoM I-system targeted to manage data exchanges under specific contexts and virtual collaboration groups (while multi-tenant collaboration domains). However, in spite of the demonstrated value, I-systems as products requires further investments to gear the market towards the adoption of the ISoS framework.

At the semantic level, the approach for future work is to develop an I-systems ontology establishing a sufficient set of reference I-systems and the respective reference implementations to support conformity certification processes. The strategy is in line with the EA-Mini-Descriptions [4]. It is also aligned with the Generic Enabler implementations as developed and maintained by the Future Internet Lab (FIWARE Lab) [30]. One main problem to get such a sufficient set of I-systems reference definitions is how to convince I-systems developer companies to frame their products under the ISoS framework. Our approach is to invite public and private user-organizations to invest on reference implementations on the proved certainty that in subsequent acquisitions the induced costs reduction pay off the investments in research and development.