New Things In Kuali Student/EagleApps

New Things In Kuali Student via EagleApps at Boston College

Last fall Kuali Student diverged (see previous post). KualiCo chose to start over from scratch to focus on cloud opportunities.  Boston College, an institution that was in the process of implementing Kuali Student,  out of necessity chose to continue on with the existing source code. In the role of architect on that effort I have helped put in place key architectural and process changes designed to move BC forward faster towards their goal. We are continuing with Kuali Student but we are doing so with some modified approaches.

First of all Kuali Student has been branded on campus as “EagleApps.” The primary goal is to create a system that will work for BC now and for a long time to come. A secondary goal is to provide a stable platform that other like minded institutions will be able use to implement their own solutions if appropriate.  As such the BC effort continues to identify likely configuration points and when done they will release the source code under an appropriate open source license.

Second, Kuali Student was built using a “Service Oriented Architecture.” Would “EagleApps” keep this orientation? In fact Boston College is perhaps more strongly committed to an SOA based solution. You see last summer, while Kuali was holding it’s community meetings that resulted in KualiCo, I was doing a “proof of concept” to test if we could address the significant integration challenges that BC (or really any university) faced by using those services. BC had already implemented CM and had started KSA and had a plan to implement Enrollment -- each was deployed using different versions of the source code. That POC showed that BC could use the Service Contracts to create “Bridges to Tomorrow” eliminating the need and risks to implement everything all at once in a “big bang” and to proof us against future technology changes.  Today BC is not just using those service contracts to bridge different versions of the software but to connect to their existing systems and their operational data store.

Today EagleApps is moving forward fast. We are leveraging the existing Kuali Student service contracts and source code to finish the original vision of Kuali Student as a modular configurable loosely coupled system.  We are also leveraging many of the procedures and processes pioneered by Kuali Student.  We are expanding on, adjusting and improving many of those ideas and approaches in a “new” and different manner.

1. The source code has been moved to BC’s private GIT repository with the intention of making it publicly available after our initial release.
2. GIT’s elegant branching features are employed to support the Kuali concept of parallel development with teams in South Africa, India and teams right here in the United States.
3. Like Kuali, the service contract documentation will be put on a public wiki to encourage comment, discourse and agreement on these core design documents.
4. Equivalent RESTful JSON bindings have been created for the service contracts supplementing, not replacing, the java binding and Soap/WSDL binding. Each binding has its own advantages and disadvantages.  Expanding the Kuali Student notion that we do not conflate the semantics of the contract with any particular protocol used to bind to the contract to any particular software language.
5. The service contracts themselves are maintained in a completely separate repository with it’s own governance structure. This was done to support other existing users of the Service Contracts including BC’s own web-service team and to prepare a path to sustainability.
6. The implementation source code layout and structure has been reworked to speed development, i.e. developers no longer have to rebuild and deploy the entire application just to test a tiny change they made to a single small feature.
7. KRAD is now deprecated in favor of move Kuali Student made towards AngularJS for UI development.
8. As was Kuali Student’s intention, each service is built and deployed independently in it’s own war file, i.e. no wiring together of services underneath as may have happened during prior development.
9. Similarly the user Interfaces and other applications also are built and deployed independent of their services. Stated another way, all applications must be able to access the services remotely across the wire.
10. Integration with RICE is deprecated with alternatives found to decrease our dependence on a middleware product given changes to RICE.
11. The loading tools developed by Kuali student have been expanded so we can load most data directly via the services instead of relying on SQL inserts.
12. A particular school’s configuration data, i.e. types, and states and other school specific data, is managed in easy to use spreadsheets that BAs can update and then directly load to configure the system themselves.
13. Use of full coverage AFT’s, Automated Functional Testing, is deprecated in favor of rigorous programmatic testing all services coupled with an AFT “lite” approach for the UI.
14. All services are instrumented to facilitate performance and load testing, production monitoring and troubleshooting.
15. The code generation techniques that were first developed by Kuali Student have been aggressively pursued improving development velocity. A service can now be implemented in hours instead of weeks.
16. Business, validation and authorization logic has been moved out of the application and placed behind the service. This is done to ensure data loaded via the services will work when called up in the UI and to make it easier to write and test new screens.
17. All code changes are accompanied by a corresponding unit test to prove the logic does what it is supposed to do.
18. All code commits are accompanied by a collegial code review inviting all peers to inspect, comment and learn from each other.
19. Over dependence on Spring Beans in general and on RICE’s configuration scheme has been deprecated in favor of a more pragmatic approach based on the kind of configuration being done.
20. Each feature has been split into a service component and a UI component so we can run dual agile teams developing the services first then the UI.

In future blog posts I will be digging deeper into some of these technical and process changes. In the mean time Boston College’s EagleApps will be “screaming” forward.