Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 65 Next »

TSC subcommittee name:

Architecture Subcommittee (ARC)

Mailing list Moderators Stephen terrill, Lingli Deng, Ramki Krishnan

Membership

Goals

Architecture Principles

Open Issues

Casablanca Release Architecture Planning Meeting (Vancouver)

JIRA project for issue prioritization: https://jira.onap.org/projects/ONAPARC/

Next Call

key summary type created updated due assignee reporter priority status resolution
Refresh

2nd week

key summary type created updated due assignee reporter priority status resolution
Refresh

Task Forces:

Meeting logistics:

Recurring meetings: Tuesdays, 1400-1600 UTC (starting June 13) 



Participating in ARC meetings

  • Architecture subcommittee is contribution-driven

    • People can sign up for slots on the agenda

    • We will request people to develop proposals/presentations to discuss during meetings and via email

  • Mid-release, we will work with PTLs to schedule a walk-through

TSC subcommittee purpose:

The architecture subcommittee is responsible for developing and maintaining a functional ONAP architecture. This functional architecture helps inform relationships and interaction between functional modules, which may include high level information flows between the modules supporting the use case(s) driving each release. It also helps the community with project proposals by clarifying the new project relationship with existing components.


Input / driver for the architecture decision are business objectives / goals.

Key deliverables from the architecture team are:

Committee agreed architecture principles

End state target architecture (baselined and changes are discussed and sent to TSC for approval)

Architecture evolution / transformation from current release to next release (generated for each ONAP release)

       Highlight short term architecture deviations that would be resolved in future 1-2 releases

For each project proposal, architecture team would evaluate and provide one of the following four recommendations.

1)      Proposed project advances target architecture by addressing the gaps.

2)      Proposed project is consistent with the target architecture and enhances functionality

3)      Proposed project is a slight deviation from the end state target architecture and is a short-term solution to meet urgent needs, architecture alignment will be achieved over next 1 or 2 releases

4)      Proposed project is inconsistent with the target architecture and will likely create overlapping functionality or architecture inconsistency.


The architecture subcommittee will not make decisions regarding internal functioning of projects. 

The architecture subcommittee is advisory by nature, and not authoritative. It may provide advice to projects and to the TSC, such as by providing a forum to help resolve architectural questions that may arise.

The architecture subcommittee operates on a rough consensus basis.  If the subcommittee is unable to reach consensus on what advice to offer, the subcommittee will refer the matter to the TSC or inform the project that advice cannot be rendered. 

The architecture subcommittee will consult with Projects to help drive alignment between components and with the functional architecture.

TSC subcommittee expected deliverables:

The architecture subcommittee will develop and maintain a functional architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will schedule a walk-through with each project to understand API interactions between components.

TSC subcommittee starting participants:

The architecture subcommittee is open to all interested participants, and meetings are open.


Proposer:

Chris Donley

  • No labels