Skip to main content
Jump to: navigation, search

Open-Measured-Data-Management-WG/Architecture Committee


Speaker of the Architecture Committee: Stefan Ebeling


The architecture committee has a regular conference call every three weeks. The minutes are public, but participation is limited to members of the WG and invited guests. Feel free to contact the speaker of the committee to request the discussion of architecture related topics.


Architecture Specification

The latest source of the architecture specification draft is available in the MDM@WEB architecture git repository along with a proof of concept implementation.

Compiled versions are available here: (latest version).

In addition there is a documentation on how the architecture was implemented for the first components (navigator/explorer) using a rich client. Since no MDM API was available, it was implemented against a mock implementation of the API (not the final version) and test data was shown using an ATFX-Parser (thanks for Gigatronik and Christian Rechner for providing this part).

The functional and executional view on the architecture in the web client is also available.

At the current stage, there also exists a presentation about best practices that should be followed.

Technology Proposal Guidelines

Each technology proposal handed to the AC for review should contain at least the following information:

  • Proposal: The description of the proposed technology itself
  • Priotity: The priority should be specified in the according Jira ticket to allow the AC to sort upcoming decisions.
  • Lock-In/Long-Term Availability: The proposal should must a description of long-term availability of the technology including possible vendor lock-in scenarios and community changes.
  • Operations: The impact on operations must be evaluated. The information gathered from the openMDM members should be taken into account, especially the enterprise environments.
  • Driving Requiremens: The driving requirements for the proposal must be stated. If the requirements are related to the openMDM architecture, they must be illustrated using a corresponding diagram. For other requirements, an explicit description of the relation to openMDM is required.
  • Possible Alternatives: Suitable alternatives to the proposed technology must be named. An evaluation matrix of all alternatives must be provided. If no alternatives are available, the reasons for the lack of alternatives must be described, referencing previous decisions where applicable. Addtional options should be provided by community members during review.


Meeting Minutes









Back to the top