| Deliverables | Table of Contents | Next |


3. Analysis of the answers

In this section the data obtained from the survey is analysed. Comments are made on the questions and answers, and some statistical summaries are presented to support the conclusions.

 Appendix C presents the questionnaire used in the survey. It presents the questions in various groupings, and these groupings are used in this section for consistency.

 All the questions and answers of the survey are listed in the tables of appendix D. All organizational acronyms are presented in Appendix A.

 

3.1 User Organization

The survey included organizations with an international scope down to local councils.

 

 As criteria like size and number of sites were not considered relevant to selection, a wide range of organizations were surveyed (from the 53 employees of the KGSt to the 80,000 of the MW and from the 2 sites of several organizations to the 675 sites of the MEH).

The number of employees and sites or buildings do not depend on the geographical scope of the organization. Thus, a local organization like MW has 150 buildings while several national character organizations have only 2.

 

 The number of sites in an organization and their geographical distribution does not necessarily imply anything about its internal connectivity. A single Directory server can service all sites (see 'Networking 1').

The MEH (675 buildings across Spain) does not have all sites connected in a common way, whilst the AA (250 sites across the world) does (but only for its central unit in Bonn and not for missions world wide). A similar structure exists in the Spanish MAE.

 The ratio of current e-mail users to potential users shown by many Spanish organizations is far from ideal. There is only one (the SEUE) which has e-mail for one 100 per cent of users.

 The situation seems to be different in other countries where usage is 100 per cent in each case (KGSt, AA, CCTA, MAFF).

 

3.2 Office automation tools

Use of PCs and word processors is very common. Spreadsheets and other tools less so. In all organizations, most documents exchanged (internally or externally) are generated by office automation tools.

 This does not imply that these documents are now transferred by e-mail. For instance, as expressed in the KGSt answer, "Most information provided by the KGSt does not originate there and is currently only available in paper form. Most of this information is generated by office automation tools, when looking to the source of information."

 The use of predefined formats and/or templates is quite extensive (official documents, letters, facsimiles, etc.). This can be taken as an indication and measure of the advance in office automation. The use of templates indicates high familiarity with these tools, and this in turn may imply stronger requirements for the new electronic directory access tool than have been anticipated, especially in terms of integration.

 The next chart displays statistics on the familiarity of the end-users with these tools:

 

 

3.3 Electronic mail

3.3.1 Products

There is a wide range of products in use in European administrations. This is not strange, because each national market has been penetrated by different products from different vendors and only some large companies are represented in more than one country.

 A list of e-mail products and companies is presented below, indicating the number of users of each tool.

 
PRODUCT PERCENTAGE COMMENT
Isocor 31% Company from the USA, with many kinds of OSI products, including X.400 MTA, UA and X.500 DSA.
NetTel 21% British company, many products for X.400 and X.500. Well positioned in Spain.
HP-Openmail 16% US company (Hewlett-Packard). Proprietary mail product with MTA's, & interface to X.500
Osiware 16% Full OSI products, MTA's , UA's and RUA's
ICL 11% British company, X.400 & X.500 products
Osilink 5%
DX-Mail 5% SW for X.400 MTA's and UA's, produced by EuroView project co-ordinator (Dr.Materna)
Openpath 5%
Retix 5% OSI products.
DEC-All-in-one 5% Digital's tool for office automation, including e-mail.
Most mailers use X.400, with SMTP gateways, to access the Internet world. Only one organization uses SMTP mail directly, with freeware software.

Some Mail User Agents offer simple directory functionality. In most cases the directory is implemented a basic list of name-address pairs, displayed as a whole for sequential browsing and providing one simple string-search function. The user can select an entry in the directory, and the electronic address of the selected entry is placed in the address field of the message being composed. These directories are usually managed by the UA or MTA software and often have a restricted database size. Facilities for importing data from other databases and querying mechanisms are very limited. They are useful where e-mail has been recently introduced, but are difficult to manage when the number of entries increases.

 Nevertheless, the simple directories available indicate the requirement for some level of directory service and are a good way of demonstrating to users the advantages of the more functional X.500 directory.

 

3.3.2 Configuration

