Hi Steve, all, My impression was that the requirements mentioned by you will be covered by the Documentation project: https://wiki.onap.org/pages/viewpage.action?pageId=3247185
Thus, perhaps, if we indeed create architecture subcommittee, it would be good to mention that it provides recommendations to Documentation project on what and how should be covered (e.g. flows, APIs etc.) per use cases and/or modules interactions. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:image001.png@01D2CD4A.BAD263F0] From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill Sent: Monday, May 15, 2017 12:10 AM To: Kanagaraj Manickam <kanagaraj.manic...@huawei.com>; Bob Monkman <bob.monk...@arm.com>; Christopher Donley (Chris) <christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org> Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee Hi All, @Chris, thanks for the proposal, I think it’s a good approach. I appreciate very much that its proposed to be open to all. I am responding to this email as it both brings up a few interesting aspects and proposes an alternative approach, which is to have a project for the architecture. I would like to address the proposal for a project based approach. For the complexity we have facing us going forward, we do need alignment in the architecture, however we also benefit from the projects being as autonomous as possible. It’s a balance. I feel that the committee approach, as proposed, can balance between providing guidance and holding things together while allowing at the same time the projects to own the APIs and have innovation in their own architecture, whereas I feel that an architecture project approach would take the balance towards being less advisory in nature and more authorative in nature, which in the long run could be limiting. I think it would be good that the architecture committee could recommend which projects own which interfaces/APIS, and when required, provide guidance on the capabilities of the interface (not how, the project is best position to produce that). One way to express these capabilities is in capturing the e2e informational call flows for the decided use cases. This email contains another proposal, which may actually have being a motivation for a project to have a repo for the artifacts (e.g. UML, or other). There is a point behind this, however I wonder whether we could address this in another way? BR, Steve From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam Sent: 12 May 2017 01:55 To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; Christopher Donley (Chris) <christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>; onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>> Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee IMHO, its really an important and critical team for onap community to ride in right path and to maintain the integrity of onap projects as a whole. so would like to suggest an idea to systematically handle it as below - should we consider architecture as a project, which will have ptl, committers and any contributors and importantly git repository. so that we formalize the approval process of the given change in onap architecture. - instead of ppt format, should we use uml and store it in XML in git repository for architecture diagram and use some tool automate the creation of architecture diagram from XML - as part of it, could we bring approval process for nbi and sbi of each component of architecture as well. - in addition, should integration project automate the validation of nbi and sbi of the project deliverable whether it meets the approved ones by architecture committee, who already had committed the nbi and sbi in architecture git repository in the appropriate form like one of yang, swagger, etc. interoperability will be taken care by this way. this end2end process will govern the integrity of onap architecture as a whole. and i am not sure, but it could bring opportunities to non tsc member as a committer in architecture project☺ for bringing his(er) expertise to onap. your thoughts. --- Kanagaraj M From:Bob Monkman To:Christopher Donley (Chris),onap-tsc, Date:2017-05-12 00:44:28 Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee +1 😊 Robert (Bob) Monkman Networking Software Strategy & Ecosystem Programs ARM 150 Rose Orchard Way San Jose, Ca 95134 M: +1.510.676.5490 Skype: robert.monkman From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com] Sent: Thursday, May 11, 2017 12:03 PM To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: RE: Proposal: Architecture Subcommittee Bob, I propose that it’s open to anyone, regardless of membership level (if any). Thanks, Chris From: Bob Monkman [mailto:bob.monk...@arm.com] Sent: Thursday, May 11, 2017 11:32 AM To: Christopher Donley (Chris); onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: RE: Proposal: Architecture Subcommittee Chris, TSC, Can Silver members put forth a representative to contribute to the architecture subcommittee, or will this be only available to TSC members or representatives from member companies of a certain level? This would seem to be to be a very important step for ONAP, btw. Very helpful to the success of this project. Regards, Bob Robert (Bob) Monkman Networking Software Strategy & Ecosystem Programs ARM 150 Rose Orchard Way San Jose, Ca 95134 M: +1.510.676.5490 Skype: robert.monkman From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris) Sent: Thursday, May 11, 2017 10:53 AM To: onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org> Subject: [onap-tsc] Proposal: Architecture Subcommittee Dear TSC, I'd like to propose the formation of an architecture subcommittee to develop and maintain a functional architecture for ONAP. Please see the details below. Chris • TSC subcommittee name: Architecture Subcommittee (ARC) • 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. 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
