Interoperability Framework for Information Systems

Version 1.0

Disclaimer

This document is an unofficial English Translation of the Interoperability Framework for Information Systems published by the Japanese Ministry of Economy, Trade and Industry. Accuracy of the technical contents may not be guaranteed.

June, 2007

Information Service Industry Division, Commerce and Information Policy Bureau, Ministry of Economy, Trade and Industry

Incorporated administrative agency

Information-Technology Promotion Agency, Japan

i

Index 1. Introduction···············································································································1

1.1 Background and Objectives of This Document·························································1 1.2 Readers···············································································································2 1.3 Scope··················································································································3 1.4 Fields of Application·····························································································3

2. Definition of Important Concepts and Terms·································································3 2.1 Concepts and Terms Provided in This Document·····················································3 2.2 General Terms·····································································································7

3. Why is Interoperability Required?··············································································10 3.1 Benefits of Interoperability··················································································10 3.2 Issues of Lack of Interoperability ·········································································11

4. Policy ······················································································································12 4.1 Total Optimization Policy····················································································13 4.2 Procurement Policy ····························································································13 4.3 Policies on making IT systems Open ····································································18 4.4 Management Policies ·························································································20

5. Guidelines ···············································································································22 5.1 Example of Component Model which has Interoperability ······································22 5.2 Guidelines for Component Design········································································24 5.3 Service Platform for External Function Call··························································24 5.4 Interoperability of Data ······················································································24 5.5 Interoperability of Messages················································································25 5.6 Guidelines for Creation of Procurement Specification·············································26

6. Points to note···········································································································29 6.1 Points to note in Design ······················································································29 6.2 Points to note in Creation of Procurement Specification··········································29 6.3 Points to note in Reconstruction/Modification of Systems ·······································30 6.4 Interoperability between Clients and Servers························································30 6.5 Cooperation with Other Systems ·········································································30 6.6 Points to note on Portability ················································································31 6.7 Points to note on Operations················································································31

7. Future Direction ······································································································32 7.1 Preparation of Guidelines for Separation of Procurement Unit and Total Design ······32 7.2 Maintenance of TRM··························································································32 7.3 Adding information on Open Standards and their Versions to be referred in TRM ····32 7.4 Preparation of Catalogs of Products Compliant with Open Standards referred by TRM···33 7.5 Creation of Neutral Procurement Specification Model············································33 7.6 Collection of Best Practices of SOA·······································································33 7.7 Research on Business Services and publishing the Catalog·····································33

ii

7.8 Assessments of interoperability for Government Procurement and revision of this Framework·················································································································34

Appendix 1. Examples of Referred Standards ····································································35 Appendix 2. Examples of Neutral Procurement Specification···············································36 Appendix 3. Reference Bibliography··················································································41 Appendix 4. Commentary ································································································43

1

1. Introduction This document is written in order to support design, development, migration, operation, and maintenance of the Japanese public system providing more practical guidelines and considerations from the viewpoint of interoperability, based on the policies of Japanese government for the building of e-Government and procurement of its information systems described in the already published “Basic Guidelines for Government Procurement Related to Information System ”, “Optimization of Operations/Systems Guidelines”, and “Agreement on Government Procurement”. Although this document is written to be utilized mainly by public organizations including the Japanese central government, it is also intended to be applicable for construction of information systems in private-sectors. Note that in utilizing the contents of this document for construction of private-sectors’ information systems, it is needed to customize them to fit the specific conditions of the intended organization considering their procurement policy and requirement for information systems instead of applying them as they are.

1.1 Background and Objectives of This Document In the “Basic Guidelines for Government Procurement Related to Information System ”, the government sets a policy that procurement should be conducted separating common platform system and function unique sub-systems with regard to the design and development phase as a general rule. The function unique sub-systems procured separately in accordance to these Basic Guidelines for Government Procurement Related to Information System must realize all functions required for the operation as each function unique sub-system as well as an integrated total system by being integrated through the common platform and exchanging information with the common platform or with other function unique sub-systems. In other words, interoperability among function unique sub-systems and between function unique sub-systems and the common platform is required. These Basic Guidelines for Government Procurement Related to Information System also set a policy that procurement should be conducted separating hardware (including ready-made software indivisible with hardware such as operation systems) and software (design and development software only). Hardware, design and development software, and ready-made software and outside services which design and development software utilizes are all components of the function unique subsystems or the common platform. Since the functions provided by function unique sub-systems or the common platform are realized by interoperation of their components, interoperability between components of a function unique sub-system or the common platform are required in addition to the interoperability among function unique sub-systems and between function unique sub-systems and the common platforms. In the operation and maintenance phase, it is preferable to enable one-by-one maintenance of a function unique sub-system and procurement and replacement in units of the component (e.g.: replacement from existing product of company A providing database function to product of company B which has equivalent functions) for better operation and maintenance. Thus interoperability of components should not be based on a unique technology of a specific vender, but should preferably

2

be realized by utilizing open standards which many venders can implement and adopt. Interoperability means the ability to fulfill all functions which require a certain type of information by exchanging data and sharing the information among subsystems (functional components) and components of the subsystems (technical components) which form the integrated information systems. Therefore, the framework to ensure the interoperability can be defined as a set of agreed upon standards and guidelines necessary for interoperability of subsystems and components. The framework to ensure the interoperability must be maintained to always suit the present conditions considering requirement changes for information systems, technical innovations, and progress of standardization and implementation.

This interoperability framework aims

to describe what is interoperability, to explain why interoperability is required, to explain existing policies, and expand them. to set more practical guidelines, to enumerate considerations for implementation, and to set the future direction,

in order to support implementation of the policy for optimization and procurement of information systems of government and public organizations and assurance of interoperability of information systems and their components.

This interoperability framework does not include the list of standards that define the technologies to be utilized by priority in order to ensure interoperability and interfaces to the technologies. In Japan, the Ministry of Economy, Trade and Industry has created Technical Reference Model (TRM) in accordance with Enterprise Architecture (EA) and there indicated validation method of technology and framework to which agencies and ministries can refer. It is advisable for each government office and ministry to create a profile which suits each of them based on the TRM considering their specific conditions. Therefore this interoperability framework only indicates guidelines regarding creation, maintenance, utilization of the TRM and refers to TRM with regard to the technologies to be utilized in design and development and list of standards corresponding to those technologies to be referred in procurement specifications.

1.2 Readers The intended readers of this document are as follows:

Policy makers relating to government procurement and optimization of government information systems

CIOs, Deputy CIOs and procurement officials of each government office and ministry Bidders for government procurement relating to information systems Information service providers the government information systems utilize

3

1.3 Scope This document provides guidelines relating to functional requirements and non-functional requirements which the information systems of government and public organizations should have from the view point of interoperability. Although there are various considerations in terms of practice of policies on construction and procurement of government’s information systems such as granularity of functional components to be procured separately, judgement whether a specific service should be procured as an function unique sub-system or a part of the common platform, or what kind of interface should be adopted as an interface between functional components, items that are not directly related to interoperability are not included into the scope of the guidelines this document provides. In terms of practical guidelines on separate procurement, it is preferable to refer to the guidebook of the “Basic Guidelines for Government Procurement Related to Information System”, prepared by the Ministry of Internal Affairs and Communications.

1.4 Fields of Application This document provides guidelines mainly for the following area,

information systems of Central government, information systems of Local government s, information systems of incorporated administrative agencies, and non-government services utilized by the government information systems,

they would also be helpful for construction of non-government information systems.

2. Definition of Important Concepts and Terms Some of the terms and concepts used in this document have special meanings regarding construction, procurement and interoperability of government and public organization’s information systems. Also, the meanings of those terms and concepts may vary depending on the context. To clarify the description of this document, some important terms and concepts used in this document are defined and explained in this section.

2.1 Concepts and Terms Provided in This Document

Making (an IT system) Open: Increasing the number of vendors who can enter into the governmental procurement, maintenance and operation services of governmental information systems in the manner of reducing the dependency on a vender specific technology by breaking down an information system into individually procurable and replaceable standard components.

Venders’ specific technology:

A Hardware (or a set of hardwares), a Software (or a set of softwares), a Services (or a set of

4

services) or their combination that provides services through a proprietary interface of a vender, not through an open standard interface.

Note) Although open standards specify interfaces, they do not specify the implementation

method of the interface. Thus, this term is applied only to interfaces, but not to implementation technology.

Components:

A Hardware (a set of hardwares), a Software (or a set of softwares), a Service (or a set of services) or their combination that is procurable and replaceable individually, and provide a specific service as a part of an information systems. In order to make components procurable and replaceable individually, it is necessary that all interfaces of the services through which the component provide the services to the other components or the component receive the services from other components be clearly defined and publicized, and that the components which support the interface are interoperable with one another.

Standard components:

Components that satisfy all the following conditions: To have all the interfaces defined as mandatory in the corresponding open standards and

provide services to other components through the interfaces; To depend only on the interfaces defined as mandatory in the corresponding open

standards in receiving services from other components; There is more than one implementation that offers equivalent services and provided by

more than one provider, or by an open source software license; and All other components on which the component depends (or in other words, all the

components which are prerequisite to the component) are either provided by an open source software license or are exchangeable with other components provided by more than one provider.

Quasi standard components:

Components which provide services to other components through publicized interfaces but do not satisfy the conditions to be standard components for some of the following reasons;

The interface used to provide services to other components does not comply with open standards.

The interfaces, through witch the component receives services from other components, includes what corresponding open standards do not specify them as mandatory requirements.

There is no implementation offering of the equivalent services provided by other venders, and the component is licensed only by a non-open source software license.

