Interested in trying out Adaptive Case Management without a huge investment? Cognoscenti might be the option for you. This post contains most of the contents of a paper I will be presenting in Germany in September on the Cognoscenti open source system which I have used in demos at the last two BPMNext conferences. To anyone wanting to experiment with ACM capabilities, a free solution might be worth trying.
The EDOC conference in Germany is mainly for researchers, and so most of this post focuses more on ways to experiment with the capabilities, and less about simply using the capabilities out of the box.
Open Source Software for Experimentation on
Adaptive Case Management Approaches
Abstract: Cognoscenti is an experimental system for exploring different approaches to supporting of complex, unpredictable work patterns. The tendency with such work environments is to make increasingly sophisticated interaction patterns, which ultimately overwhelm the user with options. The challenge is to keep the necessary cognitive concepts very simple, allow the knowledge worker a lot of freedom, but at the same time offer structural support where necessary for security and access control. Cognoscenti is freely available as an open source platform with a basic set of capabilities for tracking documents, notes, goals, and roles which might be used for further exploration into knowledge worker support patterns.
Fujitsu has leadership in the business process space going back to 1991. In 2008, the Advanced Software Design Team started a prototype project from scratch to explore innovative directions in enterprise team work support. Cognoscenti became the test bed for experimental collaboration features to demonstrate properties of an adaptive case management system for supporting knowledge workers. Features that proved to work well were subsequently implemented in the other products. In 2013 internal company changes left the project without any specific strategic value. Since some people were using it as a productivity tool for managing their work, the decision was made to make it available as an open source project for anyone to use and possibly to help maintain.
One experiment was to implement preliminary versions of the “Project Exchange Protocol” which allows case management systems, and business process management (BPM) systems, to exchange notes, documents, and goals using only representational state transfer (REST) oriented web service calls. Cognoscenti is available as a free reference implementation of these protocols for testing of protocol implementations. This paper seeks to demonstrate the open source system, its capabilities, and how research project might use the software for their own research.
Cognoscenti stores information in XML files in the file system. This was done for two reasons:
1) to avoid complication in installing the system. Requiring and initializing a database restricts the environments that it can be deployed to. The XML offers a flexible schema that can be evolved efficiently –– a task that can be quite complicated in a database. This allows prototype projects build on Cognoscenti to experiment easily with capabilities.
2) to allow direct manipulation of the files by users. The documents appear as files in the file system which can be opened and edited directly – even when the Cognoscenti server is not running. Changes are detected by file date and size.
Conceptual Object Model
The root of everything is an index which is initialized by scanning the file system. From this you can retrieve “Site” objects, “Project” objects, and “UserProfile” objects.
The Site object represents a space both on the disk and address space on the web. A Site has a set of owners and executives all of whom are allowed to create projects in the site. A Site has a visual style that applies to all projects contained by that site. The site is mapped to a particular folder in the file system, and all of the contained projects are folders within that one.
The Project object is the space where most of the work takes place. A project has a collection of notes (small message like documents with wiki-style formatting), attached documents, goals, roles, history, and email messages. All of the artifacts for a project is stored in the project folder on disk. There is a special sub folder named “.cog” which is where all the housekeeping information is kept about the project, such as old versions of documents, etc. When the server detects that a file has changed, it will display an option to the user to commit those changes, which causes a copy of that file to be saved as a version inside the housekeeping folder.
While Sites and Projects are represented in one directory tree, user information is from a folder that is disassociated from the sites and projects. The UserProfile object contains personal information for a particular user, OpenID addresses, email addresses, and settings. Because the user preferences are disassociated from the sites and projects, a user may play any role in any site or project without restriction. A user logs in once, and can access any number of projects and sites that they have access to.
Cognoscenti is written in Java and runs in any servlet container, such as Apache TomCat. The user interface is based on Spring framework, which some browser side capability from Yahoo User Interface and Google Windows Toolkit, however grafting a new user interface for specialized purpose projects is easily supported.
The entire code base is licensed under the Apache license, freely available to anyone who wants it.
Security and Access Control
Cognoscenti is first and foremost a collaborative case management system designed for lots of people to work safely with sensitive information, like health care information, social worker information, legal case information, etc. Access control needs to be a primary consideration. It is easy, or trivial even, to make a system that restricts access to particular artifacts to particular named users. But there is a problem with that: managing the many-to-many relationship between all the artifacts and users directly can be tedious and overwhelming. This leads either to users leaving the access too open so that too many people can have access, or alternatively leaving the access too restricted so that people can not get the information that they need to do the job.
An indication that users a frustrated with the access control mechanism is seen when they take a document out of the document repository in order to email it to people they want to give it to. This subversion of access control mechanism is dangerous, because email itself is an unsafe medium for sensitive documents.
The developers of Cognoscenti view security as a usability problem: it must be easy enough to use, so that people get the security right so that only the right the people who need access are getting it. These principles must be followed:
1) It must be easy for a normal, non-technical business user to express the correct security constraint to meet their needs.
2) Such an expression must meet the natural requirements of a social situation, and not merely the technical requirements of the system.
3 )As teams change and evolve, the security constraint in constructed in such a way that it tracks the changing requirements, without needing tedious maintenance by the users.
4) No surprises: the meaning of the access control settings must be clear to non-technical users.
These requirements are considerably higher than most current systems. For example, the Windows file system requires the user to do a kind of set algebra in order to determine whether a particular user can see a particular document or not.
Affordances for Change
If the project is entirely static in terms of membership, it is not difficult to get any such system set correctly so that the fixed set of members have proper access. However, projects are not static. Imagine a police detective working to solve a crime, and needs the help of an expert. That expert will need access to the case folder. Imagine how it would be if the police detective had to invite the expert, and then go to every document and give them access. The preferred expert might not be available, and the job might be done by the expert’s assistant. Imagine how it would be if the detective then had to change the access control of all the documents. And once the immediate goal is done, it might be appropriate to remove them from being able to access. In a real project we expect new people to joining and leaving every day. It does not take too much change before the management of the access rights overwhelms the detective (and he resorts to email).
One experiment built into Cognoscenti is the idea that if a person is assigned to an active goal, they automatically get access to the documents. Goals also have an ability that the person assigned to a goal and delegate the assignment to another person, in effect automatically giving them access to the project folder without further trouble. This has an additional interesting aspect that when the goal is completed, the person doing the goal, if they have no other access, will then automatically lose access which is appropriate in certain situation.
It became clear that part of the solution will involve creating intermediate constructs, called roles, which represent groups of people who are treated equivalently. Roles, by themselves, are not very innovative, but in a standard implementation of roles, the maintenance of the roles can be tedious and time consuming. Cognoscenti explores the usability problems around roles and use of roles.
Roles are highly contextual, so some experimentation was one to associate roles automatically with certain actions, or to have roles modified as the result of actions in a natural way that does not require extensive maintenance by the users. For example, adding a user to an email message might, optionally, also add that user to an associated role.
Roles were unified with the concept of a view. That is, a role is a group of people in a particular context, but it also contains elements that control how those people see the project. The reason for this is to reduce the number of different conceptual objects that the user must deal with.
Role names are also use as a form of tagging of the content. A document can be associated with particular roles as they are added into the folder, as a way of categorizing the documents. Goals can be associated with roles so that when a person is added to a role, they automatically are assigned the goals, and they have access to the documents. The use of roles gives a lot of flexibility, but the challenge remains to make the usability easy enough so that the case manager does not need to spend a lot of time creating a bunch of roles ahead of time, and instead roles are created easily, in a natural way, whenever needed by the emerging case.
Representation of Goals
Central to any work management system is the idea of tasks, activities, or goals. The challenge here was to explore the usability problems that prevent most users from keeping an accurate task list. Effort focused on how to make it really easy to create goals and assign them to others. Much as attention was given to make goal lists as easy as a checklist. The challenge is to make the creation of a new goal, the assignment of a person to that, and the notification of that user, easier than sending an email asking someone to do something. If it is easier than an email, people will use it. It also needs to be easy for the person receiving the request to access the case even when they had no prior knowledge of that particular system.
An adaptive system needs to build over time reusable templates for reuse when similar situations are recognized in the future. It would be easy to provide a programming language of some sort to allow automation of future cases, however, this approach is not suitable because the intended knowledge workers are not themselves programmers. Effort was spent on trying to make templates that result from normal use of the system, without having to focus on programming like activities.
The second challenge with templates was deciding what is and is not significant in a previous case. In some cases a previous use of a role should create a role with the same users in it, and in other cases the role should be empty.
A third challenge is deferred templates use. Many template systems assume that the template will be known and invoked at the time of case creation. The problem is that users do not always know which template is appropriate at the creation time. Knowledge users will be handed a case to work on, without knowing anything about the case. The job of the knowledge worker is to discover the details and handle whatever work needs to be done, figuring it out on the fly. A knowledge worker needs a place to work, to start collecting those details, and later determine which template to bring in.
Restructuring Over Time
Another use case challenge is that knowledge workers don’t necessarily know what parts will be significant at the time that they start working. What might initially looks like a simple goal might turn into a major project by itself. And sometimes what is expected to be a large project turns out to be trivial.
An experimental feature put into Cognoscenti is the ability to create a simple goal, and then when it looks a little more complicated, put subgoals under it. If it continues to gain complexity, the original goal can be converted to a complete project on its own. Project can be linked to goals in other projects, as if they were that goal. Status reports can be compiled from goals across multiple projects to make it look like it is consolidate in one project. Many experiments were done with trying to make it easy for users to convert back and forth from goals to projects.
Document Repository Support
Knowledge workers are often required to use organizational document repositories, and the philosophy behind Cognoscenti is that such repositories are good for organizations in general. The designers of cognoscenti however designed features to help knowledge workers when they are required to use multiple repositories – often different document storage places for different aspects of their lives. For example a doctor may keep patient data in the clinic system, but at the same time is part of a local university research organization which has thought leading documentation in a different location, while the community outreach program they volunteer has yet another.
One of the challenges with secure document repositories is letting your coworkers who are involved in a project access the same information. For example a doctor accepts a job to verify the results of a research paper located in a secure repository, but would like their recent intern to make the first pass. There are two standard ways to do this: download the file and email it to the intern, or to print it out and give the hard copy to the intern. Both of these are unacceptable because if the document is updated in the original repository, they have no access to the updated version. It is equally unacceptable for the doctor to give the username and password for the intern to access the repository directly.
Cognoscenti resolves by using a synchronized copy. The doctor accessed the repository using Cognoscenti which places a copy of the document into the project. Now the doctor can give the intern access to the copy. But the copy is synchronized with the original – optionally in both directions – so that changes in one can easily be refreshed to the other.
As you might easily imagine this is technically quite easy to do, but making it usable for users – specifically making it easier than emailing a copy of the document – requires some careful thinking about the user interface.
Federated Case Support
Just as knowledge workers are required to more than one document repository; it is also the case that Cognoscenti will not be the only case management system that is used by the pool of people who need to contribute to this case. Therefore, Cognoscenti is designed to live in a world where it presents views of a case to others, and that other case systems will have synchronized copies of those views. There is an explicit upstream / downstream relationship between cases which can be either one way or two way. Again, this is not technically difficult, but the real research is on making what ends up being a complicated collection of capabilities understandable enough, and easy enough that users will actually use them.
Project Exchange Protocol
In order to implement federated case support across different vendors or different types of case support, the protocol for exchange of information needs to be defined independently of single implementation. Workflow Management Coalition has been working on interoperability of collaborative systems for more than 20 years, and this effort is related to the work of the WfMC. Cognoscenti represents a reference implementation of a standard protocol
The open source project, the source, executables and available documentation can be accessed from the following URL: https://code.google.com/p/cognoscenti/
An online video demo using Cognoscenti from the BPMNext conference is available at https://www.youtube.com/watch?v=x-oAAjM6Wh0 .
Plans and Directions
The goal in presenting this demo at EDOC 2014 is not to show numerous accomplishments, but rather to introduce a platform that may be useful for other experimentation in usability. The system is freely available to anyone, and runs in a non-proprietary open environment.
It is the desire of the author that Cognoscenti can be helpful in resolving some of the stickier issues around usability of knowledge work environments, by making a full collaborative adaptive case management system available for free for use in clinical trials involving real knowledge workers.
Many thanks to Fujitsu for supporting this work on the open source project.
Significant contributions to the development of Cognoscenti
came from Shamim Quader, Sameer Pradhan, Kumar Raja, Jim Farris,
Sandia Yang, CY Chen, Rajiv Onat, Neal Wang, Dennis Tam, Shikha Srivastava,
Anamika Chaudhari, Ajay Kakkar, Rajeev Rastogi, and many more
people at Fujitsu around the world.