KSAppArchReport RevES

Kuali Student Service System Application Architecture Recommendations
February 11, 2008 Editors Rick Burnette, Florida State University Gordon Uyeda, University of British Columbia Tim Heidinger, University of California, Berkeley Joan Shao, University of California, Berkeley Dan Symonds, University of Maryland Contributors
Florida State University Bembry, John Bucior, Andy Develle, Greta Keels, Tom Martin, Tim San Joaquin Delta College Green, Melissa Jennings, Charles MacDannald, Chris Mooney, Catherine Olstad, Ralph Sea, Karen Tyson, Claire Welch, Lynn University of British Columbia Johnson, Heather Kraigher, Patti Lindsay, Audrey Nahm, Cindy Watson, Shannon Yen, Doris MIT Bradley, Betty Thorne, Scott Winerman, Seth Wright, Norm University of California, Berkeley Dew, Cathy Dudek, James Hays, Jon Kuo, Yu-Tin Lazzereschi, LaVern Metzgar, Johanna O'Brien, Thomas Schleifer, Ruth Sturm, Joyce Wilson, Alicia University of Maryland Bauder, Sarah Chowdhury, Shihan Gill, Barbara Granger, Mary Ann Kirksey, Glenn Landi, Michael Passarella George, Michael Phillips, Meridith Ryan, Angela Wu, Teddy Carnegie Mellon University Hill, Brian LaBarbera, Darlene IBM Heuchert, Robert

Table of Contents
1 2 3 EXECUTIVE SUMMARY ............................................................................................................. 5 INTRODUCTION ......................................................................................................................... 7 BUSINESS DOMAINS ................................................................................................................. 8 3.1 LEARNING UNIT MANAGEMENT (LUM) ..................................................................................... 8 3.1.1 Learning Unit (LU) Types ................................................................................................. 8 3.1.2 Canonical LU (CLU) ......................................................................................................... 9 3.1.3 LU Instance (LUI) ............................................................................................................. 9 3.1.4 Learning Objectives & Competencies ............................................................................... 9 3.1.5 LU Relationships ............................................................................................................ 10 3.1.6 Templates ...................................................................................................................... 10 3.1.7 Versioning ...................................................................................................................... 10 3.1.8 LUM Rules ..................................................................................................................... 10 3.1.9 Interactions with Other Services ..................................................................................... 10 3.1.10 Concierge Principles and Support for What-if Scenarios............................................. 11 3.2 SCHEDULING (SCH) ............................................................................................................. 11 3.2.1 Course Scheduling ......................................................................................................... 12 3.2.2 Needs Assessment ........................................................................................................ 13 3.2.3 Management of Resources ............................................................................................ 13 3.2.4 Conflict Resolution ......................................................................................................... 13 3.2.5 Exception Handling ........................................................................................................ 13 3.2.6 Concierge Principles and Support for What-if Scenarios ................................................ 14 3.3 ENROLLMENT (ENR) ............................................................................................................ 14 3.3.1 Management of Relationships ........................................................................................ 15 3.3.2 Collection and Maintenance of Learning Results ............................................................ 15 3.3.3 Learning Plan Support .................................................................................................... 16 3.3.4 Support for Communication Service ............................................................................... 17 3.3.5 Concierge Principles and Support for What-if Scenarios ................................................ 17 3.4 PROGRAM AUDIT AND EVALUATION (PA&E) .......................................................................... 18 3.4.1 Program Auditing............................................................................................................ 18 3.4.2 Progression and Evaluation ............................................................................................ 18 3.4.3 Institutional Impact Assessment ..................................................................................... 19 3.4.4 Concierge Principles and Support for What-if Scenarios: ............................................... 19 3.5 ADMISSIONS (ADMS) ........................................................................................................... 20 3.5.1 Capturing Prospective Learner Information .................................................................... 20 3.5.2 Admissions Application Forms........................................................................................ 20 3.5.3 Learner Application Submission ..................................................................................... 20 3.5.4 Admissions Evidence Gathering ..................................................................................... 21 3.5.5 Admissions Decision Making .......................................................................................... 21 3.5.6 Managing Recruitment Activities .................................................................................... 21 3.5.7 Concierge Principles and Support for What-if Scenarios: ............................................... 21 3.6 FINANCIAL AID (FA).............................................................................................................. 21 3.6.1 Managing Awards........................................................................................................... 22 3.6.2 Financial Aid Application Process ................................................................................... 22 3.6.3 Calculating Cost of Attendance and Need Analysis ........................................................ 22 3.6.4 Awarding and Packaging ................................................................................................ 23 3.6.5 Pre-disbursement Activities and Reconciliation .............................................................. 23 3.6.6 Special Cases, Loans and Work Study ........................................................................... 23
Application Architecture Recommendations

3.6.7 Concierge Principles and Support for What-if Scenarios ................................................ 23 3.7 STUDENT FINANCIALS (SFS) ................................................................................................ 24 3.7.1 Assessment and Pricing ................................................................................................. 24 3.7.2 Payment Plans and Invoicing ......................................................................................... 24 3.7.3 Payments and Commitments.......................................................................................... 25 3.7.4 Refunds and Disbursement of Funds ............................................................................. 25 3.7.5 Accounting ..................................................................................................................... 25 3.7.6 Reporting........................................................................................................................ 25 3.7.7 Concierge Principles and Support for What-if Scenarios ................................................ 25 3.8 PERSON IDENTITY (PI) ......................................................................................................... 25 3.8.1 Individual People ............................................................................................................ 26 3.8.2 Groups and Organizational Units .................................................................................... 26 3.8.3 Contact Information and Communication ........................................................................ 26 3.8.4 Kuali Identity Management (KIM) ................................................................................... 27 4 KUALI STUDENT SERVICE CANDIDATES ............................................................................. 27 4.1 4.2 4.3 4.4 5 OVERVIEW ........................................................................................................................... 27 SERVICE CANDIDATES .......................................................................................................... 27 CANDIDATE MODULE MATRIX ................................................................................................ 31 RELEASE 1 SCOPE ............................................................................................................... 32
OUTCOMES AND CONCLUSIONS .......................................................................................... 33
1 Executive Summary
The Kuali Student Functional Team is responsible for defining the functionality and design of the "next generation" student information system. The foundation of the design is a Service-Oriented Architecture (SOA) that acts as a blueprint, defining specific software services that will deliver the business processes and associated capabilities of the system. This approach underpins the development of a comprehensive services-based system where modules are loosely coupled for maximum flexibility to meet the broadest possible range of business practices and legislative environments. The purpose of the Application Architecture phase was to identify and analyze the services that cut across business domains. The phase resulted in four significant outcomes: 1. Documentation of High-level Business Requirements The high level functionality of the eight business domain areas originally defined in the Program Charter were explored and articulated. This process led to the re-definition of some domains to reflect the discovery of new functional requirements. The resulting business domains are Learning Management Unit (LUM), Scheduling (SCH), Enrollment (ENR), Program Audit and Evaluation (PA&E), Admissions (ADMS), Financial Aid (FA), Student Financials (SFS), and Person Identity (PI). An important element of this effort was to identify design elements needed to develop the Concierge, an application within Kuali Student that anticipates the needs of users and assists them in making timely decisions within the policy framework of an institution. 2. Identification of Service Candidates The business requirements defined for each business domain were broken down into descriptions of service capabilities. Common capabilities were grouped into an initial set of 33 service candidates. The service candidates will be continually tested and refined in future phases against increasingly detailed functional requirements. 3. Domain Partitioning The service candidates were analyzed and refined to clarify which services cut across business domains. A matrix was created to map dependencies between domains and services and among services. The service candidates were separated into logical groupings that will allow them to be worked on incrementally. This will help to scope future releases of Kuali Student. 4. Scoping of Services for Release 1 The results of the domain partitioning were used to identify the common service infrastructure services and Learning Management services to be examined further in the next phase of the project, Service Modeling and Contract Design for Release 1. The Application Architecture phase was completed over a seven month period following the agile development techniques and the Services-Oriented Analysis and Design (SOAD) methodology defined in the Planning Phase of the Kuali Student Project. Along the way, the team validated much of their initial thinking about the design elements, created some new design concepts, and learned a great deal about the process of collaboration. All of these are valuable project outcomes and will be fed into future design work. Specifically, Phase 1 validated that SOA is an appropriate approach for building student systems, as the group identified numerous common services that will be used in more than one domain. As well, the work confirmed that diverse

