Guiding principles

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
1Generic building block to enable data exchange
2Limited scope: identification, authentication, and authorisation
3Leverage existing (international) building blocks
4Agnostic towards nature and content of data
5Benefits outweigh investment for all types of participants
6International orientation


Guiding principles details:

Principle 1Generic building block to enable data exchange
StatementiSHARE is a generic identification, authentication and authorisation scheme to be used as enabler for data exchange in logistics
RationaleIn 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 2Limited scope: identification, authentication, and authorisation
StatementThe iSHARE Scheme's scope is limited to topics of identification, authentication and authorisation in the context of data exchange
RationaleiSHARE 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 3Leverage existing (international) building blocks
StatementWhere possible, iSHARE should be realised using existing and proven standards, technology or initiatives
RationaleBy 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 4Agnostic towards nature and content of data
StatementThe iSHARE Scheme does not concern itself with the contents or nature of data
RationaleGiven 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 5Benefits outweigh investment for all types of participants
StatementThe iSHARE Scheme needs to be attractive to use and implement for all types of participants/roles.
RationaleThe 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 6International orientation
StatementThe iSHARE Scheme needs to look over geographic boundaries to foster international involvement and cooperation
RationaleThe 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 nameShould 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).
StatementShould 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.
RationaleShould 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.