ArkCase is both a framework and an application.  As a framework, ArkCase provides a scaffolding to write case management applications tailored to custom-fit a specific customer.  As an application, ArkCase provides pre-built web application archives (WAR files) suitable for generic customers.  For example, we provide a law enforcement WAR and an inspector general WAR.

So we’ve known for a long time ArkCase should be both a software development tool to write case management applications, and also a standard out-of-the-box case management app.  Like JIRA is both a software defect and issue tracking application, and also a tool to specialize your own defect and issue tracking app.  Rational ClearQuest is the same way: it is both a default out of the box application life cycle management solution, and a tool to specialize your own such solution.

So how does ArkCase support these twin goals?  We all know it’s an order of magnitude easier to write a purpose-built app to specific requirements than it is to write a software development tool for other people to write their own purpose-built apps.

To write a purpose-built app we can naively map requirements to the technical architecture.  Does Customer X need a case file attribute that will never be needed by any other customer?  We just add the column to the database, add a field to our model objects, update our MVC controllers to pass the field around, and update our view to show it.  When it comes time to deliver another version of the system to Customer 99, they get all Customer X’s special fields… or else we have to make a special effort to remove Customer X’s special fields, perhaps by maintaining a branch per customer.  Shortly it becomes impossible to keep straight which customers get which fields.  We don’t really have a framework at all; we have many different purpose-built apps, one per customer.

To write a framework for building case management applications, we have to add a Core Object Model.  Then we write a standard library of components, implemented in terms of this Core Object Model.  Then we write our pre-built case management WAR files using the standard library and the Core Object Model.

For ArkCase, our Core Object Model includes:

• ArkBusinessObject – real world objects tracked by our customers (persons, organizations, firearms)
• ArkContainer – case management objects that manage business objects (case files, documents)
• ArkRelation – links (unidirectional or bidirectional) between business objects, other business objects, and containers (a vehicle contained contraband)
• ArkExternalEvent – real world events that form the history of a container (subject was arrested; a vehicle was stopped at the border)
• ArkAction – user actions that change the state of business objects or containers (split one document into two; consolidate two case files into one)
• ArkBusinessRule – constraints or guidelines that can be changed at runtime by business analysts (when a document is approved, declare a record in the records management application)
• ArkBusinessProcess – guides the life cycle of a container or business object (documents must be approved)

This object model is the set of design artifacts to write the standard component library and customer-specific applications.  The object model is the extra conceptual layer that makes the ArkCase framework different from just naively developing a purpose built application.  The proof is in the pudding; we no longer have to maintain one branch per customer; we can have a single ArkCase framework source tree, with customer-specific projects that import the framework artifacts.