Enterprise Content Management

Armedia Blog

Archive for January, 2010

What is Case Management?

January 29th, 2010 by dmiller

Armedia writes about case management, and we help our customers implement case management solutions.  But what is case management in the first place?  Ubiquitous language ensures that clients and consultants mean the same thing when they use the same words… a fancy way of saying: “make sure everyone’s on the same page.”

Case management obviously helps customers manage cases. So let’s back up and define a case.

A case is an incident of interest to some organization.  Law enforcement organizations have crimes.  Software development projects have defect reports.  Mortgage companies have loan applications.  Insurance companies have claims.  Crimes, defect reports, loan applications, and claims are numbered, tracked, and managed by these organizations.  They are all cases.

So we know what a case is.  A case also has stuff associated with it.  A case has people assigned to it; a history of actions taken by these people; tasks to be performed; relevant documents; a status; and a resolution.

The case agent focuses on the case and all its associated stuff.  That’s how crimes get solved, mortgages loaned, claims processed, and defects fixed.  The organization also pays attention to the collection of cases.  Data mining helps the organization improve.  How many cases did we process?  How much time to close a case?  Do we need to pay more attention to this kind of case, and less attention to that other kind?

Case management is how the organization manages a case and its stuff.  Case management is how the case agent defines, tracks, documents, and closes cases.  Case management helps the organization reflect on past performance and optimize future performance.

Nothing I’ve said so far implies anything about electronic support for case management.  Banks, law enforcement, and hospitals have managed cases for hundreds (even thousands) of years with no computers!

An electronic case management system should make life easier for the case agent, and give the organization more tools and better information.  It sounds obvious!  But you’d be surprised at how optimal paper processes can get, after decades or centuries of tuning.  I’ve seen applications try to replace one pencil scrawl with a dozen clicks, wizards, dropdowns, confirmations, and error messages.  I can say from certain knowledge that if a system is clunky, awkward, and hard for case agents to use – they won’t use it!  All the reporting, searching, information sharing, data mining, and metrics that organizations typically want – all of it is predicated on the case agent being willing to use the system to its full extent.

OSGi for business applications

January 29th, 2010 by dmiller

OSGi is a dynamic module system for Java.  An OSGi system is a network of components that communicate via defined interfaces.  Each component is deployable, manageable, and updatable, with predictable effects on the other deployed components.  Each component can be stopped, started, deployed, and undeployed without having to shut down the component host.  Sound familiar?  This is service-oriented architecture (SOA) in a single JVM… All the goodness of SOA, with none of the badness.

If you are a Java developer, or the administrator for a JEE system, most likely you are using OSGi already.  The Eclipse development environment is OSGi-based: Eclipse modules are OSGI components.  Almost every application server is based on OSGi: JBoss, Weblogic, WebSphere.

Using OSGi for a business application should affect your design.  Most systems allocate technical requirements to components.  For the most part, these components live only in the architecture and design.  In most all the projects I’ve ever worked on, the deliverable Java code lives in big honkin’ jar files with little or no traceability back to the architecture and design.  Inside the jar file, every class has access to every other class, and the internal dependencies end up spreading all over the place.  Reasoning about the code base, or pulling out smaller features for reuse elsewhere, becomes very difficult.

In a well-designed OSGi architecture, each logical component from the architecture and design should become one OSGi bundle (the OSGi jargon for component).  Clients have access only to the public interface of each bundle; the implementation remains inaccessible.  Instead of a handful of big honkin’ monolithic jar files, you end up with many small well-defined bundles.  This direct correspondence of one architecture/design artifact (a component) to one development/runtime artifact (a bundle) is what I like the most about OSGi.

Some benefits of a network of well-defined, small components:

  1. Easy to support different implementations of the same interface.  When development starts, you can quickly release stub bundles of the interfaces your team is responsible for; other teams consume your stub bundle to write their own bundles.  As you complete real implementations of each interface, your clients can replace their stubs with the real thing, without missing a beat.
  2. Clients can upgrade only the bundles they’re interested in.  With one big honkin’ jar file, every client has to upgrade every time you release, even if they don’t need the defect fixes or new features in this release.  With a network of small bundles, each client only gets what they really need.
  3. An end to classpath hell.  The OSGi runtime can host different versions of each bundle.
  4. Supposing you are a software vendor, you can package your applications as a set of bundles.  You can offer a basic cheaper system with a few bundles, and value-added features implemented as extra bundles.  Your clients that don’t want or need a NIEM interface, and your clients that want it very much, are both happy.

