Most of my colleagues can share truly lyrical reflections on the beauty of a piece of clean, well-written code. Recently however, some of our technical consultants have spent considerably less time in their Eclipse or IntelliJ environments. The recent trend among Document Management vendors to offer case management configuration frameworks has really shifted the focus from development-from-the-ground-up to composing applications on the basis of existing components.
As coding guru Martin Fowler puts it:
Any fool can write code that a computer can understand. Good programmers write code that humans can understand
I admit that initially we looked at these configuration frameworks with a fair amount of skepticism, supposing it was more marketing speak than technological reality. However, as soon as we started playing around with Documentum xCP, Documentum D2 and Alfresco Workdesk we were blown off our feet. Those frameworks allow us to configure user-friendly and amazingly powerful case management applications at a fraction of the time and cost that was needed before.
Finding the middle ground between custom built and off-the-shelf applications
One could say that these configuration frameworks take the sweet middle spot between on the one hand very flexible but time and money consuming custom built applications, and on the other hand quite cheap but rigid off-the-shelf applications.
Let me give you some insight into Documentum xCP (xCelerated Composition Platform), according to us the most powerful framework of the three mentioned. Documentum xCP offers the possibility to compose both the user interface (front-end) and the underlying complex business logic (back-end) from existing components. From version 2.0 on, all this configuration work can be executed in a single unified designer tool, xCP Designer.
Composing your user interface
For the user interface (front-end) this means that user screens can be composed by dragging and dropping user interface widgets onto a chosen layout, as shown in the screenshot below. Typically you start by defining the master page, which will contain all functionality that needs to reappear on all screens within the application, such as navigation items, the header and the footer. The master page is thus quite similar to the slide master page in PowerPoint.
Business object screens
Next, you can start composing business object screens and application screens. Business object screens are screens that create, view or update the application’s business objects. Suppose you are building a complaints management application, then the ‘complaint’ will be a typical business object with specific metadata such as type, description, severity, submission date, complaint handler etc.
Once you’ve specified the descriptive metadata for the complaint object, xCP will allow you to auto-generate the business object screens for creating, viewing and updating a complaint case and bind it automatically to the back-end services. Auto-generated screens serve as a starting point and can of course still be manually updated (changing styles, removing or re-ordering input fields etc.).
Application screens are not bound to specific business objects and are typically composed from the ground up based on the UI widgets. Examples are search screens, overview pages etc. To get some further insight in the power of this screen composition, we want to emphasize that xCP supports inter-widget communication (for example, the selection of a specific item in widget 1 can automatically update the information shown in widget 2) and that access to screens or even specific widgets can depend on the role of the user.
Composing your business logic: stateless versus stateful processes
With regard to business logic (back-end), we want to highlight xCP’s support for both stateless and stateful processes.
Stateless processes are sequences of configurable automatic tasks that are executed as a single transaction; they can be considered as the automatic execution of business rules based on specific business events.
Let’s return to our complaints case example. Suppose that the complaint handler for a specific complaint can be assigned automatically based on a combination of the complaint type and the severity (i.e. based on a specific business rule). Then we can configure a stateless process in xCP automatically computing the required complaint handler based on this business rule whenever the type and/or severity of a complaint is created or updated (the business event).
Those types of automation used to require custom coding in the past, within xCP many of them can now be configured using stateless processes.
Stateful processes are the ‘traditional' business process workflows which consist of a combination of manual tasks, automatic tasks and decision points. As shown below, xCP offers the possibility to graphically model complex business processes; in addition an extensive set of activity templates is available, which allows you to configure common automatic tasks within your business process, such as automatically changing the permissions on a case or document, moving a document or even interacting with external systems via web services.
The features mentioned above only scratch the surface, but should give you a taste of the framework’s configuration power. Also important to know: in case the configuration power should still be insufficient, it's still possible to integrate your own custom code components.
More than speed and cost
Apart from a considerable faster and cheaper application development process, the use of configuration over coding has some other sometimes overlooked benefits:
- There’s a much smoother upgrade process to new platform versions as the amount of custom development is considerably smaller.
- Projects can be executed in a more agile way, which improves end user acceptance and allows for quicker adaptation to changing business requirements.
- Finally, as existing components are being reused they are less error-prone, resulting in more stable applications.