🔧BDI Maintenance and Community Contributions
1. Introduction
This page describes the BDI Change and Release Management Process for maintaining the BDI Architecture Documentation. As BDI transitions into a maintenance phase, a thorough process for change and release management is becoming increasingly important.
Both the associations that follow the BDI and the BDI itself exist in an environment subject to continuous change due to:
Legislative and regulatory changes
Technological advances
Emergence of new application areas
Previous experience and lessons learned from previous projects
Changes in business processes
Such environmental changes may call for changes in the BDI Reference Architecture. However, as these changes could impact many stakeholders, careful change management is important. The BDI Change Management and Release Management Processes are introduced for this purpose.
1.2 Scope
The Change and Release Management applies to the following assets:
The BDI Developer Portal, including example IT components provided by BDI
Explicitly out of scope are any third party IT components mentioned in the BDI Framework documentation or BDI Developer Portal. These components are subject to their own change and release management processes.
1.3 Core principles
The Change and Release Management Process must be transparent, predictable and fair. Each of these principles is discussed below.
Transparency
Transparency Principle
The Change and Release Management Process must be transparent
Statement
Everything that happens regarding (potential) changes, decisions and releases is well documented and publicly visible.
Rationale
By using a transparent process, stakeholders are expected to have a better trust in the outcome of the process and the involvement of the community & stakeholders throughout the process, resulting in wider adoption of the BDI.
Example implementation
Maintaining all RfCs and MCs in a public GitHub repository ensures that all stakeholders are able to track progress.
Predictability
Predictability
The Change and Release Management Process must be predictable
Statement
Careful planning and execution of releases and version deprecation should lead to a predictable situation for stakeholders.
Rationale
Adoption of the BDI means implementation in technical products, contracts and possibly other assets. Maintaining these assets is costly for stakeholders. A predictable version, release and version deprecation process should lead to a manageable impact of changes for stakeholders.
Example implementation
Designing and adhering to a release schedule of a certain amount of major releases per year ensures that stakeholders are able to plan the required capacity in advance.
Fairness
Fairness principle
The Change and Release Management Process must be fair
Statement
All decisions must be made carefully, respecting and weighing the interests of involved stakeholders, through a clear decision making process.
Rationale
By making sure that decisions are made carefully, stakeholders will have a better trust in the outcome of the decision making process.
Example implementation
A well-designed governance structure, incorporating defined escalation paths, ensures that stakeholders have a process to challenge decisions. This builds trust and prevents any single individual (such as the Product Owner) from having absolute, unchecked authority.
1.4 Change management process
A change can be either a Request for Change (RfC) or a Minor Change, the difference being the impact of the change to the community. An accepted RfC requires BDI-based associations to take action to remain compliant with the new BDI version, whereas Minor Changes do not. However, associations, at their discretion, can decide not to comply with the new BDI version but rather follow the old one.
1.4.1 RfCs
1.4.1.1 Process for RfCs
The following diagram describes the process for managing RfCs.
Roughly the RfC transitions through the following phases:
Identification
A stakeholder — such as the BDI Product Owner — identifies a required change or opportunity for improvement.
Registration
The stakeholder — possibly supported by the Product Owner — describes the RfC and registers it.
Discussion
The Product Owner discusses the RfC with the Expert Group. The Expert Group and Product Owner formulate an advice on the RfC for the Architecture Board.
Decision
The Architecture Board decides whether or not to start impact analysis, taking into account the advice from the Expert Group and Product Owner.
Scheduling
The Product Owner schedules the RfC for impact analysis.
Impact analysis
The Product Owner, supported by the community and the BDI organization, performs an impact analysis.
Discussion
The RfC and the impact analysis are discussed with the Expert Group. The Expert Group and Product owner formulate an advice on the RfC and the impact analysis for the Architecture Board.
Decision
The Architecture Board decides whether or not to accept the RfC and schedule it for implementation.
Implementation scheduling
The Product Owner schedules the RfC for implementation.
The result of this process is an accepted RfC, with a clearly described impact on the reference architecture.
1.4.1.2 Templates
The RfC process is supported by the following templates:
RfC Description Template [to be drafted]
RfC Impact Analysis Template [to be drafted]
The decision making process is supported by:
RfC Decision Guidelines [to be drafted]
1.4.2 Minor Changes
Minor Changes (MCs) are defined as changes in the managed assets that do not impact the community. These changes can for example be:
Spelling mistakes
Text improvements
Reordering of information
Other minor improvements
1.4.2.1 Process for Minor Changes
The following diagram describes the process for Minor Changes (MCs).
Roughly the MC transitions through the following phases:
Identification
A stakeholder identifies a potential change and notifies the Product Owner.
Description & Registration
The stakeholder registers and describes the required MC.
Decision
The Product Owner decides whether to accept or reject the MC. An MC can be rejected if it does not meet the required criteria and is more appropriately handled as an RfC.
Implementation scheduling
The Product Owner schedules the MC for implementation.
1.4.1.2 Templates
The MC process is supported by the following templates:
MC Description [to be drafted]
1.4.3 Release management
The Change Management Process results in a backlog of RfCs and MCs that require implementation. To process this this backlog efficiently, the Release Management Process was created. This process defines the procedures for selecting changes to be implemented and for consolidating those changes into releases (versions).
1.4.3.1 Release process for major versions
The following diagram describes the process for scoping and producing a major version.
The release process for major versions is as follows:
Scoping
The Product Owner selects the initial scope for the major version by selecting RfCs and MCs from the backlog. The product strategy and/or product roadmap are guidelines for selection.
Informing
The Product Owner informs stakeholders and the Expert Group and schedules the release scope as a topic for the Architecture Board agenda.
Final scoping
Based on feedback from the stakeholders, Expert Group and Architecture Board, the Product Owner selects the final release scope for the version and informs the stakeholders and Expert group about the selected scope.
Implementation
The selected RfCs and MCs are implemented in the assets, leading to a staging version for the next release.
Decision
The staging version is scheduled for discussion in the Architecture Board. The Architecture Board either decides whether the new major needs more work or whether it can be released.
Release
The major version is released.
Timing requirements
The minimum time between step 3 (final scoping) and 6 (release) must be 3 months.
In special circumstances the Product Owner can decide to follow a fast-track process in which this minimum time requirement is not applicable. The Architecture Board must approve this fast-track process.
1.4.3.2 Release process for minor releases
The following diagram describes the process for scoping and producing a minor version.
The release process for minor versions is as follows:
Scoping
The Product Owner selects the initial scope for the minor version, by selecting MCs from the backlog.
Implementation
The selected RfCs and MCs are implemented in the assets.
Releasing
The major version is released.
Informing
The Product Owner informs stakeholders about the release.
1.4.3.3 Release and version guidelines
The release schedule guidelines for releases of major versions is as follows:
Maximum release frequency: quarterly
A quarterly release may be skipped if there are no changes with potential impact on stakeholders are selected and implemented
In special circumstances the Product Owner can decide to create an extra major version release using a fast-track release process.
The release schedule guidelines for minor versions is as follows:
The Product Owner can decide to release minor versions whenever deemed necessary
Versions are numbered as follows: x.y.z.
With every major version, x or y is updated. Updates of x are reserved for major versions that touch the complete or most of the framework. Updates of y are used for other major versions.
With every minor version, z is updated.
The version deprecation process can be described as follows:
Each major version is marked as deprecated upon the release of a new major version.
During the 6-month deprecation period, the deprecated version remains available but is no longer actively maintained, except for critical security fixes if necessary.
After 6 months, the deprecated version reaches End-of-Life (EOL) and is no longer supported.
Users are encouraged to migrate to the latest major version as soon as possible to ensure continued support and compliance with the standard.
The Product Owner is responsible for organizing the Version Deprecation Process.
1.4.4 Roles and responsibilities
The following roles are recognized in the Change and Release Management processes:
Stakeholder
Description
Any party involved in BDI as a member, user, IT service provider, or in any other role.
Responsibilities
Raise RfCs and MCs
Provide input on RfCs and MCs
Support in impact analysis
Implement new versions of the BDI
Expert Group
Description
A group of experts, appointed by the Product Owner.
Responsibilities
Provide input on RfCs and MCs
Support the Product Owner in preparing advice for the Architecture Board about RfCs and impact analysis
Provide feedback on selected major version scope
Architecture Board
Description
A group of experts responsible for the BDI assets maintained with this Change and Release Management Processes.
Responsibilities
Decide on incoming RfC requests
Decide on prepared RfC impact analysis
Provide feedback on selected major version scope
Decide on implementation of a prepared major version
Product Owner
Description
Person responsible for the management of the BDI and the execution of the Change and Release Management Processes.
Responsibilities
Raise RfCs and MCs
Support stakeholders in registering and describing RfCs and MCs
Register RfCs and MCs
Organize and prepare Expert Group meetings
Organize and prepare Architecture Board meetings
Organize RfC impact analysis
Organize implementation of RfCs and MCs
Scope major and minor versions
Inform stakeholders about version scoping and process feedback
Decide on scoping and timing of minor releases
Organize version release process
Organize version deprecation process
Last updated