1. Kuali Rice Evolving the Technology Framework for Kuali Applications Brian McGough (Indiana University) Aaron Godert (Cornell University) Warner Onstine (University of Arizona)

2. Why Evolve? Realign technical strategy to match evolved board vision for Kuali –Started as a (KFS) Kuali Financial System –Evolved to a umbrella suite of administrative higher education systems Facilitate a common architecture that can be used for future Kuali applications IT industry advances and standards for SOA based architectures

3. The Goals Enable the technology infrastructure investment that was made for the Financial system to be leveraged by other Kuali sister projects Use a common development framework to gain productivity and consistency across Kuali projects

4. The Goals Common underlying infrastructure in other Kuali modules will allow for easier adoption of new modules as they are developed Create a reusable development environment that could be adopted as a general approach to systems development and systems integration at an institution

5. Kuali Rice There are several middleware subcomponents that make up Rice This diagram represents the core infrastructure components that represent Rice The next slide shows the role that Rice components play in applications

7. Kuali Rice As shown in the previous diagram, Rice is made up of several reusable pieces of middleware A Rice enabled application will make use of the Rice Client to gain access to Rice middleware functionality Using the Rice Client in a Kuali Development project, development and integration with other Rice enabled applications and services comes for free

8. How we got here Several key factors have influenced the evolution of our frameworks –The need for multiple separate applications to be able to be loosely connected –The need for multiple separate applications to exist under the Kuali umbrella of products –Most administrative applications have common needs for middleware –Providing a solid base upon which to build our systems will allow us to avoid duplication of effort across projects

9. How we got here Some History: –Workflow (KEW) existed as a standalone integration oriented project at IU before Kuali began –Workflow enabled many disparate applications to be able to all use a common workflow engine to drive business processes electronically through the University –Workflow provides a relatively simple API, but leaves many choices about how to implement workflow in the hands of developers

10. How we got here History Continued: –To come up with a unified approach to using workflow, writing transactions in Kuali Systems, and other commonly needed application components the (KNS) Kuali Nervous System was born –The KNS abstracted a lot of the complexity of how to develop functionality in KFS and provided a large set of reusable code to enforce consistency and to assist productivity within the KFS project

11. How we got here Present thoughts and futures: –Having KNS as an asset that was built for KFS allowed for good productivity and standards enforcement…but only within KFS –So in order to extend into a multi-application platform some additional pieces were required –This is where the KSB (Kuali Service Bus) comes into the picture –The KSB will allow for cross application messaging and service invocation among disperate Kuali Rice enabled applications

12. How we got here Present thoughts and futures continued: –The KSB will provide the functionality needed to facilitate real-time integration of services and applications Reducing the need for batch types of integration Increasing our business process agility –The KSB will facilitate better application to service and service to service integration –We also wanted to increase the ability for Kuali systems to interact in an advanced way with people and this is how the KEN (Kuali Enterprise Notification) component concept arrived

13. How we got here Present thoughts and futures continued: –Using KEN we will be able to leverage other core infrastructure of Kuali to deliver a unified communications system with our users from all different kinds of applications –KEN will allow users to define how they like to receive communications

14. How we got here Futures –Looking ahead the components of Rice will allow for enhancements in the ways that our business processes are carried out without having to look at rewriting a bunch of systems –Adoption of technology standards for components of Rice is a primary concern going forward: BPEL, JSRs, Portals, etc; to allow for interoperation with other standards compliant products and services in our environments

15. Rice Subcomponents The KSB will enable applications and services deployed on the bus to interact with other applications and services deployed on the bus The KSB will also enable web service invocation for services that should be exposed Allows for synchronous and asynchronous communications between applications and services KSB (Kuali Service Bus)

16. Rice Subcomponents Provides reusable code, shared services, and strategy for development Documents (processes) and workflow integration –Maintenance –Transactional Data Dictionary Lookups Inquiries Rules Approaches to solving common development tasks KNS (Kuali Nervous System)

17. Rice Subcomponents Facilitates the routing and approval of transactions through the University Allows for rules to be created for how transactions should be approved Provides hooks for client applications to handle workflow lifecycle events for transactions Provides common document (process) search function and common Action List function that span across different applications and will integrate with KEN KEW (Kuali Enterprise Workflow)

18. Rice Subcomponents Provide a single list for all university related communications –Workflow items (KEW) –Non-workflow items (KEN) Examples of non-workflow items: –Your book is overdue –A concert is coming up on campus –Graduation check list to all Seniors KEN (Kuali Enterprise Notification)

19. Rice Subcomponents KEN (Kuali Enterprise Notification)

20. Rice Subcomponents Eliminate sifting through email Quickly find what you need, to go about your university related business Provide a controlled environment –Eliminate unwanted messages –Integrated user and group management Audit trail Centralize communication broker More robust preference capabilities KEN (Kuali Enterprise Notification)

21. Rice Subcomponents Integration with KEW: –Action list –Audit trail (logging) –User and groups Services exposed on KSB for direct consumption (HTTP Remoting) Services exposed as web services via KSB’s generic web services mechanism Out-of-the-box integration with KEW Out-of-the-box web app for viewing notification details, maintaining the system, sending messages (generic form) Future portlets for portal integration (any JSR168 portal) KEN (Kuali Enterprise Notification)

22. Frameworks and Methodology Kuali has chosen to Adopt common approaches to development problems This in turn has led to our adoption of certain general components required by our software distributions By building and adopting certain frameworks, some of the methodology of development decisions are simplified

23. Conclusion Evolving the technology framework for Kuali will create some interesting possibilities for future Kuali projects The focus of the evolution to enable rapid project development in a common way for Kuali projects Better business process agility for our systems through real time integration and support for defining and evolving workflow processes and messaging practices