Please note that the Architecture subcommittee page has moved to a new location within in this wiki.
Click on the link below to access the new location
New Location for Architecture Subcommittee wiki Page
TSC
...
Architecture Subcommittee (ARC)
Architecture subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a functional ONAP architecture, guided by principles. This functional architecture helps maintain 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, but may identify synergies across 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.
Mailing list Moderators Stephen terrill, Lingli Deng, Ramki Krishnan
...
Dublin Architecture Planning Meeting (Montreal, Oct 29-31)
JIRA project for issue prioritization: https://jira.onap.org/projects/ONAPARC/
Next Call
| Anchor | ||||
|---|---|---|---|---|
|
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
2nd week
| Anchor | ||||
|---|---|---|---|---|
|
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Followup
Items that are finished from an architecture point of view, but not delived into the the community:
...
| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Task Forces:
<DRAFT> (Maybe this should be moved lower)
The architecture sub-committee can initiate tasks forces to progress specific topics. The output of the tasks forces are always reported back into the architecture sub-committee before further progressing towards the TSC or the ONAP projects. As per the nature of the architecture sub-committee the Task Forces are advisory by nature. The creation and termination of tasks forces are clearly announced in the architecture sub-committee meetings.
The current task forces are :
...
Platform Maturity Requirements (S3P)
...
</DRAFT>
...
can be found here: ONAP Architecture TaskForces - Ongoing
Meeting Contributions:
The meeting input and conributions can be found here: ArchCom Contributions
Meeting logistics:
Recurring meetings: Tuesdays, 1400-1600 UTC (starting June 13)
Meeting Minutes:
...
The meeting minutes
...
can be found here: ONAP Archecture Meeting Notes
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
- Looking for input from the community, including EUAG
- 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, guided by principles. This functional architecture helps maintain 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.
- starting point: ONAP Architecture Evolution 05022017_v7.pptx
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, but may identify synergies across 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:
...