Only one vender provides a component on which the components depend (or in other words, a components which is prerequisite to the component) with a non-open source

5

software license.

Non standard components:

Components which provide services to other components through closed interfaces Component description:

External specification of component to be procured, that consists of descriptions of mandatory functions, required capabilities, required reliabilities, required interfaces through which the component provides services to other components, and what the component should not depend on as the interaction with other components. Technical specifications of neutral procurement specifications shall be described by using components descriptions.

Functional components:

Components which granularity is rather large and subject to be procured separately Technical components:

Components which granularity is rather small and to be sub-components of a functional component

Open standard:

As a general rule, “open standard” means a technical standard that satisfies all the following criteria: 1) The standard was established by using open participation process and its concrete

specification is publicized at an implement-able level. 2) Anyone can adopt the standard. 3) There are more than one product implementations that conform to the technical standard in

the market.

Note) Examples of open standard are international de jure standards such as ISO, IEC, and ITU, and Japanese Industrial Standards. In terms of de facto standards, more detailed description of the conditions for open standards mentioned above is as follows.

Establishment, maintenance, revision, and withdrawal of the standard specification are conducted by an open nonprofit organization whose doors are open to everyone with democratic procedures. Also, neither specific enterprise nor individual has any privilege on the decision of establishment, maintenance, revision or withdrawal of the standard, as the procedure.

The specification of the technical specification of the standard is publicized and there is no limit on the usage and implementation of the specification. In the case that there is any intellectual property rights which is required to implement the spcificication, the intellectual

6

property rights should be licensed RF (Royalty-Free) or RAND (Reasonable And Non-Discrimin atory).

There are more than one products that conform to the technical standard and those products are provided by more than one venders, or the conforming implementation is licensed under an open source software license.

Also, it is an important condition to be open standard that the technical contsnts which the the technical specification specifies them as mandatory requirements do not conflict with any international de jure international standards such as ISO, IEC, or ITU, or Japanese Industrial Standards.

Vender lock-in:

Situations where fair competition in procurement is blocked for some of the following reasons Dependence related to selection of technical components at the system procurement:

There is virtually only one vender who provides the specific component. There is virtually only one vender who provides components on which the specific

component depends. There is virtually only one vender who provides components to which the specific

component provides services. The format in which the specific component stores its data (e.g. electronic document)

is not disclosed to the level of information that express the meanings of the data (e.g. schema), or the data can not be read from or written to by other implementations which have equivalent functions with the component since the format does not conform to open standards such as XML standard or ODF standard.

Interface between the specific component and another component with which the component interacts (interoperates) is not disclosed, or an intellectual property right is necessary for implementation of the interface and the intellectual property right is not licensed RF (Royalty-Free) nor RAND (Reasonable And Non-Discriminatory).

Dependence related to selection of venders at the operation and maintenance service

procurement: Only the vender which provided an information system can maintain or revise the

system, since the system has not been made open enough. Other venders than the vender who provided a component can not maintain or tune up

the component well, since information on the component is not disclosed enough.

Standard conformance: Either of service provider conformance or service receiver conformance

Service provider conformance:

The condition that an implementation (components) of a standard implemented all the interfaces which is specified as mandatory in the standards, and those interface works as specified in the

7

standard. If the case that the standard includes some optional interface, implementation dependent behavior, implementation defined parameters or allowed extension of the standard, those implementation defined interface and behavior must be documented in the conformance document and be publicized.

Service receiver conformance:

Either of strict service receiver conformance or implementation dependent service receiver conformance

Strict service receiver conformance:

The condition that an application (component) of a standard, which is implemented in a manner that the application only rely on mandatory interfaces of the standard and receive services from other component only through those interface. Strict sevice receiver conforming component must depend on neither depend on optional features which are selected by an implementation, implementation dependent behaviors, implementation defined parameters, nor extensions implemented by a service provider conforming implementation.

Implementation dependent service receiver conformance:

The condition that an application (component) of a standard, which depends on either optional interfaces of the standard, implementation dependent behaviors, implementation defined parameters, or extensions of the standard which are allowed explicitly. Implementation dependent service receiver conforming application (components) must document all the optional interfaces, implementation dependent behaviors, implementation defined values that the application depend on in the conformance document and publicize it, The application that receive a service from other component through an interface that that is not specified by the standard does not meet the requirement of implementation dependent service receiver conformance.

Compliance certification:

Certification that indicates an implementation complies with a standard, The certification is granted by a neutral certification organization after standard compliance testing in accordance with the compliance testing methods provided with the standard.

2.2 General Terms Interoperability:

From the technical viewpoint, interoperability means the ability to fulfill all the functions which requires some information that are obtained by communication between components and utilized by each of the components. Interoperability between components descriptions means that components which meet all the requirements of each component description are exchangeable each other.

8

Fields of application of interoperability includes interfaces of hardware components such as connector, slot, bus, and memory, interfaces of software technical components such as middleware, database system, and operating system, and interfaces of functional components such as communication protocol, common function subsystem, and individual function subsystem.

From the view point of information system supervisor or the organization who perform total optimization, interoperability means to enable business systems which are developed by each department independently to be integrated across the barriers of organizations, organizational structures and business processes.

From the information viewpoint, interoperability means that information can be interchanged or shared between applications developed for different purposes. As a result of that, collaboration between applications can be enabled. The integrated application understands information sent from other applications at the level of meanings (semantics), not the level of format (syntax), converts the information to the formats adequate to itself or its users, and execute processing. Thus, information interchanged between applications need to include information which indicates the meaning of the data (e.g. schema) instead of data itself only.

Interface:

The boundary shared by components. It includes interfaces of hardware components such as connector, slot, bus, and memory, interfaces of software technical components such as middleware, database system, and operating system, communication protocols, and interfaces of functional components such as nication protocol, common platform subsystem and function unique sub-systems.

Reliability:

Ability of a functional unit to fulfill a required function under the designated conditions for the designated period

Connectivity:

Ability to connect to other systems or devices without changing the system or the device EA (Enterprise Architecture):

A systematic approach to improve operation or system from “total optimization” point of view in order to quickly respond to the changes in social environment and information technology,. It is also organized lists of business processes, structure of information systems and technologies to be utilized by an organization wide. EA consists of five reference models; PRM (Performance Reference Model), BRM (Business Reference Model), DRM (Data Reference Model), SRM (Service Component Reference Model), and TRM (Technical Reference Model).

9

TRM (Technical Reference Model):

Technical Reference Model (TRM) is the reference model to be referred at the establishmeny of Technical Architecture (TA), and standard technologies to be utilized are described in. To optimize information systems totally, it is necessary to grasp the direction and generation of technologies and build the information system based on a common TRM. TRM is the standard related to Technical Architecture (TA) utilized for realizing and maintaining interoperability, portability, and scalability of the information systems in construction and operation of the e-Government. What embodies Policy and Business Architecture (BA) and Data Architecture (DA) is Application Processing Architecture (AA). Technical Architecture (TA) is hardware architecture, system software architecture, and network architecture which serve as a support basis of Application Processing Architecture (AA), and technologies of each technical element shall be selected with reference to the recommended technologies of the Technical Reference Model (TRM). In the 2005 version of Japanese Technical Reference Model (TRM) , standard technologies are classified into four major categories; “application software” where operation programs utilized in government offices and ministries and programs utilized in office operation are included in, “application platform” where OS, middleware, database management systems necessary to operate application software are included in, “external environment” where hardware such as networks and hard-disks are included in, and “common platform” constructed as a total system where security and management are included in. Application platform is further classified into “Channel” which is connection point with end users or external system, “Process” which provide operation environment for application and supplementary services, “Data” which includes database and data exchange, and “Base” which includes OS and communication. There are 23 categories in all and each category is classified into further detailed services to clarify technologies to be standard.

SOA (Service Oriented Architecture):

Concept to add flexibility to information systems which support business by treating components of business process and information platform that support those business processes as highly secured and standardized services. It becomes possible to reuse services and to modify information systems in order to respond to changes in business requirements by combining existing services. Technically speaking, it could be defined as architecture of organization level that promotes loosely coupled system integration, reusability of business components, and interoperability between systems, but it does not always have to utilize web service related technologies such as SOAP, WSDL, and UDDI.

10

RF (Royalty-Free)： License granted to anyone with any purpose at no charge

RAND (Reasonable And Non-Discriminatory):

License granted to anyone with any purpose at reasonable license fee without discrimination 3. Why is Interoperability Required?

In the Basic Guidelines for Government Procurement Related to Information System the necessity of interoperability is described as “In terms of government procurement relatied to information systems, historically there was a time when construction of information systems based on vender’s original technology specification was mainstream, however at present as information communication technologies advance, it is becoming possible to construct flexible information systems which allow design, development, and future modification using various technologies and products. Also, as high-degree of information systems usage and their networking in the whole society progress, it is becoming increasingly important to secure interoperability between information systems of public and private, and central and local governments.”

3.1 Benefits of Interoperability To secure interoperability is an important condition to construct flexible information system and have various benefits as follows.

Improvement of user convenience

Enables construction of consistent user interface independent from applications or their platform

Enables on-stop-service by interconnection among information systems Ensures long-term preservation, browse and access to the information stored as a data

Reduction in development cost of information systems Reduction in cost and manpower is expected over the long term since it becomes possible

to develop new applications or modify existing applications by reusing and combining components.

Reduction in operation and maintenance cost of information systems Reduction in operation and maintenance cost and manpower is expected compared to

replacement of whole system, since it becomes possible to replace low performance components or high-cost components in a unit of component.

Options of a component procurement in system modification is expected to be increased then the possibility to procure the most appropriate component also will be increased, since lock-in to a specific information product or service can be avoided,

