Agenda

1. Review timeline and service specifications
2. Review, discuss and develop scenarios.

Minutes

Atendees: Andy Berner, Jim Conallen, Derry Davis, Ian Hancock, Jim Amsden, Jonathan Harclerode, Scott Bosworth, Simon Helsen and Vishy Ramaswamy

1. Reviewed minutes from last meeting.
2. Jim C. made those who did not complete their homework feel guilty.
3. Jim C. explained the timeline and overall goals of this workgroup. The main goal is to produce an initial draft of a set of specifications that a tool vendor (model repository vendor) can implement that will manage models and possibly other AM artifacts enabling them to participate in the larger Collaborative ALM. This specification is expected to work hand in hand with the other OSLC specifications, and in general will follow the same architectural principals.
   
   An initial draft of the AM team architectural direction was created off the main AM home page. It is ispired by (and shamlessly copied from) the CM teams architecure direction documents (version 1 and version 2). In practical terms Jim believes that three main types of specifications will come out of this process;
   • A common resource format/document/schema for capturing common model element information that is useful in the implementation, impact analysis and reporting scenarios. This resource does not assume any storage format of its own, but rather provides a set of defined and expected information about model elements. Jim C. started a resource schema discussion document that we can use to collaborate around off line.
   • A REST API which clients can use to access the model information and its meta information (i.e. external links). The API should follow the lead of the other workgroups and be discoverable, and leverage well defined namespaces. Due to the expected complexity of supporting generic modeling tools and their formats, it is unlikely that the initial specification will support the creation of new model resources for the various tools by generic clients, however querying for and 'picking' existing model elements is part of the API.
   • A simple query language for finding model elements given the generic and minimal common information that we have defined in the resource formats.
4. Vishy asked if there were any OSLC wide guidelines that we can follow regarding all aspects of work in this team. Jim C. mentioned that the OSLC leads have just recently brought up this topic and have commissioned a series of tasks to produce such documentation, to be consumed by all OSLC teams that Provides technical guidance on cross-domain topics. These inlcude; linking, collections, versioning, query, discovery, etc.
5. Vishy also reminded up that all the work we are doing needs to be independent of the internal storage formats used by individual tools contributing model content to be managed by AM repository services.
6. Jonathan began the scenario discussions with a diagram that shows a layered set of requirements, with directional relationships between them and a separate set of design and implementation models. ed. note: added call outs for three requirements layers based on discussions in group.
   
   In these scenarios the linkages established are used for two purposes; 1) documentation and 2) impact analysis.
   
   Jonathan said that they are able to generate human consumable documentation for many purposes including; verification with stakeholders (clients) of business processes, and business services down to the flow level, and functional specifications for implementation by the team leads. Such a scenario begins by selecting a business service, which can be expressed as a sequence like diagram detailing the flow.
   
   Links can be followed to requirements. In general the links help developers and reviewers understand what the business service really does.
7. Andy verified that in this scenario the relationships between requirements and model elements are many to many, and that in many ways this is an example of the business facade pattern. The top level requirements are directly from the customer/client, the middle layer represents specific business functionality, and the third specific technical functionality.
8. Vishy asked if in this scenario it would be possible for models to play the role of initiating requirements. In other words could models be oewn the left hand side of the diagram driving requirements in the same way that the requirements are driving the design and implementation. Jonathan first said that this type of scenario (loosely) was something they started with, but now maintain a very strict barrier between requirements and design/implementation models. So for now they are not using them that way, but that doesn't mean that this overal scenario could not support it.
9. Ian H. said that System Architect currently supports such a model. Where model elements are used to 'create' requirements in Doors.
10. Jim postulated that this might be more prelevant in the systems space where requirements can be expressed in more detailed/formal documents and models. Ian H. said it probably depends on the business. If the business documents things with models then it could happen. Andy pointed out that if we are generalizing models to include business process models then this is actually the norm for enterprises.
11. Vishy also asked how rewquirements were traced back. Jonathan said that is done by following the links up the requirements chain to the requirements at higher levels. Jonathan stated that you can not have a requirement in the lower levels without it tracing to a requirement at a higher level.
12. Vishy asked how change was dealt with, specifically when changes are introduced in either the requirements or design and implementation. Jonathan indicated that requirements in this scenario are versioned like any artifact, and that when a change is made it is part of a set that is delivered in 'unison'. They do not operate where a single change is made in a requirement and the other relevant artifacts are not addressed for another 6 mos.
13. Andy asked if all three requirements layers get back to the stakeholders (clients). Jonathan confirmed they do. The client has the option to check off on all layers of requirements, however only the technically minded clients are capable of understanding the lowest layer of requirements.
14. Jim A. commented that if what we are discussing here is represented as set of resources and links between them, that we can take different approaches to capturing it. For example we can extract the common properties and especially useful ones [making them available via the repository services].
15. Derry added that approach might just be another model. He is not concerned with how the resources and links are managed (i.e. database, XML, RDF), but is more concerned with getting the [logical] model right.
16. Jim C. as punishment for contributing asked Jim A. if he could update the wiki with what he saw as ‘abstracted common properties’ of what Jonathan presented today. This will be used as baseline as we include the next scenario and discuss it.
17. Jim A. asked Derry to present his scenario at the next meeting, where will discuss and comment on it, adding any useful content to the document Jim A. is preparing.

Homework

• Jim C. to post minutes and add to architecture direction document
• Jim A. to add a page to the wiki describing his conclusions about the process that Jonathan introduced, and distilling is architectural significant aspects.
• Derry will prepare and present another business scenario next meeting.

-- JimConallen - 20 Aug 2009