Interoperability profiles

ATHENA partners defined the concept of interoperability profile at the very beginning of the project. They were used by the different ATHENA projects, in order to support collaboration between ATHENA partners and in order to be refined and improved for usage as part of the ATHENA Interoperability Framework. But from concrete experience of usage of profiles in one hand, from piloting activities results analysis in the other hand, it appears that the profiles as initially defined were not always appropriate.

The concept of an interoperability profile was initially defined when preparing the description of work of the ATHENA project [ATHENA 2003], on basis of a categorisation per application domains (initially Supply Chain Management, Product Portfolio Management, Collaborative Product Development, and e-Procurement) and industry sectors (initially Automotive, Aerospace, Furniture and Telecommunication).

The profile concept aimed fist to facilitate coordination and collaboration between ATHENA projects and ATHENA involved communities. It aimed second to be a reusable component of the ATHENA Interoperability Framework, validated through concrete usage and lessons learnt from its application by the ATHENA partners through research and piloting activities.

Interoperability profiles were used by piloting activities:

• as categorisation of requirements that supports commonality analysis and generalisation of requirements
• as context element to establish relationships between business needs/interoperability issues and solution components

Interoperability profiles were used by research activities in order to package integrated set of solutions. An interoperability profile consists of interoperability guidelines, specifications and solutions on the conceptual, the applicative and technical level, specifically selected, grouped and configured for the enterprise.

Profiles are derived by the ATHENA Interoperability Framework and can be used to support an industrial sector community through establishment of a Web-based portal supporting each application domain’s viewpoint for a given industry sector. They can also be used to support a community dedicated to an application domain, through establishment of a Web-based portal supporting each industrial sectors’ viewpoints. Finally they can be used to allow these different communities to share their experience and efforts to address common interoperability issues and to reduce development of similar and overlapping solutions that are themselves a source of non-interoperability.

ATHENA initial aim was to create four ATHENA Interoperability Profiles (AIPs) for selected scenarios covering the application domains as described in the table below.

For each of these application domains, the proposed approach was the following:

• to identify domain-specific dictionaries, thesauri, nomenclatures and coding that will have impact on the development and usage of domain-specific reference ontologies
• to also take into consideration industry standards, and legislations and regulations given by the national legislative assemblies
• to prioritise, for each of these domains, specific software concerns and aspects differently for each specific context, as a specific context always required custom-tailored views or models

• were more related to a one-to-one collaboration with specific non-open solutions (in such a case usage of standards is useless, and it is required to have a deep and detailed analysis of business process, objects and specific applications – without being able to use any standards)
• were addressing an industrial sector or a domain where no standards are defined nor used
• were issued from a context where organisations were not using any standards
• were issued from a context where it was just required to compose services for a non-repeatable process

For these kinds of situations, the more appropriate technologies and solutions are those related to fast integration of legacy technologies (such as enterprise application integration (EAI), CORBA and Web services) and applications without any support of well-structured automated business process (such as workflow process model). Within the context of an enterprise, flexibility, fast development and reconfiguration are properties that are very important.

Consequently, AIF had to adapt the initial approach with results coming from piloting activities and their analysis in order to propose guidelines for profile development, considering that some other important factors may impact the mapping that were not already discovered. So the proposed approach should allow to discover and to enrich continuously the proposed profiles.