Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Open-Measured-Data-Management-WG/Architecture Committee"

m (Next Conference Call)
m (Documents)
Line 31: Line 31:
 
The functional and executional view on the architecture in the web client is also [[Media:2015-12-04 openMDM BMW UseCase Architecture.pdf|available]].
 
The functional and executional view on the architecture in the web client is also [[Media:2015-12-04 openMDM BMW UseCase Architecture.pdf|available]].
  
At the current stage, there also exists a presentation about [https://dev.eclipse.org/mhonarc/lists/mdmbl-dev/pdf83tlKJrayz.pdf best practices] that should be followed.
+
At the current stage, there also exists a presentation about [https://dev.eclipse.org/mhonarc/lists/mdmbl-dev/pdfcpG8tIunZe.pdf best practices] that should be followed.
  
 
== Technology Proposal Guidelines ==
 
== Technology Proposal Guidelines ==

Revision as of 04:04, 19 May 2017

Members

Speaker of the Architecture Committee: Andreas Benzing

Organization

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.

Next Conference Call

The next AC meeting will be held on May 19, 2017, 09:30 CET.

Topics:

  • TBA

Documents

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: File:Architecture-specification.zip (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.

Presentations

Meeting Minutes

Others

Back to the top