requirements from different schools can be accommodated in a common system. The team was able to map existing requirements to the application architecture as well as incorporate new innovative ideas. Additional valuable insights to the process have been captured in the Appendices for the benefit of future teams facing similar challenges.
2 Introduction
The Kuali Student Functional Team was formed in July 2007 to achieve the following three major goals of the Application Architecture phase: Documentation of High-level Business Requirements Explore and articulate the high level functionality of the eight business domain areas defined in the Program Charter (Admissions, Financial Aid, Curriculum Development, Enrollment, Scheduling, Student Financials, Degree Audit, Person Identity). Service Candidate Identification Analyze business requirements to create an initial list of possible service candidates with representative capabilities. Domain Partitioning Analyze and refine service candidates to discover cross cutting services. Map the service dependencies between domains and services and among services to meet business requirements. Separate service candidates into logical groupings that can be worked on incrementally. This will help to scope future releases of Kuali Student. Scoping of Services for Release 1 Identify service candidates that are required to support the base functionality for Release 1.
The Functional Team modified versions of existing Service Oriented Analysis and Design (SOAD) methodologies to meet the goals for this phase of the project. The resulting three-phase methodology was required to address the unique demands of a community development project involving multiple institutions. The team developed this new methodology with the support of external SOA experts over the course of seven months, four workshops and numerous virtual meetings. This methodology will continue to evolve and be evaluated at future phase milestones. The first phase of the new Kuali SOAD methodology focused on gathering business requirements. Teams comprised of 7-10 business analysts (BA) and Subject Matter Experts (SME) representing every institution gathered specific domain requirements from their home institutions prior to a 4-5 day workshop. During the workshop the domain teams brainstormed new possibilities in domain functionality and captured requirements using functional statements, conceptual data models and swim lane diagrams. The teams continued to meet virtually and refine the artifacts after the workshop. Institutional reviews and gap analyses were performed at the end of the phase. The second phase focused on the identification of service candidates and service capabilities. The business requirements from Phase 1 were decomposed into descriptions of the capabilities that would need to be accommodated by the service candidates. The capabilities were examined to find commonalities and then recomposed into an initial list of service candidates. The service candidates were then mapped to one or more of the business domains to identify which services need to be packaged into the upcoming releases. In the process of mapping candidates to domains, the service candidate list was further modified because of re-conceptualization of both services and domains. The next phase in the Kuali Student SOAD methodology reviews and refines the services and capabilities and creates the Service Contracts. The details for the Service Modeling and Service

Contract Design of the methodology will be defined, applied and refined during the upcoming Release 1 Service Modeling and Service Contract Design.
3 Business Domains
The following section articulates the main functional concepts that were discovered as a result of using the SOAD approach. The workshops were organized around traditional domains. Once the teams divorced themselves from the traditional domain-centric thinking and focused on commonality and flexibility, many new concepts emerged. For example, the traditional concept of an admissions application was extrapolated into sub-processes that were very similar among different domains and eventually lead to the concept of evidence management. Domain labels themselves changed throughout the course of the process: Degree Audit became more accurately known as Program Audit and Evaluation. Overall, the benefits of increased flexibility were highlighted in the Learning Unit and the Learning Plan areas and were used to create the service candidates found in the next section. This section provides a summary of discoveries from each of the business domains during the Application Architecture phase. It also identifies concepts that would support the Charters vision for the Concierge. Domain capabilities and high-level use cases can be found in Appendices A and C. Information about accessing conceptual data models of user requirements and swim lane diagrams for representing the relationship between business processes and the actors affecting those processes can be found in Appendix I.
3.1 Learning Unit Management (LUM)

Learning Unit (LU) is an abstract concept representing any component of learning (e.g. competency) completed as part of the student learning experience. Learning Units are the core product of the institution. They can be highly regimented and coordinated as part of a specific goal (e.g. complete first year of Law School), or they can be flexible and loosely coupled activities that support an experiential goal (e.g. attend a series of lectures and write a paper). Learning Unit Management (LUM) is the Kuali Student module for managing Learning Units that are recognized by the institution. LUM supports the management of all aspects associated with these learning experiences. This includes the creation, update, inquiry and deletion capabilities as appropriate. In addition to updating and archiving Learning Units, the module also supports the Development and Approval of new Learning Units and substantive changes to existing Learning Units. Major Levels of LUM Abstraction
3.1.1 Learning Unit (LU) Types

Learning Unit Types (LUT) provide a basic structure or template for creating an LU. Depending on the type of LU, there may be different information associated with the LU. This can be thought of as a template for creating any LU of that type. Each institution can create new LU Types as needed to accommodate new learning experiences. A starter set of LU Types (LUT) may include: Single Course (e.g. English 101) or Grouped Course (e.g. Biology 101 Lecture with Lab) Degree Program (e.g. Degree in Integrative Biology) Academic Plan (e.g. learner specific collection of academic and non-academic LU and learning objectives) 8

Exam or Test (e.g. Biology 101 Final Exam, MIT Swim Test, GMAT, CLEP) Other types of LU (e.g. Thesis, Dissertation, Co-op Work Study, Study Abroad, Independent Research, Internship, Service Learning, etc.)
3.1.2 Canonical LU (CLU)

Canonical LUs are the inventory of LUs for an institution, the collection of LUs that have been defined. These have generally been reviewed and approved through an approval process. There is a status (e.g. active, inactive, retired) associated with the "canonical" learning unit. Canonical LUs are often approved for a range of Academic Cycles. An institution's catalog may be thought of as containing the active, Canonical LU describing such LU Types as Courses and Degrees. Learners do not register for these LU as they are not specific offerings of scheduled LUs. Examples include: the course description of Calculus III a Master's degree in Business Administration
3.1.3 LU Instance (LUI)

LU Instances are the specific offering (occurrence) of a Canonical LU usually during a specific Academic Cycle (or specific dates). In some instances there may not be associated calendar dates (e.g. online courses). This type of LU can be nested depending on university needs. For most, this is the LU that is connected to a particular section. It has time/location/instructor elements. Often the LUI is tied to enrollment. Examples include: Calculus III would be listed in the class schedule under Fall 2007 with the instructor name, meeting time, and possibly a section breakdown. The requirements to earn an MBA for the cohort of learners beginning in 1950 vs. the cohort beginning in 2008. These are distinct LUIs because each cohort is associated with a distinct Academic Cycle. A specific LSAT examination. Key Concepts:
3.1.4 Learning Objectives & Competencies

A key concept within Learning Unit Management is the learning objective which can be the purpose of the LU or an independent goal that may be used to guide a learner's academic plan. Part of the stated objective for an LU might be a set of expected competencies to be achieved at the conclusion of the LU. A competency refers to an individual's demonstrated Knowledge, Skills, or Abilities (KSAs) performed to a specific standard. Competencies are observable, behavioral acts that require a combination of KSA's to execute. Competencies are impartial and measurable and not person specific. For example, you may be able either to speak French or not. Competencies can be said to be the learning objective of an LU. If a learner can demonstrate that s/he has met a particular competency, then a waiver, or exception, may be given for the LU including relevant credit as part of meeting a course or program requirement.

3.1.5 LU Relationships
The relationships between LU may include hierarchical or composition type relationships (e.g. course ABC is composed of Lecture and Labs), and lateral or horizontal type relationships (e.g. for program audit purposes, course ABC = DEF). LU can be thought of as building blocks so that a new LU can be created based on combining other existing LUs.
3.1.6 Templates
LU templates can be thought of as an iterative cascade of structure and rules as each level (LUT > CLU > LUI) is created. The LU Type provides a template for the CLU and the CLU in turn provides a more complete "template" for the LUI. At each level there are a series of rules to direct the creation of the LU.
3.1.7 Versioning
LUM supports the versioning of CLU and LUI. Versioning allows for learning units to be closed off from being offered but retained in the catalog for historical reference, and to allow for managing changes to aspects of learning units that may occur over time (e.g. prerequisite rules, description).
3.1.8 LUM Rules

Learning Unit Management supports extensive sets of rules. Rules may be associated with Learning Unit Types, Canonical Learning Units or Learning Unit Instances. These rules support Program Audit, Registration Restrictions and relationships to other Learning Units for individual learners (e.g. duplicates and equivalent learning units, transfer credit, etc.) that are related to the Enrollment module. Below is a partial list of rules supported: Registration Restriction. LUM is responsible for defining program level registration restriction rules (e.g. ENGL501 is restricted to learners in an English Major programs). Time Requirements. Meeting time requirements for the amount (frequency and duration) of contact hours required (e.g. MATH110 must have 3 contact hours per week). Equivalency. Internal courses or courses from other institutions (and other LU) can have equivalences with LUs offered by the institution. These relationships may be considered exactly the same (e.g. cross-listed or duplicate), or equivalent for specific purposes such as Program Audit but perhaps not for registration prerequisite checking. Equivalency may be defined as symmetrical (e.g. A = B and B = A) or asymmetrical (e.g. A = B but B NOT = A). Composition. These rules determine how Learning Units are made up from other LU (e.g. Course A may be composed of a minimum of 1 lecture and optionally 1 lab).
3.1.9 Interactions with Other Services

Enrollment services supports relationships between people and Learning Units or Learning Unit Instances (e.g. learners enrolled in courses/sections, instructors teaching a course/section). Scheduling services support the scheduling of resources associated with Learning Unit 10

Instances (e.g. building/room, instructors or A/V equipment). Workflow will be used at several layers of the process, including the Learning Unit development and approval processes. Student Financials related services manage the pricing, invoicing, payment options, revenue distribution for Learning Units (e.g. cost of programs and courses). Degree is a type of LU, therefore the LU defines the building blocks (such as other LU types, e.g. courses) and rules (requirements such as time limits, duplication rules, minimal GPA, etc.) to make degrees. Program Audit and Evaluation (PA&E) interprets and applies the rules.
3.1.10
Concierge Principles and Support for What-if Scenarios
Learners and potential learners will be able to explore learning objectives and options for acquiring these objectives. Learners will be able to query the institution's catalog using flexible searching utilities. Learners can examine specific learning experiences using the experiences they have completed or those they plan to complete (e.g. How would these courses that I'm interested in satisfy the requirements for an undergraduate minor?). Learners could also use the same information to run queries against all learning experiences offered by an institution to find the experiences that best fit their learning objectives.
3.2 Scheduling (SCH)