The number of MTAs is not determined by the number of users but more by connectivity factors. In most cases the MTA covers a whole LAN, which in turn is usually a whole building or site. LANs are present in administrations almost as often as PCs and word processors, although full inter-LAN connections are less frequent. In many cases, a LAN has an e-mail connection to the outside world, but no full network connection to other LANs.

 The platforms used for MTAs are very different in size, from PC-DOS to DEC-minis (DOS users want to move to 386 Unix (SCO)). The conclusion drawn from the interviews is that the number of mailboxes and UAs does not effect the power of the MTA. The main factor here seems too be the real level of e-mail traffic. The future use of a directory service would probably be related to the use of e-mail.

 It is worth mentioning that some MTA products use X.500 technology, with the implementation provided only as a functional test bed. Deviations from the standard can often be found in such cases. It would be interesting to analyse the possibilities of using such X.500 services to either implement a local DSA or connect to existing DSAs for directory consultation and, possibly, enhancing integration with local e-mail software and smoothing the installation process.

 

3.3.3 Usage

The basic usage of e-mail is clearly for interpersonal messaging (on a one-to-one or one-to-many basis and in free text format). Many organizations have pre-composed headers and/or official signatures.

 Use of file attachments for document and data delivery is widespread. Some have additional role/functional mailboxes related to a department and mapped onto a delivery list for people in the department (or perhaps a secretary distributes the received mail in the department).

 

 Fig. 3.4: Basic usage of e-mail by employees

3.3.4 Integration

All users mentioned word processors as a prime candidate for directory integration. As such, these should be the second tool to be considered for close integration with the directory (the first one being the e-mail UA). Fax servers are also mentioned, as are office automation packages like Team Office and All-In-One.

 

3.4 Networking

When asked about the protocols used, the most common answer is "Ethernet with TCP/IP". In relation to the physical and data link layers (referred to as "hardware"), Ethernet is the common answer with just one case using dial-up to build TCP/IP connections.

 The network protocols used are typically TCP/IP, LAN Manager or Novell (IPX). Exceptions are one organization using Decnet, and several others using protocols to be superseded, e.g. RCL, or marginally, e.g. NETBEUI.

 

 Fig. 3.5: Popular protocols used in the organizations

Answers to the question "Are all sites connected?" differed considerably. Some organizations have just one site whereas others have full connectivity between sites by means of a router and leased lines or similar. Many others have partial connectivity for e-mail purposes only. In this case 68% of the organizations have all sites connected.

 The typical connection map is X.25 for X.400 mail and, increasingly, IP lines (either leased or dial-up) to connect to an Internet service providing connectivity to the SMTP community.

 Before the explosion of Internet, X.25 was more commonly used for building e-mail connections. Now many administrations are using Internet connections to launch WWW servers, to collect information from the Internet and to access the SMTP community directly. It is hard to say categorically whether IP connectivity will replace X.25 lines, but many organizations admit to having plans to transfer to the Internet by either leased lines or ISDN.

 

 In Spain, where many of the end-users were located, the interviewed organization MAP co-ordinates e-mail between public administrations. They operate the root MTA for the Spanish administrations, routing inter-ministerial mail and acting as a gateway to a Spanish ADMD (Telefónica-Mensatex) and to SMTP-Internet. To connect to the MAP, some Spanish organizations use dial-up, others use X.25.

3.5 Existing links with other entities

The group of questions "Existing Links With Other Entities (1)" proved the most difficult to answer. The question in its original form was :

 "What other organizations/ administrations/ departments in the EU does this organization work with? List them sorted by size or importance of the information interchange (both electronic means and paper), indicating for each entity the different means of transmission used (courier, mail, fax, e-mail, other) and the percentage of the traffic for each".

 No organization answered this question completely and, in many cases (60%), no figure for external traffic (neither telematic or any other type) was provided.

It has always proved to be difficult to ascertain the amount of postal mail that an organization interchanges due to the mail service not usually being centralized or accounted for in any one department. Neither the amount of traffic nor its distribution by destination (local/national/European) could be reported by some organizations.

 What did come out of the question was an indication of which other organizations were communicated with by the interviewed organization. All users seemed to think that having access to the directory data of other organizations (and vice versa) would be useful.

 Obviously, the degree of usefulness will depend on the amount of information available, i.e. how many organizations communicated with by the user have an accessible directory database.

 

3.6 Categories of organization to include in the directory service

What organizations should be included within the directory service? If we take into account the organizations that the end-users work with and their answers to the question "what other organizations might find it useful to have access to your directory data?", it is possible to ascertain the categories of organization that should be included in the directory service. The most popular organization categories were:

 • National administrations (ministries and other central entities) of the same country.

 • European institutions (Council, Commission).

 • Regional administrations of the same country (autonomous communities or equivalent).

 • Other national, regional and local administrations in Europe (ministries, regional authorities, missions, etc.).

 • Local communities and their associations in the same country.

 • Research centres (e.g. CSIC) and universities (included in the IRIS net, etc.).

 • State owned companies (Spanish railroads, Spanish seaports, etc.).

 • Private companies (power industry, etc.).

 • Partners in European projects.

 • Internet ISTMO.

 • NATO.

 • UN.

 • British Government on-line activities (G7).

 The current means of communication include postal mail and courier (paper and magnetic tapes), fax, e-mail and telex. The reported figures on e-mail traffic loads are not overly significant and are difficult to compare. The general feeling is that there is still too much reliance on paper documentation.

 