Reduction in total cost by system integration Contribution to the total optimization is expected, since information system will become

11

more flexible, then it becomes possible to integrate systems which conduct similar business beyond the across the barrier of organizations and sections.that conduct similar operations.

3.2 Issues of Lack of Interoperability

In this section, problems that lack of interoperability may cause are described. 3.2.1 Restriction of User’s PC

In construction of electronic application submission systems, Ministry A adopted the method to install an application program into users’ PC, and Ministry B and Ministry C adopted the method to download Java applets. As a result of that, a problem happened. Those electronic application submission software could not coexist in a user’s PC, since the version of operating system on which the application program of Ministry A depended on and the version of that the software of Ministry B and Ministry C were supported were different. Furthermore, application submission systems of Ministry B and C might not work correctly on a user’s PC, since the versions of Java Virtual Machines which the Java applets of Ministry B and C were different. Those problems were caused by that the software to be installed in users’ PC depended on (a version of) a specific operating system and those ministries did not provide enough versions of application submission softwares supported on the top of operation systems and their versions which are used in the nation.

3.2.2 Difficulties in Application Development Utilizing Similar Applications

Ministry D tried to develop a document management system by porting and modifying the similar document management system developed by Ministry E.. However, the Ministry D needed to develop the new document management system from scratch, since porting of the application was so difficult, because the Ministry D had a technical standard to develop an information system by using the .NET technology, but Ministry E ran multiple application softwares on a common server which was built based on the J2EE technology.

Application portability and reusability were lost, since the platform technologies used may be different by each ministry and the functions of an application developed by a ministry were not provided by services that can be used through an interface which is independent from any platform technology.

3.2.3 Limitation of Migration

The personnel management system of Ministry F developed was working on the database

12

system, operation system and hardware of company G. Since the combining of Ministry F and Ministry H was decided, Ministries F and H considered to port the personnel management system of Ministry F on the top of a computer of Ministry H which had higher performance of the computer of Ministry F. However, since the database of company G was only supported on the top of the operation system of company G, the database system could not work on the computer of Ministry H. Ministries F and H also consider to use a database of company J, instead of the database of company G, which can ran on the computer of Ministry H. However, the personnel management system of Ministry F could not be ported on the database of company J since the personnel management system depended on some unique functions of the database of company G.

An application could not be ported between different database systems which complied with the same standard since the application used unique functions of a specific database product through an extended or optional interface other than that the standard specifies the interface as a mandatory requirement for compliance.

3.2.4 Issues of Data Compatibility

It was announced that a new version of word processor of company K which City L was using would be launched and support service for the existing version would be withdrawn 2 years later. City L had to make a decision on whether they would update the current word processors or switch them to other word processors which have lower cost. As the result of investigation, City L recognized that current IT budgets of City L was not enough to update all the existing word processors installed in the PCs of all the city employees. However, it was also impossible, to switch existing word processor to another which was not data format compatible with the word processor of company K, because City L had already stored large quantities of electronic documents with the unique format of the company K. Thus City L had to appropriate the budget for the upgrade of the word processors for the following year, and keep paying the money to upgrade of the word processors following the product release plan of the company K in the future. Lock-in to a specific vender unique technology was caused since electric documents had not been being stored by the manner converted to an open standard compliant format in addition to the product unique format, or there was no way to convert electric documents that were stored by a product unique format to an open standard compliant format.

4. Policy In this section, government’s policy related to interoperability of information systems is introduced and explained.

13

4.1 Total Optimization Policy

In order to optimize the information systems of government and public organizations, it is not enough to optimize each system but interconnection of systems among multiple sections and total optimization of information systems are needed. In order to achieve this aim, the following policies were set in the Optimization of Operations/Systems Guidelines issued by the Ministry of Internal Affairs and Communications.

With regard to similar operations which multiple ministries, offices, bureaus, or divisions

conduct, the business patterns, functional specifications, and processing methods of the operations shall be uniformed and standardized.

The business processes which are currently conducted by multiple ministries, offices, bureaus or divisions separately, but central processing would be more effectively shall be integrated and performed at a single location. Items of application forms, slips and so on shall be standardized and simplified.

Operations which do not require officials’ judgment and is not a core competence of the organization in charge of operation/system shall be outsourced.

A function to determine and evaluate the effect of optimization of operation/system shall be incorporated into them in order to pursue further optimization continuously and autonomously.

With regard to data used in the information systems associating with each other and the ones being interconnected in the future, the format of the data shall be standardized in order to secure data portability between those systems.

If a business process is performed by multiple ministries, offices, bureaus, or divisions, a part the process or whole shall be supported by IT systems. If the IT systems can adopt the same or very similar method on the information processing, the IT systems shall be converged as a central system and shared by relevant ministries, offices, bureaus, and divisions. Even in the case where separate management of data by each section is appropriate, functionalities of application and data management shall be standardized, converged and centralized, in order to reduce system development and operational cost while maintaining compatibility of the data across those sections.

Hardware, software and communication protocol which construct an information system shall comply with international de jure or de-facto standards in order to make the information system as an open system.

4.2 Procurement Policy

4.2.1 Polices Related to Separate Procurement

In the Basic Guidelines for Government Procurement Related to Information System, the

14

following policies regarding three types of procurement separation (separate procurement in design and development phase, separate procurement of hardware and software, and separate procurement of service venders for the design and development phase, and the ones for migration, operation and maintenance phase) are set.

“By dividing a project into appropriate scale for procurements(separate procurement) instead of procuring a big project as a single total solution, opportunities for businesses to participate in competition would expand, and cost reduction can be expected by inviting more competitors a. For this reason, with regard to the design/development phase of a specific information system, sections in charge of procurement shall make separate procurements dividing the system into a common platform system and each individual business function based on the result of investigation of architecture of the information system as a general rule.”

“Sections in charge of procurement shall procure hardware (including ready-made software indivisible with the hardware such as operation systems) and software (that requires design and development in the procurement only) separately with regard to the information which has a specific procurement size, as a general rule and the detail of the procurements shall be described in the procurement plan.”

Procurement as a total solution

Design/development

Software

Har

dwar

e

Ope

ratio

n

Main

tenan

ce

Separate procurement IB

usine

ss

func

tiiom

A common platform

Har

dwar

e

Ope

ratio

n Se

rvice

Main

tenan

ce

Serv

ice

IBus

ines

Func

tionm

IBus

iness

Func

tion

Common service functions

Ind

ivid

ual

busin

ess

func

tion

Indi

vidu

al bu

sines

s

func

tion

Indi

vidu

al bu

sines

s fu

nctio

n

Indi

vidu

al bu

sines

s f u

nctio

n

Busin

ess

Func

tions

15

Note) Ready-made software could be procured either with hardware or with the software which is designed and developed in the procurement.

“Based on the current situation where more than 90% of procurements of operation and maintenance services are conducted on a single tendering contract, and that competitiveness is far from secured, sections in charge of procurement shall separate procurements of operation and maintenance services from the procurement of IT system design and development service (hereinafter referred to as “design and development, and so on”), by open tendering and the detail of the procurement shall be documented in the procurement plan.with regard to the information systems which procurement has a specific size, as a general rule,”

In order to support further understanding of procurement separation and the necessity of securing interoperability, an example of function division and integration of those functions is illustrated below. Note) This is not an actual example.

Software

Custom application which reauires design and development

Ready-made application packages

Ready-made middlewares Separate procurement

Hardware and software indivisible with the hardware

Hardware-dependent softwaree.g. device drivers of OS

Hardware

Services in design/

development/ migration phase

Services in operation

phase

Services in maintenance

phase

16

In the above example, cross-sectoral functions utilized for all business operations, linked individual business function systems, operation management functions, functions for improving efficiency of business processing, and main infrastructure (common functions, and hardware) are treated as common system platform. The Common system platform and individual business functions are interoperated through a loosely coupled method. Examples of components of the Common system platforms are network, hardware, middleware (e.g. database and service integration management functions), common functions (e.g. integrated authentication platform and integrated database), common business functions (e.g. document management), and operation management functions (e.g. monitoring and back up).

4.2.2 Policies on Neutrality of Requirement Specifications

The Basic Guidelines for Government Procurement Related to Information System sets the following policies regarding neutrality of requirement specification.

“If a vender who is involved in preparation of a procurement specification prepares one based on a unique technology of a specific vender, whole information system may depend on the unique technology of the specific vender even if it is tendered by separate procurements. To avoid such situation, neutrality of contents of requirements in the procurement specifications for design and following phases shall be properly confirmed, and the requirement specification shall not include the requirements which are described by using concrete information which points to a technology, such as a brand name of a product, unless there is a rational reason such as description of a specific brand name is necessary in order to secure work-ability or interoperability between hardware and software that will be procured separately..

Individual function system group

Resid

ents’

re

cord

s

Tax a

ffairs

Nati

onal

Hea

lth

Insu

ranc

e

Ann

uit y

Com

mon

op

erati

ons

Standard technology

Service integration management functions

Infrastructure

Common functions

Hardware Ope

ratio

n man

agem

ent

fu

nctio

ns

Common system platform

17

Concretely speaking, as a general rule, open standards, such as international de jure standards or Japan Industrial Standards、 based descriptions of requirement specification is preferred, not using vendor unique functions, vendor unique data formats, nor vendor unique architecture.

Also, requirement specification shall not become favorable to a specific hardware or software in the manner that the specification lists mandatory functionalities only as the requirements of the component to be procured..”

4.2.3 Policies on Preference of Open Standards

