Date post: | 18-Dec-2015 |
Category: |
Documents |
Upload: | damon-morrison |
View: | 215 times |
Download: | 0 times |
Kuali Student: A Next Generation Administrative System
Educause Enterprise 2008Chicago, May 28, 2008
Richard SpencerActing CIO, University of British Columbia
2
Outline
• Universities: how are they different?• Systems
– challenges & opportunities– a short history of systems– exponential growth
• Kuali Student system– goals and principals– design elements– technical principles
• Community and open source– contributing to KS
• Concluding thoughts
3
Universities
4
How universities work• Students and faculty
– teaching and learning– research– community service
• Product– learning, knowledge and educated people– we don’t sell it, it doesn’t generate revenue
• Staff– support these activities
• Everybody– does a lot of tedious administrative stuff
• Money and time are limited– it is hard to come up with a high margin, best selling, product
5
Systems in a university
Systems should:• help people do what they need to do
– easy to use– intelligent– eliminate paper forms and files
• help run the enterprise efficiently– give people the tools and information they need– support processes that cross departments– be scalable
• support end users– make it easier to learn, teach and do research– make it easier for people to help people
6
Challenges & Opportunities
7
PaperPaper forms:• have been around for a long time• define how we work• define our departmental structure• lead to duplication of data
– information is often wrong
• make it difficult to access information• result in
– poor service– services that don’t scale– a focus on the department, not the user
• have led to processes that need radical change
8
ProcessesProcesses that were developed for paper forms:• require frequent, repetitive human input
– staff are required to:• transfer information to and from forms and files• operate on the information
– supervisors and managers have to:• check that rules have been applied• look for anomalies• stay in the paper loop
– most decisions are based on rules and policies, not judgment
• are interrupted at department boundaries
Online processes should be radically different
9
Systems that Wow users
• use the information we already have• present options and alternatives• provide immediate, helpful, feedback and response• apply rules to eliminate unnecessary approvals• eliminate all paper – but let users:
– interrupt processes and return to them later– work on plans and scenarios over time– keep copies of any results
• make it easy for people to do what they know how to do– no training on the system!
• trust the user *subject to review and audit
10
Systems that Wow staff
• allow customers to complete processes online• let the customer see what staff see
– customers and staff should always see the same information
• use rules and workflow to automate approvals– automate the routine, alert staff to the exceptions,
• if in-person approval is required, make it simple– make it easy to see what has to be approved– provide the necessary information, rules, etc.– allow staff to override rules when appropriate
• if customers need help, give staff the information they need to provide it
• no training needed to do what they know how to do
11
Systems that pay off
Systems should• deliver all processes on-line
– end to end, no paper
• complete transactions in real time• use rules engines to apply business rules• use work flow to orchestrate processes• support processes that cross unit boundaries• make information accessible to authorized users• make it easy to configure your processes• enable change and innovation• be scalable
12
The goal is not to reduce the number of people
It is to give them tools to let them do more
13
A little history
14
A short history of student systems• BC
– paper based processes– information silos in separate departments– the customer had to help us run the institution
• SRS– on-line records, flat files, reports
• SIS– support for core processes in core departments– often more work & time for other users– we began to help the customer
15
Current systems
Current systems support core processes, but they:• are inflexible• make it difficult to change processes• result in systems “silos”, with duplicate records• are expensive to install and maintain• often have missing functionality• frustrate end users
Key university functions are often:• not well supported • not supported at all
16
Changing people and processes
Current organizational structure leads to:• difficulty sharing resources across departments• system and data silos• duplicate information
– often out of date – hard to update and correct
• processes that are hard to automate– handoffs to other departments or systems can break automation
Change management is needed to:• get staff to share responsibility for end users• help individuals accept and embrace change
Managing change is the biggest systems challenge
17
the power of exponential growth
18
Powerful computers
Exponential growth in:• processing speed• memory size• network bandwidth• storage capacity
The power of doubling:• grains of rice on a chess board:
– 1 grain on the first square, 2 on the second, 4 on the third,...– 64 squares– 1.85 x 1019 grains – 900 years production at current rates
19
Inte
grat
edC
ircui
t
Tra
nsis
tor
Vac
uum
tube
Rel
ay
Ele
ctro
-m
echa
nica
l
1.E-05
1.E+05
1.E+15
1.E+25
1.E+35
1.E+45
1.E+55
1900 1920 1940 1960 1980 2000 2020 2040 2060 2080 2100
Increasing computer power
logarithmic plot
Ray Kurzweil, “The Singularity is Near”
One insect brain
One mouse brain
One human brain
All human brains
Cal
cula
tions
per
sec
ond
per
$1,0
00 1055
1035
1015
10-5
20
Kuali Student - goals and principles
21
Goals for Kuali Student• community source development
– institutions pool their resources and their ideas– community commitment ensures long term support
• open source– there will be an open source reference implementation
• SOA– service interface definitions and contracts will be published– this will help develop a support community– it will make it easier to extend the functionality
• flexible systems can give comparative advantage– how we support students and faculty helps define us– great systems can help us attract and keep the best people– staff have tools and time to do more and help more
22
Functional PrinciplesIn addition to storing information and running key processes:• support a wide range of users and activities
– eliminate unnecessary constraints
• support a wide range of business processes– “customization is good”– “your processes, not someone else’s best practices”
• make it easier to change business processes– implement new processes more quickly and economically
• deliver scalable processes– all information is online and updated in real time
• enhance human interactions – great interface design, tools for staff delivering service
• internationalization
Support the end user
23
Kuali Student - design elements
24
Modular design
Service oriented architecture:• system is delivered in applications or modules• a school can use some or all the modules• modules can interface with existing systems
– financial aid, scheduling
• partners can develop modules that meet special or general needs– residence management, student discipline– these can be reused by other schools
• modules– share and reuse services– can interface to existing systems
25
High level entities
Use entity models that allow flexibility:• person• time• learning units
– courses, sections, lectures, student contributions, non-credit..
• resources– learning spaces
• rooms– collections of rooms, parts of rooms
• outdoor spaces• online resources
assumptions should not restrict what you can do
26
People, identity and access
Identity management• persons are the high level entity
– one identity per user• easy for users to create (or transfer) their own identity• multiple personas are allowed• roles, authorizations and privileges are added over time
– distributed administration– delegated authority
• manage access for people and applications• separate authentication and authorization• apply appropriate rules and polices to all access• check what is released against need to know
27
Learning units
Learning from Home Depot – a “learning unit” can be:• course; single lecture in a course; 15 minute student
presentation in a course• participation in community service• any activity that the student wants to include on a formal
or co-curricular transcript• a “learning unit number” is like a SKU...• we can also have:
– learning results– learning plans– learning resources
if you can imagine it, KS can accommodate it
28
Concierge• use what we know about:
– the person, the rules, the experience of others
• suggest valid choices– don’t make the user wade through choices that don’t apply
• apply and explain the relevant rules– don’t expect the user to read and understand the regulations
• anticipate peoples needs– these courses meet your requirements and match your interests
• integrate processes to make things easier– do you want to apply your tuition credit to your child’s registration?
• implement using rules and workflow
support the end user!no training required for things we know how to do
29
Concierge
InstitutionalInformation
Requirements
PersonalInformation
Information aboutthe experiences
of othersPossibilities
We should use:
to support users
Options
Record
Status
Goals
Pitfalls
30
Concierge sits lookingand listening for changes ina person’s state, institution
rules, peoples experiences, etc.
Concierge “sees”student accept
offer
Concierge conceptsability to register triggered by accepting offer of admission
Concierge checks student info, program, required courses, elective opportunities, and guides student to solutionthat works for her
process ends when student has a complete program thatmeets her needs
Rules engine
Workflow
Uses
Information
Concierge “knows”the rules and
process
31
Using workflow and rules engines:• processes are represented using workflow, not coded
into the system• rules are represented in rules engines, making them
easier to review and change• responsibility for processes and rules is separated from
technical issues• rules and policies govern access to information• workflow and rules engine technology is reusable and
scalable• a configuration application will be provided
process change is easier
Rules and workflow
...somewhat
32
Business rules environment
• A Business Rules Management Service (BRMS) • A Rules Engine (Drools) • Rules user interfaces (create and modify rules) • Business services that execute rules
– Placing the rules execution inside the service that needs it. • The enrolment service would execute pre-requisite rules, etc • The student financial service would execute fee calculation rules
• Business Rules Data Warehouse– Rules are extracted and loaded into the data warehouse. BI tools
(e.g. Jasper) can write reports against this data warehouse.
• Workflow moves rules to appropriate level when approval is required
Building the Kuali Student BRMS, Dew & Fernig, Kuali Days VI
33
Rules and Business Intelligence
• Traditionally Business Intelligence only deals with “facts” in the Enterprise Systems. Now we can apply BI to business rules. For example:– Is there any correlation between student success and pre-
requisite rules?– Which courses are referenced most frequently in curriculum
rules?– Are there any rules that inhibit student success (e.g. requiring
students to take more than 4 years to finish their program)?
Building the Kuali Student BRMS, Dew & Fernig, Kuali Days VI
34
Access to information
To ensure users and systems have access to information:• abstract data from systems
– information is often common to more than one application
• data must be current and correct– one primary data store, no information stored on paper
• data should be maintained and provided by services– applications don’t need to know how or where data is stored
• manage access to data services– identity management for people and applications
• apply rules and policies within the service– check that information to be returned is appropriate
rules and policies should be known and explicit
35
Zero stop shopping
we shouldn’t have to do things a system can do for us
..renew my parking pass for me!!
36
Kuali Student - technical principles
37
Service oriented architecture• break business processes down into “services” which are:
– reusable– autonomous– agnostic– stateless– loosely coupled
• define services by:– service contracts (what they do)– service interface definitions (how they communicate)
• applications are built from reusable components, using:– modular design– loosely coupled components– workflow and rules engines (services)
38
Implementing SOAWeb services• simplicity• platform neutrality• standards
– including SOAP, WSDL, XML
Standards• use open standards wherever possible (e.g. PESC)Configuration• simplify administration of rules and workflowGovernance• Separate governance of service contracts from technical
decisions
39
Agility - make process change easier!
40
Component abstractionSOA allows abstraction of components into layers• presentation layer
– portal
• applications - “owned” by departments– business services– use rules engines and workflow to abstract logic and process flow
• process agnostic services– services are available to multiple business processes
• data services– applications don’t have to understand the data structure
• service bus– provides communication services, ensures integrity
41
Contact Admission Enrolment
Identityservices
Evaluationservice
Awardsassignment
Person data academic history awards
Conceptual system architecture
Rulesservices
Workflowservices
Learning planservice
Businessservices
Process agnosticservices
Infrastructureservices
Presentationlayer
Dataservices
Con
cier
gePortalConcierge
Service bus
42
Community & open source
43
Community source development
Institutions formally partner to develop systems
• systems are created specifically for higher education
• shared resources spread the cost of development
• upgrades and enhancements contributed by the community lower the cost of software maintenance and enhancement
• flexible architecture allows use of CS, vendor supplied and home grown components.
• commercial installation and support is encouraged
44
Open source applications
SOA systems can be implemented:• using open source development tools• using open source infrastructure components• using open standards• by building open source applicationsBenefits:• code is open and can be modified by the institution• other institutions can develop modules you can use• applications may be more reliable• support and development can be assuredRisks:• support and development may not be assured
45
KS founder & partnersFounders • University of British Columbia• University of California, Berkeley• University of Maryland, College Park• Florida State University• San Joaquin Delta College• University of Southern California
Partners• MIT• Cambridge University
Also• Andrew Mellon Foundation• Kuali Foundation• AACRAO, NITLE
46
KS contribution opportunities
• Founders– substantial commitment in money and people
• Partners– significant commitment to core product
• Contributors– Help sustain, or enhance by developing new modules
• Adopters– commitment to adopt some modules
• Supporters– get the Kuali Student bumper sticker....
47
Concluding thoughtsOur next generation systems must:• be focused on the needs of end users• be much easier to use• be scalable (online, real time, no paper)• be flexible and configurable
– make customization easier– make process change easier
• support processes that cross departments and domains
Our next generation systems should:• be developed on an open source platform• be developed using community source development• we can Wow the user!
48
Information on Kuali Student
www.kuali.org
www.kuali.org/communities/ks/