Release 4.0, Approved, Jun 2020
GS1 Architectural Principles
sets out the architectural principles that underpin the GS1 system
Contents
- Business value
- Conformance
- Consistency
- Deprecation
- Extensibility
- Forward looking
- Global multi-sector standards
- GS1 identification keys
- Interoperability
- Non-duplication
- Non-significance of keys
- Open supply chains and value networks
- Re-use of components
- Royalty free
- Scalability
- Security
- Simplicity
- Technology independence
- Third party standards
- Vision and mission
Preamble
This document sets out the architectural principles that underpin the GS1 system.
The objectives of this document are:
■ to inform and guide all those involved in the development and maintenance of the GS1 system by providing a shared understanding of the principles of the GS1 System Architecture; and
■ to provide to users of the GS1 system, and anyone else with an interest in the subject, an insight into the foundational ideas that inform the design of the system.
The full benefits of the GS1 system can only be obtained when the GS1 standards, guidelines, solutions and services, respect the architecture and the principles.
Draft deliverables are reviewed against the principles as an integral part of the systems development processes. Signs of non-conformance trigger a dialogue about the specific divergences between the Architecture Group (or one of its members) and the Work Group responsible for the deliverables. If divergences remain after this dialogue, the deliverables may still be put to the Board Committee for Standards for ratification. Deviation from one or more of the architecture principles does not disqualify a development of the system because other factors, commercial or geopolitical for example, may be more important. However, it is the responsibility of the Architecture Group to make the Management Board (or its designated sub-committee) aware of any deviations from the principles so that they can take them into account as part of their ratification decision.
The principles should remain stable, although the GS1 System Architecture might change.
The Principles
Business value
Conformance
Consistency
Deprecation
Extensibility
Forward looking
Global multi-sector standards
GS1 identification keys
Interoperability
Non-duplication
Non-significance of keys
Open supply chains and value networks
Re-use of components
Royalty free
Scalability
Security
Simplicity
Technology independence
Third party standards
Vision and mission
The GS1 system shall support business processes, be tied to trading partner needs and demonstrate its business value.
GS1 standards must be created pragmatically and where there is a genuine intention to implement. No one company, industry, or geography should dominate the definition of the standards to the disadvantage of others in the value chain.
As new GS1 system components are developed and deployed, the overall cost of implementation needs to be considered and the GS1 System Architecture should achieve the best overall value across the entire supply chains and value networks.
Standards and solutions should be defined in a way that makes it possible to assess, practically and without ambiguity, whether or not an implementation is conformant as claimed. It will often, but not always, be desirable to include criteria for assessing conformance as part of the standard.
GS1 should assist end users to eliminate exceptions and variances from the GS1 standards in their implementations.
Consistency shall be guaranteed within and between each layer (see definition) of the GS1 System Architecture.
The GS1 standards and services development processes should include a step which confirms, in a rigorous way, that new standards, guidelines, solutions and services are consistent with the GS1 System Architecture.
Every effort should be made to deprecate and ultimately remove obsolete or redundant GS1 system components.
The GS1 System Architecture shall ensure extensibility of the standards, of the tools for implementations, and of the implementations themselves. Extensibility is a necessity for all GS1 system components in order to cater for new and/or more efficient business processes and for the expanding user community.
The GS1 System Architecture shall be forward-looking and support adaptable, flexible solutions. It shall provide for migration strategies and when possible backward compatibility (see definition).
When a non-backward compatible GS1 system component is created, it must be demonstrated to provide significant improvement and be more flexible in order to support future business requirements, some of which might not yet be known.
Standards should be developed to be applicable to the broadest possible range of contexts, (e.g. ideally global, multi-sector).
Meeting requirements that arise from a global perspective must be balanced against the need to meet local, regional or sector-specific requirements.
The GS1 system is founded on identification keys whose values are unique within their designated domains and which unambiguously identify business objects.
The principle regarding the use of the identification key classes (see definition) in GS1 standards is as follows:
1. Use of class 1 or class 2 identification keys as primary identification is mandatory for an implementation to be conformant with the GS1 System.
2. All GS1 standards, guidelines, solutions and services are designed to use class 1 identification keys as the primary identification for business objects. Class 2 identification keys might introduce restrictions or process rules that are not fully aligned with GS1 models.
3. The use of class 3 identification keys for primary identification is recognised in specific components of the GS1 system.
The goal of the GS1 system is to establish one and only one way to perform a given function in a GS1 system conformant way. Therefore, the GS1 System Architecture should avoid duplication.
When migrating to new and better ways to achieve existing functions, some form of duplication is inevitable. The impact is mitigated if these new and better ways are backward compatible (see “Forward looking”) and superseded standards are deprecated (see “Deprecation“).
A GS1 identification key is non-significant as it does not embed business information about the business object it identifies; information about the entity is instead associated with the key.
Embedding information into a key severely limits the capacity of the key space and leads to severe problems if the nature or structure of the embedded information ever needs to change.
The GS1 system shall be developed to suit open supply chains and value networks.
GS1 standards that are applied at the interfaces between organisations are defined outside the context of any particular trading relationship. This provides interoperability without the need for organisations on each side of the interface to negotiate in advance.
Standard data elements should be re-used consistently across different GS1 standards. GS1 should store, reuse and share precise core component and business definitions and their equivalent representations in the GS1 system.
To the fullest extent possible, the GS1 system and architectural components shall not require the payment of any type of royalties, fees or other considerations to third parties and shall not impose any conditions or restrictions on the use of any technologies or methods. For further reference, consult the GS1 policy on Intellectual Property.
The GS1 System Architecture is such that a user can initially use limited parts of it, use more of it later and be confident that all the parts will be fully interoperable. By allowing for continued growth, the GS1 system can be utilised effectively by the smallest of local companies and the largest of the multinational companies simultaneously.
Sustainable growth of the GS1 system both in number of users and range of standards is important and therefore the system shall be scalable. Scalability is the ability of a network or a process to handle increasing amounts of activity in a seamless manner.
GS1 services should be provided with appropriate security and GS1 standards and solutions should enable appropriate security to be built into users’ implementations. This might relate to access control, authentication, non-repudiation and so on, and apply to physical, digital and commercial security.
The GS1 system should promote simplicity and standardise interfaces to achieve easier and less costly implementation.
The GS1 System Architecture should promote technology independence and a layered approach.
The GS1 identification keys and GS1 data standards are defined in a modular way, independently of the data carrier and information sharing technology in which they are used.
The GS1 System Architecture encourages normative references to, and application guidance from ISO, ISO/IEC, UN/CEFACT, IETF and W3C. The work of standards bodies other than these five should also be considered and, if suitable, adopted.
Where appropriate, GS1 system components should be propagated through other standards bodies, thereby increasing the impact, effectiveness, adoption, and acceptance of the GS1 system globally.
Glossary of terms:
Backward compatibility
Backward compatibility is the ability to have a component of the GS1 system replace an older component, such that implementations of the newer version are able to interoperate with implementations of the previous version(s). In order to protect investments in existing implementations, changes to the GS1 system should be backward compatible where possible.
Classes of identification keys
Identification keys that are relevant in the GS1 system are divided into classes. Class 1 identification keys are administered by GS1 and fully under its control. Class 2 identification keys are those for which a portion of the GS1 identification capacity is allocated to an identification scheme administered by an external agency. Class 3 identification keys are administered and controlled outside GS1 but are supported in some parts of the GS1 System. This classification is explained in the part of the GS1 System Architecture dealing with the “Identify” layer.
Architecture layers
The GS1 System Architecture is designed on the basis of three layers (identify, capture and share) which assists in establishing a modular approach where individual components of the GS1 system can be defined and documented independently of one another.
Interoperability
Interoperability is the capability of different systems to exchange data based on a shared understanding of business processes, to read and write in compatible formats and use compatible protocols.
Change log
Log of Changes
Release |
Date of Change |
Changed By |
Summary of Change |
2.1 |
May 2012 |
A. Osborne |
Approved by GS1 General Assembly in May 2012 |
2.1.1 |
Nov 2015 |
D. Buckley |
Latest GS1 branding applied (no content changes) |
3.0 |
May 2016 |
D. Buckley |
Royalty free principle updated following General Assembly approval |
4.0 |
Jun 2020 |
H. Barthel |
Agreed by Architecture Group 22 Jan and approved by GS1 General Assembly in June 2020. |