Scheduling (SCH) is the Kuali Student System module for offering LUs (e.g., courses, final exams, special events, extension) by building and publishing LU schedules and managing the resources (e.g., instructors, space, equipment) associated with that offering. Scheduling SMEs articulated a vision where users of the system would have much greater flexibility and analytic capability available to them. These new capabilities would replace the myriad of shadow systems currently required to manage the scheduling of campus resources. NOTE: during the third phase of the SOAD methodology the concept of personal calendar scheduling was introduced but not extensively explored. Scheduling processes can be distributed, centralized or a combination, including other institutions (e.g., sister campuses or Extension programs) that utilize the same space for some portion of their offering. Both supply and demand scheduling are required and most institutions use a combination of these approaches (pre-reg and post-reg) to provide the best offering of LU. Milestones can be optionally associated with various phases of the build schedule allowing the institution to manage the overall process across various stakeholders including academic departments, faculty, the scheduling office and other modules. Workflow and communication are required among stakeholders throughout the various phases of scheduling. Scheduling also relies on data from other modules including PI (Person Identity, HR), LUM (Learning Unit Management), Financials, Facilities, Program Audit and Evaluation (PA&E), and ENR (Enrollment). The twin hearts of the SCH application are powerful optimization and rules engines. The optimization engine takes into account resources, requests, preferences, priorities, etc. in order to build the "best" schedule. There must be the option to optimize different ways, e.g., instructor preferences, most LUI scheduled, highest space utilization (depends on "expected" enrollment), etc. for various rounds of refinement to the consolidated schedule. Additionally, the optimization should attempt to incorporate priority rules that reward departmental cooperation and flexibility in resolving scheduling conflicts
11

while discouraging unhelpful behaviors (e.g. late submission of scheduling data, excessive requests for exceptions, etc.). The rules engine system is the automated system through which all departmental scheduling requests must pass. Requests are categorized and matched against scheduling rules, and immediate feedback is provided to departmental users about the request acceptability. The rules engine will have an exception sub-system attached to it that allows for the modification of scheduling rules in specific instances. The rules engine will be extensive, and will include a wide variety of rules including (but not limited to) data completeness rules, authorization rules, enrollment planning, submission timing, activation, sharing & cross-listing, course cancellation, contact hours, and many others. An important point in understanding the overall role of the Scheduling Module began from the agreement that not every instantiated Learning Unit requires the association of resources managed by Scheduling. For example, an instance of an LU Type of Program (e.g. English Major) would not require a room space, a meeting time, or special equipment needs. Another example, a transfer course LU created in LUM for articulating a course taken at another institution would not need to utilize Scheduling resources.
3.2.1 Course Scheduling

Scheduling Module swim lanes (see Appendix I) document process flows associated with scheduling academic courses, final exams, and special events. Timeframes differ depending on the type of resource being scheduled, but for most institutions, the first priority is scheduling matriculated courses. Once the schedule of classes has settled down (e.g., 5th week into the term) final exams are scheduled and the schedule is opened up to special events. NOTE: Personal calendaring has not been documented in swim lanes. The typical scheduling life cycle includes six phases: Setup. Primarily a scheduling office function to Define Calendar, Import Needs Assessment, Manage/Update Resources; Collect Instructors Preferences. Request (Scenarios). Departments and sub-divisions have the opportunity to build their schedule based on the base calendar, "smart" rollover of previous year/term. They can schedule their own space and then optimize their requests for space that is controlled by the scheduling office including designated space (they usually get) and globally shared space. Consolidate. Based on an institution-defined date, departments must finalize their scheduling requests so that the scheduling office can build the consolidated master schedule. The scheduling office compares schedules from each department checking for conflicts and adherence to global rules. The scheduling office also optimizes certain sections and resolves conflicts. Fine Tune. Scheduling office publishes a "preview" schedule that can then be reviewed by departments for any final changes or additional information including the assignment of more fluid resources, e.g., TA's. Publish: Based on an institution-defined date, the scheduling office publishes schedules in a variety of formats and through a number of distribution mechanisms that can be accessed by learners.
12

Changes are expected including the addition and cancellation of LU initiated by instructors/departments and/or based on actual enrollment. Open Schedule: Based on an institution-defined date, the scheduling office works with departments to schedule final exams. The schedule is also open to special events that occur throughout the year, across terms. A number of smaller scheduling processes were also analyzed and diagrammed.
3.2.2 Needs Assessment

Needs Assessment is a critical analysis step that accounts for everything known about demand, trends, etc. in advance of building a schedule. Statistical data is needed from ENR, ADM, PA&E, LUM, and Administration (Strategic Plan, trends, quotas, etc.). The output from this effort informs the scheduling process in general or very specific ways. It is possible that an institution might want to build future schedules based on needs assessment data. These future schedules are much looser in nature and are not ready for prime time/enrollment. Obviously the closer the schedule the more solid it is.
3.2.3 Management of Resources

Management of Resources enables stakeholders to maintain space, instructors, equipment, and any other resource associated with scheduling/offering an LU. Managing/updating resources, at it's heart, is about 1) maintaining accurate inventory data and 2) coordinating with the appropriate offices on campus to ensure resources remain in useful condition. Interaction is in the form of communication and interfaces are assumed with other systems including HR, facilities, equipment and other offices (campus security, housekeeping, etc.).
3.2.4 Conflict Resolution

Conflict Resolution comes into play whenever the optimization system encounters a conflict for which it has insufficient "alternative preference" data to perform an automatic resolution. This sub-process identifies conflicts and problems, notifies all departmental stakeholders involved, makes suggestions to all stakeholders regarding possible resolutions, and then gives users the option of either accepting those suggestions or entering additional alternative scheduling preferences which are then re-run through the optimizer until an acceptable scheduling resolution (meeting preference criteria for all stakeholders) is achieved. This sub-system will incorporate functionality that rewards stakeholders for speedy responses to system requests for data. It will also reward stakeholders for their flexibility in past conflict situations with increased priorities on future requests.
3.2.5 Exception Handling

Exceptions initiate whenever a user runs afoul of the scheduling rules engine and seeks redress. This sub-process allows users to submit a request for exception to a particular scheduling rule, then runs those requests through another layer of the rules engine which both analyzes the nature of the request and the request history of the user or department to develop a limited automated
13

response. Other requests which require human review will be fed through and human users can use the sub-system to communicate with requestor to obtain additional details and context for the request before processing. All communication related to the exception issue at hand is stored/tracked in the subsystem. All request histories (and their results) are also stored by the system for future human review and/or incorporation into the rules engine. Successful results are fed back into the main scheduling flow as modified rules. Unsuccessful results feed back into the main flow by prompting the user to modify their original scheduling request.
3.2.6 Concierge Principles and Support for What-if Scenarios

