Kuali Days :: Chicago May 13-14 Evolving a New Agile SOAD Methodology May 13-14, 2008 Scott Thorne, MIT Andrew Bucior, FSU.

Kuali Days :: Chicago May 13-14

Evolving a New Agile SOAD Methodology

May 13-14, 2008

Scott Thorne, MIT

Andrew Bucior, FSU

2Kuali Days :: Chicago May 13-14


Session Objectives What is KS? Why did KS need a new approach? What is the current KS 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



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



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.”



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



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



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



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



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



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



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



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



Functional Statements - cont.



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



Conceptual Data Model - cont.



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



Swim Lane Process Models - cont.



Business Questions What questions might be asked of the module as defined? Developed by:

Pure brain-storming session Analysis of Swim Lane Process Models



Business Questions - cont.



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



Capabilities - cont.



Service Candidates Low detail in this phase

Name Quick description Representative capabilities

Identified through clustering of capabilities



Service Candidates - cont.



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)



Cross Reference Diagram - cont.



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)



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



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



Phase 2 – Examples of work products/deliverables Some are still in heavy flux

Format Approach



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”



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



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



Stack Diagrams -cont.



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



Service Descriptions - cont.



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



Message Structures - cont.



Validation work “Can we realize this use case/scenario using the services we have

now?” May take a couple forms

Sequence diagrams Pseudo-code



Validation work - cont.



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



Lessons Learned Experience Collaboration Adaptation



Questions

Kuali Days :: Chicago May 13-14 Evolving a New Agile SOAD Methodology May 13-14, 2008 Scott Thorne, MIT Andrew Bucior, FSU.

Documents

kuali days

new agile soad methodology

new approach

different goals

different institutions

different ways

whats different

current ks methodology