CEN BII3 Amsterdam (I)

Tuesday, 11th February

Meeting started in the Openbare Bibliotheek Amsterdam with the roll call and presentation of  the appointed Editors, in the meeting there is people from Norway, Sweden, Iceland, Ireland, Italy, Germany, Netherlands, UK, Turkey and Catalunya.

Management Team

  • Stuart Feder – Chair
  • Jostein Fromyr – Vice chair
  • Antonia Caressa – Vice chair
  • Martin Forsberg – Post award Team leader
  • Veit Jahns – Catalogue Team leader
  • Kornelis Difjhout – Pre award Team leader
  • Natalie Muric – Notification Team leader

Editors Team

  • Georg Birgisson – Post award business process editor
  • Edmund Gray – Architecture technical editor
  • Carmen Ciciriello – Capacity building editor
  • Yildiray Kabak – Post award technical editor
  • Fred van Blommestein – Pre award business process editor
  • Oriol Bausà – Pre award technical editor

Jostein explained the overall scope of the BII deliverables, and phrased it as “The path towards more efficient procurement in Europe”.

He said that our aim is to to provide guidance on how to utilize international standards based on the EU requirements and specifications, not on creating new standards: “We do not develop syntaxes, we bind to existing syntaxes”.

BII methodology

Jostein explained the BII methodology

There is a set of technology neutral artefacts:

  • BII Profile
    • Business goals
    • Business requirements
    • Business process
    • Information Requirement Model
    • Business Rules

And some technology specific tools when binding to a specific syntax:

  • BII Syntax Binding
    • Implementation guidance
  • BII Validation Tools
    • Compliance

Pre-Award challenges

Kornelis explained the priorities and main challenges of the pre-award task team. His list of priorities cover:

  1. The reference model for the pre-award
  2. Modularity of profiles, how to combine them to implement procedures
  3. The envelope to carry e-tendering information
  4. Convergence with Xvergabe project
  5. The new contract profile

He also indicated that the aim is to provide requirements to e-SENS to start creating and driving pilots.

Post-Award challenges

Martin explained that the post-award team has to  work on the issues they have. They have already received more than 200 issues that have to be resolved.

There are also new profiles such as the punch out that have to be defined.

Catalogue challenges

Veit explained that the main challenges for the Catalogue task team are in the pre-award catalogue and how to implement them. Discussions are going on whether to use spreadsheets.

All catalogue deliverables are allocated on the pre-award editors.

Architecture challenges

Jostein listed the priorities for the architecture team:

  1. Modularity approach, how to combine profiles
  2. Customization, what do allow customers to customize
  3. Message level response, how do we allow technical responses to transactions
  4. Business document header and envelope, joint effort with pre-award and that should be aligned with the e-SENS project

Capacity Building challenges

The main challenges for the capacity building team is on the communication and on the web site maintenance. The news and events should be updated on a regular basis.

Architecture Team Meeting

Discussion on the Reference Model

To ensure consistency across the different profiles, Enterprise Architect has been used to document the ones created in BII2. The information contents has not been included, so only the business processes have been defined in BPMN. These models have to be reviewed in detail.

Using BPMN means redrawing the UML Activity Diagrams of CEN BII2.

There has been a debate on the tool and its functionalities, and whether this tool has to be used to document the profiles, the requirements and the business rules. The agreement has been not to use EA to document requirements or business rules.

Regarding the data model, the conflict with using Gefeg.fx has been identified.

More work has to be done to review and agree on tools to document the profiles and information requirement models, and the architecture team has to review the work done so far and provide input.

Capture business requirements

Martin presented the cycle to capture goals and requirements using key examples. Goals should be illustrated using key examples, and high level requirements should be derived from goals and key examples.

High level requirements have to be elaborated into information requirements, business rules or process requirements.

Discussion started on which metadata should be captured for high level requirements and information requirements? In BII2 we had an identifier, a name and a usage.

Metadata for the HLR requirements

  • Identifier
  • Requirement statement
  • Reference to goals
  • Rationale

Metadata for information requirements

  • Identifier
  • Reference to the Business term located in the vocabulary
    • Name
    • Description
  • Description of the requirement
  • Usage – Explains how this element meets the requirement
    • Legal requirement reference
  • Group – relation to concept
  • Reference to High level business requirement
  • Structuring of required business terms in a model
    • Cardinality
    • Relation to concept

Administrative data to log

  • Submitter
  • Date
  • Change comments
  • Core-discussion


  • Reusability of business terms – Terms are global, requirements are local

Discussion on Core Concepts

The team discussed on  the concept of Core. There is a definition on the Core Concept from the European MultiStakeholder Forum but it seems to be too broad or too abstract.

It was agreed that there is a need to provide input on these Core concepts and develop the CEN BII understanding on these concepts based on our experience.

Martin Forsberg will work with Edmund Gray on this deliverable.

Code List Management

Veit Jahns made a presentation on Code List Management. He elaborated on these points:

  • Question on how to maintain our code lists? The need for a new code on the Commodity Classification code list drove this question. The code list was an extendable BII code list so it should not represent a problem, but there is a need for defining how to maintain the code list.
  • Should the version of the various code systems identified at instance level? Syntaxes allow to identify the list version identifier, should this element be included in the Information Requirement Model?
  • The agency maintaining the code list should also be identified?
  • Should more documentation on the codes be provided? Basically to explain the meaning behind each code.
  • Should the provision of code lists be done in artefacts other than pdf files? Machine readable format is necessary? Genericode, SKOS, ADMS are possible options, or even all of them.

As a conclusion for the way forward, Veit will:

  • Define policies for maintenance of code lists
  • Decision on which formats to publish machine readable code lists
  • Decide on whether to take into account versions of syntaxes


Regarding the priorities for the Architecture Team, it has been agreed that the Pre-award and Post-award teams should drive the priorities for deliverables of the Architecture Team, as non delivering in the Architecture Team can delay the work in these two teams.

Post a Comment

Your email is never shared. Required fields are marked *