SCH has a concierge function to help learners with scheduling. It starts with the identification of possible LUI (meeting learner's objectives as outlined in the Learning Plan). The next step is to see what's being offered in the upcoming term and then, incorporating the learner's personal calendar, propose a schedule. There may be options for the schedule which is passed back to Enrollment for the learner to review and approve or deny all or part of the proposed slate. What-if capabilities are key to departmental and centralized schedulers. As part of finalizing the LU offering for a particular term, academic departments run a several scenarios to tune the schedule, tweaking various optimization parameters with each iteration. Similarly, once the central scheduling office is ready to merge departmental requests into the consolidated schedule, the ability to preview results of various What-if versions facilitates creating the optimal schedule most classes for most learners meeting the most preferences for required resources.
3.3 Enrollment (ENR)

The Enrollment module is the core application in Kuali Student responsible for the management of the relationships between a person and a Learning Unit and the collection and maintenance of learning results and records of activity that consequently arise from said relationships. During the course of exploring Enrollment, a new vision emerged for an expanded Academic Plan. The new vision turned into the Kuali Student Learning Plan (LP). The LP represents a highly personalized, customizable capability that allows learners and their advisers to plan, track, and evaluate individual learning goals and outcomes over the course of their academic career. LPs place learners at the center of their own learning experience, allowing them to manage and to monitor their progress, records and information within a self-defined, contextual framework. The LP is an andragogic approach to learning, empowering learners to map, and assess their own goals, experiences, and outcomes. Through the management of relationships, this module determines whether an association can be created between a person and a Learning Unit and acts as the association repository. The Enrollment module enables the learner to create a Learning Plan, record his/her learning intentions, make selections for desired learning units (such as programs, specializations and courses), check eligibility towards these learning units and subsequently register in these learning units. An LP can also be used to pursue personal, intellectual and civic growth, graduate and professional planning, and as a tool for reflection. The Enrollment module enables a program advisor to identify cohorts of learners within a specified program so that s/he may perform academic evaluations such as
14

graduation clearance. The Enrollment module enables an instructor to identify a class list for the course s/he is teaching so that s/he may submit grades for this cohort of learners. Through the collection and maintenance of learning results (i.e., grades, evaluation decisions, academic standing etc.), this module becomes the central repository for such information. As such, it enables both the learner and the administrator to access these learning results. Instructors submit grades through this module and academic advisors evaluate and record program audit exceptions. The person-to-learning results that are stored here enable reporting. This reporting includes both individualized reports like class lists or academic transcripts and aggregated reports such as institutional enrollment management and retention reports (e.g. average time to completion, failure rates by program, demographic profile analysis etc.)
3.3.1 Management of Relationships

The Enrollment module coordinates information with various modules (such as Scheduling, Program Audit and Evaluation, Student Financials and Learning Unit Management) to determine eligibility of a learner with respect to a desired learning unit. The Enrollment module enables the learner to plan for immediate and long-term enrollment goals ensuring conflict-free scheduling and to determine academic and financial eligibility. The module also supports the management of waitlists or other means of measuring demand for learning units and allocating places when demand exceeds supply. The learner is able to check eligibility (perform what-if scenarios) by selecting various learning units and evaluating the selection against her learning intentions, academic history, course schedule etc. Once eligibility has been determined and enrollment confirmed, the relationship is then recorded in the Enrollment module. In addition to the relationship between a learner and a learning unit, the Enrollment domain records all relationships between a person (e.g. learner, provider, sponsor) and LUs and the institution. The relationship can have various types (e.g. enrolled, waitlisted, completed, planned) Learners are people who consume and experience the LU. These are learners in the broadest sense of the word which could include matriculated students, extension students, visiting scholars, researchers, corporate staff taking continuing education, conference attendees, lecture participants, etc. Providers offer the LU, conducting or facilitating the learning experience. Most commonly we understand instructors to be providers, but providers are also guest lecturers, teaching assistants, graders, readers, interpreters, proctors, etc... Sponsors administer and manage the LU. Sponsors are schools, departments and other organizations within the institution that may provide funding, approval and oversight, possibly the institutional "owners", of the LU.
3.3.2 Collection and Maintenance of Learning Results

The Enrollment module facilitates the complex dynamics surrounding the deposit and retrieval of learning results and in doing so, becomes a critical information repository of the learning result. This module enables the learner to access enrollment and grade information, the instructor to access class lists and enter grades and the administrator to access evaluation decision and record program audit exceptions. Learning result rules will be captured in LUM. However, as outlined below, different
15

learners may have different rules applied to them when taking the same LUI. LUM will need to capture these nesting/hierarchal relationship rules. The relationship identified between the person and the learning unit is invoked during the deposit and retrieval of learning results. For example, if a person is identified to have an "instructor-to-course" relationship, she may then be able to a access class list or enter grades for the course she is teaching. Alternatively, different learner types may be associated with different learning result types. For example, a learner auditing a course may be subject to a Pass/Fail grading scheme whereas a learner in an academic program taking the same course may be subject to a percentage grading scheme. In addition, the Enrollment module may also apply other features to assist the instructor when entering grades. A translation feature would enable the instructor to enter a value of "86%" which would be translated to a letter grade of A-. A class average calculation feature would enable the instructor to input grades while following a bell curve algorithm. Workflow is also tightly incorporated into the Enrollment module. For example, if a change of grade is submitted by the instructor and must be subsequently approved by the Department Head, the Enrollment module must understand the relationship between the instructor, the course and the Department Head and facilitate an approval process. Because of the repository nature of the Enrollment module, it is the steward of the official academic record. The academic record can be disseminated and displayed in a variety of ways including, but not limited to: A hard-copy official transcript An EDI transcript (T130 format or PESC/AACRAO XML) A record available on the learner or staff portal A record available in the Program Audit and Evaluation module A record available in the learner's Learning Plan
In addition to various displays of the record, the information available in the Enrollment module also facilitates aggregated reporting such as institutional enrollment management and retention reports (e.g. average time to completion, failure rates by program, demographic profile analysis etc.).
3.3.3 Learning Plan Support

The LP is most easily understood in a formal academic framework, as it assists learners in achieving institutionally defined milestones such as planning for optimal time to degree, completing the prerequisites for an English major, graduating as an Environmental Studies major, or completing a dissertation. This functionality is currently, if clumsily, available in some current student systems. As a next generation student system component, the KS LP takes this functionality a step further as it teams up with another transformational KS domain, Learning Unit Management (LUM). Together, LP & LUM partner to enable learners to pursue any objective that can be expressed as a learning unit like passing the swim test, demonstrating a competency, participating in a Service Learning experience, or completing a research internship. At its most transformational, LP will also help learners to pursue highly personal goals and objectives relevant to their educational experience, but not necessarily institutionally defined or definable. This may be because the institution does not recognize the learning activity or because the learner chooses to manage particular learning objectives independently. For example, a learner may wish to
16

leverage time on campus to pursue an interest in Jazz, an athlete may be working towards a personal best, or a learner may be planning for a career in politics. These extra-curricular avocations may not be included as part of the learner's institutionally tracked and measured learning objectives, but the learner may nonetheless want to use tools available in the KS LP to define and measure progress towards these personal learning goals. Through the LP, educators will finally be able tear down the Wizard's curtain, inviting learners to step into the control room and harness the services, tools and functionality needed to self-administrate and self-actualize their own uniquely defined learning objectives. Both institutionally sanctioned Learning Units (LUs) and personally defined learning activities co-exist in the LP, just as they co-exist in the life of the learner. The LP brings together a suite of services designed to help individual learners reach goals, objectives, and competencies. The LP serves to extend to learners, in a self-service platform, the same tools used by faculty and administration to manage the traditional curriculum. The goal of the LP is to provide a learner with the richest possible experience both inside and outside the classroom. The LP stores an individual's preferences and chosen LUs and consumes KS services expressed in Enrollment (ENR), Program Audit and Evaluation (PA&E) and Scheduling (SCH) to create a powerful tool that can be used by the LP's owner, his/her advisor, and other KS modules.
3.3.4 Support for Communication Service

The relationships identified and stored in the Enrollment module enable grouping of people into cohorts that can subsequently be used for communication. For example, an instructor may want to contact her class via email. The Enrollment module provides the cohort of learners who have a relationship to the instructor through the specified class. It is important to note that the Enrollment module will use a Communication Service to send and receive communications.

The Enrollment module communicates relationship and learning results information to all other modules (e.g. Admissions, Program Audit and Evaluation, Scheduling, Student Financials, Financial Aid, Learning Unit Management etc.) Through the interactions of the various modules, the user is provided with valuable impact assessment information so that she can make an informed decision. For example, If a learner decides to drop a course from her current course load, this action will make the learner ineligible for her current student loan. The learner is notified immediately of the consequences of this action prior to completing the action. If the learner attempts to build a relationship with a course, but is blocked for some reason, the concierge retrieves and analyzes the Learning Plan and provides several options i.e., "Based on your choice in conjunction with your Learning Plan, here are some choices you may be interested in." If the learner registers for courses located within the same geographic area, the concierge recommends a parking lot location. i.e., "We noticed you've registered in these courses and that these courses are located within the same geographic proximity, you may be interested in parking in this parking lot."
17

Individuals will use the LP to facilitate the discovery and selection of possible future actions and then track progress toward stated objectives. Rules associated with other KS modules will be exposed in the LP user experience interface, e.g. the individual will be notified that a planned spring course load is insufficient to maintain financial aid eligibility, or will be presented with a choice of courses that satisfy a specific requirement. KS modules will leverage individuals' stored LPs in their future needs assessments.
3.4 Program Audit and Evaluation (PA&E)

The Program Audit and Evaluation module will play a central role interacting with the institution's learning experiences and the Learners that utilize them to meet their educational goals. At its core, the PA&E module uses rules to relate Learning Unit Instance Results to Learning Units and Learning Plans in the context of a learner's goals and objectives. The results of these evaluations provide information and guide learner and institutional activities. The vision of this module is to be able to function beyond simply program auditing roles; it should support an increased understanding by learners of the learning experiences and outcomes they are attempting to achieve in order to provide increased value across Kuali Student.
3.4.1 Program Auditing

Requirements for the fulfillment of a Learning Unit will be obtained from LUM and used in order to support the planning of a learner's experience or to evaluate an experience's completion. An experience can consist of any Learning Unit or combination of Learning Units managed in the Learning Unit Management module. This means that PA&E will evaluate not only traditional learning experiences such as courses and programs, but any learning experience managed within the LUM module (i.e. objectives/goals, competencies, etc).
3.4.2 Progression and Evaluation

Programs often have benchmarks or milestones determining when a learner is advanced from one phase of a program to another or from year one to year two. These points will be articulated within LUM and allow the PA&E module to support the evaluation of how learners transition. Another element of how institutions track progression is by the use of summarizations of learning results such as grade point averages, credit totals, expressions of competencies, etc. These various summaries are typically related to specific components of the overall learning experience. An example of this can be seen looking at GPAs. A learner may have a GPA related to his or her degree, major, overall institutional experience, etc. PA&E collects learning result summary rules from LUM, collects learning results from the Enrollment module, determines the learning result summary, and stores that summary in Enrollment. A major role of PA&E is the evaluation of learning experiences and the results that are derived from those experiences. These results will be used to answer questions related to the determination of academic standing, academic risk, semester or commencement honors, etc. Other areas of Kuali Student and the institution use learning experiences as a means to answer questions such as those related to financial aid eligibility, program admission criteria, prerequisites, athletic eligibility, etc. This need can also be served by PA&E.
18

3.4.3 Institutional Impact Assessment
PA&E provides a powerful tool to the institution for obtaining data to support various types of decisionmaking activities. The module has a broad understanding of how learners are utilizing learning units. This understanding is broader than simply 'what' a learner has done or plans to do. The unique value of Program Audit and Evaluation is adding the extra layer of 'why' a learning experience is consumed by a learner (e.g. Five learners enrolled in Spanish I). Two of those used the course to satisfy a major requirement, one to satisfy a minor requirement, and two for a personal language acquisition learning objective). One example of a process that would benefit greatly is in the development and adjustment of curricula. PA&E will support curriculum development by providing data on how learners are using learning units. Questions that may be asked include: What programs use Course A as a major requirement? How many learners have Course B in their Learning Plan? What types of learning objectives or requirements are being served? How many learners will likely need Course C next Fall based on Learning Plan objectives and actual enrollments. What are the top 20 "most useful" courses offered by the University? (defined as usable toward the most requirements/options) What are the top 5 "most useful" courses for learners double majoring in X and Y? Which are the top 5/10 most demanded upper level courses taken outside the major for learners in major X?
3.4.4 Concierge Principles and Support for What-if Scenarios:

