This is a report commissioned by FUJITSU Australia in 1994. This report was prepared by Brandle Pty Ltd
RUBAC (Rational Universal Business Automation Code) is an Information management technology developed and promoted by Halisa Pty Ltd. RUBAC is a wide-ranging and flexible technology which addresses the most pressing problems of Electronic Information Interchange (EII).
This report has been prepared to assist potential participants in RUBAC-based projects. It presents an introduction to Halisa's International structure, and an outline of the wide scope of the technology. The report was prepared by Brandle Pty Limited, a Sydney-based language and communication consultancy with particular interests in information structures.
The report begins with an outline of Halisa's operations, then presents a condensed but complete description of RUBAC: first as a generalised information management technology, then in terms of the specific aspects which might be relevant to particular projects.
RUBAC IN DETAIL
The Need: Electronic Information Management
Electronic systems are being used for information interchange at an increasing rate. Electronic Data Interchange (EDI) and electronic mail (e-mail) are well established but diverse applications, and various CCITT standards - such as X.25 and X.400 - have been implemented around the world.
As has happened in many other cases, as industries have developed internationally, all this variety creates a number of problems. While all suppliers - an all users even more so - acknowledge the value and importance of standards, separate proprietary solutions have emerged which have little in common beyond their overall objectives. As a result, system developers and service providers have no firm foundation for their technical strategies, and users have no information on which to base a decision. Incompatibilities destroy the benefits of competition.
Many organisations, for many reasons, are trying to end this confusion. Government bodies, industry groupings, and user associations all have an interest in the development and implementation of a single standard. They are all trying to solve the4 same fundamental problems: incompatible data formats cannot be easily exchanged or processed by automatic means.
Although data transmission standards remain numerous, there is now enough consistency that particular standards are implemented for particular environments; the actual content of the transmitted data is not affected by the transmission process. "Gateway" systems can accept input according to one standard, and retransmit it according to another standard, without needing to consider the data itself. A great variety of data types, both at the level of "record" or document and at the level of "field" or information item, can be transmitted with no danger of corruption. The unfortunate consequence is that the data must be treated as unstructured.
The nearest thing to widespread standard is EDI. This embodies a transaction-oriented approach, where the systems at each end have identical information about the limited range of acceptable data formats.
Also widespread, but totally unstandardised, is paperless facsimile. This embodies a graphic-image-oriented approach, where the systems at each end have no information at all about data formats.
Between these two extremes, also widespread and with standardisation in some respects, is electronic mail. This embodies a transaction-based approach to "header" data, which contains an "address" in standardised format; but it embodies an "unformatted" approach to the body text, which is treated as entirely unstructured.
The differences between these three mechanisms are significant"
RUBAC aims to solve all these problems. It is a universally-applicable coding system, supporting variable data types and formats which can be defined according to common principles. RUBAC can form the basis of a global standardised Electronic Information Interchange (EII) system, which will either absorb existing fragmentary approaches or render them obsolete. As well as solving problems of distribution and interpretation, RUBAC is designed to support automatic filing of electronic documents. The special benefit of this facility is that related historical material is automatically associated with new material.
A Solution Emerges
There are, as yet, no general standards for EII as a whole. There are, however, several claimants to standard status in some areas. The best-known of these are EDIFACT, CALS/SGML and Object-Oriented Programming and its associated techniques.
EDIFACT has been developed as a standard for EDI, but is limited in applicability and flexibility. We describe EDIFACT as being intended for information communication, but designed according to the principles of data communication.
Stephen Gould quotes a report published in September 1987 by the Yankee Group. In this report, titled EDI in Australia, they said that RUBAC was "way beyond EDI" and provides "the ideal solution for business automation".
RUBAC is claimed to have "implications" for CALS. We cannot see any incompatibilities between RUBAC and SGML coding systems, and it seems that RUBAC is CALS compliant. This issue requires further investigation for any potential user who has an investment in CALS-related technology.
RUBAC is also claiming to be consistent with Object-Oriented technology. Stephen Gould has submitted a proposal for a conference paper, for the Object Technology '93 conference, which appears to bear out this claim.
RUBAC's design objectives can be summarised as follows:
These design objectives have been formalised as RUBAC's design principles.
RUBAC incorporates three basic design principles, which can be conveniently referred to as distribution coding, content coding, and structure coding.
Distribution coding is a record of selections made from a series of nested options. Distribution lists are defined in a hierarchical menu-like structure; each selection moves to a lower level where further options are available. Each entry in the distribution lists can contain specific information about transmission requirements for individual recipients.
Content coding extends the capabilities of existing character coding systems. In standard coding systems like ANSI or EBCDIC, every character is represented by a unique combination of 8 bits. In material consisting mostly or words, most character combinations do not occur, so there are many possible binary representations which are unused. A stored dictionary permits every word to be encoded as the sequence-number of its dictionary entry, so that only "real" words are represented. Most non-specialist dictionaries contain far fewer than 65,000 words, so words whose average length is about five characters - usually plus a space - can be represented by on 16 bits instead of 48. This increased efficiency greatly reduces transmission times and costs.
Structure coding represents document formats as a series of item definitions. For example, a purchase order might contain a document-type indicator, one or more items of supplier identification, delivery instructions, and multiple detail lines; each detail line might contain product identification, quantity, price quoted, and so on. If the systems at each end have common definitions of document format, only the variables - the actual items - need be transmitted. Superficially, this is similar to EDI. The crucial difference is that the format definitions themselves can be encoded and transmitted using the same principles.
If these three levels of coding can be standardised, it becomes possible to encode, transmit, and decode any document accurately and economically. The RUBAC coding system is hierarchical, with marked conceptual resemblance to communication models such as SNA/SDLC. In this approach, as a document is prepared for output, each functional "layer" encodes the block it receives from the previous layer, and sends the newly-encoded block on to the next layer. As a document is received as input, the layers of coding are removed in reverse sequence.
These coding levels are implemented by means of tables stored by the systems at each end of a transmission. The tables include distribution lists and document formats. Automatic backups are hierarchically controlled, both locally and centrally, so that the information held at each station is controlled and synchronised by the next higher node.
Progress to Standardisation
For the RUBAC technology to become accepted and endorsed as a standard, three obstacles must be overcome. First widespread implementation will require large-scale commitment from a wide variety of interested parties. Second, widespread use will require large-scale participation by users, each of whom must have a unique address or other identification. Third, all computer-based dictionaries are subject to update in one way or another (the publisher may issue a new edition, or the user may add local or technical terms), sot the content coding mechanism must incorporate dictionary standardisation. Halisa has developed strategies to address all three obstacles.
Halisa has for some time been deeply involved with DGXXI (21st Directorate-General) of the European Commission. This body is responsible for automation procedures in relation to Customs and Excise throughout the European Community.
The objectives of DGXXI are merely one example of a growing tendency for governmental and supra-governmental instrumentalities to influence the computerisation of business. In time, all business systems will have to interact with a number of regulatory authorities. Even when a business computerises for its own reasons, it must take the needs to the authorities into account.
Of course, even Halisa cannot guarantee that the RUBAC solution will become the global standard. Halisa has therefore developed an approach based on the certainty that some solution will be chosen: RUBAC projects are oriented both toward general issues of standardisation and automation, as well as toward specific features and capabilities of RUBAC. Meanwhile, Halisa has documentary evidence of widespread and high level support for RUBAC within the European Telematics Research Programme.
The problem of user identification does not appear to be particularly serious. The same issue has been successfully dealt with by the administrators of the Internet. Halisa's organisation, with its International and regional elements, constitutes a suitable mechanism for global co-ordination of user addressing: the actual solution adopted will probably be a hierarchical approach similar to Internet's. User organisations of various kinds, notably professional associations and standards bodies, are all likely to play a part in maintaining high-integrity distribution processes.
The question of dictionary maintenance is rather more complex, as it must be resolved at several different levels: choice of dictionary, synchronisation of updates, and means of implementation. Halisa's strategy is based on add-on PC cards incorporating a dictionary, as developed by a company called MEMEX. That company failed, but the concept has been adopted by a number of other companies. As is the case with a spell-check dictionary, user updates would need to be stored on disk. This solution satisfies the basic requirements, but leaves unanswered the question of synchronisation (making sure that recipients can decode new words or variant spellings). It also fails to meet the needs of platforms other than the "industry-standard" PC (Apple Macintoshes, SPARC workstations, and mainframes will not generally accept PC add-ons). Regardless of implementation, the same dictionary must be used by all parties to a transmission. Halisa believes that official bodies would be in a position to co-ordinate dictionary usage and synchronisation; Brandle's view is that standardisation of content coding is likely to be a long time coming, and should not be seen as a primary consideration in standards development or implementation.
Halisa sees project sponsorship as the first stage in the development of a long-term relationship. Halisa's standard project definition has three elements:
The sponsor identifies an application or function, within the sponsoring organisation, which is the subject of the project. The three-stage approach to project development is intended to maximise the effectiveness of the solution, while at the same time it clearly minimises risk to the sponsor's investment and business activity.
The sponsor also nominates a "project liaison manager", who has the short-term responsibility of representing the sponsor's interests throughout the project; a longer-term role is to identify other potential applications within the organisation.
A sponsored project therefore entails an investment not only in Halisa's services and in the costs of staff time and resources to service the project, but also in a significant commitment to the performance of the project.
The results of a project must be of benefit both to Halisa and to the sponsoring organisation. Not surprisingly, Halisa's objective is to see the implementation of a RUBAC-based system in the sponsoring organisation. Every RUBAC user is, in effect, a vote for RUBAC as the preferred standard for EII.
For the sponsor, there will probably be no existing strategic objectives that a RUBAC project will bear on directly. The first aim will usually be identifiable service improvement or cost reduction, but it is necessary to distinguish between the specific advantages of RUBAC and the general benefits of automation. The second aim, though, may be to seek ways in which RUBAC can support general strategic objectives. The questions the sponsor must answer are:
It is important to realise that RUBAC is a solution to problems of electronic information Interchange. Any automated solution to EII operations will require the joint participation of at least a reasonable number of trading partners. RUBAC's distribution coding mechanism simplifies the use and control of distribution lists, but a simple PC mailing-list package might achieve as much. The significant potential benefits are in automation of the distribution process. This requires trading partners who can receive material by means of electronic transmission and process it in electronic form.
If, after a successful project, the sponsor wants to incorporate RUBAC (or RUBAC based facilities) into its own products, a franchising relationship can be arranged. Franchising is subject to the payment of royalties, and requires that the franchisee comply with some aspects of the ISO 9000 standard. This stage represents shared commitment, on the part of both Halisa and the franchisee, to the support and promotion of RUBAC as the global standard for EII.
THE NEXT MOVE
Brandle cannot make any advance recommendation about any proposed project sponsorship. We will, of course, be very happy to explore the possibility of advising on specific projects. As an intermediate measure, we summarise here the key factors which we believe a potential sponsor should consider:
Provided that each project is carefully reviewed at the end of each stage, Halisa's customary project structure ensures that sponsoring organisation retain adequate control of their investment and commitment.