There are some drawbacks to OSGi for business applications.

  1. Currently using OSGi with plain ol’ Web applications can take some work.  Products like the SpringSource dm Server aim to make this easier.  Also, the OSGi Alliance is working on Enterprise specifications to define how OSGi can be used with JNDI, data sources, JPA, etc.
  2. Java developers have to become a little more aware of design issues.  Most Java programmers I work with want to get their features implemented and defects resolved with as little time and thought as possible.  This is the very genesis of the big honkin’ jar files I keep mentioning… It takes little time or thought to slam out one more class and add it to the one big honkin’ jar file.  This problem should get easier with better tool support.  For example, the Spring Tool Suite and IntelliJ IDEA have first-class support for OSGi development.

InfoQ has an excellent series of blogs to help you get started with OSGi development: Part 1, Part 2, Part 3, Part 4.  Peter Kriens’ blog is a great way to keep up with OSGi news and events.

NIEM as it relates to Case Management

January 19th, 2010 by James Bailey

As it relates to Case Management, NIEM is very important.  The need for sharing information is vital for the war on terrorism as well as combating domestic crimes (i.e. drugs, sexual perpetrators and etc.).  Law Enforcement agencies have to be able to share case related data and NIEM sets the framework for accomplishing that.  Given that each agency has its own Case Management system that supports its business processes, security model, data structure and etc., there needs to be a common language/schema for these systems to export and import pieces or the entire case.  NIEM is that standard.

As my colleague has clearly stated in his blog, My name is NIEM, NIEM is not a silver bullet.  There are many issues to resolve:

  1. Security of information once export from system.
  2. Sharing of information between civilian and intelligence agencies – What if it contains data about US citizen?  How do we share with our international partners?
  3. What if one system does not support all data elements and during the import data is lost?  Agency could be making decisions based on limited information.
  4. When does the imported data become stale?  What if the case is active and new information contradicts the export data that has been shared?
  5. Given the limited budgets of local and state law enforcements, how do they participate in collaborating to combat crime?
  6. How do we combat data overload once data is being shared throughout the community?

These issues/concerns must and will be addressed because the alternative is not acceptable.  Our enemy wins when we allow distractions to take our eyes off accomplishing this goal of information sharing amongst the community.  As I review current and future procurements, I am glad to see the FBI, DHS and others make this a core element of their system.

My name is NIEM!

January 13th, 2010 by Jim Nasr

Those of you with affinity to old British pop culture or the unforgettable Madness of 80s fame (ahem: “my house in the middle of my street…”) will probably remember the infamous ”my name is Michael Caine” circular. Long before Rick Astley Rickrolling, poor old Michael was flavor-du-jour of everyman comedians looking for a quick, omnipresent quip. Well, forget all of that. These days, my name is NIEM!

NIEM which stands for the, inevitably, not so sexy sounding National Information Exchange Model is a formal information exchange schema developed by the US government (specifically DOJ and DHS) to further information sharing across Federal, and in time, State and Local government agencies and their business constituents. NIEM builds on from the much more bulky Global Justice XML Data Model (GJXDM) model; an off-shoot of post 9/11 information sharing initiatives. The idea of NIEM (currently in version 2.1) is to provide a consistent, non-redundant, open standards based XML schema that has some well defined entities and activities for improved inter-agency communication and information sharing.

All good…but what’s new, eh? Well, I think what is new is the fact that NIEM seems to be much more than just another academic exercise. Since its infancy in 2005, there have been multiple live and pilot projects (particularly around criminal investigation related content) at many Federal and State agencies, a set of open source tools have been developed and continue to grow, and the government (including Fed CIO, Vivek Kundra) seem more than ever to be pushing the standard and making it a part of the overall US government strategy for information sharing–see data.gov.

So, how does this apply to content management? Well, as with 21CFR11, 5015 2&4, SOX and most your other garden variety compliance oriented standards, there is an opportunity. An opportunity to become compliant (read: running afoul of the government is not a good thing if you want to work with them). And, an opportunity to be productive (read: information transparency and efficient content sharing can lead to some bottom line savings and possibly…and this is where you need to put your salesforce.com hat on…new revenue development channels).

As far as ECM goes, it seems to me that minimally NIEM would have an obvious play along the lines of Case Management (particularly for investigative records) and, in a larger context, Records Management. Empirically though it’s not there yet. Case Management is still quite immature as an offering. Though there are, of course, many solutions out there, most are heavily bespoke or still based on legacy structured data and structured data management systems. In a world of exploding DOC, PPT, PDF, MP3, FLV, et al content sources the days of pure structured content solutions are numbered. As for Records Management, despite hype to the contrary, it seems we are still very much focused on eDiscovery related records management–hail Email Archival!! I think there is change afoot though, with greater investment than ever–at least by the government–in Case Management, Records Management and information sharing initiatives.

NIEM, of course, is not nor will ever be a silver bullet. Ultimately, it’s a suggested structure for content storage and exchange. However, as with the neighbor’s grass, you could always bemoan the greener pastures…only to realize in time that with a little spade work your own grass aint half bad. NIEM can be that spade…

Copyright © 2002–2011, Armedia. All Rights Reserved.