Shared Artifact Repository - Architectural Principles

Background

• Opened during Tooling Conference Call on August 26,2010
• Goal a draft for presentation at OHT Board Meeting 9/30 or 10/1 (Dues date around 9/23)

Description from Tooling Investment Strategy (from 2009)

• Artifact Search and Select
  • Query capability to return a set of artifact data based on selected meta-data matches
  • Difference++
• User Authentication
• Artifact Management Control
  • Artifact Metatdata Manager
    • Document artifact content and relationships
    • Artifact Identity and Version-Data Manager
      • Does not do Version Management, but does know same
      • Can accept externally defined Identities or create new ones when required (next)
    • Unique Identifier Generator (OID registry ability)
  • Artifact Synchronizer++
    • Artifact Importer
      • Package Assembler
    • Artifact Exporter
      • Representation Transformer
• APIs For other services such as the dependent functions (++ above)

++ Are function that depends upon (Needs, is dying for) a SAR, but is not part thereof

Items for Consideration

Architectural Principles Underlying a Shared Artifact Repository include:

• The focus should be on the critical capabilities to register artifacts and postpone the other features that a Shared Artifact Repository enables
• Shared Artifact Repository should consider applicability of existing open source and commercial products
• Core requirements will be identified first and then those that are desirable but may be added on later to meet the more sophisticated requirements
• Identify support and configuration requirements
• Open Source software preferable, weighing the maintenance history and commitment of the community
• Requirements will be met iteratively, with multiple planned releases
• Software should be architected to easily support extensibility without disrupting initial deployments