Architecture Management Kickoff Meeting

Date: 24 July 2009
Time: 9:00 AM Pacific, 12:00 PM Eastern, 5:00 PM UK, 6:00 PM Frankfurt, 7:00 PM Haifa
Call In Number: (emailed)
Participation request: contact JimConallen

Agenda

1. Brief introduction of participants.
2. OSLC Introduction and Architecture Management team goals
   1. Deliver a set of specifications that can be implemented by tool vendors that make AM resources accessible.
   2. Business scenario driven
   3. We are not defining or assuming any specific development processes
   4. We are not making requirements on artifact contents. We must treat the artifacts in AM as black boxes for the most part.
   5. We are not developing new languages or artifact types.
3. Explanation of the recommended process
   1. Summary of how CM team made their first deliverable
   2. Policies regarding editing of wiki
4. Discuss meeting logistics (frequency, length, times, …)
   1. Set date for next meeting/time
5. Start working

Minutes

Atendees: Jim Conallen, Dan Leroux, Maneesh Goyal, Simon Helsen, Vishy Ramaswamy, Marnie Andrews, Jin Li, Scott Bosworth, Hendra Suwanda, Ian Hancock, Steve Abrams, Srinivasan Renganatha, Alan Yeung

1. Introduction of participants
2. Jim C. presented a brief overview of the scope of the Architecture Management team.
   • Steve A. pointed out that while we can't change the specifications of things like UML, we can influence how these artifacts and resources are used in development processes.
3. Scott B. briefly discussed the OSLC, and the change management teams first year's progress
   • The OSLC (and Jazz as well) came out ofof Rational's experiences with customers trying to get a handle on their develoment processes.
   • Most don't rely on a single vendor, and are faced with the challenges of integration and making it all work.
   • The OSLC effort has recognized that there are a few pretty simple and common patterns that should be supported. Suporting these patterns can make it cheaper for vendors developing integrations, and it opens up the market for new tools and ideas.
   • The OSLC started about a year ago, and now has about 130 participants from 20+ companies.
   • The focus is on real progress on real scenarios.
   • The Change Management team started working back in Nov 2008, with Accenture, contributors from Mylyn, and various IBM Rational product teams.
     • Started as a small team
     • only a few scenarios
     • specified a REST api and formats
   • In 6 months time the team drafted a 1.0 specification with an implementation in RTC 2.0. This specification also with implementations for ClearQuest? and Telelogic change management enabled clients like Mylyn and RQM to get integrations to multiple change management tools for the price of one.
   • The next steps are to expand on the scenarios and people involved.
4. Steve A. added that when they started they expected to be focused on the design of things like work item formats, but because they took a business scenario driven approach they were led to develop things like: resource pickers and creators, discovery mechanisms, and query support.
   • The secret: focus on scenarios.
5. Scott B. said that the CM team was adaptable. They captured and dealt with integration scenarios as they popped up. They were good at scoping work for the 1.0 deliverable.
   • There were only 3-4 scenarios they worked on initially:
     1. Find and report on a defec.
     2. Fix a reported defect, and verify
     3. Find all change requests for a given context.
   • These are just your common sense scenarios.
   • Scenarios were captured as tool agnostic. Specific details about tooling were not considered.
6. The CM team divided work into 4-6 month time intervals.
7. We shifted focus to logistics. Friday meetings are not suitable to some participants (who are off on Fridays), so we agreed toshoot for Thursday meetings.
   • Since the farthest west folk are East coast US, and we have willing participants much farther east, we will try for a 10am EST time.
   • General meetings are to be every other week. Additional meetings can be arrange as necessary.
8. Begining of general discussions. Jim C. asked Derry D. and Ren to describe the architecture management relevent scenarios they practice.
9. Derry D. contributed
   • models (UML/EMF) generate code.
   • Make use patterns like MVC.
   • Not using DSLs
   • start with a "loose model" to analyze
   • get generated application (prototypes) in front of stateholders quickly to get and incorporate feedback
   • use a variety of tools (RSA, XML Spy, EMF models)
   • iterate over everything
   • no real disctinction between models used for analysis and prototype generation, and the final implementation
10. Ren added
    • use of business process models (at various levels) shown to stakeholders to verify business assumptions
    • models are imported in to RSA
      • analyzed
      • high level interfaces extracted
    • platform specific details are added to models (PSM + profile content)
    • traceability is important, but different tooling makes it difficult.
    • questions about use of asset management.
11. Derry D. added that traceability is incredibly important to him as well

Action Items

• Derry and Ren will describe in some more detail their development scenarios.
• The rest of the team will comment on them as they are developed.
• Jim will sent out invites to the next meetings (using recurring calendar inivite)

-- JimConallen - 17 Jul 2009