posted 2012-30-09 20:00:00 -0500
The road to hell is paved with paperwork. Volumes and volumes of terrible, flammable paperwork that angrily climb walls, threatening to consume anything and anyone in a cataclysm of input error and infeasibility.
In the beginning…
While this is perhaps an exaggeration for effect, it is not far from the situation I encountered when I began this contract with the University of Toronto’s Office of the Vice President and Provost (colloquially referred to as the Provost’s Office) in December 2010. Due to a recent change in policy effected by the Higher Education Quality Council of Ontario, it had become necessary for the Provost’s Office to track every stage of governance involved in the creation, change, review and closure of programs, units, and various other academic entities, with a level of fidelity that would permit comprehensive audits. At that time, this tracking was accomplished using a colour-coded spreadsheet (suitably sized to function as Paul Bunyan’s tablecloth) and the meticulousness of a few, extremely talented individuals. It was clear that this strategy for coping with the new requirements was far from sustainable, providing overwhelming impetus for the design and construction of Sakia.
The (initial) design requirements for Sakia fell into six broad categories:
- Process Support and Management
- Document Management
- Data Entry
- User Notifications
To save time, I will focus only on the first: how Sakia supports the extremely complex and dynamic processes described above while emphasizing accuracy and intuitiveness. The solution I came up with is best described in pictures…
The multi-process overview is the first interface state the user is presented with after logging in. Sakia forces all the processes it manages to respect a (subset) of phases which can be configured when the application is installed. This choice permitted the creation of this useful, bird’s eye view which provides information on the status of currently executing business processes in a highly visual manner. Sakia’s focus is always on process visualization instead of simply pushing work around to different individuals. The reason for this stems from a desire to retain some of the virtues (believe it or not) of the spreadsheets the Provost’s Office was using to manage these processes in the past. Spreadsheets are highly visual, and imply a single physical structure (a sheet) which is both the visualization of data and the method of interacting with it. In the above screenshot, the multi-process overview provides a single visualization which can be dragged around much like a spreadsheet, and where individual tiles (like cells) are the interaction points. This notion of visualizations as interaction mechanisms is one I adhere to rather fanatically in my designs, and one you will see repeated with disturbing frequency on this site in the future…
Sakia makes heavy use of progressive disclosure. Mousing over a single process in the multi-process overview reveals methods of interaction - in this case, the ability to jump into that process and view its details. The aforementioned phases are now arranged along the bottom of the screen, and are further divided into milestones and steps (I refer to this area as the step browser). Selecting a step reveals the tasks (occupying the centre of the screen) which must be completed in order to complete the containing step. Tasks represent a unit of work, such as a meeting which must be held or a document that must be authored. Notes may be taken on the task (or the step, or the overall process), and documents can be attached directly to it as well. As before, these interaction options (and others) are presented when a user mouses over a task. Process progress is visualized in several subtle ways, including colour changes on tasks, iconography on the step browser (truck for in-progress, check mark for complete, with the green arrow pointing to the current step), text under the process name in the top right, and various opacity effects for steps within the step browser. Sakia offers a great deal of flexibility in the execution of processes (one of its key design requirements):
- Steps and tasks may be started/completed out of order
- Tasks may be optional or required
- Tasks may be cloned if they need to be completed more than once
- Steps can be rewound, providing a fresh copy of the step (all tasks are reset) while retaining the previous version in a read-only state (accessible via a drop-down list of previous versions -not shown here)
Estimated completion dates may be set for individual tasks, allowing for the calculation of estimated completion dates for their containing step(s) and process. As well, this information drives a personalized notification system which can be viewed by selecting the notification button in the bottom-right corner of the screen. Users register for notifications on a process-by-process basis. In the above screenshot, mousing over an overdue task presents the user with the option to jump directly to the task within its containing process.
One of the most unique features of Sakia is the ability to specify the consequences of a process. A consequence is a proposed action - create, change or review - coupled with a data type and, in the case of change or review, a particular database record. When creating or changing, users are presented with a simple CRUD form for the data type they have specified, so that they may fill in or change the values they desire. Review is a bit of a no-op. Each consequence can be given an effective date, approved, or rejected individually and changes are made to the underlying database of programs, units, and various other academic entities only when a consequence is approved and its effective date (if provided) is reached.
From a more technical perspective, the most powerful part of consequences is that they provide a persistent link between a change made to the underlying database and the business process which authorized it. In this way, consequences form a detailed history of the governance which has affected each entity in the database, facilitating detailed reports as well as Quality Council audits. Illustrated above, a user can view an individual record and its history, and click through to the process whose consequence(s) authorized the action visualized on the right side of the screen. Manual changes to the database made via the Database Explorer are also recorded as “manual change” or “manual create” consequences, so that no alteration to Sakia’s picture of the University is ever made without a complete audit trail.
Process Scheduling and Definition
If a process follows a predictable cycle, or if one is known to be starting at some point in the future, users may schedule it instead of initiating it right away. In this scenario, the process passes into the system timeline which allows users to view and manipulate scheduled processes, as well as previous completed/cancelled processes and any upcoming consequence executions. This interface ensures that all previously executed processes remain fully accessible to the user for viewing through the single process details interface (in read-only mode, of course).
Sakia features a fully dynamic process execution engine - nothing specific about any business process is hard-coded into the system. A powerful interface is provided to administrative users for creating new business process templates and editing existing ones, though permission to edit templates which have been used is restricted to various degrees (preventing, among other things, structural changes to processes which have already been completed). In this case, a process may be grandfathered and replaced by a newer version of itself.
Sakia also features a flexible authorization system, allowing system administrators to authorize new users to view the application (with varying levels of privilege), to create and modify user groups (roles), and to tag template processes and their instances with those groups which should be permitted to see them. This system, via minor extension, could one day permit multiple offices to utilize a single instance of Sakia without interfering with one another’s work.
The Nerdy Stuff
In case anyone is wondering, Sakia is an Enterprise Java (J2EE6) application running on Glassfish 3.1, supported by Hibernate and a DB2 LUW database (though it is fully database independent). At the level of application logic, it makes extensive use of stateless session beans (EJB3), the Java Transactions API (JTA), the Java Authentication and Authorization Service (JAAS), and the Java API for RESTful Web Services (JAX-RS). JSON+REST is used as an intermediary between the Enterprise Java and the presentation layer, because it’s fat cousin SOAP+XML is…fat. The presentation layer itself is implemented using largely custom widgets developed for the dojo AJAX framework (1.6), and employs CSS3 and HTML5.
In anticipation of someone asking, a sakia is an ancient Persian water wheel. The name was selected primarily because many of the business processes defined by the Provost’s Office are cyclical in nature (occurring on a staggered basis every few years), but also because Sakia (the software), much like water, is intended to keep people alive and stress-free :)
Sakia has been in Production at the University of Toronto since the summer of 2012, and has become a core component of the University of Toronto’s Next Generation Student Information Systems (NGSIS) initiative and curriculum management strategy. Though I have not demonstrated the full range of Sakia’s functionality, I do hope what I have shown gives you a reasonable understanding of how the requirements presented by the University of Toronto’s Provost’s Office were met. If you are interested in hearing more about Sakia’s functionality, or the technology which underlies it, feel free to contact me directly or leave a comment below.