PA&E provides feedback to learners holistically by applying information from across Kuali Student to support learner decisions. At the earliest stages of a learner's experience, PA&E acts as a conduit helping to connect prospective learners with programs and learning experiences that best align with their academic history and objectives. This allows learners to make informed decisions on the best pathways. For example, a 1st year learner at an external institution would be able to identify the courses they have completed and query the top 10 programs that align with their objectives and first year of courses. The learner could obtain guidance on the courses that would best prepare them for admission requirements for their programs of choice and explore the impact of how different courses they plan to take would affect completion paths. By using learning unit pricing rules, PA&E will also apply projected tuition costs to the various pathways to help learners choose the program composition that best meets their fiscal requirements. PA&E provides completion information as a learner progresses through his/her experiences informing how requirements are satisfied and the requirements still left outstanding. Using optimization and degree templates, the module helps to recommend Learning Units that most efficiently meet the learner's spectrum of requirements. For example, although three courses would meet the learner's requirements and objectives, only one of them would satisfy a requirement for two majors allowing the learner to make a more efficient decision. The learner's decision making process is further supported with information to guide which of these Learning Unit Instances are available, in what time frames, and which experiences will be dependent upon the completion of other experiences (e.g. prerequisites).
19

A learner in academic difficulty planning a reduced course load in the next semester could receive the following assessment feedback: the reduced load would result in an 80% reduction in financial aid the number of credits would make it mathematically impossible to achieve the learner's goal GPA at the end of the term only 2 courses are applicable to a degree preventing the learner from being athletically eligible the reduced load would result in a time to degree change from 8 to 9 semesters
By analyzing a learner's academic history and objectives, PA&E will make learners aware of other learning experiences that align with their goals and provide suggestions based on how other learners with similar goals and backgrounds may have achieved them.
3.5 Admissions (ADMS)

The role of the Admissions module is to capture prospective learner application information, documentation and evidence and to use that information to evaluate learner admissibility for the purposes of rendering an admission decision. In the traditional interpretation, the Admissions module is used to join learners with the program (learning units) they wish to pursue. However, the module may also support admission to a different program once on campus or even organizations (such as honor societies) as the fundamental design and functional needs are very similar.
3.5.1 Capturing Prospective Learner Information

Whereas the Charter implies that Admissions starts with an application, it is impossible to have an admissions module without considering that much learner data arrives during a pre-applicant phase. The expectation is that most learners will enter into the Kuali Student System via Admissions. The Admissions domain and the Person Identity modules need to be flexible enough to process data that will arrive from many sources and in many formats. Not only should the data be maintained, but we will also need to maintain the source of data in some cases.
3.5.2 Admissions Application Forms

The assumption coming out of Phase I is that the Admissions Module must be able to accommodate the idea that each institution will have a number of different application types and forms. The expectation is that these application interfaces will be intelligent enough that each page of the application dynamically renders the questions that will capture only the necessary information. The module also will support multiple concurrent applications per learner.
3.5.3 Learner Application Submission

Promising prospective learners may be encouraged to apply for admission. The application interface should meet the needs of all the prospective learners. Once the application is submitted, the learner should be able to verify the correctness of personal information and determine the status of the application.
20

3.5.4 Admissions Evidence Gathering
We used the term "evidence" very loosely to include all the credentials and documents a learner may submit and the data about the learner and his or her credentials whether virtual or tangible. At any time in the application process, the application should be able to determine what is yet needed, and then inform the learner. Much of the evidence will be distilled down into pieces of data (e.g., a transcript is not a piece of paper, rather it is a collection of academic data that can be broken down to "Algebra 1 grade"). Whereas the scope of Kuali Student does not include a document management system, it is expected to support connections to such systems to extend evidence gathering functionality.
3.5.5 Admissions Decision Making

The expectation is that the Admissions module will allow for a rules-driven work flow that will move a learner's application through the decision process. The work flow should also support the management of the application by the Admissions Office up to and including: the generation of normative and comparative data about the learner; pooling of like applications for the purpose of evaluating eligibility for admission; choosing, modeling, or selecting the best applicants based on user-provided algorithms, and managing the notification of the learner and the learners response to various types of decisions. The module will also support application environments in which multiple decisions are required (e.g. both department and graduate school must approve for admission).
3.5.6 Managing Recruitment Activities

Whereas it is agreed that recruitment is central to the Admissions function, it is likely that many recruitment activities will be managed by CRM (customer/constituent relationship management) software, a content management solution (CMS), and scheduling software (potentially the Kuali Student Scheduling Module) for events like receptions, tour visits, etc. The relationship between recruitment and admissions is a complex one, given that information and processes central to admissions functions occur during the recruitment phase and that recruitment activity continues beyond the point at which a learner submits an application. Further discussion will occur among participating institutions to explore the scope of recruitment in Kuali Student and desired functionality.
3.5.7 Concierge Principles and Support for What-if Scenarios:

Concierge functionality will guide learners through the application process, including providing information to applicants about status updates and unresolved application steps. The concierge also will meet learners' pre-application needs, including exploring learning units that match their interests and goals, informing learners about admission requirements and processes as part of exploration process, and offering a what-if environment for learners to obtain preliminary eligibility determinations based on self-reported data. It would make sense to join the pre-application phase to the Learning Plan as the learner may be able to determine if a program is a good match for them.
3.6 Financial Aid (FA)

The Financial Aid module is the core application in Kuali Student System responsible for maintaining inventories of awards and resources 21

maintaining characteristics and needs of learners assigning awards to learners for disbursement by the Student Financials Module administering the awarding of "outside" awards (e.g. departmental and 3rd party awards) communicating information about awards and resources to other modules, third parties, learners, and other interested parties
The Financial Aid module design is based on the assumption that Financial Aid maintains a repository of financial data but is not responsible for "real money" transactions. The assumption is that Student Financials handles disbursements, deposits, and audits of learner accounts, even though a separate Institutional Financials or Foundation or Development Office (not parts of Kuali Student) may own and manage the pools of money from which aid is awarded.
3.6.1 Managing Awards

A distinction had to made to avoid purely U.S. connotations of "funds," "awards," and "packages." We defined that financial aid involved resources (Award Resources) that were representations of the funding sources that may go to a specific award (FA Award). The FA Award is typically the name of the award that is communicated to the learner. This FA Award may have many supporting Award Resources, and conversely, a large Award Resource could fund more than one Award. Finally, an Award Instance was defined to represent a specific instance of an award that was awarded for a given term for a certain monetary value. The Financial Aid Module needs to be able to manage both monetary and non-monetary "awards" within the service design. There are data attributes that are associated with these awards and resources including identification of resource types (e.g., federally funded, privately funded) and award types like scholarships and need-based aid. Additionally there are criteria for eligibility, minimum and maximum award amounts, award custodians, etc.
3.6.2 Financial Aid Application Process

The Financial Aid module has provisions for processing applications either through learner-initiated action or automatically based on predetermined eligibility for awards. As such, the U.S. government ISIR data (for example) can instantiate an application for a learner. The application allows for collection of evidence to support the application and to provide data for federal and institutional verification of eligibility. The expectation is that the evidence required to complete an application depends on the criteria needed to match learners to awards they may qualify to receive. The process also allows for the nomination and selection of learners for some awards as well as for scholarships. The expectation is that any change to learner data, academic record, or award criteria will automatically cause the application to see if any additional documentation is needed. Learners will be able to track their application process and needed documents or data via the concierge function.
3.6.3 Calculating Cost of Attendance and Need Analysis

The Financial Aid Module assumes that there will be various categories and algorithms that will determine what cost of attendance model is needed for each learner (including the condition that there is NO cost of attendance model). Because the assignment of the cost of attendance model will
22

