1. Introduction

This section is considered as final by the authors

This chapter is the outcome of a joint effort by several experts in the area of specifications for the Education Enterprise. From this work several demands and general requirements have been identified. The need for interoperability is twofold: intra-enterprise (e.g. full integration with the Management Information System) and inter-enterprise (e.g. interchange of transcripts or learning plans among institutions). For this to be possible organizations must be able to interoperate and integrate data as well as software. Some interoperability issues still remain: proper management of digital rights, definition of globally accepted human identifiers, agreement on a common reference architecture that must be platform independent and technology neutral, etc. Eleven recommendations have been identified to move forward towards real interoperable Education Enterprises.

Increasing collaboration among enterprises during the entire product life cycle is a global trend. Organizations are transforming themselves into "networked organizations". But to achieve this, enterprise systems and applications need to be interoperable in order to achieve seamless business interaction across organizational boundaries.

Currently, enterprises face many difficulties related to lack of interoperability. Interoperability, defined as "the ability of two or more systems or components to exchange information and to use the information that has been exchanged", needs to be addressed in respect of all layers of an enterprise (including ICT Systems, Knowledge, Business and Semantics). It needs to be tackled using a holistic perspective, a multidisciplinary approach, and by bring together the best research teams, industry expertise and ICT suppliers.

There are a variety of enterprise architectures that could be used, to one degree or another, to achieve the goal of interoperability and thus increase teaching and learning effects. 

A single monolithic system could be implemented. This type of architecture solves much of the problem because all functionality is provided by a single system, and probably by a single vendor. This is the approach that many schools in the U.S. take because they see no other options.  Schools must purchase all their functionality from the same vendor that has a single do-all system, or they must build their own integrated system. These types of systems are usually expensive, brittle, hard to maintain, and do not provide users the choice to purchase other systems.

Another approach is to build or buy different systems and then to integrate them using an ETL (Extract, Transform, Load) or similar tool.  This tool helps to automate the exchange of information among the systems.  These systems benefit from relatively tight integration.  However, the systems are not easily upgraded, or interchanged with other systems, due to application dependencies.

A third approach, far different from a monolithic system, is one that enables schools to choose best-of-breed systems from multiple vendors.  If schools do not like a software system, they can replace it with another.  If they want to have two systems, from two vendors, that have similar functionality in order to benefit from the best features of each, they may do this as well. This approach, of course, requires standards for interoperability and vendor adherence to those standards.

While the open source movement is now seriously moving into the enterprise software market, particularly within the operating system and database sectors and most open source software is available freely for use and development, some companies are more orienting towards Service Oriented Architectures, providing support and services for integration and maintenance, modifying it for the single enterprise, ensuring that the software continues to be updated.

The open reference architectures embrace existing and emerging industry standards. This approach facilitates the ease of extension and interoperability of the system. The basis for interoperability occur at different levels, namely on the system level and the learning level.

At the system level, interoperability refers to the portability of the underlying services. Existing techniques for the integration of services from different organizations, as required by the customer's system architecture, points to the use of web services.

The functional interoperability issues are separated from those of data interoperability, the latter being the focus of the learning level. Most current standards relevant for data interoperability (e.g. AML, XPDL, hr-XML, BPEL, SCORM, etc.) are XML based, and XML bindings are developed where they are not yet provided.

At the learning level, interoperability refers to the portability of the learning resources (content, narrative and selectors). By adopting a standardized approach to learning resource development, the ability to "develop once, use multiple times" can be realized.

Interoperability in the area of Enterprise specifications is mainly concerned with the exchange of data and messages between the MLE and other systems within or without the learning environment, e.g. the school library management system, a Human Resources Management System (HRMS) or even the school cafeteria. There is a need for the exchange of information within the learning environment, for example, an authoring system will store learning objects in a repository, which, in turn will be retrieved from the repository by the LMS. Also, there is a need for the exchange of information between the learning environment and external systems, for instance the portfolio and performance information in a learner profile may be transferred to an external HRMS, or a transportation system may need to access the preference and personal information of a student in order to know if she requires any special attention due to a physical disability.

In this area, as far as interoperability is concerned, we must define both an agreed data model and a common communication mechanism [1]. The latter may even be provided as an Application Programming Interface (API) that allows different components in a distributed environment to provide a higher-level functionality in the learning system.

An agreed API may be of interested because of the following two reasons:

• Software components reuse. A learning environment could be built from reusable software components, which are plug with each other through an agreed, common and open interface.
• Interoperability among heterogeneous systems. A runtime environment from a system A could use a course description or learning activities sequence definition that makes reference to LOs in other, external systems B and C. In order to be able to communicate the first system A, with the repositories in systems B and C, we need a common interface to access the latter systems. In addition, accessing an external LO can require that who is trying to retrieve it has the appropriate rights to do it.

The Learning Technology standardization process has witnessed a progressive change from the definition of common and agreed data models to exchange information (LO, metadata, learner information, etc) to the identification of interfaces to access the services provided by software components running at the same learning institutions or even at an external, remote and different learning system, possibly developed by a different vendor. Therefore there is a need for standards and specifications that deal with software interfaces, communication protocols, APIs, message passing mechanisms, etc.

An extensive use of standards (including standards for learning technology as well as general technology standards) makes it possible for software developers to produce independent, standalone software components that can act as integrated part of the e-learning infrastructure. This kind of flexibility in terms of setting up the learning infrastructure is important for technical, as well as for pedagogical innovation.