Sakai 3 at CSU – a catalyst for rethinking Information Systems

Sakai 3 at CSU - a catalyst for rethinking Information Systems
Paul Bristow : Enterprise Architect - Applications Charles Sturt University - Australia

Presentation Structure
Application needs
Back end, Front End
Sakai 3 at CSU
Sakai 3 and SOA
Sakai 3 and Online Architecture
Organisational Implications for IT
September 2009 AuSakai 09 - Bathurst, NSW, Australia “ Sakai as a Scholarly Environment: Pedagogy, Systems, Processes and Outcomes”

Applications Need To Be
Reliable
Backed Up
Meet Business needs
Usable
Adaptable
Scalable
Fast
Attractive
Accessible
Easy to maintain
etc

Applications Need
Some of these requirements conflict
Institutional IT tends to emphasise the reliable, stable side
We’ve been burnt too many times losing things
Don’t want to break billing, student admin, payroll!
But modern organisations need to leverage their information
Which means leveraging applications
We need more agility
But still need stability where it counts

Applications and Process
Applications support Business Processes
But inflexible applications mean we often change business process to work around how the application designer expected the process to work
This limits innovation
More flexible applications allow us to let the business optimise the process and change the application to support the new process
Organisational change makes this critical

Back end, Front end
At last year’s conference Nico and Ian talked about Server Side vs Client Side development
Server side development is slow and owned by tech people
Client side is more rapid and open to broader involvement
This is the model for Sakai 3, a back end kernel providing content and services with user interface implementation on the client through javascript (libraries)

Back end, Front end
Massimo Pezzini - Gartner Applications: Trends & Technologies Summit
September 2009 AuSakai 09 - Bathurst, NSW, Australia “ Sakai as a Scholarly Environment: Pedagogy, Systems, Processes and Outcomes” Front End Back End Modern user experience Reliability Ease of development Availability Fast Results Scalability Low Cost Integrity Multiple devices Security … … OPPORTUNISTIC SYSTEMATIC

Back end, Front end
This struck a chord
We’ve always had difficulties being opportunistic
IT build apps that have the back end characteristics
We have difficulty with apps where people would prefer to have their application 90% on the back end characteristics than not at all
Also resources dedicated to those back end attributes
Users want modern applications, device independent, etc

Back end, Front end
Both sets of attributes are required
We need a stable back end to support innovation at the front end
Parallels with enterprise architecture - an organisation needs to build a stable ‘platform for execution’ to allow freedom to innovate with manageable risk
But we need to consciously separate the two, in both application architecture and mindset

Sakai and Client Side
So we’ve built a new tool/app with client side techniques in our sakai 2.4 system
Next presentation will talk about this
New skills, but new enthusiasm
These skills will be relevant to sakai 3
So building skills, mindset for transition

Sakai 3 and Client Side
Sakai 2 tools typically had services and tool code in the same stovepipe
Separation within the tool projects but typically tools were standalone apart from core sakai services
Sakai 3 has resources in a common address space which may be shared across user interfaces
The RESTful access to JCR content gives us a kind of universal access layer
We can create servlets to proxy restful addresses into soap calls to SOA endpoints in other systems

Sakai at CSU - Uses
Virtual Learning Environment
teaching tools and entry point per subject offering
guaranteed provisioning of tools to sites
provisioning of users and groups
entry point for teaching resources
portfolios
Collaboration
Research, Administrivia, Projects
collaboration tools, shared resources

Sakai 3 at CSU - Functions
Content Repository
Authorisation
Content Search
Resource Addressing (that universal access space)
Organisation
Widget Server/Host
Widget container
Organiser of content
Organiser/manager of people and groups?
Portal/Entry Point

Sakai 3 at CSU - Use
Likely to want same provisioning of sites, groups users for subject offerings
More flexible cohorts, dynamic groups native
Likely to need the same set of tools
In transition we may need to host some tools in a Sakai 2 instance and integrate the two instances
Lose none of the backend desired ‘ities’
More flexible, pluggable options for back end services and integration
Better content management, sharing, authorisation
Better personalisation

Sakai 3 at CSU - Use
Confident Sakai 3 has an architecture that will meet these needs
Participating in Sakai 3 so our needs and experiences contribute to the range of experience influencing direction

Sakai 3 and SOA
Our application vendors are increasingly providing SOAP endpoints to their APIs
They are exposing data and units of functionality
Our integration server has SOAP endpoints to all its ‘flow services’
We have an enterprise data model which will be increasingly able to provide real enterprise shared data through SOA services
Sakai 3 natively uses REST. We can create servlets which can map RESTful addresses into SOAP calls and return results

Sakai 3 and SOA
We can create representations of SOAP services in the JCR which could make them discoverable through standard Sakai 3 services
At the UI level our proxied SOAP services have the same addressability and calling conventions as native Sakai 3 content
Sakai 3 content is (subject to authorisation) able to be accessed through RESTful services by other systems

Online Architecture
Organisation of online resources
By audience - eg students, prospects, staff, public
By content - eg disciplines, organisational structure
By workflow - eg enrol, make a payment
Personalised portal
Generic entry point - the front door

Sakai 3 has the potential to do all these
But we’ll probably mix and match
Vendors may have portals that have off the shelf functionality that is compelling to specific audiences or content areas
But we’ll expect vendors to have similar front end back end separations of concern
And we’ll expect seamless integration across all portals

Organisational IT Implications
Need to develop client side skills
Need Identity Management to support authentication requirements between the back end and the front end
ie single sign on needs to be able to pass through to content providers (eg Sakai 3 JCR)
Expect more volatility in new client side applications
Potentially users mashing up our services with their own widgets
Security/Authorisation needs to be enforced at the back end resource entry point (the restful URL into the kernel), it can’t be left to the UI level

Thank you
Questions

Sakai 3 at CSU – a catalyst for rethinking Information Systems

by AuSakai on Sep 29, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 1

Statistics

Sakai 3 at CSU – a catalyst for rethinking Information Systems — Presentation Transcript