Kuali Student Service System Application Architecture Recommendations

odecrackAI and Robotics

Oct 29, 2013 (3 years and 5 months ago)

144 views





Kuali
Student

Service System

Application Architecture Recommendations



February 11
, 2008


Editors

Rick Burnette,
Florida State University

Gordon Uyeda,
University of British Columbia

Tim Heidinger,
Univ
ersity

of California, Berkeley


Joan Shao,
Univ
e
rsity

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


Univ
ersity

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

K
irksey, Glenn

Landi, Michael

Passarella George, Michael

Phillips, Meridith

Ryan, Angela

Wu, Teddy


Carnegie Mellon University

Hill, Brian

LaBarbera, Darlene


IBM

Heuchert, Robert


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


2


Table of Contents

1

EXECUTIVE SUMMARY
................................
................................
................................
..................

4

2

INTRODUCTION

................................
................................
................................
..............................

6

3

BUSINESS DOMAINS

................................
................................
................................
.....................

7

3.1

L
EARNING
U
NIT
M
ANAGEMENT
(LUM)

................................
................................
........................

7

3.1.1

Learning Unit (LU) Types

................................
................................
................................
.....

7

3.1.2

Canonical LU (CLU)
................................
................................
................................
..............

8

3.1.3

LU Instance (LUI)
................................
................................
................................
..................

8

3.1.4

Learning Objectives & Competencies

................................
................................
..................

8

3.1.5

LU Relationships
................................
................................
................................
...................

9

3.1.6

Templates

................................
................................
................................
.............................

9

3.1.7

Versioning

................................
................................
................................
.............................

9

3.1.8

LUM Rules

................................
................................
................................
............................

9

3.1.9

Interactions with Other Services
................................
................................
...........................

9

3.1.10

Concierge Principles and Support for What
-
if Scenarios

................................
..............

10

3.2

S
CHEDULING
(SCH)

................................
................................
................................
.................

10

3.2.1

Course Scheduling

................................
................................
................................
.............

11

3.2.2

Needs Assessment

................................
................................
................................
.............

12

3.2.3

Management of Resources

................................
................................
................................

12

3.2.4

Conflict Resolution

................................
................................
................................
..............

12

3.2.5

Exception Han
dling

................................
................................
................................
.............

12

3.2.6

Concierge Principles and Support for What
-
if Scenarios

................................
..................

13

3.3

E
NROLLMENT
(ENR)

................................
................................
................................
................

13

3.3.1

Management of Relationships

................................
................................
............................

14

3.3.2

Collection and Maintenance of Learning Results

................................
..............................

14

3.
3.3

Learning Plan Support

................................
................................
................................
........

15

3.3.4

Support for Communication Service

................................
................................
..................

16

3.3.5

Concierge Principles and Support for What
-
if Scena
rios

................................
..................

16

3.4

P
ROGRAM
A
UDIT AND
E
VALUATION
(PA&E)
................................
................................
..............

17

3.4.1

Program Auditing

................................
................................
................................
................

17

3.4.2

Progression and Evaluation
................................
................................
................................

17

3.4.3

Institutional Impact Assessment

................................
................................
.........................

18

3.4.4

Concierge Principles and Support

for What
-
if Scenarios:

................................
.................

18

3.5

A
DMISSIONS
(ADMS)

................................
................................
................................
...............

19

3.5.1

Capturing Prospective Learner Information

................................
................................
.......

19

3.5.2

Admissions Application Forms

................................
................................
...........................

19

3.5.3

Learner Application Submission

................................
................................
.........................

19

3.5.4

Admis
sions Evidence Gathering

................................
................................
........................

20

3.5.5

Admissions Decision Making
................................
................................
..............................

20

3.5.6

Managing Recruitment Activities

................................
................................
........................

20

3.5.7

Concierge Principles and Support for What
-
if Scenarios:

................................
.................

20

3.6

F
INANCIAL
A
ID
(FA)

................................
................................
................................
..................

20

3.6.1

Managing Awards

................................
................................
................................
...............

21

3.6.2

