View Source

To achieve the goals of the iSHARE scheme, it is paramount to stay close to a set of guiding principles. As time progresses new principles can be defined, existing principles can be adapted or dropped if deemed necessary. The guiding principles were defined using the format as suggested* by TOGAF 8.1.1 architectural principles.

The following principles define the iSHARE scheme and must be kept in mind at all times during further development (see details of guiding principles below):

Principle #	Principle name
1	Generic building block to enable data exchange
2	Limited scope: identification, authentication, and authorisation
3	Leverage existing (international) building blocks
4	Agnostic towards nature and content of data
5	Benefits outweigh investment for all types of participants
6	International orientation

Guiding principles details:

Principle 1	Generic building block to enable data exchange
Statement	iSHARE is a generic identification, authentication and authorisation scheme to be used as enabler for data exchange in logistics
Rationale	In every exchange of data, identification, authentication and authorisation are fundamental factors. iSHARE aims to simplify processes of identification, authentication and authorisation as a generic solution to facilitate data exchange in the logistics sector.
Implications	The iSHARE scheme will allow for extension or adaptability so it can be used in situation/sector specific cases; The iSHARE scheme will not cater to a specific sector or market, it is applicable in an N amount of cases; The iSHARE scheme will not be a point solution.

Principle 2	Limited scope: identification, authentication, and authorisation
Statement	The iSHARE scheme's scope is limited to topics of identification, authentication and authorisation in the context of data exchange
Rationale	iSHARE aims to improve the circumstances for data exchange throughout the logistics sector and provides focus on the topic of identification, authentication and authorisation. Identification, authentication and authorisation are a fundamental part of any data exchange, but are not solved in a scalable or standardised way at the moment.
Implications	Without this principle, there is a risk of 'scope creep': related topics could take away the focus off the intended topics

Principle 3	Leverage existing (international) building blocks
Statement	Where possible, iSHARE should be realised using existing and proven standards, technology or initiatives
Rationale	By reusing building blocks already available and in use, the impact on organisations to participate in iSHARE and the time to realise the iSHARE scheme are lowered. Standards, technology and initiatives preferably have a broad (international) usage base and are backed by a professional organisation charged with maintenance of the standards, technology or initiatives.
Implications	the iSHARE scheme will build on or use existing (international) standards, technology or initiatives where possible; the iSHARE scheme will aim to use open standards, technology or initiatives; the iSHARE scheme may use proprietary standards, technology or initiatives; if existing and/or proven standards, technology or initiatives do not provide what is needed, alternative solutions will be sought.

Principle 4	Agnostic towards nature and content of data
Statement	The iSHARE scheme does not concern itself with the contents or nature of data
Rationale	Given the generic nature of the iSHARE scheme and the aim to be applicable throughout the logistics sector, iSHARE needs to function with any type of possible data and/or any relevant data exchange interaction model. To this end, the contents of data are only considered where it concerns the facilities needed within iSHARE to adequately exchange various types of data (e.g. requirements to security, encryption, etc.). It is up to the participating organisations to ensure that iSHARE adequately fulfills requirements to the process of identification, authentication and authorisation in the context of data exchange.
Implications	the iSHARE scheme will not specify the (allowed) content of data exchanges done within an iSHARE context; the iSHARE scheme does not specify content specific data standards; the iSHARE scheme should not have limitations connected to types of data or standards used.

Principle 5	Benefits outweigh investment for all types of participants
Statement	The iSHARE scheme needs to be attractive to use and implement for all types of participants/roles.
Rationale	The iSHARE scheme knows different roles with different responsibilities. When a potential participant considers taking a (or multiple) role(s) in the iSHARE scheme, the iSHARE scheme should aim to have the lowest possible threshold to participate for the potential participant. Depending on what the character of the potential participant is (e.g smaller size or larger size organisations) and which role the participant wants to take, this could mean that the impact of implementation needs to be small or that the implementation is kept relatively simple.
Implications	the ISHARE scheme aims to keep thresholds to participate in the iSHARE scheme (e.g. in terms of implementation impact or onboarding/certification effort) as low as possible for all possible roles; the iSHARE scheme strives for the lowest possible impact for participants when changes occur in the future. Changes to used standards will take place; within the iSHARE scheme and its specifications thought needs to be given to how change is dealt with in an efficient way.

Principle 6	International orientation
Statement	The iSHARE scheme needs to look over geographic boundaries to foster international involvement and cooperation
Rationale	The logistics sector is per definition an international sector. The iSHARE scheme needs to facilitate, to the extent that it is practical and possible, international involvement.
Implications	the iSHARE scheme needs its participants to provide knowledge and experience on how the iSHARE scheme can stay (and become) attractive in the international context

*Format used for defining guiding principles, based on TOGAF standard:

Principle name	Should both represent the essence of the rule as well as be easy to remember. Specific technology platforms should not be mentioned in the name or statement of a principle. Avoid ambiguous words in the Name and in the Statement such as: 'support', 'open', 'consider', and for lack of good measure the word 'avoid', itself, be careful with 'manage(ment)', and look for unnecessary adjectives and adverbs (fluff).
Statement	Should succinctly and unambiguously communicate the fundamental rule. For the most part, the principles statements for managing information are similar from one organisation to the next. It is vital that the principles statement be unambiguous.
Rationale	Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
Implications	Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. It will often be apparent that current systems, standards, or practices would be incongruent with the principle upon adoption. The impact to the business and consequences of adopting a principle should be clearly stated. The reader should readily discern the answer to: 'How does this affect me?' It is important not to oversimplify, trivialise, or judge the merit of the impact. Some of the implications will be identified as potential impacts only, and may be speculative rather than fully analysed.