Each ISB Business Data Standard is a small part of an ESCS enterprise data architecture, entitled the ISB Business Data Architecture. The architecture shows:
If you are new to the ISB standards library, then reading this page will help you understand how to use it. Access the standards.
The ISB Business Data Architecture can be applied across each sector of ESCS, ie:
Each part of the ESCS sector has unique terminology, so a standard that defines a common piece of information will inevitably use terminology that is not ‘native’ to every sector. In order to avoid an appearance of being tied to any one sector, ISB standards in these cases will use sector-neutral terminology ie terminology that is not in use in any sector.
The advantage of using sector-neutral terminology is that data collected in one sector can be used in another. The disadvantage is that each sector must become accustomed to the common terminology used for data transfer and know how to interpret the data for use. For example:
Different sectors use the words ‘pupil’, ‘learner’, ‘student’ or ‘child’ in relation to the people they deal with.
In the ISB standards you will find a standard for ‘role’ and a standard for ‘person’, but no standard for ‘pupil’ etc. You will need to use the standard for ‘role’ and the role type ‘learner’, which is the generic term adopted by ISB standards for any person engaged in or intending to engage in or having recently engaged in learning, training or study in any sector. For example:
Different sectors use the words ‘school’, ‘college’ and ‘university’ to define the role of an organisation that provides learning, training or study.
In the ISB standards you will find a standard for ‘role’ and a standard for ‘organisation’ but no standard for ‘school’ etc. You will need to use the standard for ‘role’ and the role type ‘learning opportunity provider’, which is the generic term adopted by ISB standards for any organisation (or person) that delivers opportunities for learning, training or study. For example:
Sometimes, a role can be carried out by both an organisation and person. For example, both can be parties to a contract.
Within the ISB standards, the term ‘party’ is used when information and activities can be carried out by either a person or an organisation. Where a role can only be performed by a person, then the standards refer to ‘person’. Where the role can only be performed by an organisation, then the standards refer to ‘organisation’.
ISB standards seek global optimisation to achieve the greatest benefits in total across ESCS. They are different from many other standards which define data for a specific process or type of system and in which the structure and content of such standards are optimised to that purpose. Whilst optimising the purpose, these standards lead to sub-optimal enterprises because every process or application requires its own unique optimised standards. Systems that participate in more than one process must support many different customised data exchanges.
ISB standards, on the other hand, seek to be process independent so that each piece of data is transferred in exactly the same form no matter what the purpose or context. In order for ISB standards to achieve this, each ISB standard must be:
This means that, for example, there is no ISB standard to cover:
The benefit of this approach is that three modular building-block standards are common between the two business processes in these examples, showing the generality and re-usability of the standards.
Important information held in ‘party’,’ party relationship’ and ‘party relationship role’ (such as a person’s name, date of birth, gender etc), does not have to be defined twice, once for use in the context of learning and once again in the context of employment.
When searching for standards, readers need to understand and use the common terminology.
For example, you should start from a point like the ‘enrolment’ standard and follow all of its links to pick up the necessary related standards of ‘party’, ‘party relationship’ and ‘party relationship role’.
ISB standards have a managed lifecycle and as each standard moves through its lifecycle it is allocated
Each standard has an introduction page on the website, and for each standard there is an information panel that looks like this:
Date of Standard: 25 September 2012
Decision: Approved: Recommended
Standard type: Controlled Vocabularies
Standards categories: Attendance
The ‘Decision’ field gives the status of the standard:
There are 2 stages for approved standards:
Standard types describe what sort of standard is listed. There are four standard types:
These standards relate to specific areas of the data model describing the data that underpins ESCS business. They are defined in response to a business need and captured in a business case. As they are developed, every effort is made to ensure that the BDS is capable of supporting all the ESCS business needs for the same data. BDSs define information semantics and structure in a logical way that ensures that any binding to an encoding (such as XML or CSV) will always convey the same meaning.
These support the BDSs and can take the form of flat controlled lists which provide a set of approved formatting and values to be used across the ESCS. They might also be hierarchical thesauri which contain relationships between terms, or authority files which relate specifically to names, subjects and series and can contain cross references. Once approved, all of these types are independent ISB standards in their own right.
These are issued to support ISB standards. Documents may include:
These standards specify an encoding schema (or ‘binding’) for data exchange. Technical data standards will conform to ESCS ISB business data standards (BDS).
The topic areas attempt to group those standards and controlled lists in a particular information domain of the business data architecture.
Users can either: