Page Operations
Browse Space
Special Meeting: Task Planning February
Agenda
| 1 | Distribution of efforts in pilot |
| 2 | Design and Implementation process and team setup |
| 3 | System Development Environment |
| 4 | Upcoming meetings |
| 5 | Messaging system concepts |
Notes
Word version of notes can be found here.
| ID | Ag. |
Type |
What? |
Who? |
Due Date |
| 1 | 1 | I | Off topic: ROCKS is tightly tied to RedHat due to its close ties to the RedHat installer. It would be a major effort to change it. | ||
| 2 | 2 | D | List of efforts on board refined with assignments, priorities and timeline. | ||
| 3 | 2 | D | The five efforts identified as main efforts for this month are: 1) OSSE, 2) Data Exchange, 3) Agent Contract Network, 4) Messaging Service, 5) Hardening Collaboration Tools. Further work will be identified for supporting the SoW and design for other efforts as needed. |
Mon 2/9 | |
| 4 | 2 | D | For the next months, the integrated development and architecture team will follow a standard 6 week iteration cycle. This cycle applies to all prototype efforts (the currently 13 identified subprojects) and to all members of the team, whether developer or architect; for instance both architects and developers participate equally in the design phase and are equally responsible for the result. The role in the team (developer, architect, manager) determines the scope of view and the expected input provided. The basic iteration pattern is the following: Design phase: 1 week Setup phase: 1 week Construction phase: 3 weeks Transition phase: 1 week The design phase is the beginning. All effort (subproject) team members identify tasks for this iteration, deliverables and success criteria, which lead to operational prototypes at the end. The architects develop domain models and designs relevant for the activities within the iteration. Design models include revisions of long view models specific for this iteration, detailed design models needed for identified tasks. A decision making process occurs in the subsequent development team meeting. Setup phase: Getting the construction started by doing necessary setup work and getting into the details, refining and completing the designs. Construction phase: Implementation, test development, testing in close collaboration of developers and architects. Architects evaluate how the short term designs fit into the overall designs for the pilot period; they go into long term view and interact with the product management on concepts. Construction includes development team testing and ends with delivery of the prototype to the architecture team for testing. Transition phase: Wrapping the prototype up. Fixing the blocker and critical issues. Developing documentation of architecture as-built. Meeting the success criteria. Subsequently follows a decision making process about the prioritization of next efforts and integration of efforts. Might lead to refocus and changes. |
||
| 5 | 2 | I | Design phase outcome: Tasks should be briefly stated, one sentence, with similar short success criteria. Domain and design models: Provide a long term view (scope pilot this year) on a coarse level. Provide short term view (this iteration): APIs, messages, interaction protocols Models include domain models and in particular design models, going down to the level of message types, interaction protocols, API models etc. Developers are expected to focus on the short term view of what can be done within one iteration with sufficient time to release it in good quality. Work on designs happens in tight collaboration of the responsible architect and developer. |
||
| 6 | 2 | I | Deliverables at the end of an iteration: Code: operational code, machine-to-machine interactions implemented in production environment Documentation: all messages defined within a conversation, as-built architecture |
||
| 7 | 2 | D | Change and refocus of activities within one iteration should be limited to small things and refinements of focus. Changes to design should be decided after the end of the iteration cycle. | ||
| 8 | 2 | I | The product (management) team is responsible for contracts and user involvement and cover high-level architecture and concepts. Architects are the pin between product team and development team. Perform specification of APIs, messaging and user interface, information model. Later will work with user interface designer. Decision of designs is a collaboration between architects and developers. Must reflect overall intent and technical reason. Development team receives messaging and API designs and advises on designs. Development team needs the knowledge of intent to make the correct design decisions during everyday programming. |
||
| 9 | 2 | AI | Develop designs for the 5 identified efforts by Monday. Present in development meeting concisely with success criteria for decision making. Have objectives, domain models, short term design models and a set of tasks and deliverables ready. Mostly get through design week this week, next week address remaining design items. |
AT, DT | Mon 2/9 |
| 10 | 2 | I | The most important artifacts across all efforts are interaction patterns. All interaction patterns should be named. We're after the detailed description of these patterns with detailed message definition etc. There might be additional external protocols and interaction patterns within the system. | ||
| 11 | 2 | I | The goal now is to start practicing the six week iteration cycle across teams. The size of the team will increase to 15 core and 20 additional FTE resources in construction of the CI. | ||
| 12 | 2 | D | After the end of iteration 2 or 3 we should schedule a system engineering workshop covering best practices, process, lessons learned, notations, SE responsibilities etc. | ||
| 13 | 3 | We need a shared code and design document environment that everyone has access to. Web based tools are too clunky for this effort. Need a file management and versioning system that enables offline availability of directory tree, such as source code, design models and documents etc. Use GIT for now. |
|||
| 14 | 3 | D | For now we use GIT for file version management. We'll develop a System Development Environment later in April after some initial experience. |
||
| 15 | 3 | AI | Provide GIT presentation (not on Monday). | Dorian | Tue 2/10 |
| 16 | 4 | I | Upcoming meetings: Messaging service: Matt needs to talk to Rabbit MQ people. A design meeting with Alex, Claudiu will happen later today. Agent network: Talk internally Wednesday 11am. Then call with Munindar. Define precisely use case for first cycle. Data Exchange: Internal discussion Wed 2pm. Hardening Collaboration Tools: Talk internally Friday in the AM. |
||
| 17 | 5 | Matthew shows the figure with Exchange Space, Exchange Point, Broker etc from the CI Infrastructure architecture as basic vision for the messaging system. To goal is to set up a federation of message brokers (each owned by one entity, domain of authority) based on AMQP. All are in a mutual client relationship with some others. By agreement, brokers join what is called the Exchange space. This forms a "layer on top of" or "cloud around" othe brokers. Application clients need not be aware of the presence of brokers and their location. They only should know of the Exchange space. (Note that AMQP clients within the applications might have some knowledge of the closest broker). Application clients connect into the Exchange Space. The client agent negotiates participation with the exchange space. They can manipulate the Exchange Space, e.g. add an Exchange Point (i.e. a topic), by interacting with the Exchange Space agent. The exchange space agent interacts with broker agents and negotiates the reification of the exchange point on the respective broker etc. Layers exist: AMQP AMQP Federation Exchange Space Exchange Point |
|||
| 18 | 5 | AI | Build domain model for AMQP 1.0 | Claudiu | Mon 2/9 |
| 19 | 5 | I | AMQP 1.0 is a broker model that can be clustered. Does not support notion of federation at the protocol level right now. We want to support the federated model right now, however. |
||
| 20 | 5 | I | Currently ESB and the first AMQP models are centralized approaches. Skype on the other hand is not. We want connections to brokers as local as possible and no centralized model. | ||
| 21 | 5 | D | Tomorrow 2pm follow up. |