Software System Interoperability versus Enterprise Application Interoperability

When dealing? with Interoperability of enterprise application, the goal is to prepare (governance) and to build (architecture) continuous operational interoperability for the business, i.e. efficient collaboration between business processes, the applications supporting them and the technologies realizing the applications.

With three organisations (O1, O2 and O3) applying standard processes A, B and C, we have to consider collaboration with a collaborative cross organizational process, which can be formalized as a BPMN collaboration between A, B and C (interoperability in terms of synchronized inputs and outputs), or as a BPMN process with each organisation assigned to a role defined by this collaboration process.

Here we address the interoperability at Business Layer. But in a digital and computerized area, collaboration can't occur without considering without the ability to retain, to share, to exchange and to aggregate information about the products or services and the processes associated to those products or services their activities are about. In addition, some applications play roles in the business processes and are consequently business actors, even if automates, or robots (the term "robot" comes from a russian word which mean "to work").

The application layers is constituted of active elements, the application components and collaboration between active component (business layer similar), their activities being organized according to standard applicative processes in order delivering services to other active elements, being other applicative components or business actors. Their main purpose is to serve the business layer in alignement with enterprise motivation, taking into account various motivation elements in terms of requirements and constraints, considering strategic goals and drivers defined by the enterprises' vision. In today's world with complex interdependencies, the ability to collaborate a digital way with actors external to each organisation is key, leading to the emerging digital business ecosystems for which set of consistent standards have to be establish, being data, service, process or event oriented application protocols. What is inside the application layers aims at serving (or to be used by) the business layer, in a way it satisfies expectations captured in the motivations of the organisations.

Many software products are today aiming at realizing application components dedicated to specific standardized business processes such as Ressource Planning (ERP Systems), Product Data Management (PDM systems), Customers Relations Management, etc. The reason why we indicate that Application Components serves the standardized business processes in the next diagrams.

Of course, each depicted application component is a component of the each organisations' information/applicative system. Consequently the application components will have to collaborate and to communique across the boundaries of these information/communication systems. Some cross organisations collaborative working environments are consequently to be put in place, with dedicated application components such Enterprise Application Integration solutions (EAI), Enterprise Service Bus (ESB) or Data Bus (EDB), often structured and organized as Hubs in such a context. It can be centralized external hubs or internal peer to peer hub, according to the constraints or current practices of each considered Digital Business Ecosystem (DBE).

When dealing with Software Product Development Processes, such an interoperability is usually out of scope, as this is not the responsability of the software providers to deploy, to integrate, to enact and to support the running applications within the enterprises. The interoperability concerns firt the ability to integrate legacy software relying on Continuous Integration for parallel development, and eventually to deploy and enact released software products version as a service which can be integrated relying on Web APIs and Distributed Data Services. For the Client Enterprises, it requires a lot of on demand a posteriori specific integration by developers, with potentially difficulties to maintain the interoperability at the upper business layer, as software architecture is mainly relying in the code and because not models are made available which can be reused in legacy Modeling Framework. The is a kind of divorce between software development community and system/enterprise architects relying on model based approaches.

Industrial approaches are not industrial if they don't rely on standards and underlying interoperabilty framework. The development processes, being for business processes, software product or technologies? should all consider who they are to serve and to facilitate deployment and integration of delivered products or services , being at technical, applicative or business layer. This is less and less the case. And it leads to fragmented organisations with siloed applications,? making in many case the life of employees less and less easy, as it supports less and less the productivity which is expected from them.

A software product or a digital delivering service are to be considered as constituents of the enteprise information and digital systems, but the market is more and more volatil, heterogeneous, complex and uncertain.

However, I'm quite convince that reintroduction of modeling in the software engineering activities should be beneficial if not mandatory in order to master the complexity of the digital business ecosystems. Interoperability testbeds for software development should be define having the Enteprise needs in terms of interoperability as a target.?

A global and holistic approach should be imagine with the federation of approaches adopted by the concerned communities, with in particular introduction of Interoperability Testbed for qualifying products in terms of "integrability" within the targeted Digital Business Ecosystems.

Here we can imagine this DBS to publish their specification through some digital models which could be used by software provider for qualifying their products according to the DBE's needs.

It should be one key enabler in order to enable Collaborative Working Environment Engineering.

Don't hesitate to comment and share you ideas. Don't hesitate to like or to share the article if you thinks it brings value ;)