It is preferable for government and public organizations to secure interoperability of information systems among those organizations as well as with non-government and international related organizations in order to provide highly convenient services and to pursue effective public operations. Thus the software which interface, such as communication protocols, APIs, etc., complies with open standards need to be procured as far as possible.

Government and public organizations should procure software whose data formats and file formats comply with open standards as far as possible in order to enable long-term storage and easy access including browse-ability to public documents and to realize transparency, accountability and expansion of citizen participation of/to governmental policies.

Interoperation of IT systems and exchange of their data with integrity among government agencies and their related organizations is necessary to offer services to citizens and related organizations effectively on demand. Therefore, it is preferable to secure interoperability by selecting solutions which comply with open standards and which do not depend on any function that is unique to a specific product. As a result of that, government and public organization can achieve flexibility on the development, maintenance and migration of IT systems, avoidance of lock-in to products or services provided by a specific vendor, and can maintain the choices in future procurements.

At the development of requirement specification for governmental or public organizations’ IT systems procurement, unique functions, unique data formats or unique architecture specific to a vendor should not be included in the requirements, as a general ruel. Procurements based on open standards, such as international de jure standards and Japanese Industrial Standards shall be preferred..

4.2.4 Policies on Selection of the Most Suitable Information Systems

18

Government and public organizations must procure the most appropriate software that meet with the business of each operation after comprehensive comparative review of functions, security, prices, operational risks in the future, users (citizens) side burden in utilizing the public service systems, and so on.

Government and public organizations must procure the most appropriate solutions throughout life-cycle of the IT solutions. Government and public organizations should pay attention to the following points in order to minimize cost and risks of the development and operation of the information systems.

Selection of solutions which create the largest benefits with the lowest cost Avoidance of excessive dependence on a product which does not have interoperability Ensuring flexibility of IT systems and options of their technology selection at the

development, function enhancement, integration and migration of IT systems

In order to ensure flexibility of IT systems and options of their technology selection,in the future, it is preferable that government and public organizations avoid dependence on a specific products or services whose specifications are not disclosed, or whose specifications are unique to a specific vendor and is not implemented by other software products. The best IT solutions from the view point of life-cycle base must be selected by considering total conditions and situations such as existence of equivalent alternatives in the market, availability of human resources and required training to develop those resources, replacement of hardware, conversion of data and its format, operational risks throughout life-cycle of the solutions, and users (citizens) side burden in utilizing the public IT solutions, and so on.

To achieve the above-mentioned goal, government and public organizations must include all software products, which could contribute to relevant business, as the options to be procured regardless of whether those products are open source software or commercial software.

Government and public organizations should procure the most appropriate solutions regardless of licensing conditions and development methods by comparing possible alternatives which realize interoperability and flexibility at maximum level and meet the requirements of the target business under the given conditions. As the result, either of open source software, commercial software, or a combination of those software might be selected. Procurement of the most suitable solution should be determined depending on requirements of each business.

4.3 Policies on making IT systems Open

In order to broaden options related to the development of information systems of government and

19

public organizations, to realize fair competition and transparency of procurements, and to procure high-quality information systems for proper price, it is required to eliminate dependency on a vender’s unique technology at the development and modification of information systems and further promotion of making governmental IT systems open.

The objective of making IT systems open is not only to broaden options for procurement of information systems in the initial stage but also to broaden options for procurement throughout the lifecycle of the system including service procurements such as operation, management services and system maintenance and modification. This can be achieved by dividing information system into multiple interoperable components and enabling replacement of those components individually. It is also preferable to have options of venders who can provide operation, maintenance and modification services and to make it possible to replace the vendor with another. Thus securing of interoperability among components and elimination of lock-in to a vender’s unique technology must be promoted through active utilization of open standards in IT solution procurements of government and public organizations.

To achieve the above objectives, government and public organizations must pursue fair competition and transparency in their procurements by referring to open standards for the description of interface related requirements, through which components of the IT system can interoperate each other, in addition to listing mandatory functions, required performance and reliablity which the IT system need to provide in a technology or vendor neutral manner.

In order to realize effective and efficient public services, interoperation of IT systems and data sharing across government and public organizations need to be enabled. And in order to realize end to end system integration and data sharing among those IT systems, procurement for information systems of government and public organizations need be conducted by taking interoperability aspect into account.

If there are multiple alternatives which meet business requirements, it is preferable to select and procure the most appropriate one by comparing requirements and conditions of the target business equally and by comparing the total costs throughout the life cycle of the system. In the case that multiple alternatives exists those evaluations are competitive, priority should be given to standard components in the procurement, which comply with open standards being implemented by multiple products, rather than non-standard components whose interface necessary to interoperate with other components are not disclosed, or quasi standard components which have some deviation against an open standard or the standards which the components comply with has actually single implementation only,

To realize above objectives, it is preferable for government and public organizations to promote securing interoperability in IT system procurement and making governmental and public organizations’ IT systems open in accordance with the following policies.

20

Software and services which could support to target business shall be compared and investigated

in terms of business requirements and compliance with open standards equally regardless of the terms and condition of the such as commercial software license or open source software license.

The software which complies with open standards or the ones which specifications are based on open standards shall be procured as a general rule, in the all future procurement of government information systems.

Standard components shall be procured as far as possible to secure interoperability. If it is difficult to procure standard components for some reason, quasi standard components which are close to standard components should be procured.

As a general rule, Modification rights of the software which is important for components integration shall be obtained as far as the cost of the license is appropriate in order to secure interoperability of government information systems. The modification right of those software will help for government to pursue securing open standards based interoperability of government information systems.

In procurement of standard components that secure interoperability based on open standards, if there is not much difference of functions and cost among multiple candidates, technical innovations and development methods of the software shall also be taken into account in the evaluation of advantages and disadvantages of the technologies, in order to improve productivity and interoperability of the software in future.

4.4 Management Policies

It is preferable for government and public organizations to conduct management of development, operation, maintenance and modification of information system in accordance with the following policies for construction and procurement of the most appropriate information systems.

For construction and procurement of the most appropriate information systems, CIOs and Deputy CIOs who take responsibility for information systems throughout their life-cycle shall be appointed and have them fulfill their responsibility..

Information systems shall always be maintained fully optimized by being assessed from the view point of total optimization throughout their life-cycle.

A common TRM for government and public organizations shall be developed for reference of the offices of ministries, local governments, and other public organizations. The TRM shall be updated or reconfirmed periodically as the result of the survey and assessment of technologies from the view points of trend, diffusion, compliance with open standards, and affinity with existing information systems. The assessment and validation of the technologies should be conducted from the following two viewpoints.

21

Whether the technology meet technical requirements of the target business in the target locale Whether the technology is appropriate as a standard technology used in government and public

organizations

The technologies which are referred to by TRM need to be assessed in terms of the following points through the adequacy assessment of standard technologies, From the standardization viewpoint:

Whether the technology is the one which has been standardized as a standard specification or it is being standardized.

Whether the licensing condition of the IPR (Intellectual Property Right) has become clarified at the establishment of the standard and the standard specification can be implemented freely or without paying unreasonable royalty .

From the technical viewpoint: For assuring of interoperability among information systems, whether there is any successful

reference that conforming implementations of a standard could interoperate each other or there is any positive progress such reference is being created. (Assessment of interoperability)

For assuring of portability of information systems, whether there is any successful reference that an application has been ported from an conforming implementation of a standard to another implementation of the standard, or there is any positive progress such reference is being created. (Assessment of application portability)

Whether the technology has functionalities or characteristics which enable the information system is being used, enhanced and maintained continuously in future, such as scalability and platform independence. (Assessment of continuity for the future).

Whether the technology is required and applicable for the target business. Since the intended fields of application of the TRM are business of front, middle, and back office in government ministries. (Assessment of existing system affinity).

Furthermore, assessment need to be conducted from the view points of practicability and potential, specifically whether the technology has been adopted widely in commercial products, public domain and open source software, or there is any positive prospects the the technology become adopted, whether there is any positive prospect the technology is being used continuously in future, and whether the technology specification is being updated by an open organization or community such as standardi organization.

It is preferable for each ministry or public organization to develop customized profile of the TRM by selecting preferred technologies to be procured from a lot of technologies listed in the common TRM, by taking their unique requirement into account, and keep the profile up to dated.

22

5. Guidelines In this chapter, guidelines which information system designers and procurement staff should follow to implement above mentioned policies are described.

5.1 Example of Component Model which has Interoperability

Note) Services may run either on the same computer or on different computers. If all services run on the same computer, the interface for the service call may use API or vender’s proprietary messaging system. If some of the services run on different computers, the interface for the service call needs to have the mechanism for calling services which run on remote systems. When all services run on the same platform (e.g. Windows, EJB), the mechanism for calling services which run on remote systems might be the platform dependent technology (e.g. DCOM, RMI-IIOP). But when platforms are different, the interface for the service call needs to be independent from platforms (e.g. CORBA, web service).

Guideline: It is preferable not to restrict physical computers or platforms on which separated functions run in order to increase the number of bidders for the separated procurement. Thus it is mandatory that the interface for service call shall be independent from platforms and services shall be integrated asynchronously and with loose coupling trchnology.

Individual function partIn

divi

dual

se

rvice

Indi

vidu

al

serv

ice

Indi

vidu

al

serv

ice

Indi

vidu

al

serv

ice

Common part

Ministry client standard software

WEB portal server

Com

mon

ap

plica

tion

serv

ice

Com

mon

data

base

se

rvice

Secu

rity

serv

ic e

Ope

ratio

n

cont

inui

ty se

rvice

LAN in the

ministry

Service call interface

23

Note) A functional component consists of some technical components and a business logic. It

provides services to other software through the service interface. In many cases, the business logic and functional components are closely coupled through API corresponding to the performance requirement.