be dynamic, any change in the learner's application data or enrollment status may change their cost of attendance. It is also recognized that this cost of attendance is actualized and refined until such time as the learner has a firm schedule of classes. Cost of attendance is crucial to the calculation of "need" for U.S. learners. Another expectation is that learners and the institution will be able perform a need analysis.
3.6.4 Awarding and Packaging

The challenge with awarding and packaging is that some awards are distributed by polling all eligible learners and then assigning the awards. Other awards come with earmarks like third-party awards and scholarships and are guaranteed in most cases pending final eligibility determination. Finally, there is a need to accommodate the fact that some awards are awarded in a specific sequence. Packaging is assumed to within certain time frames where different rules may apply (e.g., early packaging may be based on a percentage attrition), whereas later packages may be limited by the amount of money that is associated with the award. It is assumed that the model will be able to match learners with awards dynamically and that any change to the learner record could generate automatic repackaging. The module also will support awards that are assigned to learners through subjective evaluation processes and work flow, rather than rules-driven eligibility.
3.6.5 Pre-disbursement Activities and Reconciliation

It is assumed that the Financial Aid module will propose what funds will be disbursed to which learners, but the actual execution of the disbursement to the learner account will be done by the Student Financials module. Because disbursement data is largely based in Financial Aid we contend that disbursement does not require the migration of learner award package information to another system. The Financial Aid and Student Financials (SFS) modules can model the actual disbursement by executing a dry run to see if there are sufficient resources to cover all awards and also to determine if all award resources have been used. The system also will support communication among FA, SFS, and ledger systems to reconcile financial transaction and to identify discrepancies using automated processes.
3.6.6 Special Cases, Loans and Work Study

Loans and Work Study largely fit into the design of any other award in the sense that there are award criteria and specific monetary limits. However, there are some unique work flow and management needs that distinguish these and other special cases as requiring special attention. The flexibility of the proposed service orientation should be able to accommodate these nuances.

The Financial Aid module has a large need for concierge and what-if capabilities. Learners should be able to know exactly what is needed of them in terms of documentation and data at any time. Additionally, prospective learners should be able to get a meaningful prediction of what aid they may qualify for based upon desired major, anticipated academic record, and self-reported demographic and family information. Learners should also able to anticipate the impact of various actions on their
23

financial aid package, such as changing their registration or accepting a graduate fellowship. The iterative nature of the packaging process lends itself to a dynamically generated repackaging at any time. Institutional needs for what-if scenario development also will be supported. Awarding and packaging can be modeled using adjusted algorithms and rules. Award resources can be altered in a hypothetical state to model the impact of budget modifications.
3.7 Student Financials (SFS)

The Student Financials Domain design is based on a retail business model for an organization that is responsible for selling a wide variety of products and services, provided by a number of different suppliers, to a wide variety of customers. The system's reliance on rules will allow any number of Financial Domains (e.g. Tuition, Housing, Library, Food Services, Parking) to be incorporated into the SFS. The Pricing and Assessment rules, Invoicing rules, Payment Option rules and Revenue Distribution rules will reside within the Product/Service service. For example, LUM (Learning Unit Management) will support pricing information for courses and programs. The SFS will support what-if scenarios allowing learners, prospects or any interested party to determine the cost of products and services offered by the institution.
3.7.1 Assessment and Pricing

The SFS will calculate the cost of purchased or assessed items or services based on the product, the date of the purchase (e.g. late course add) and the type of customer. The SFS will also be responsible for determining whether additional Charges are to be assessed (e.g. taxes, learner levied fees) when a customer purchases a product or service. The SFS will use a series of rules to calculate a customer's price and additional assessments. These rules will be managed within the product domains and not within the SFS. Each customer will have a Financial Account for each of the enabled Financial Domains that the customer does business with. Charges will be posted to the customer's Financial Account.
3.7.2 Payment Plans and Invoicing

The SFS will calculate when payment for Charges is due based on criteria such as the customer's Payment Plans (e.g. beginning of an academic cycle, monthly), the Product or Service, or the sale (e.g. a late purchase may default to the next month). The system will allow the customer to access their Invoice and Statements data in a variety of ways. Third Party Sponsors will be able to setup contracts to pay for all or selected Charges on behalf of a customer. The sponsor will be billed for these Charges. Where appropriate, the system will support the deferment of due dates.
24

3.7.3 Payments and Commitments
The SFS will support a wide variety of payment types (e.g. credit card, eCheck, Interac Online, internet banking, financial aid) to pay for a customer's Charges. These payments will be posted to the customer's Financial Account and matched using rules to particular charges and charge types. In the case of sponsorship agreements, a commitment for payment will be logged into the customer's Financial Account until the payment is received.
3.7.4 Refunds and Disbursement of Funds

