1 / 43

Evolving a New Agile SOAD Methodology May 13-14, 2008

Scott Thorne, MIT Andrew Bucior, FSU. Evolving a New Agile SOAD Methodology May 13-14, 2008. Evolving a New Agile SOAD Methodology. Session Objectives What is KS? Why did KS need a new approach? What is the current KS methodology?. Evolving a New Agile SOAD Methodology. Kuali Student

genero
Download Presentation

Evolving a New Agile SOAD Methodology May 13-14, 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Scott Thorne, MIT Andrew Bucior, FSU Evolving a New Agile SOAD MethodologyMay 13-14, 2008

  2. Evolving a New Agile SOAD Methodology • Session Objectives • What is KS? • Why did KS need a new approach? • What is the current KS methodology?

  3. Evolving a New Agile SOAD Methodology • Kuali Student • The product: • Next Generation Student Information System • Student-centric design • General Goals • Modularity • Flexibility • Configurability • The project: • Community-source development approach • Participation from founders/partners across North America • 5 year timeline with phased delivery

  4. Evolving a New Agile SOAD Methodology • Challenges • Multiple institutions with varying needs • Most methodologies are designed for a single set of business requirements. • SOA • People have a hard time letting go of existing techniques • Distributed teams • New Concepts/Representations of Core Concepts • Community-source approach • Scope of work • Timeframe

  5. Evolving a New Agile SOAD Methodology • Why not use a traditional methodology/approach? • What’s different? • Different goals than traditional approaches • Enable change while still maintaining some stability • How do we minimize disruptive changes • Different technology/tools • Need to integrate with existing systems at different institutions • Many institutions will need to integrate non-KS modules • Same functionality/data may be needed in multiple scenarios • “We've got the same concepts, but we need to use them in a slightly different way.”

  6. Evolving a New Agile SOAD Methodology • How do we partition the problem • Solve it in pieces • Not redo everything • Service Contracts provide a way to define that partitioning and predefine integration points • Designing from middle • Allow lower level details to be swapped • Allow re-use/participation in unforeseen ways • Minimize disruptive changes

  7. Evolving a New Agile SOAD Methodology • SOA – cont. • Loose coupling • “What's the minimum that a consumer needs to know about a provider?” • Implementations should be swappable • Need to keep contracts free of implementation details where possible • Best practice: Contract-first design • Reuse and composition • Make sure that services can be composed in different ways • Limit inadvertent assumption of context • Requires looking at service from multiple different context • awareness of all potential contexts

  8. Evolving a New Agile SOAD Methodology • Existing methodologies/approaches • DB First / Data-centric • Captures shared understanding of entities and relationships • Integration/interoperability point is at the service layer, not data layer • May not have single data representation • Each module needs independence • BDUF • Detailed picture of overall service landscape • Unable to release until analysis of entire project completed • OO • Service orientation can be seen as another layer of abstraction to object orientation • Differences in principles and goals lead to different needs/approaches • Most assume complete agreement on processes/data – don't have that

  9. Evolving a New Agile SOAD Methodology • Existing methodologies/approaches -cont. • User-centric design • Lots of useful concepts for application development • Limited value for service design • Services should be designed for any User experience • Agile • Deliverable focused, adaptation, reflection • Emphasis on working code as milestones at odds with contract-first design • Other SOA Methodologies • Service design and implementation in single step at odds with contract-first design • Concepts and goals for design and implementation may be able to be teased apart

  10. Evolving a New Agile SOAD Methodology • General concept • Need to understand the entire project's scope and relationships between modules • Untangle boundaries to allow independent adoption of modules • Once boundaries are established and general functionality determined can focus on a particular module and encompassed services • Once services are defined, can then determine specific requirements for the release • Loosely maps to the general phases of functional work • Document everything we agree on; don’t dwell on the differences

  11. Evolving a New Agile SOAD Methodology • Phase 1 (Application Architecture)‏ • Split the SIS into a set of known or expected modules • Ex. would usually expect an SIS to have an Enrollment module • Gather information about the module • Make sure that institutions are agreed conceptually as to what is in that module • Resulted in initial set of deliverables • Functional Statements • Conceptual Data Models • Swim Lane Process Models • Business Questions • Start service identification • Identify capabilities • Group into service candidates

  12. Evolving a New Agile SOAD Methodology • Phase 1 – Examples of work products/deliverables • Some items are not deliverables in conventional sense • Serve as tools to enhance understanding/analysis • Used as stepping stones to next bit of work • Note: included screenshots are not usually of most recent copies of work • Older versions chosen to attempt to show simpler examples

  13. Evolving a New Agile SOAD Methodology • Functional Statements • Initial deliverable: high-level use cases • Breadth of functionality more important than depth • Format proved too formal for rapid capture • Unnecessary detail for this phase • Switched to functional statements • Ex. “A Faculty member submits grades for Course 123.” • Lowered barrier to entry • No need for introduction to template • Similar to (but not exactly the same as)‏ • Text version of Use Case Diagrams in OOAD • User Stories in Agile

  14. Evolving a New Agile SOAD Methodology • Functional Statements - cont.

  15. Evolving a New Agile SOAD Methodology • Conceptual Data Model • Goals • Not to create DB schema • Get clarity on nouns (entities) in domain and relationships between them • Kept at relatively high level of detail • Focus on core concepts/entities • Limited use of attributes • Side-step urge to discuss representations • Limit diving into extreme detail • Important to have definition list as well • Concepts must be understood in the same way

  16. Evolving a New Agile SOAD Methodology • Conceptual Data Model - cont.

  17. Evolving a New Agile SOAD Methodology • Swim Lane Process Models • Initial Deliverables: BPM diagrams and Swim Lane Diagrams • Merged documents to Swim Lane Process Models • Should have current module as an “Actor” • Lines which cross lanes indicate service calls • Depending on modelling technique, boxes may indicate service calls • Detailed analysis of decision points has limited value in this phase • A distraction, since we want to allow for difference here • More useful during application design

  18. Evolving a New Agile SOAD Methodology • Swim Lane Process Models - cont.

  19. Evolving a New Agile SOAD Methodology • Business Questions • What questions might be asked of the module as defined? • Developed by: • Pure brain-storming session • Analysis of Swim Lane Process Models

  20. Evolving a New Agile SOAD Methodology • Business Questions - cont.

  21. Evolving a New Agile SOAD Methodology • Capabilities • Initial Deliverable: low detail service operations • Switched to descriptions of functionality • Operations unnecessary detail for this phase • Allowed increased participation • Not seen as code/technical • Developed from previous deliverables • Some operations discovered during creation of other deliverables • Close mapping between business questions and capabilities

  22. Evolving a New Agile SOAD Methodology • Capabilities - cont.

  23. Evolving a New Agile SOAD Methodology • Service Candidates • Low detail in this phase • Name • Quick description • Representative capabilities • Identified through clustering of capabilities

  24. Evolving a New Agile SOAD Methodology • Service Candidates - cont.

  25. Evolving a New Agile SOAD Methodology • Cross Reference Diagram • Analysis tool • Illustrates which items are heavily intercoupled • May indicate need to merge items or shift boundaries • May suggest potential release clustering • Goal • Attempt to minimize dependencies/interactions in grid • Important to document reasoning behind results • More important as tool for analysis than actual deliverable • Useful later for visualizing potential brittle areas • Which service or module is responsible for what (SOR)‏

  26. Evolving a New Agile SOAD Methodology • Cross Reference Diagram - cont.

  27. Evolving a New Agile SOAD Methodology • Phase 2 (Service Modeling and Contract Design)‏ • Move into module(s) decided for next release • Working from information from phase 1, look at candidates required for first modules • Determine potential overlap in functionality or concepts • Group accordingly to ensure that boundaries are worked out - “Baskets” • Split into groups to achieve efficiencies in work • Use Case Team • Data Team • Services Team • Currently in progress on LUM and common services (our first release)‏

  28. Evolving a New Agile SOAD Methodology • Phase 2 - cont. • Collect additional scenarios in greater detail • Analyze for concepts to be expressed in data • Analyze for orchestration and infrastructure needs • Document concepts and add detail to conceptual data models • Solidify service candidates • Factoring/analysis • may change number of services or scope • Convert capabilities to operations • Create secondary documentation (detailed descriptions, cross reference matrices, service specific data models)‏ • Migrate data concepts into message structures identified in operations

  29. Evolving a New Agile SOAD Methodology • Phase 2 -cont. • Test and analysis • Validate using scenarios and use cases • Multiple levels • First pass may be in the abstract • Subsequent passes may be with test cases identified for the release • Results of validation may prompt for changes to services and messages • Other feedback • Implementation team feedback • Technical limitations

  30. Evolving a New Agile SOAD Methodology • Phase 2 – Examples of work products/deliverables • Some are still in heavy flux • Format • Approach

  31. Evolving a New Agile SOAD Methodology • Scenarios/Use Cases • Extension of work from Phase 1 • Functional Statements • Swimlane Process Models • Scenarios/Narratives serve as raw data • Analysis should reveal additional requirements for services • Operations • Messages • Orchestrations/Choreography • May have multiple versions/intermediate steps/stages • Ex. May initially be collected in institution-specific jargon • Help with later institution-specific gap analysis • Would eventually require translation to “Kuali Speak”

  32. Evolving a New Agile SOAD Methodology • Conceptual Data Model • Extension of work from Phase 1 • Conceptual Data Model • Definitions of Concepts/Entities • Two primary views • First: additional detail is added from work on analysis of scenarios/use cases • Concepts included should be documented as before • Ensure common understanding of concepts and reasoning • Need to start integrating concept of Service of Record • Second: service specific view • Used to provide visual depiction of concepts directly referenced as parameters or returns in contract • Due to decreased detail, may be created from earlier work

  33. Evolving a New Agile SOAD Methodology • Stack Diagrams • Analysis tool • Used to determine potential interactions/boundaries • Can combine some elements of UML sequence diagrams • Concepts • Top: Consumers/UI/Application • Bottom: Producers/data layer • Easier to draw when looking at particular context • Same service may be both above and below another service • Particular scenario limits some shifting • May shift involved services if scenario changes

  34. Evolving a New Agile SOAD Methodology • Stack Diagrams -cont.

  35. Evolving a New Agile SOAD Methodology • Service Descriptions • Extension of work from Phase 1 • Service Candidates • Primary distinctions from earlier work • May have different scope/dependencies • Additional analysis performed on areas of overlap • Cross reference diagrams • Stack diagrams • Analysis might have revealed different boundary/interaction patterns • Much more detailed • Operations instead of Capabilities • May be adjusted multiple times • Stable before detailed application work begins • Map to Service Contracts

  36. Evolving a New Agile SOAD Methodology • Service Descriptions - cont.

  37. Evolving a New Agile SOAD Methodology • Message Structures • Derived from • Needs expressed in Service Descriptions • View of Conceptual Data Model • General goals • Minimize number of unique structures • While meeting the general contextual needs

  38. Evolving a New Agile SOAD Methodology • Message Structures - cont.

  39. Evolving a New Agile SOAD Methodology • Validation work • “Can we realize this use case/scenario using the services we have now?” • May take a couple forms • Sequence diagrams • Pseudo-code

  40. Evolving a New Agile SOAD Methodology • Validation work - cont.

  41. Evolving a New Agile SOAD Methodology • Phase 3 (Application Design)‏ • Determine requirements and specifications for the module release • More focused than effort required for service modelling and contract design • Describes what the application should do • Once requirements and specifications are collected, work can start on detailed design (UI, orchestration, etc.)‏ • More standard application development practices should apply

  42. Evolving a New Agile SOAD Methodology • Lessons Learned • Experience • Collaboration • Adaptation

  43. Evolving a New Agile SOAD Methodology • Questions

More Related