3.7 E-mail traffic load

Sometimes the e-mail traffic loading is quite asymmetric, where input and output loads vary considerably.

 A good example of this was KGSt answer about fax traffic: "The proportion of incoming fax messages is probably more than 50%, while amount is less than 50% for outgoing requests. (What is not strange for an information provider: requests/orders come in by fax, the information material is sent by mail)".

Put another way, the total communication related to each partner is not always proportional to the level of e-mail communication.

 Many organizations did not report a figure for the percentage of documents exchanged by e-mail internally and externally. As mentioned previously, it is not easy to calculate the usage of postal mail and some organizations do not even have controls on the use of e-mail.

 As expected, e-mail is the preferred medium for internal message interchanges. In some cases the level of usage reaches 95-100% (SEUE), but is usually somewhat lower.

 

 The second most popular medium has a level of usage often below 10%.

As stated previously, the general feeling is that there is still too much reliance on paper documentation and that e-mail usage needs to expand: there is only one organization (MW) where the e-mail traffic load appears to be high both internally and externally.

 

 In most cases, e-mail traffic within European institutions will become more important in the future. Strong growth is expected: The European Commission will request all documents to be submitted by e-mail from next year onwards.

Another example: there is a large number of documents (ca. 12000 per year) which are distributed from the Secretariat of the European Council to various sites all over Europe. This distribution is done in cascade, currently by using various electronic media. In the future, the process is to be completely e-mail based. The European Council is currently setting up a procedure for this process and the X.500 Directory Service (together with X.400) is envisaged as infrastructure.

 

3.8 Directory data

The following list was indicated by end-users as being the data deemed most useful for a future directory service to provide on peer organizations:

• Personal name

 • Organization name

 • Post (name, roles and responsibilities)

• Organization unit and/or department

• Hierarchical relationships

• E-mail address

• Internet address of systems

 • Postal address

• Telephone number(s)

• Fax number(s)

• Type of e-mail

• Other communication and document processing facilities

 • Activities and services provided by the organization

• Security certificate

• Distribution lists

 

3.9 Existing directories

3.9.1 Directory types

Within each of the interviewed Spanish Administrations there was often an internal directory (telephone directory or similar) generated by any automation tool (word processor, dBase 4, etc.) and existing in a paper printed version only. In addition to this, a paper-based directory of high posts in the whole Spanish Administration (called FAC) is managed by a private company and sold to almost all administration organizations. Finally, the MAP publishes the structure of the upper Administration levels in a directory. This includes data on every institution it is connected with (ministries, autonomous communities, etc.). This directory has a search function and is distributed by e-mail.

 

 Several users have an X.500 directory service currently in use, although some of them have only partial functionality. For instance, the Isocor-X.500 directory of the MC is automatically configured with all X.400 information from the Ministry and they would like to extend it with additional data.

Probably the most developed service is located in MW. Some interesting comments about it are made in the following two paragraphs:

 "The Magistrat operates 2 DSAs, predominantly used for e-mail address mapping. For each message entering the Magistrat, the external address is replaced by an internal address containing inter-organizational routing information. Therefore about 5 queries per message are started. The amount of e-mail is about 2000 messages per day. Interactive requests are much less frequent: about 200 per day".

 "The information is not managed directly in the Directory but taken from various sources. Among these are the Magistrat's payroll, telephone directory and All-In-One user tables. The information is uploaded from these sources each week."

 Other organizations had to overcome massive obstacles to convince the office employees of an organization to use X.500. One of the objections was that data is concentrated in the Directory, which is a potential contravention of data protection laws. Another objection was the fear of losing autonomy over the data. These organizational problems will be greater if external access to internal data is allowed.

 Other examples of existing directories is the miscellaneous directory service provided on the CCTA Web server which includes a directory of governmental organizations with A-Z mapping to function and organization name. For other government departments, the CCTA may be able to offer a limited set of contact data on all government organizations using the "Civil Service Yearbook" CD-ROM, which contains the necessary information. The CD-ROM is under copyright of the HMSO (the Government stationery office) and may therefore be unavailable for use by EuroView.