Guideline: In order to ensure the interoperability among technical components and the exchangeability of technical components, upper-layer technical components shall consist of standard components which use only mandatory functions and interfaces that open standards define as mandatory ones, which lower-layer technical components provide. When the development of the business logic is outsourced, it is necessary to state clearly in the procurement specification that the software to be developed has to be dependent only to mandatory functions and interfaces that lower-layer technical components provide and open standards define as mandatory. And it should not depend on vender’s proprietary technologies or interfaces which lower-layer technical components provide. Note) In some cases, it is difficult to implement required functions or the performance of the system

only with interfaces which open standards define as mandatory. Even though utilizing vender’s proprietary technologies and interfaces may be inevitable in such cases, the usage of proprietary technologies or interfaces of the specific vender should not be required in the procurement specification. It is preferable to have the vender propose implementation method,

Functional component

Business logic

Open standard interface

Open standard interface

Open standard interface

Open standard interface

Open standard interface

Open standard interface

Standard technical

component

Standardtechnical

component

Standard technical

component

Standard technical component (operating system)

Technical component (hardware)

Service interface

24

assess the impact on interoperability by the technical evaluation phase, and evaluate the cost for the life cycle of the system.

5.2 Guidelines for Component Design

Even though functional components and technical components are the smallest unit of separate procurement, man-hours for procurement operation, operation, and maintenance could increase if the procurements are divided into too small segmentation. For example, it is useful to define the hard disk device as the component because the device can be replaced if it breaks down. However, it is not meaningful to break the hard disk device down into parts such as screws and ROM and define them as components.

Guideline: It is preferable to make the size of component that the procurement staff can recognize as a meaningful unit and macro components can be defined by combining them. With regard to technical components, the smallest size is the one which is specified in TRM; e.g. database and operating system interfaces, etc.

5.3 Service Platform for External Function Call The selection of the service platform which functional components utilize for calling services that other functional components provide is closely related to the system’s non-functional requirement which is whether relevant functional components operate on the same or different kinds of platforms. When all functional components operate on the one computer and share the main memory, the service platform for the external function call is provided as the function of the operating system. And the function call is enabled by using standard API specified in TRM. When functional components operate on multiple computers but on the same platform (e.g. NET, EJB), the service platform for external function call is a procedure to call remote function which the platform provides. If platforms are not expected to be unified in the future, it is required to select the service platform which is independent from lower layer platforms and what has the data/protocol conversion function as the mediation function, the message validation function (e.g. Enterprise Service Bus) and the transportation service that supports multiple procedures/protocols to call remote functions,. Guideline: From the viewpoint of the separate procurement of each functional component and the broadening procurement options, the platforms on which functional components operate should not be restricted as far as possible. Thus it is preferable to select a service platform for the external function call independently from the lower layer platform as far as non-functional requirements such as performance, security, and stability are allowed.

5.4 Interoperability of Data Data which are stored for prolonged period and are exchanged and reused by multiple users such as

25

office documents need to be stored in the format which assures the access to the data for the future. Thus it is not preferable to store data in the format which depends on the vender’s proprietary technology and does not allow other venders to develop the method to access the data stored in the format legally or the format whose logic structure of data is not disclosed. Since the data may be utilized widely by users (e.g. citizens) other than the government and public organizations which have created the data, the data format should be supported by multiple technologies and products and must not require users’ additional investment such as purchase of the specific product to access the data. Guideline: It is preferable to adopt the open standard data format as the format of data which are stored for prolonged period and are exchanged and reused by multiple users. If there are multiple open standards for data format, it should select the format which uses XML whose degree of dependency to a specific platform or specific technologies is low. If there are multiple open standards that adopt XML, from formats which are specified in TRM and supported by multiple products/venders it should select the format which is expected to have marketability and to be supported by the larger number of products/venders .

Guideline: If current data are stored in the data format other than open standards, for the improvement of the interoperability it is preferable to use the open standard format to newly store, exchange, or save data. And gradually converting existing data into open standard data format is also preferable for the interoperability improvement.

5.5 Interoperability of Messages The format of messages exchanged among functional components depends on the adopted service platform for the external function call by each government or public organizations. Since the service platform for the external function call is included in the common part, it should be selected by the phase of the dividing functions of the entire system and the phase of the defining non-functional requirements and it will be described as the functional specification of the service platform. Guideline: From the viewpoint of the separate procurement for each functional component unit and the broadening procurement options, the platforms on which functional components run should not be resricted as far as possible. Thus it is preferable that the format of messages exchanged among functional components should be independent from the platform as far as it is allowed with the selected service platform of the external function call.

Guideline: As the format of messages exchanged among functional components, it is recommended to use XML whose degree of dependence on the platform is low and enables explicit description of the logic structure of messages as a schema. As the schema of XML, the open standard schema should be selected by priority and should be extended if needed. If the interoperability with the external system is required, the adopted schema should be disclosed.

26

5.6 Guidelines for Creation of Procurement Specification

In the procurement of computer products and services for construction of the e-Government, it is required to carefully avoid the situation that the components of e-Government virtually depend on the vender’s proprietary technology and to avoid the future continuous procurement of the product or the service from the specific vender. It must be careful not to force users of the e-government to use a specific vender’s product or a service as a result of the dependency of the e-Government on the specific vendor’s technology. In order to achieve this objective, following points should be noted wherever possible in the procurement of computer products and services.

Guideline: As provided in the Clause 3 of Article 6 of ‘Agreement on Government Procurement’, “There shall be no requirement which referes to a particular trademark or trade name, patent, design or type, specific origin, producer or supplier” is a general rule. However, when a procurement of an integrated system is divided into multiple parts or multiple phases by components and when those components depend on one another, such as the cases where hardware and software are procured separately, or the operating system and the application software are procured separately, for the clarification of the requirement, it is acceptable to specify product names of components which are determined to procure in the prior procurement and to make requirements in new procurement that the components work together with the components procured in the prior procurement. For the clarification of the requirement that relates to interoperability, it is effective to disclose detailed technical information such as the interface specification of the components which is delivered in the prior procurement.

Note) The Clause 3 of Article 6 of ‘Agreement on Government Procurement’, provides an

exceptional case which allows to refer a brand, etc. by adding words such as “or its equivalent” However, if the requirement is defined with the expression, “xxxx, or its equivalent”, it may be interpreted that all functions that xxxx offers are necessary. And this will violate the rule of “features not mandatory to the assigned task will not be required” of “Measures Related to Japanese Public Sector Procurement of Computer Products and Services” Specifications 4. Furthermore, it should be noted that the definition of requirements which refer to a brand makes venders hesitant to bid using an alternate product for the referred product because it is virtually impossible to prove that the alternate product is either equal or surpass the product referred in all functions. And it should be noted that such brand designated requirement procurement specification will impede the procurement of products other than the product referred.

Guidelines: In order to create a neutral procurement specification which causes less miscommunication between the procurement staff and bidders, the procurement specification must be written quoting only technologies provided in TRM or open standards, as far as possible.

27

Guideline: It is preferable that the requirement to inherit existing assets (peripheral devices, software, data, etc.) which do not have interfaces conform to open standards such as international standards and Japanese Industrial Standards should not be a part of requirements for new procurement after the comprehensive evaluation on the future risk of lock-in to a specific technology which is required to inherit assets and of the cost for the procurement and the operation, etc.

Note) The requirement to new procurement to inherit current system assets dependent on non-standard interface may cause lock-in to a specific technology consecutively. If the specification of the lock-in technology is not disclosed and the usage of the specification is not allowed to everyone like the case with open source software, it is virtually impossible that venders other than the supplier of the asset causing lock-in construct an environment fully compatible with the current system. And this might exclude products developed by other venders from procurement options, and procurement options become narrower as a result. Avoiding the lock-in to a specific technology has an effect to increase procurement options.

Guideline: The functional requirement of procurements must not include the interface which open standards (such as international standards and Japanese Industrial Standards) do not specify as mandatory and functions which those standards specify as optional. When those inessential or optional interfaces or functions are essential for businesses, the necessity for the business should be clearly described and the usage of the interface or the function must be limited. For the procurement of application software or data, it should be clearly stated as the requirement that the application software or data should not be created using interfaces or optional functions, which referred specifications or standards do not specify as mandatory, unless the usage of those interfaces and functions are essential for businesses.

Note) Usage of interfaces or functions dependent on implementation/products causes dependence to

a specific technology between the software and the environment on which the software runs, or between the data and software which creates or utilizes the data, and lock-in is caused as a result.

Guideline: In accordance with the Clause 2 of Article 6 of ‘Agreement on Government Procurement’, international standards and Japanese Industrial Standards should be chosen at first for the standard referred by procurement specification. When relevant international standards or Japanese Industrial Standards do not exist, other open standards should be chosen next.

Guideline: When standards to be referred do not exist, the functional requirement of the procurement should be provided by specifying minimum functions necessary for businesses. In the description of requirements it is preferable that desirable functions are separated from essential requirements.

28

Guideline: If a requirement regarding on the portability/interoperability of data with the existing system needs to be specified, due to the requirement of the existing asset inheritance, the standard format for the data conversion which is defined by open standards such as international standards or Japanese Industrial Standards should be used as mediation.

Note) By using the format specified by open standards as the mediation for the data conversion, data

which are needed to be inherited will be converted to standard data format gradually and the possibility of information system lock-in caused by the inherited data format can be expected to decrease.

Guideline: If the existing system does not have the conversion function to above-mentioned standard formats for the data conversion, it is not preferable to specify that the new information system to be procured should have ability to handle the inherited data asset retaining current non-standard data format, for a functional requirement of the new system to be procured, And it is preferable to request the mechanism to convert the inherited data to a standard data conversion format or to the data format of the new system as an additional requirement for a new system.