Financial Aid Application Process

................................
................................
......................

21

3.6.3

Calculating Cost of Attendance and Need Analysis

................................
..........................

21

3.6.4

Awarding and Packaging

................................
................................
................................
....

22

3.6.5

Pre
-
disbursement Activities and Reconciliation

................................
................................
.

22


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


3

3.6.6

Special Cases, Loans and Work Study

................................
................................
..............

22

3.6.7

Concierge Principles and Support for What
-
if Scenarios

................................
..................

22

3.7

S
TUDENT
F
INANCIALS
(SFS)

................................
................................
................................
....

23

3.7.1

Assessment and Pricing

................................
................................
................................
.....

23

3.7.2

Payment Plans and Invoicing

................................
................................
.............................

23

3.7.3

Payments and Commitments

................................
................................
.............................

24

3.7.4

Refunds and Disbursement of Funds
................................
................................
.................

24

3.7.5

A
ccounting

................................
................................
................................
..........................

24

3.7.6

Reporting

................................
................................
................................
............................

24

3.7.7

Concierge Principles and Support for What
-
if Scenarios

................................
..................

24

3.8

P
ERSON
I
DENTITY
(PI)

................................
................................
................................
..............

24

3.8.1

Individual People

................................
................................
................................
................

25

3.8.2

Groups and Organizational Units

................................
................................
.......................

25

3.8.3

Contact Information and Communication
................................
................................
...........

25

3.8.4

Kuali Identity Management (KIM)

................................
................................
.......................

26

4

KUALI STUDENT SERVIC
E CANDIDATES
................................
................................
.................

26

4.1

O
VERVIEW
................................
................................
................................
................................

26

4.2

S
ERVICE
C
ANDIDATES

................................
................................
................................
..............

26

4.3

C
ANDIDATE
M
ODULE
M
ATRIX
................................
................................
................................
....

30

4.4

R
ELEASE
1

S
COPE

................................
................................
................................
...................

31

5

OUTCOMES AND CONCLUS
IONS

................................
................................
..............................

32



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


4

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 loo
sely 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 gr
ouped 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 i
nto 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 i
n 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 collaborat
ion. 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

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


5

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.


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


6

2

Introduction

T
he
Kuali Student

Functional Team was formed in July 2007 to achieve the following three majo
r
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 D
evelopment, 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 Parti
tioning

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 w
orked 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
inst
itutions. 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 a
nd captured requirements using functional statements, conceptual data m
odels and
swim lane diagrams. The teams conti
nued 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 candidate
s. 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 b
ecause 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

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


7

Contrac
t 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 tradi
tional 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 se
ction.


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 Charter’s vision for
the Concierge. Domain capabilities and high
-
level u
se 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, in
quiry 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 Abstr
action

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 an
y 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 Progr
am (e.g. Degree in Integrative Biology)



Academic Plan (e.g. learner specific collection of academic and non
-
academic LU and learning
objectives)


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


8



Exam or Test (e.g. Biology 101 Final Exam, MIT Swim Test, GMAT, CLEP)



Other types of LU (e.g. Thesis, Dissertat
ion, Co
-
op Work Study, Study Abroad, Independent
Research, Internship, Service Learning, etc.)


3.1.2

Canon
ical LU (CLU)


Canonical LUs are the inventory of LU
s

for an institution, the collection of LU
s

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 conta
ining 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 Busine
ss 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). Thi
s 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 t
he 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

Lea
rning Objectives & Competencies

A key concept within Learning Unit Management is the learning objective which can be the purpose of
the LU or an independe
nt 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, o
r 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 spea
k 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
cou
rse or program requirement.



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


9

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 pu
rposes, 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

Template
s

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 LU
I. 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 ext
ensive 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 def
ining 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 determin
e 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 I
nstances (e.g. learners enrolled in courses/sections, instructors teaching a
course/section).



Scheduling services
support the scheduling of resources associated with Learning Unit

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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

F
inancial
s