3.9.2 Opinions

Opinions on the usefulness of the service range from "quite useful" to "absolutely necessary", for both internal and external information. Most think the available data is not good enough and should be improved. For instance, most organizations work with other organizations on which they possess only incomplete data and would like to include these organizations in a future directory. Moreover, other users consider that their existing databases do not hold all of the information required by a directory service.

 They also pointed out that currently significant administrative overheads are related to address changes, which can be limited by directory access. In general, the usefulness depends on the amount of information available (i.e. how many of the organizations that the users work with have a directory entry?), the searching mechanism and other factors (e.g. the possibility general mailing using a directory lookup which does not require the typing of a complex e-mail addresses every time a message is sent, etc.).

 

3.9.3 Access method

The access method is a rather important issue. Several answers underline the requirement of providing both personal and role (functional) entries; The users will like to conduct a free search (by activity, organization, etc.), although it should also be possible to look up roles instead of people (which change too often) and distribution lists.

 An issue related to the access method is the proprietary directory products (e.g. Osiware, Nettel) that only support their own tools.

 

3.9.4 Functional search

Several organizations would like such a functional search of the data such that searches can be made on the various organizational roles, with each role entry then being mapped onto the appropriate person or group of people. In the same way, the MAFF have already considered presenting a function oriented search of the data, specifically for functional role mailboxes. But they think that a comprehensive view of this nature would be difficult to organise and maintain. A business analysis will be required to ascertain the requirements of and need for such a service.

 Others organizations would like the directory to implement an identification system of the information services associated with every entity. For instance, to be able to answer the question "What is the name of the Lérida Council public information system?", giving the name of the Web server, Videotex address, etc.

 In the long term, the MAP wants to create a multi-sector clearing centre for e-mail (transmission registration, generation and distribution of public and private keys, EDI, etc.).

 In relation to the source of the data used in the directory, almost all DBMSs in the market are present in administrations (including Ingres, Oracle, Dbase III, Informix, Access and other sources such as text files and indexed files). As expected, the number of interfaces to the directory is large, and the task of loading user data into the directory will require some effort in finding intermediate standard formats between the database and the X.500 DIT.

 Those using Oracle or Informix may well have an easier task since the tools for exporting data are well known. Those with free private formats will require specific developments for the conversion.

 

3.10 Service conception

3.10.1 Different views

Most users are interested in having different "views" of the data. This would allow an organization to present, for example, a comprehensive view of the data for internal users and a more restricted view for external consumption.

 Only a few organizations seem to be uninterested in this issue. The reason given for this is that all data they would like to include in the directory is already considered "public". In addition to this, they do not have any special legal or security requirements except the ones coming from the national data protection law.

 It should be pointed out that most users are not familiar with data protection laws, and in some countries these laws are quite restrictive (France being a good example).

 On the other hand, the organizational problems discussed below are seen as a greater obstacle than requirements arising from data protection regulations.

 In addition to data privacy there is a secondary reason for the different views. This is the fact that some entries/attributes are technical (i.e. for system use only). Among these are the All-In-One-ID or the corporate RFC 822 address.

 So the users interested in having different views are divided into those who think an internal (private) view and an external (public) one would be a good solution, and those who think that having these views would not probably fulfil data protection requirements satisfactorily and would therefore like a different set-up. Several organizations (15%) found no real difference between the public and private view other than the structure of data (white pages/functional view).

 It seems more sensible to consider those private fields depending on an entry. Examples which could fit into the public/private view would be: telephone numbers and/or e-mail addresses (e.g. of directors, managers), or the department attribute of all employees. Private messaging data examples would be: number of personnel, login IDs, etc.

 This problem is even more difficult to solve when an organization is dealing with data from other external organizations and putting it into an integrated directory service on their behalves (KGSt). It is not clear if it is desirable and/or possible for KGSt to put information about their members (attributes containing pricing information, etc.) into the directory. As stated by the KGSt, additional attributes are needed which contain pricing information and such attributes would obviously not be in the public view. They would probably not be available in an internal view either, however, as there is no information which the local community itself could or should provide. The "external view from the KGSt perspective" of the local community entry contains more information than the internal view. This might be an interesting User Agent feature, to provide a view on a directory entry which is an extension of the entry as it is in the directory, with the additional attributes having been taken from some local database.

 

3.10.2 Security requirements