Guideline: When there are special requirements regarding inherited assets from existing system other than data, it is preferable that those requirements should be distinguished from general requirements of the new system and be provided as a special instruction.

Note) To distinguish temporary requirements relating to the asset inheritance separately from

general requirements has an effect to prevent the temporary requirements from being inherited to the following procurement without discretion. Regarding on requirements to inherit assets other than data, if the existing hardware or software which have non-standard interface is switched to hardware or software that have standard interface or is inherited with the hardware or software that have standard interface, it becomes unnecessary to require the inheritance of assets which have non-standard interface or data format as a special instruction again in the next system procurements. And it makes procurements compliant with standards in the future.

Guideline: When brands of specific products, in addition to standard references and definition of requirements by functions, are referred as examples for the clarification of requirements, it is preferable to list multiple products which meet requirements (not only commercial products but also open source software) and to describe that equivalent or better performances and functions are required.

Note) By referring multiple products as examples, it should be shown that only common functions

of those products are required and required essential functions become clear.

29

6. Points to note In this chapter, points to note for design, development, operation, maintenance, and reconstruction/modification of interoperable information systems are listed, and coping techniques are described wherever possible. Since points to note and coping techniques may be contradictory in some cases, the most suitable measures should be taken in actual operation considering requirements of the operation and the information system and their priorities.

6.1 Points to note in Design For the design of an overall system which can be procured separately and has interoperability, it is necessary to determine the interface between services provided by individual functions and the system’s common part in the design phase of the common part. If an interface independent from platforms and the loose coupling of services are selected, system limitations for individual functions decrease and the separate procurement becomes easier, but this might have negative impact on system’s performance. In the design phase, it is necessary to select the most suitable interfaces from the view point of what services are provided as individual function systems and considering requirements of each individual function system.

6.2 Points to note in Creation of Procurement Specification Open standard technical specifications (standards documents) define mandatory interfaces which must be provided by the standard compliant implementation and define the behavior of the implementation in utilizing the interface. Moreover items which are dependent on the standard compliant implementation,such as interfaces that the implementation can select, the behavior dependent on the implementation, items on which the open standard does not have any requirements to the behavior of the implementation, limitations which are dependent on the implementation, etc may also be specified in standard technical specifications. Even if an application runs on the open standard compliant implementation or an application only calls functions of the open standard compliant implementation, the application which depends on unique interfaces or functions of a implementations, may not have portability or interoperability with other open standard compliant implementations. Moreover, the interoperability between applications compliant with the same open standard may be lost. Thus, when development of interoperable applications which refer to open standards are outsourced, it is necessary to clearly state, as a requirement in the procurement specification, that the application should not depend on interfaces or behaviors which the open standard does not designate as mandatory. Also, for the procurement of the existing application compliant with the open standard, it is necessary to investigate the limitation of implementation-dependent interfaces or behaviors for the open standard on which the application depends and investigate the interoperability of the application with other implementations and applications which are compliant with the same open standard.

30

6.3 Points to note in Reconstruction/Modification of Systems In the case of the development of a new information system, the service platform for the external function call can be determined after the optimization of whole system and the functional segmentation in accordance with above-mentioned policies and guidelines. However, for the case of the modification to the existing system or the case of the incorporation of some functions of the existing system into a new system, the interface mismatch between the existing system and the service platform for the external function call of the new system may occur and it may cause problems for interoperability. For example, there is the case that the existing system is a program written in COBOL for the main frame computer and using the character-type terminal of the main frame computer as the user interface and a new system is going to be developed using Java. When functional components are using different interfaces and the modification of existing functional components has to be minimized for some reason, it is worth to consider to achieve the interoperability among functional components which have different interfaces by selecting the service platform which utilizes platform independent loose-coupling and by wrapping the existing functional components for the connection with the selected service platform.

6.4 Interoperability between Clients and Servers In terms of interaction between clients and servers, the mainstream method is to install a special program which cooperates with programs on the server onto clients, or to utilize services which the platform provides on condition that clients and server use the same platform (operating system and middleware). However, if this method is adopted, the constraint that the program for the cooperation on the client depends on the specific operating system and CPU architecture and server and clients have to use the same operating system arises. This may limit the separate procurement of hardware and software or the separate procurement of platform parts and individual function parts, and procurement options may be restricted as a result. Furthermore, this also may force additional investment (e.g. purchase of a PC on which a specific application operates) on external users who desire to utilize services which the government or public organizations provide (e.g. electronic application services which government provides). Thus, interfaces and protocols to utilize the services should not depend on the specific vender’s unique technology (such as function supported only by the certain web browser,) and should be limited to those which use only mandatory interfaces specified by open standards. It is preferable that interfaces and protocols should be popular enough to be supported by multiple products.

6.5 Cooperation with Other Systems In cooperation of systems between different organizations via Internet, it may be required to call services which are running on remote systems crossing over fire walls built at the boundary of the

31

organizations as a security measure. Although system cooperation can be accomplished by the secure communication route between organizations utilizing technologies such as VPN and interfaces such as remote procedure call, it is not recommended to build such special communication route between organizations from security viewpoint. For cooperation of systems via Internet, it is preferable to consider service call procedures which can be written by text such as XML and methods to execute the call with a protocol which passes fire walls such as HTTP. In such case, it is required to pay attention to the authentication of users (including programs) and the encryption of electronic transmission.

6.6 Points to note on Portability

6.6.1 Points to note in Data Migration

In order to improve data portability, it is preferable to accumulate data in XML format in which the logical structure of data is explicitly stored and to migrate data via XML. Even for the data migration using XML, it should be noted that the printing result may vary depending on fonts, style files and rendering engines since XML has not detailed output instruction and it has only logical structure of data.

6.6.2 Points to note on Double Standards

In some cases, there are multiple open standards which have the same scope and can not be implemented at the same time. In such case, one open standard to be referred from TRM should be selected by the whole ministry or office. When multiple open standards on data format exist, it is preferable that procurement includes the product which supports multiple open standards simultaneously in order to enable data exchange among ministries and offices.

Note) An example of double standards is the standards of optical disks.

6.6.3 Points to note on difference of Versions of referred Open Standard

In some cases, there are multiple versions of an open standard as a result of a sequence of revisions and it is not always assured that those different versions are fully interoperable each other. In such case, if the latest version of the open standard is adopted, there may be very few implementations compliant to the latest version, and the interoperability may not be assured with the products compliant to the widely prevalent old version. Thus it is necessary to select the proven version of the open standard in consideration of the diffusion of its implementation.

6.7 Points to note on Operations Usable character types and fonts may vary depending on information systems, platforms, and

32

applications. Such difference of character types and fonts may disturb information exchange and impair interoperability. In the environment where multiple platforms or applications are used at one time, it is preferable that each organization which uses those platforms and applications defines a common character group to ensure data portability. And it is also preferable to include the usability of a common character group into the system requirements in the procurement of information systems, and conduct daily operations within the range of the common character group. If there is a possibility to exchange data with other organizations, the character group specified by International Standard (e.g. ISO/IEC 10646) or Japanese Industrial Standards should be chosen as the common character group, and usage of non-standard characters (external characters) should be avoided as far as possible. Also, fonts which can be used on multiple platforms should be used for electronic documents.

7. Future Direction

When the government and public organizations construct and procure the information systems, in order to construct systems which have interoperability and flexibility, it is not sufficient only to comply with policies and guidelines which are described in this document. In this chapter, actions which are required to facilitate construction of a system with interoperability and flexibility are described in the form of the proposal.

7.1 Preparation of Guidelines for Separation of Procurement Unit and Total Design For the smooth implementation of ‘Basic Guidelines for Government Procurement Related to Information Systems’, it is preferable to issue guidelines concerning a basic design of the system and methods of the functional division based on the separated procurement rule, the design of system’s common parts, and the design of interfaces to implement the interoperability. Guidelines should be corresponding to the practicable guide book prepared by Ministry of Internal Affairs and Communications and also be complement to the contents of the guide book.

7.2 Maintenance of TRM TRM referred by the government and public organizations in construction/procurement of information systems should be kept suitable for technical advancement and diffusion. The government should prepare a common TRM to be referred by the government and public organizations and review it at fixed intervals (for instance, two years). Each government and public organizations are recommended to prepare their own profiles to the common TRM prepared by the government for the consideration of their distinctiveness. These profiles should be reviewed according to the review cycle of common TRM.

7.3 Adding information on Open Standards and their Versions to be referred in TRM In the current TRM created and published by the Ministry of Economy, Trade and Industry, names of

33

technologies which should be preferentially procured by the government are specified, but the information on open standards and their versions to be referred by procurement specifications are not always specified. In order to make it easy for the procurement staff of the government and public organizations to write technically unambiguous procurement specifications, the information on open standards and their versions corresponding to technologies to be preferentially procured should be specified in TRM.

7.4 Preparation of Catalogs of Products Compliant with Open Standards referred by TRM Even if a neutral and unambiguous procurement specification is prepared by referring to TRM, the procurement staff should carefully assess the degree of conformity of components incorporated in systems to open standards at the review of proposals and the acceptance of them in order to ensure interoperability of actual systems. In order to make it easy for the procurement staff to assess the degree of conformance (deviation and expansion) of products to open standards, it is preferable that the inventory of products compliant with open standards referred by TRM and their conformity to open standards should be prepared as a reference material of TRM and be available for the reference to the government and public organizations