The SFS will be responsible for managing the creation of Disbursement or Refund requests. Where appropriate, a disbursement request may be automatically or manually generated to disburse money back to the customer or the sponsor. The system will also support the transfer of money between Financial Domains. The SFS may be responsible for the actual disbursement of money back to a customer or the disbursement of money may be handled by the appropriate external system (e.g. institution's Financial System, credit card company). This will be configurable using rules.
3.7.5 Accounting
The SFS will generate Journal Voucher (JV) transactions for revenue, payments, and for Accounts Payable. The JV transactions will be forward to the institution's Financial System for the posting to the General Ledger. The SFS will support the distribution of revenue across multiple accounts.
3.7.6 Reporting
While all modules will need some common service to do routine and ad hoc data mining, it is important to note that "reporting" for the purposes of SFS has an additional fundamental difference. The SFS will report, for auditing and compliance purposes, to official offices, such as the federal government. This may include basic data statistics or information on processes. This would be hooked into a "compile and send" service.

The SFS will allow customers (and prospective customers) to see the total estimated cost of a purchase before completing the purchase. The system will itemize each Item including those that will be assessed by the system. Pricing information, payment due date and payment options will be shown to the customer. The system will also allow the customer to view all discount options from late purchase, based on payment types or early payment.
3.8 Person Identity (PI)

The Person Identity module is the Kuali Student System module for managing data about individual people, collections of people, organizational units and the inter-entity relationships. The domain also
25

manages the communications between people, groups of people and organizations. Unlike the other application domains, Person Identity acts as a collection of common functionality that is referenced in each of the other domains. That leads to some abstraction which causes issues similar to those found in Learning Unit Management, though more pronounced due to more concepts and entities.
3.8.1 Individual People

Kuali Student's Person Identity module will support and manage information about people who potentially may be interested in establishing or have already established a relationship with the hosting institution. The module may multiplex with other systems such as the institution's Human Resource System for some personal information. The module will allow the creation of relationships between people. When a new person is added to Kuali Student, the module will determine the minimum amount of information required based on the type of person. Authentication It was determined that not all people who will interact with the institution using Kuali Student need to be authenticated in the system (e.g. individuals created through a test tape). Also, not all principals (i.e. authenticated entities) will be people. Some may be system processes or other services. People may have multiple principals. This will allow for different sets of permissions to be assessed to the same person based on authentication methods. Authorization Kuali Student will support the question "Can X do Y with Z?" where X = Principal, Y = Set of permissions (or role from our KIM discussions), and Z = Qualifier (or context). Authorizations will be granted to principals, not people in Kuali Student. The vast majority of authorizations within Kuali Student will require context information. There will be very few individuals with global access (particularly since some entities are heavily abstracted).
3.8.2 Groups and Organizational Units

Kuali Student's Person Identity module will support and manage data about groups of individuals, and organizational units. Groups and organizational units may be either internal or external to the hosting institution. The module will support the collection of information about the groups and organizational units. For groups, the module will support the membership of individuals and the assignment of roles with the group. The module will also allow the creation of relationships between individual people and organizational units through functions (i.e. roles). Groups and organizational units may be nested within other groups or organizational units (e.g. departments within a faculty).
3.8.3 Contact Information and Communication

The module will manage contact information to facilitate communication between the institution, individuals, groups or organizational units. A wide variety of communication options will be supported, including traditional mechanisms (e.g. email, mail, phone technologies, instant messaging, etc.), but also taking advantage of the web-based approaches to deliver information such as message boards and social networking sites (e.g. Facebook).
26

3.8.4 Kuali Identity Management (KIM)
Kuali Student is working with the Kuali Identity Management (KIM) development team in the PI arena. KIM is a new Kuali Rice component that concentrates on providing a cohesive set of identity management services for consistent re-use across the other Kuali Rice components in addition to the Kuali applications. As such, we are exploring mutual goals/needs that might be met through this partnership.
4 Kuali Student Service Candidates

4.1 Overview
The Functional Team was able to identify a preliminary list of 48 service candidates during step II of the Kuali Student SOAD methodology (Appendix D). This list was further refined to 33 service candidates. The list of service candidates and representative service capabilities (Appendix B) reflects the knowledge gained during the duration of the Application Architecture phase. Service Candidate definition will continue to evolve and service candidates will transition to finalized services and contracts in subsequent phases of the project.
4.2 Service Candidates

Services marked with an asterisk * were identified in SOAD Step II only. Services marked with [R1] will be included in Release One application. Additional analysis in subsequent phases of the project may dramatically change both the factoring and scope of the candidates listed below.
3rd Party Sponsorship Service* - This service manages the "contract" between a Customer and a Third Party who agrees to pay for some or all of the Customer's Charges. Accounting Service* - This service is responsible for creating Journal Voucher (JV) transactions to support Accounts Payable and Accounts Receivable transactions for the Student Financials services. Admissions Service* - This service manages the admissions process. This service may exist only as a convenience layer to functionality within other services (Person to LU, Workflow, Evidence, etc.). Aid Award Service - This service manages the connection of recipients to awards and the standard Financial Aid package concept. Application Service* - This service manages the catalog of applications at the university. This service may not exist in a general form. Authentication Service [R1] - This service establishes identity only. It may also provide a mapping from the identity "Principal" to the original entity (typically a person or machine process).
27

Authorization Service [R1] - This service manages the maintenance, auditing and checking of authorizations. Award Resources Service - This service manages the catalog of award resource information. Communication Service [R1] - This service sends and manages messages. Contact Service [R1] - This service manages of contact information for people or organizations, such as addresses, and user preferences in certain contexts. Dictionary Service [R1] - This service manages information about field names and types, including other metadata such as field length and restricted values. Decisions Service* - This service provides capabilities to return decisions based around the application of one or more rulesets. A general decisions service may not exist, though there may be individual services designed around particular decisions. Disbursement Service* - The service is responsible for validating a request for the disbursement of funds either back to the Customer or the 3rd Party Sponsor who made payments on behalf of a Customer, or to transfer funds from one Financial Account to another (e.g. Tuition account to the customer's Housing account). The actual disbursement of $s or transfer of $s from one Financial Domain to another (e.g. Tuition to Housing) will not be performed by this service. Enrollment Service - See Person to Learning Unit Service. Evidence Service [R1] - This service manages images of documents and how facts are derived and linked to a record. Exception Management Service* - This service manages exceptions to rules where individual requirements are overridden. Financial Account Service - The Financial Account service would support the validation, creation and update of a Financial Account through the posting of Charges and Payments/Commitments. Formatting and Display Service (became User Preference Service) - This service manages formatting and display preferences for a given user. This service may be changed into a general user preferences service. Group Service [R1] - This service manages groups consisting of Principals and other Groups. Hierarchy Service - This service provides capabilities related to the management of hierarchical relationships. Id Service - The purpose of an Id service is to generate unique Ids, and maps Ids. It becomes important when integrating external identifier systems in a local context. Invoicing Service* - This service is responsible for determining when Payment for an Item is due.
28

Learning Objectives Service - This service manages the taxonomy of Learning Objectives and how they are related to one another. Learning Plan Service* - This service manages learner objectives, preferences, aspirations and plans. This service may exist only as a convenience layer to functionality within other services (Person to LU, Person to Learning Objective, Scenario, etc.). Learning Results Service - This service manages the catalog of Learning Results. Learning Unit Service [R1] - This service manages the catalog of Learning Unit Types, Canonical Learning Units and Learning Unit Instances. Location Service* - This service provides capabilities for mapping a campus address to a coordinate system and/or finding the distance between two points. This service may not be necessary. Logging Service [R1] - The Logging service allows for logging of both system/application and business events. Milestone Service - This service defines milestone dates (e.g. first day of class, grades due date). Other milestones may be relative and based on a window with a start date (e.g. online class must be completed within 6 months of registration). Optimization Service* - This service provides capabilities to optimize results based on some criteria. This service can be seen as a special case of decisions and likely does not exist. Organization Service [R1] - This service manages the catalog of organizations. Payment Plan Service* - The Customer's Payment Plan determines the schedule for which the Customer will make payment. Payment Service - This service provides capabilities to create and apply payments. Person Service [R1] - This service provides capabilities to create, update, and find people. This service assigns person identifiers and manages the resolution of duplicate identities (includes the ability to "merge" records). This service allows for the reading or updating of basic person information. Person to Learning Objectives Service * - This service manages the relationships between people and Learning Objectives. Person to Learning Unit Service (became Enrollment Service)- This service manages the relationship between a person (e.g. learner, provider, sponsor) and LUs. Pricing Service - This service provides capabilities to be able to determine the price of a given "product" or set of products. This may include associated taxes and fees. This service may be merged with the Product Service. Product Service - This service provides information on "products" recognized by SFS and acts as an integration point for information from other business domains.
29

Program Audit Service - This service evaluates an academic record against rules and reports progress. Relationship Service [R1] - This service manages the connection between a person and another entity (typically, person or organization). Resource Service - This service manages the catalog of resources (e.g. rooms, equipment, professors). Results Service* - This service manages the results of engaging with an LUI for both learners and providers. This service may be merged with the Person to LU Service. Rules Service [R1] - This service manages the storage and retrieval of rules and rulesets as well as providing natural language expressions. Scenario Service - This service saves a snapshot of schedule outcomes for selected assumption set. This includes the ability to save scenarios based on different criteria and optimization objectives (e.g., don't worry about space in this schedule creation, optimize based on provider preferences, etc.). This service will likely be changed to be more general, allowing for usage outside of the scheduling domain. Scheduling Service - This service encompasses three main areas of capabilities : managing institutional calendars (campus-wide, departmental, terms, etc.), managing personal calendars (learners, instructors, etc.), and managing time tables or the actual scheduling of resources to create the institution's schedule of LUs. Status Service - This service manages the status of a learner, which may stem from other domains or outside systems. Survey Service* - This service would manage all aspects around the creation, distribution and collection of survey results. The service could be used in the collection of feedback on LUs that may be required a part of the LU approval process and the evaluation of LUIs (e.g. learner feedback). A general survey service may not exist. Time Cycle Management Service* - This service manages the various time cycles (e.g. academic cycles, scheduling periods, fiscal year cycles and calendar years) that will be referenced by Kuali Student and their relationships. This service may not exist or may be merged with one or more services related to the scheduling domain. Translation Service [R1] - This service manages the translation of information from one form to another (ex. "corn" = "maize"). User Preferences Service - See Formatting and Display Service. Workflow Service [R1] - This service manages the definition, configuration and control of business processes where human intervention is needed. This service determines the next potential steps in a process, manages work queues, and monitors status of particular work items.
30
Kuali Student Service System Application Architecture Recommendations 4.3 Candidate Module Matrix
The Candidate Module Cross Reference Matrix identifies the Service Candidates that are associated with each of the Program Charters Business Domains. The primary purpose of the Candidate Module Matrix is to provide a list of possible services and their relationships to the business domains at a particular point in time. In this phase, the dependencies were based on a very high level analysis that started with domain capabilities which were then aggregated into service candidates. The matrix serves as a vehicle for analysis and discussion. Subsequent analysis may dramatically alter the definition and/or scope of the service candidates and capabilities, which in turn may alter their relationships to the business domains. There are two types of relationships that are considered Direct Dependencies (flagged with X). Dependencies of the first type are those that are called directly by the domain that is the producer of the service (e.g. Pricing and Payment services owned by Student Financials). The second type supports relationships that are created where two domains intersect (e.g. Learning Unit Management is provider of the Product Service which is consumed by Student Financials). Candidate Module Cross Reference Matrix (Services in bold with [R1] are included in the Release One application)
Service Candidate Aid Award Authentication [R1] Authorization [R1] Award Resources Communication [R1] Contact [R1] Dictionary [R1] Enrollment Service Evidence [R1] Financial Account Group [R1] Hierarchy Id Learning Objective Learning Results Learning Unit Service [R1] Logging [R1] Milestone Organization [R1] Payment Person [R1] Pricing Product ENR X X X X X O X X O ? O O O O X X X X ? ? X X X LUM O X X O X ? X ? O X O X O X X X X O X X X X X SCH O X X O X ? X X O O O O O O O X X X X O X ? ? PAE ? X X O X O O X O O O O O O X X ? O ? O X O O PI O X X O X X X O X O X X O O O O X ? X O X O O FA X X X X X X X ? X X O O O O X ? X X ? X X O O SFS ? X X ? X X X ? O X O ? O O O ? X X X X X X X ADMS X X X X X X X X X ? O O O O X X X X ? ? X X X
31

Program Audit Relationship [R1] Resource Rules [R1] Scenario Scheduling Status Translation [R1] User Preferences Workflow [R1] X X X X X X X X O X O ? X X X ? O X O X O ? X X X X O X O X X O O X X ? O O O X O X O X X ? O X O X O X X X X ? X X O X O X X X X ? X X O X X X X X X X X X O X
Key
Value Description X O ? Directly dependent upon the service. Not directly dependent upon the service. Functionality within service may be used in the module, though it is at least one step away in each case (through another service). There are still questions as to if the dependencies present are direct or indirect.
4.4 Release 1 Scope

To determine which service candidates require further analysis and design for Release 1, the team reviewed the matrix looking for service candidates that were required to support the base functionality for both Person Identity and Learning Unit Management. Other service candidates may be flagged as Direct Dependencies in the matrix (e.g. Product service for LUM) but are not required to support the basic functionality of the release. These services will be stubbed out or bookmarked in Release 1 and will be reviewed later when appropriate (i.e. when Student Financials is scheduled for implementation). The team did not attempt to scope subsequent releases because the service candidates and capabilities are still in a preliminary state and they are expected to change as the analysis progresses. This Just-In-Time agile principle is very relevant to this phase of the project. The Service Modeling team will be going through each of the dependencies as one of the early deliverables of the Service Modeling phase. This analysis will help to firm up the services and the dependencies. The order that the domains are packaged for release will also have an impact on which services are included in these upcoming releases. The following list of service candidates is planned for further analysis during the R1 Service Modeling and Contract Design phase of the project: 1. Authentication Service - This service establishes identity only. It may also provide a mapping from the identity "Principal" to the original entity (typically a person or machine process). 2. Authorization Service - This service manages the maintenance, auditing and checking of authorizations. 3. Communication Service - This service sends and manages messages.
32

4. Contact Service - This service manages of contact information for people or organizations, such as addresses, and user preferences in certain contexts. 5. Dictionary Service - This service manages information about field names and types, including other metadata such as field length and restricted values. 6. Evidence Service - This service manages images of documents and how facts are derived and linked to a record. 7. Group Service - This service manages groups consisting of Principals and other Groups. 8. Learning Unit Service - This service manages the catalog of Learning Unit Types, Canonical Learning Units and Learning Unit Instances. 9. Logging Service - The Logging service allows for logging of both system/application and business events. 10. Organization Service - This service manages the catalog of organizations. 11. Person Service - This service provides capabilities to create, update, and find people. This service assigns person identifiers and manages the resolution of duplicate identities (includes the ability to "merge" records). This service allows for the reading or updating of basic person information. 12. Relationship Service - This service manages the connection between a person and another entity (typically, person or organization). 13. Rules Service - This service manages the storage and retrieval of rules and rulesets as well as providing natural language expressions. 14. Translation Service - This service manages the translation of information from one form to another (ex. "corn" = "maize"). 15. Workflow Service - This service manages the definition, configuration and control of business processes where human intervention is needed. This service determines the next potential steps in a process, manages work queues, and monitors status of particular work items.
5 Outcomes and Conclusions

Services Oriented Architecture as a means of design brought a new set of principles and new ways of thinking about how functional goals are achieved in an enterprise student services system. Applying these concepts resulted in the achievement of the primary objectives of the Application Architecture phase and has reaffirmed the design goals of reusability, flexibility, and innovation. Documentation of High-level Business Requirements The team successfully documented the broad layer of functionality that will be supported across the core domains of Kuali Student from the perspective of multiple institutions. These activities allowed for agreement on the range of that functionality and provided the foundation for the identification of services and the partitioning of domains.
33

Service Candidate Identification Using the lens of SOA, an initial set of 33 service candidates was identified. These services were developed from a representative sample of capabilities created from the teams high-level investigation of business domain requirements. The service candidates will be continually tested and refined in subsequent phases using increasingly detailed functional requirements. Domain Partitioning It was important to separate the services into domains that can be worked on incrementally. The team accomplished this by examining the high level functional scope of Kuali Student business requirements, and analyzing that functionality for redundancy and reusability across the scope of domains. These domains were then reformed based on service functionality. This has allowed for the identification of the common infrastructure services and Learning Unit Management services which define the body of work for the next phase. Scoping of Services for Release 1 The domain partitioning work has allowed for the identification of the common infrastructure services and Learning Unit Management services which define the body of work for the next phase. These service candidates will be reviewed in the next phase of the project. Applying SOAD in a community development project which involved multiple institutions presented unique challenges. This was primarily due to the lack of a pre-existing roadmap. The team successfully developed a methodology with the support of external SOA experts to complete this phase of the project and develop the approach that will be used in the next phases of Service Modeling and Service Contract Design. This approach will continue to be evaluated at future phase milestones SOA concepts and the modeling methodologies were somewhat abstract and unfamiliar to most of the team. That combined with the need to experience how the refined methodologies would impact stages of work in the project resulted in some challenging workshop starts. It took the team time to get up to speed on what was desired and how it should be represented. There is a learning and discovery element to this process that will need to be accommodated in our future planning. SOA principles and the concept of Concierge functionality as part of student information systems led to major re-conceptualizations of the domains and their functionality. This was an important outcome of the Application Architecture phase of work. The overall goal of this project is not to replace the functionality that currently exists in higher education, but to envision new and transformational ways of doing things. The SOA lens allowed us to recognize that Degree Audit was a broader process and was therefore renamed Program Audit and Evaluation. The domain team realized that Program Audit sat strategically between the Learning Units (e.g., major, degree program, courses, competencies) and the learner. Thus, rather than being limited to a graduation check from a functional perspective, it was re-conceived as mechanism for applying rules that affect how Learning Units are composed and completed to meet the objectives of the learner. Similarly, the Learning Plan concept was defined as more than a curricular planning tool, but rather a complete mechanism for matching curricular and extra-curricular activities to the stated or proposed goals of a given learner. Finally, the Learning Unit construct came to represent more than what was proposed in the charter. Coincidentally, the simplicity of this construct actually provides institutions with much greater flexibility
34

in determining a learner's success in obtaining their educational objectives. The conceptualization of the Learning Unit accommodates the traditional notion of determining degree eligibility by passing a requisite number of prescribed courses, but institutions could also redefine a degree as a collection of competencies that may be captured in the more granular learning units that comprise a course or the competency could be earned based on experiences in several courses. Collaboration and cooperation amongst institutions has been very positive. In bringing together the views and processes from six institutions, we've discovered many more similarities than differences. Although distance between institutions limits the ability meet in person frequently, the team has become increasingly comfortable and successful with the technology tools to support virtual collaboration. The work done to this point confirms many of our expectations and the reaction of the team is a sense of excitement that the Kuali Student Systems will be a redefining event. The separation of the data layer from the workflow and rules layer appears in principle to be the correct plan. It is presumed that this structural organization will allow for great flexibility in configuring the rules and workflow that affect data. However, that increased flexibility may create a challenge if the orchestration of services isn't tight enough. Similarly, the breaking down of silos is certain to lead to issues of who actually owns the data. Heretofore, SIS solutions have been mostly siloed into domains, where the owner of each domain is the data custodian for their domain. Now there may need to be an institutional data custodian who not only determines who "owns" data but also who owns the rules and workflow that affect the creation and updating of data. Finally, the Service Candidate Matrix identified direct dependencies in several domains for most of the services. Whereas this is evidence supporting the applicability of SOA to SIS, the graying of the lines between the historical silos, may make it harder to develop them in a truly modular fashion. The ability to deploy Kuali Student one module at a time may be restricted if it is determined that the domain modules are highly interdependent. One challenge of the service design phase will be to determine if the connections between the various Kuali modules can be orchestrated with well-defined service connectors that allow each module to operate independent of the design of the adjacent modules. The clear definition of services on the boundaries of each domain will allow institutions to adopt Kuali Student for most of their SIS needs while allowing them to integrate with their existing Financial Aid solution, for example. In summary, the first phase laid the foundation for the ultimate success of the Kuali Student System. The next phase will be a very important test of our assumptions thus far. As the services are better defined, the logical clustering of services and the dependencies between services may dictate that certain modules need to be deployed together or in a specific sequence even though that conclusion may be contrary to the release schedule as defined in the program charter.
35

KSAppArchReport RevES

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

KSAppArchReport RevES

Uploaded by

Copyright:

Available Formats

Kuali Student Service System Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

OUTCOMES AND CONCLUSIONS .......................................................................................... 33

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.1 Learning Unit Management (LUM)

3.1.1 Learning Unit (LU) Types

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.1.2 Canonical LU (CLU)

3.1.3 LU Instance (LUI)

3.1.4 Learning Objectives & Competencies

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.1.8 LUM Rules

3.1.9 Interactions with Other Services

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

Concierge Principles and Support for What-if Scenarios

3.2 Scheduling (SCH)

Kuali Student Service System Application Architecture Recommendations

3.2.1 Course Scheduling

Kuali Student Service System Application Architecture Recommendations

3.2.2 Needs Assessment

3.2.3 Management of Resources

3.2.4 Conflict Resolution

3.2.5 Exception Handling

Kuali Student Service System Application Architecture Recommendations

3.2.6 Concierge Principles and Support for What-if Scenarios

3.3 Enrollment (ENR)

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.3.1 Management of Relationships

3.3.2 Collection and Maintenance of Learning Results

Kuali Student Service System Application Architecture Recommendations

3.3.3 Learning Plan Support

Kuali Student Service System Application Architecture Recommendations

3.3.4 Support for Communication Service

3.3.5 Concierge Principles and Support for What-if Scenarios

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.4 Program Audit and Evaluation (PA&E)

3.4.1 Program Auditing

3.4.2 Progression and Evaluation

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.4.4 Concierge Principles and Support for What-if Scenarios:

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.5 Admissions (ADMS)

3.5.1 Capturing Prospective Learner Information

3.5.2 Admissions Application Forms

3.5.3 Learner Application Submission

Application Architecture Recommendations

Kuali Student Service System Application Architecture Recommendations

3.5.5 Admissions Decision Making

3.5.6 Managing Recruitment Activities