Issues on security requirements raised by the users are as follows:

 • If the directory server is managed by a third entity (e.g. EuroView), the users may have to send their sensitive data to it, if at all.

 • The requirement that only authorised people may modify any data provided in the directory should be enforced using identification by password.

 • In some countries (including Spain) the law requires the registration of all databases with personal data.

 • Several users have some special security requirements. For example DGTel (data about military frequency assignments, etc.).

 • Does the provider of directory information give any guarantee for the integrity of the data or is it possible to store directory entries without guarantee? What might be the legal implications of such a guarantee?

 

3.10.3 Access to the directory service

The question "How many people in the organization would want access to the directory service?" produced the most common answer "Every (or nearly every) potential user of e-mail".

 An interesting answer came from KGSt: "Depends on the usefulness of the service in terms of quantity and quality of data, the quality of the user interface and on the cost of the service".

 The answer "X entries corresponding to X potential users of e-mail would be wanted" demonstrates a limited view of the directory, probably arising from the fact that the users were not too familiar with this service. Those with more experience in directories would prefer the directory to serve e-mail, telephone, post, and telematic access to the organization.

 Although some organizations did not answer the question about computing equipment, it has been inferred that everybody with access to the directory service will have a desktop PC.

 

3.10.4 Response time and availability

The response time requirement expressed by the users ranged from less than 10 seconds to up to 60 seconds:

< 10 seconds (21% of the organizations)

 10-15 seconds (10.5% of the organizations)

 < 30 seconds (21% of the organizations)

 30-60 seconds (21% of the organizations)

 few seconds (10,5% of the organizations)

 No answer (16% of the organizations)

 These are maximum times corresponding to remote access for a simple consultation.

 The responses given concerning the requirements for service availability were:

Total (53% of the organizations)

 Total in Working Hours (26% of the organizations)

 98% (11% of the organizations)

 No answer (10% of the organizations)

 

3.10.5 Integration with other tools

It is assumed that e-mail software shall be integrated with the directory service. Other software considered for integration would be office applications (word processors, diary managers, etc.), mailing applications, safety software, telephony applications (click and dial), Web servers, business applications (form entry, EDI, business transactions, etc.) and various proprietary user applications.

An example question posed (by MAS) was: "How would information transfer from the EuroView user agent to OpenMail be done?". Integration with other tools is a basic requirement: "A directory service without potential for such integration is regarded as less useful."

 It was also noted that integration should not be limited to the client side only. The source databases (Ingres, Oracle etc.) might provide X.500 interfaces to at least part of the data they are storing.

3.10.6 Data maintenance procedure

Most organizations would prefer to run a local directory service, probably with help from EuroView. So from the user persepective the directory will ideally be distributed with each user organization holding it's own data (this could be especially suitable because of the variability of the data) and having complete control of their server. As it happens, some users are already running their own X.500 DSA(s).

 

 Other organizations (20%) would like to have more information about this issue before making the decision to become pilot users. The implementation of a directory service (or perhaps a directory service based on X.500 technology!) is thus still an open question for them. Only the CINDOC and the CCTA would prefer to send their data to a central EuroView directory service. In the first case this is due to the CINDOC not being confident in their ability to maintain the directory; in the second case the CCTA said that they would rather not expend any effort on converting the data and running their own DSA. Neither the CINDOC nor CCTA answered the question about the way they prefer to periodically update the information:

• Generate a file in an specific format with the changes and send it to the directory manager.

 • Connect remotely to the directory and directly update the information.

 Other concerns relate to regular data loading and ensuring that data updates are performed correctly. Most users would prefer a local server in order to losing autonomy over data. To this end users said that they would welcome any support (from EuroView) on process documentation, equipment maintenance and manager training and support. Training potential users to use e-mail and related applications would also be useful.

 

3.11 Miscellaneous

Finally, other concerns addressed by the users were:

 The administrative domains are not well-organised at this time. For example, it is not yet clear who is the official naming authority represented by the country-level entries. This is true for most European countries, and appropriate actions by EuroView were requested.

 Integration with existing X.400 services.

 The quality of the service, bearing in mind that it is decentralized and dependent on the ability of each organization to keep its data up to date and on the reliability of links to each DSA involved in a query.

 In relation to the EuroView pilot service and its starting date; and the concertation with other European activities of the various DGs (namely DG III and DG XIII) and the Secretariat of the European Council.

In relation to this last point, the MAS pointed out the fact that different proprietary systems are used to access the different telematic services of the European Commission (e.g. project Eurodesk uses a product called First Class, while the project Handynet uses its own product). They stressed that this does not favour the use of open protocols.

 


| Deliverables | Table of Contents | Next |


Title: User Requirements Report
Issue: 2.0
Date: 07 + 13