7.5 Creation of Neutral Procurement Specification Model In order to make it easy for the procurement staff of the government and public organizations to write neutral and unambiguous procurement specifications, it is preferable that a model of neutral procurement specification should be published and should be shared among the government and public organizations as the best practice. It is also preferable that the model of procurement specification should include both models of the procurement specification for the common part of a system and for individual functions from the view point of separate procurements.

7.6 Collection of Best Practices of SOA As a reference to Deputy CIO and to information system designers of the government and public organizations, it is preferable that utilization cases and best practices of Service Oriented Architecture (SOA) in the government and public organizations should be collected.

7.7 Research on Business Services and publishing the Catalog In order to make it easy for the procurement staff of the government and public organizations to write neutral and unambiguous procurement specifications, it is preferable that the research on business services which the government and public organizations can utilize should be conducted, and the result of the research should be cataloged and published. The term of “business services” here includes services which have interfaces that can be incorporated into information systems of the government and public organizations and whose functions are provided by non-government

34

organizations through networks.

7.8 Assessments of interoperability for Government Procurement and revision of this Framework It should be investigated and assessed that actual procurements of the government and public organizations are pursuant to policies and guidelines of this Interoperability Framework. And guidelines provided by this Interoperability Framework should be revised accurately to reflect requests from procurement workplace.

35

Appendix 1. Examples of Referred Standards (quoted from the material for the 20th Deputy CIO Conference held on October 28, 2005)

Standard Reference POSIX standard ISO/IEC 9945-1:2003, ISO/IEC 9945-2:2003, ISO/IEC 9945-3:2003 LSB (Linux Standard Base) standard

ISO/IEC 23360-1:2006

Standard format for public opened office document

ISO/IEC 26300:2006

SQL standard ISO/IEC 9075-1:2003, ISO/IEC 9075-2:2003, ISO/IEC 9075-3:2003, ISO/IEC 9075-4:2003, ISO/IEC 9075-5:1999, ISO/IEC 9075-5:1999/Amd 1:2001

W3C HTML standard

W3C Recommendation HTML 4.01 Specification http://www.w3.org/TR/html401/

SMTP standard RFC 2821 Internet message format standard

RFC 2822

MIME standard RFC 1341 HTTP standard RFC 2068 ISO9660 standard ISO 9660:1988 ECMA script standard

ISO/IEC 16262:2002

JPEG standard ISO/IEC 15444-1:2004, ISO/IEC 15444-2:2004, ISO/IEC 15444-3:2002, ISO/IEC 15444-3:2002/Amd 2:2003

GIF standard GRAPHICS INTERCHANGE FORMAT(sm) version 89a http://www.dcs.ed.ac.uk/home/mxr/gfx/2d/GIF89a.txt

J2EE1.4 standard Java Specification Request 151 Java 2 Platform, Enterprise Edition 1.4 (J2EE 1.4) Specification http://www.jcp.org/en/jsr/detail?id=151

MPEG1 standard ISO/IEC 11171-1:1993, ISO/IEC 11171-1/Cor1:1996, ISO/IEC 11171-1/Cor2:1999 ISO/IEC 11171-2:1993, ISO/IEC 11171-2/Cor1:1996 ISO/IEC 11171-2.Cor2:1999, ISO/IEC 11171-2/Cor3:2003 ISO/IEC 11171-3:1993, ISO/IEC 11171-3/Cor1:1996

MPEG2 standard ISO/IEC 13818-1:2000, ISO/IEC 13818-1:2000/Cor1:2002, ISO/IEC 13818-1:2000/Cor2:2002, ISO/IEC 13818-1:2000/Amd1:2003, ISO/IEC 13818-1:2000/Amd2:2004,ISO/IEC 13818-1:2000/Amd 3:2004 ISO/IEC 13818-2:2000, ISO/IEC 13818-2:2000/Cor1:2002 ISO/IEC 13818-2:2000/Amd 1:2001, ISO/IEC 13818-3:1998

MPEG4 standard ISO/IEC 14496-1:2004, ISO/IEC 14496-2:2004, ISO/IEC 14496-2:2004/Cor 1:2004, ISO/IEC 14496-2:2004/Amd 1:2004 ISO/IEC 14496-3:2001, ISO/IEC 14496-3:2001/Cor 1:2002 ISO/IEC 14496-3:2001/Amd 1:2003/Cor 1:2004 ISO/IEC 14496-3:2001/Cor 2:2004, ISO/IEC 14496-3:2001/Amd 1:2003 ISO/IEC 14496-3:2001/Amd 2:2004,ISO/IEC 14496-3:2001/Amd 3:2005

36

Appendix 2. Examples of Neutral Procurement Specification (quoted from the material for the 20th Deputy CIO Conference held on October 28, 2005)

Item Examples of requirement using trade names

Way to ensure neutrality

Examples of expression to ensure neutrality

Functional description

An operating system for PC which have multi-user multi-task capability, network function based on TCP/IP, and graphical user interface

Reference to open standards (international standards)

Operating system compliant with POSIX standard

Operating system

･ Equaling or surpassing the latest Microsoft Windows XP Professional

･ Equaling or surpassing Solaris 7

･ RedHat Enterprise Linux

Reference to open standards

Operating system compliant with LSB standard

Functional description

Word processing software which has capability to process Japanese document and has ruling function

Functional description and special instruction

To meet either one of the following conditions i or ii i. Japanese word processing software which has capability to read, edit and export document files created with Ichitaro 9 and ruling function ii. Combination of a Japanese word processing software which does not have capability to read document files created with Ichitaro 9 directly and measures to enable the software to read document files created with Ichitaro 9 such as utility software which convert document files created with Ichitaro 9 into a format the software can read

Reference to open standards

Japanese word processing software which has capability to read, edit, print and export document compliant with OASIS Open Document Format standard

Reference to open standards

Japanese spreadsheet software which has capability to read, edit, print and export document compliant with OASIS Open Document Format Standard

Business software, authoring tools, etc.

･ Equaling or surpassing the latest JustSystems Ichitaro

･ Capability to read, edit, and export files created with JustSystems Ichitaro 9

･ Equaling or surpassing the latest Microsoft Word

･ Equaling or surpassing the latest Microsoft Excel

･ Equaling or surpassing the latest Microsoft PowerPoint

･ Equaling or surpassing the latest Microsoft FrontPage

･ Equaling Adobe Photoshop

Reference to open standards and special instruction

Japanese spreadsheet software which has capability to read, edit, print and export document compliant with OASIS Open Document Format Standard Measures to enable the spreadsheet software to be procured read data extracted from spreadsheets created with Excel 98 and measures to assist macro migration should be provided

37

Reference to open standards

Japanese presentation software which has capability to read, edit, print and export document compliant with OASIS Open Document Format Standard

Reference to open standards

HTML editor software which has a function to automatically generate documents that uses HTML provided by W3C HTML standard with GUI operation

Functional description

Photo retouching software which enables correction and editing of digital images such as digital photographs Capability to edit images compliant with JPEG standard and GIF standard format

Web browser

･ Equaling or surpassing the latest Microsoft Internet Explorer

Reference to open standards and functional description

Web browser software which has ability to display of and to input through forms to web contents created with functions provided by W3C HTML standard and ECMA script standard. A function to display image data compliant with JPEC standard and GIF standard formant should be available. HTTP standard, HTTP over TLS standard and FTP standard should be supported as communication protocol.

Functional description

Japanese input sub-system which supports character sets included in JIS X 0201, JIS X 0213, and ASCII coded character set standard, has functions of phrase translation, learning function, word storing, and input of Japanese characters using Roman characters, and works with multiple operating systems. Character translation with space bar, selection with return key, switching of hiragana/katakana with PF key, and a function to customize mapping of keys used for character translation should be available.

Japanese-language input system

･ Equaling or surpassing the latest JustSystems ATOK

Functional description and special instruction

Japanese input sub-system which supports character sets included in JIS X 0201, JIS X 0213, and ASCII coded character set standard, has functions of phrase translation, learning function, word storing, and input of Japanese characters using Roman characters, and works with multiple operating systems. Character translation with space bar, selection with return key, switching of hiragana/katakana with PF key, and a function to customize mapping of keys used for character translation should be

38

available. Measures to continuously use words stored by the word storing function of current JustSystem Ichitaro 9 with the new Japanese input system to be procured should be provided.

Reference to open standards (international standards)

Database server which has an interface specified by SQL standard.

Functional description

Simplified database software which is able to create relational database in file unit.

Functional description

System management software which has function of network management, job management, asset management, license management, automatic delivery of software, resource management, security management, and availability management.

Reference to open standards

Application server software which provides implementation environment for Java code that has an interface specified by J2EE 1.4 standard.

Reference to open standards

Application server software which provides web server function compliant with HTTP standard and implementation environment for Java code that has an interface specified by J2EE 1.4 standard.

Functional description

Software which automatically shut down specified systems in the event of power disturbance in conjunction with uninterruptible power system (UPS)

Database, middle ware, operational manage- ment tool, etc.

･ Equaling or surpassing Oracle 8i Enterprise Edition

･ Equaling or surpassing the latest Microsoft Access

･ System management software which has equaling or surpassing functions of Hitachi JP1

･ Equaling or surpassing the latest BEA WebLogic Application Server

･ Equaling or surpassing the latest IBM WebSphere Application Server Enterprise

･ Equaling the latest APC PowerChute

･ Equaling the latest BrightStor ARCserve

Functional description

Software which backup data stored into computers that connected to a network and manage the backup data through the network.

Functional description

Groupware software which has functions of e-mail, calendar, scheduler, electronic bulletin board and electronic document management, and supports web browsers as a client for document browsing.

Groupware, etc.

