The following diagram illustrates the overall Architecture Process. It shows the basic stages of a release, going from M0 (release kickoff), to M2/M3 (API Freeze) and to code delivery in M4.

...

• M4

  • ARCHITECTURE SUBCOMMITTEE M3M4 -
    
    • #A TEST CASES (Architecture) - At M4, unit testing is done where APIs and interfaces are tested. A checkpoint what was discussed at M2 and M3. The APIs could be testsed based on the designs that were tested. For example, the NBAPI may implement some actions. These actions might be CRUD operations. The team could report that some part of it was tested and some needs to be pushed to the next release.
    • #B PTL UPDATES (Architecture) - PTLs are managing S/W deliveries at Code Freeze, and testing is occurring. Feedback from the integration team. Unit testing needs to happen within the component. The pair-wise testing exposes tests the interfaces between components, reviewed at the component reviews.
    • #C COMPONENT DIAGRAM UPDATES (Architecture) - If swagger JSON files needed to be made, the links to the swagger files should be updated from their component reviews.
    • #D NEXT RELEASE ARCHITECTURE FOCUS - Discussions are happening around what the focus of the Architecture efforts for the next release are happening. For example at the end of R7 the Architecture sub-committee was discussing aligning the Platform component wiki pages, and also the next steps for the Architecture flow diagrams that were started in R4.
    • #E DOCUMENTING THE ARCHITECTURE - Documenting the architecture is an ongoing effort. Each release will open discussions about how to best document the Architecture. It helps to have a focus on a particular topic per release to make the work more manageable.
  • Use Case Engagement -
    • API - Use case teams that are impacting the APIs and thus the component swagger should also report on changes to the component pages.
  • Components (PTL) Engagement -
    • API & Component Descriptions - Updates to swagger/JSON files should be reflected in the component pages.
  • • #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include architecture portal landing page enhancements, architecture component description work, and process work. Because the teams are fully engaged trying to meeting delivery deadlines, the Architecture enhancements are fully self-contained activities within the Architecture sub-committee they can continue to evolve during M3, M4 and RCx. For example, suggestions for common templates can be discussed in this time frame. This also sets the stage for making the focus of the next release more coherent.
  • Use Case Engagement -
    • API - Use case teams that are impacting the APIs and thus the component swagger should also report on changes to the component pages.
  • Components (PTL) Engagement -
    • API & Component Descriptions - Updates to swagger/JSON files should be reflected in the component pages.

• RCx (Runtime Compliance)
  

  • ARCHITECTURE SUBCOMMITTEE at RC0/RC1/RC2 -
    
    • #A RELEASE CERTIFICATION - The API reviewed were the ones that were tested by the integration teams. The high-level requirements drive the low-level requirements. They would drive test cases. Test cases are run, if they pass and there is something that is wrong with the requirements/epics/user stories, the test cases don't change and then re-test happens. The feedback with a problem they need to make sure that problems are also notified in the architecture sub-committee.
    • #B NEXT RELEASE ARCHITECTURE FOCUS - Discussions are happening around what the focus of the Architecture efforts for the next release are happening. For example at the end of R7 the Architecture sub-committee was discussing aligning the Platform component wiki pages, and also the next steps for the Architecture flow diagrams that were started in R4.
    • #4 ARCHITECTURE ENHANCEMENTS (Architecture Base-lined) - Architecture enhancements are secondary architectural enhancements that are worked during a release. These may include architecture portal landing page enhancements, architecture component description work, and process work. Because the teams are fully engaged trying to meeting delivery deadlines, the Architecture enhancements are fully self-contained activities within the Architecture sub-committee they can continue to evolve during M3, M4 and RCx. For example, suggestions for common templates can be discussed in this time frame. This also sets the stage for making the focus of the next release more coherent.
    • 
      
  • Use Case Engagement -
    • API - Uxnent pages.
  • Components (PTL) Engagement -
    • Axions - Upd

  RCx

  • Runtime Compliance

Artifacts

• Information Model Artifact Contains

  • Classes

  • Relationships with Multiplicity

  • Important Attributes with Multiplicity 

  • Definitions

  • Data Types 

  • Feed to Data Dictionary

  • Tooling - Papyrus with GitHub

• Component Data Model Artifacts (Implementation Specific)

  • Component Data Model

    • Contains objects, attributes, & relationships (more detail than information model)

  • Mapping to Information Model

  • Feed to Data Dictionary?

• API Artifacts

  • API Model

  • Mapping to Information Model

...