related services manage the
pricing, invoicing, payment options, revenue
distribution for Learning Units (e.g. cost of programs an
d 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 fo
r 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 institutio
n'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 a
n 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 LU
s

(e.g., courses, final exams,
special ev
ents, extension) by

building and publishing LU schedules and managing the resources (e.g.,
instructors, space, equipment) associated with that offering.
Scheduling SMEs articula
ted 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 camp
uses 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. Wor
kflow 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"
s
chedule. 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.


Add
itionally,

the optimization should

attempt to incorporate
priority rules that reward departmental cooperation and flexibility in resolving scheduling conflicts

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


11

while discouraging unhelpful behaviors (e.g. late submission of scheduling data, excessive requests
for ex
ceptions, 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
includin
g (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 lane
s

(see App
endix 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 f
or most institutions, the first priority is scheduling matriculated cou
rses.
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 cy
cle includes six phases:


Setup
.

Primarily a scheduling office function to Define Calendar, Import Needs Assessment,
Manage/Update Resources;
Collect
Instructors’
Pr
eferences.


Request (Scenarios)
.

Departments and sub
-
divisions have the opportunity to bui
ld 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 d
epartment 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 fina
l 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 mechan
isms that can be accessed by learners.

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 w
orks 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 da
ta 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 sc
hedules

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

Man
agement of

Resources

enables stakeholders to maintain space, instructors, equipment, and any
other resource associated with scheduling/offering an LU.


Managing/up
dating 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 assu
med 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 a
ll 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
-
r
un
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 la
yer 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

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 a
lso 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 modif
y 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 revi
ew and approve or deny all or part of the proposed slate.


What
-
if capabilit
i
es 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 schedu
le,
tweaking various optimization parameters with each iteration. Similarly, once the central scheduling
office is ready to merge departmental requests into the cons
o
lidated schedule, the ability to preview
results of various What
-
if version
s

facilitates c
reating 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

respo
nsible for
the management of the
relationships betwee
n 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

hig
hly
personalized, customizable capability that
allows learners and their advisers to plan, track, and
evaluate individual learning goals and outcomes over the cours
e 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 l
earning, 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 a
ssociation 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 lea
rning 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 i
dentify cohorts of
learners within a specified program so that s/he may perform academic evaluations such as

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 l
earner 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 re
porting 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 a
nalysis 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 re
spect 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 managemen
t of waitlists or other
means of measuring demand for learning units and allocating places when demand exceeds supply.
The learner is able to check eligib
i
lity (perform what
-
if scenarios) by selecting various learning units
and evaluating the selection aga
inst 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 le
arning 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 c
onsume and experience the LU. These are learners in the broadest
sense of the word which could include matriculated
students
, extension
student
s, visiting
scholars, researchers, corporate staff taking continuing education, conference attendees,
lecture par
ticipants, 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 Lear
ning 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 enr
ollment 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, differe
nt

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


15

learners may have different rules applied to them when taking the same LUI. LUM will need to capture
these nesting/hiera
r
chal relationship rules.


The relationship identified between the person and the learning unit is invoked during the deposit and
ret
riev
a
l 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 a
ssociated 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 additio
n, 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 calculati
on 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 appr
oved by the Department Head, the
Enrollment module must understand the relationship between the instructor, the course and the
Department Head and facili
t
ate an approval process.


Because
of
the repository nature of the Enrollment module, it is the stewar
d 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 lear
ner 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 aggrega
ted 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 fra
mework, 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 system
s. 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 Manag
ement (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 int
ernship.


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 n
ot recognize the learning activity or because the learner
chooses to manage particular learning objectives independently. For example, a learner may wish to

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 availab
le 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
functio
nality 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
ma
nage 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 Enrollmen
t (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 Enrollm
ent 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 in
structor through the specified class. It is important to note that the Enrollment
module
will use a
Communication Service
to
send and receive communications.


3.3.5

Concierge Principles and Support for What
-
if Scenarios

The Enrollment module communicates rela
tionship 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
provi
ded 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 le
arner 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 p
rovides 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 l
ot 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."



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 ins
ufficient 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 Instan
ce 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 gu
ide

learner and institutional activities. The vision of this module is to be able to
function be
yond 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 man
aged 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

Pr
ogression 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 suppo
rt 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 re
sult 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 deriv
ed 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.


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


18

3.4.3

Instit
utional Impact Assessment

PA&E

provides a powerful tool to th
e institution for obtaining data to support various types of decision
-
making 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 min
or 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 learn
ers 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 lea
rners 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 usefu
l" 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 holisti
cally 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 w
ith 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 progr
ams 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 com
pletion 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 ef
ficiently 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 decis
ion. 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.
prer
equisites).




Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 math
ematically 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
hon
or 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 consider
ing 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 M
odule 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 rend
ers 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 appli
cation 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.


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


20

3.5.4

Admissions Evidence Gatheri
ng

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 s
hould 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 Ad
missions 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 o
f the learner and the learner’s 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 Recruitme
nt 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), an
d 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 env
ironment 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 t
h
e learner may be able to determine if a program is a good match for them.


3.6

F
inancial Aid
(FA)

The Financial Aid module is the core application in
Kuali Student

System responsible for




maintaining inventories of awards and resources


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


21



maintaining characteristics and needs of learners



assigning awards to learners for disbursement by t
he
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. con
notations 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 in
cluding 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 ins
tantiate 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 lear
ner 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

Calcu
lating 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

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 actuali
zed 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

Awa
rding 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
packa
ging 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 lea
rner 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 largel
y 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 discrepan
cies 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 m
anagement
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.


3.6.7

Concierge Principles an
d Support for What
-
if Scenarios

The Fina
ncial 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 p
rediction of what aid they may
qualify for based upon desired major, anticipated academ
ic record, and self
-
reported
demographic
and family information. Learners should also able to anticipate the impact of various actions on their

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


23

financial aid package, su
ch 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 supporte
d. 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
Financ
ial 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. Fo
r 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 determinin
g 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 w
ithin 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 I
nvoicing

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 C
harges. Where appropriate, the system will support the deferment of due dates.



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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

Accou
nt 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 th
e 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 t
ransactions 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.


3.7.7

Concierge Principles and Support for What
-
if S
cenarios

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 custo
mer 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, organizatio
nal units and the inter
-
entity relationships. The domain also

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 refer
enced 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
Resourc
e 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.


A
uthentication

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) wi
ll 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 su
pport 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 authori
zations 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 s
upport 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 organi
zational
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 betwee
n 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 w
eb
-
based approaches to deliver information such as message boards
and social networking sites (e.g. Facebook).



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 ne
w 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 c
andidates
during step II of
the
Kuali Student

SOAD methodology

(Appendix D).

This list was further re
fined to 33 service
candidates. The list of service c
andidates and representative service capabilities

(Appendix B)
reflects the knowledge gained during the
duration of the
Application Architecture phase
. Service
Candidate definition

will continue to evo
lve and service candidates

will transition
to finalized

services
and contracts in subs
equent phases of the project.




4.2

Service Candidates

Se
rvices marked with an asterisk ‘
*


were identified
in SOAD
Step II

only.


Services marked with ‘[R1]’ will be includ
ed 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 t
he
Student

Financial
s s
ervices.


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

-

Thi
s 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.


Authenticati
on 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).


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


27


Authorization Service


[R1]

-

This service manages the maintenance, audi
ting

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 contac
t 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 v
alues.


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 decision
s.


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

-

S
ee
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 overridd
en.


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 Servic
e)


-

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 Se
rvice


-

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.



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


28

Learning Objectives Service


-

This service manages the taxonomy of

Learning Objectives and how
they are related to one another.


Learning P
lan 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 Re
sults 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 even
ts.


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


Opti
mization 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

organiza
tions.


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 informat
ion.


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. learne
r, 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 Servic
e.


Product Service


-

This service provides information on "products"

recognized by SFS and acts as
an integration point for information from

other business domains.



Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


29

Program Audit Service


-

This service evaluates an academic record

against rules and r
eports
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,
professo
rs).


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 r
ulesets 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 objectiv
es (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 enco
mpasses 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 in
stitution'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 Servic
e*


-

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

m
ore
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
-

S
ee Formatting and Display Service
.


Workflow Servic
e


[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 st
atus of particular work
items.


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


30

4.3

Candidate
Module Matrix

The Candidate Module Cross Reference Matrix identifies the Service Candidates that are associated
with each of the Program Charter’s 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 cand
idates. 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 b
y
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 Matri
x


(Services in
bold
with

[R1]

are included in the Release One application
)




Service Candidate

ENR

LUM

SCH

PAE

PI

FA

SFS

ADMS

Aid Award

X

O

O

?

O

X

?

X

Authentication

[R1]

X

X

X

X

X

X

X

X

Authorization

[R1]

X

X

X

X

X

X

X

X

Award Resources

X

O

O

O

O

X

?

X

Communication

[R1]

X

X

X

X

X

X

X

X

Contact

[R1]

O

?

?

O

X

X

X

X

Dictionary

[R1]

X

X

X

O

X

X

X

X

Enrollment Service

X

?

X

X

O

?

?

X

Evidence

[R1]

O

O

O

O

X

X

O

X

Financial Account

?

X

O

O

O

X

X

?

Group

[R1]

O

O

O

O

X

O

O

O

Hierarchy


O

X

O

O

X

O

?

O

Id

O

O

O

O

O

O

O

O

Learning Objective

O

X

O

O

O

O

O

O

Learning Results

X

X

O

X

O

X

O

X

Learning Unit Service

[R1]

X

X

X

X

O

?

?

X

Logging

[R1]

X

X

X

?

X

X

X

X

Milestone


X

O

X

O

?

X

X

X

Organization

[R1]

?

X

X

?

X

?

X

?

Payment


?

X

O

O

O

X

X

?

Person

[R1]

X

X

X

X

X

X

X

X

Pricing


X

X

?

O

O

O

X

X

Product


X

X

?

O

O

O

X

X


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


31


Key

Value

Description

X

Directly dependent upon the service.

O

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 deter
mine 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
D
irect
D
ependencies 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 reviewe
d
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 an
alysis 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 per
son 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.


Program Audit

X

O

O

X

O

O

O

X

Relationship


[R1]

X

?

?

O

X

X

X

X

Resource


X

X

X

O

O

X

X

X

Rules

[R1]

X

X

X

X

X

X

X

X

Scen
ario


X

X

X

X

X

X

X

X

S
cheduling


X

?

X

?

?

?

?

X

Status


X

O

O

O

O

X

X

X

Translation

[R1]

X

X

X

O

X

X

X

X

User Preferences

O

O

O

O

O

O

O

O

Workflow

[R1]

X

X

X

X

X

X

X

X


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


32

4.

Contact Service
-

This service manages of contact informatio
n 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 S
ervice
-

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 Learnin
g 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 u
pdating 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 contro
l 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 m
eans 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 Arch
itecture
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 do
mains 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.


Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


33


Service Candid
ate 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 team’s 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
t
eam 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 funct
ionality. This has allowed for
the identification of the common infrastructure services and Learning Unit M
anagement services
which define

the body of work for the next phase.


Scoping of Services for Release 1

Th
e domain partitioning work
has allowed fo
r 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 de
velopment 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
phas
e 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 somewha
t 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 wha
t 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 s
ystem
s led
to major
re
-
conceptualization
s 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 h
igher 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 therefor
e

renamed Program Audit and Evaluation. The domain team realized that Program Audi
t
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 t
hat 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
-
c
urricular activities to the stated or pro
posed
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 wit
h much greater flexibility

Kuali Student Service S
ystem

Application Architecture Recommendations



Application

Architecture
Recommendations


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 presc
ribed 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.


Collab
oration and cooperation amongst institu
tions has been very positive. In b
ringing together the
views and processes from six institutions, we've discovered many more similarities than differences.
Although distance between institutions limits the ability m
eet 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 exc
itement 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 flexibi
lity 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 actuall
y 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 a
lso 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 hig
hly 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
de
pendencies

between service
s

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.