･ Equaling or surpassing Lotus Notes Domino

Reference to open standards and special instruction

E-mail client software which has functions to create e-mails in a format compliant with internet message format standard and MIME standard and send/receive e-mails with communication protocol compliant with SMTP standard. Capability to exchange e-mails with Lotus Notes/Domino 6.5 is required.

39

Anti-virus software

･ Equaling or surpassing Norton Antivirus

Functional description

Anti-virus software which has a resident virus check function and is effective against boot sector virus, execution type virus, and macro virus. Function to automatically update pattern files is required.

Functional description

Character display software which can display documents written in PDF 1.4 format. If a font specified in a document is not within the range the character display software can access, it is acceptable to display the document using an alternative font. If a function which is not provided by PDF 1.4 is included in a document, it is acceptable to display the document after indicating the function will be skipped, or displaying a warning message or an error message.

Reference to open standards (international standards)

Media playing software which has functions to play animation and sound in format compliant with MPEG 1 standard, MPEG standard, and MPEG 4 standard.

Content delivery software, content viewer software

･ Equaling or surpassing the latest Adobe Acrobat Reader

･ Equaling or surpassing the latest Real Player Basic

･ Equaling or surpassing Real Server G2 Plus

Reference to open standards (international standards) and special instruction

Streaming delivery software which delivers animation and sound in format compliant with MPEG 1 standard, MPEG 2 standard, and MPEG 4 standard. Capability to receive access from 100 clients simultaneously is required.

CD / DVD authoring software

･ Equaling or surpassing the latest BHA B’s Recorder

Reference to open standards

CD writing software which can create CD in format compliant with ISO 9660. Joliet and Romeo file name format should be supported. Writing function into medias such as CD-RW, DDCD-R, DDCD-RW, DVD-R, DVD-RW, DVD-RAM, DVD+R, DVD+RW, and DVD+R DL as well as CD-R is required. In writing into DVD, UDF should be supported.

Other software

･ Equaling or surpassing Val Laboratory’s Eki-spert

Functional description

Software which displays railway timetables, fare calculation, and connection information. All JR lines, all private railways, and bus lines should be included. A function to update the software on line in accordance with revision of lines, timetables or fares is required.

Client PC ･ Personal Computer with CPU equaling or surpassing Intel Pentium 4-M (1.6GHz)

Reference to software whose procurement is determined.

A personal computer on which the operating system included into this time’s procurement works. The PC should be equipped with CPU which has power-saving function, display

40

monitor which displays 1027 x 768 or more of pixels, a pointing device such as mouse, 512MB or more of main memory unit, magnetic disk device with capacity of 20GB or more, CD-ROM unit with 20 x or more of speed, 100baseT network interface, and USB interface. Ability to finish all boot-up process including login, and connection to network and to get ready to start operation within 150 seconds from power activation, upon initial installation of operating system, is required.

Explicit specification of software which is determined to be procured in another procurement

A personal computer and an operating system on which version 1.1 of OpenOffice.org whose procurement in office software procurement (No. xxxx) has been determined works. 512MB or more of main memory unit, magnetic disk device with capacity of 20GB or more, CD-ROM unit with 20 x or more of speed, 100baseT network interface, and USB interface should be mounted. Ability to finish reading of a document file with 20MB or more size using version 1.1 of OpenOffice.org within 15 seconds

41

Appendix 3. Reference Bibliography Government Related

MIC Basic Guidelines for Government Procurement Related to Information Systems (Draft) http://www.soumu.go.jp/s-news/2007/070301_5.html

MIC Optimization of Operations/Systems Guidelines http://www.soumu.go.jp/gyoukan/kanri/a_01-02.html

MIC Panel on Construction Procedure of E-Local Government System http://www.soumu.go.jp/denshijiti/denshi_kentoukai.html

METI EA Portal (including TRM and guides of METI) http://www.meti.go.jp/policy/it_policy/ea/index.html

Technical Reference Model (TRM) Overview http://www.meti.go.jp/policy/it_policy/ea/gainen/model/trm/index.html

Framework on Technical Reference Model (TRM) http://www.meti.go.jp/policy/it_policy/ea/data/report/r31/index.html

Technical Reference Model (TRM) Report of Survey, Guidelines on Utilization of TRM and Technical Evaluation http://www.meti.go.jp/policy/it_policy/ea/data/report/r32/index.html

Guidelines on Planning, Maintenance, and Management of Technical Reference Model http://www.meti.go.jp/policy/it_policy/ea/data/report/r33/index.html

Utilization Guide of Reference Model for Operation and Systems Optimizing Plan http://www.meti.go.jp/policy/it_policy/ea/data/report/r34/index.html

Experiment and Evaluation Report on Practicality of Reference Models http://www.meti.go.jp/policy/it_policy/ea/data/report/r35/index.html

New Media Development Association, Guideline on Procurement

http://www.nmda.or.jp/choutatsumodel/index3.html Standard specification of APPLIC local information platform.

http://www.applic.or.jp/tech/

EA Related Invitation to Collaborative Authoring of the Enterprise Architecture Management Guide

http://colab.cim3.net/file/work/Expedition_Workshop/2007-01-23_CollaborativeOrganizingWorkshopToPlanFutureWorkshops/Luo_EA_Mgmt_Guide_Progress_2007_01_23.ppt

SOA Related Practical Guide to SOA Implementation

http://colab.cim3.net/cgi-bin/wiki.pl?PracticalGuidetoSOAImplementation 2nd SOA for E-Government Conference

http://colab.cim3.net/cgi-bin/wiki.pl?SOAforEGovernment_2006_10_3031 SOA of OMG

http://www.omg.org/attachments/pdf/OMG-and-the-SOA.pdf

42

http://soa.omg.org./SOA-Info-Day_12-06.htm Collaborative Organizing Workshop: Opening Up Networked Improvement Activities Around Service Oriented Architecture in 2007

http://colab.cim3.net/cgi-bin/wiki.pl?ExpeditionWorkshop/CollaborativeOrganizingWorkshopToPlanWorkshops_01_23_07 http://colab.cim3.net/file/work/Expedition_Workshop/2007-01-23_CollaborativeOrganizingWorkshopToPlanFutureWorkshops/DMayo01232007.ppt

Opening Up SOA Networking: Initiatives and Perspectives from State Government http://colab.cim3.net/file/work/Expedition_Workshop/2007-01-23_CollaborativeOrganizingWorkshopToPlanFutureWorkshops/Sweden_SOA_StateGovtPerspective_2007_01_23.ppt http://colab.cim3.net/cgi-bin/wiki.pl?ExpeditionWorkshop/CollaborativeOrganizingWorkshopToPlanWorkshops_01_23_07

Justice Reference Architecture (JRA) Specification, Working Draft (U.S. Department of Justice) http://colab.cim3.net/file/work/Expedition_Workshop/2007-01-23_CollaborativeOrganizingWorkshopToPlanFutureWorkshops/Sweden_JusticeRefArc_2007_01_23.pdf

XBRL Related XBRL Japan

http://www.xbrl-jp.org/whatisxbrl/ Bank of Japan’s Approach

http://www.xbrl-jp.org/download/S10.document5.zip EDINET

http://www.xbrl-jp.org/download/S10.document3.zip Local Tax

http://www.xbrl-jp.org/download/S10.document8.zip National Tax e-Tax

http://www.e-tax.nta.go.jp/shiyou/shiyou3.html

International Trends Related

Information Site on Public Sector and Open Source http://www.publicsectoross.info/ http://www.publicsectoross.info/resources/details_s.php?Id_resources=11

U.S. Federal Government "Data Interoperability across the Enterprise - Why Current Technology Can’t Achieve it. Draft version dated 29 January 2007."

http://colab.cim3.net/forum//sicop-forum/2007-01/msg00009.html

43

Appendix 4. Commentary Priority of Interoperability in Optimization

Although interoperability is considered a factor of optimization, this document does not provide a guideline on the priority of interoperability in optimization. Priority order of factors of optimization including interoperability should be determined based on cost evaluation of the system throughout life-cycle. Thus this document entrusts the Optimization of Operations/Systems Guidelines of the Ministry of Internal Affairs and Communications to provide all guidelines on optimization by referring to the Optimization of Operations/Systems Guidelines.

Relationship between Technical Specifications of Procurement Specifications and Optimization Plan of Operations/Systems Guidelines.

The term “technical specifications of procurement specifications” in this document includes system method requirement definition, information/data requirement definition, user interface requirement definition, external interface requirement definition, network requirement definition, software requirement definition, hardware requirement definition, and information security requirement definition of requirement definition document mentioned in the Guidelines for Optimization Plan of Operation and Systems.

Interfaces Independent from Platforms

The term “interfaces independent from platforms” in this document means message formats and protocols which are able to convey information among multiple platforms independently from hardware architectures, operating systems, programming languages, etc and does not include specific open standards such as XML, WSDL, SOAP, and HTTP.

Positioning of Appendix 1 and Appendix 2

In Appendix 1 and Appendix 2, materials submitted for Deputy CIO Conference is quoted without modification. In Appendix 2, examples of requirement description using the contents of requirement or referring to open standards which are modified from requirement description using product names in the actual procurement of clients of ministry LAN are listed. These examples have not actually used and they are not recommended descriptions to be used as they are. In actual procurement, more detailed description of requirement should be given considering requirement relating to inheritance of existing assets, functional requirements essential for daily operation, and so on. Appendix 1 is the list of open standards mentioned in the descriptions which refer to open standards in

44

Appendix 2, and it does not cover all open standards to which government and public organizations should refer. Subset of open standards which government and public organizations should preferentially procure should be examined and selected in preparation of TRM by each organization.