Armedia Blog

Archive for July, 2010

Armedia Case Management (ACM) vs. NIEM

July 29th, 2010 by Rahul Rana

Is there any doubt that ACM wins this battle?

But how so? Read on…

Part 1 – The challenge

NIEM is an important cog in a government case management solution. At some point in a case’s lifecycle, you may need to share the case-related information with other agencies or individuals, perhaps to get assistance in completing the case or maybe to give more information to another agency for a similar case that they’re working on. Whatever the reason, this information must be easily passed from one system to the next without being ‘lost in translation’.

NIEM (National Information Exchange Model) is a framework for sharing enterprise-wide information across all levels of government. It has a core set of elements that are standard across all the agencies and has more specific ones for the various entities and stakeholders. Agencies can now speak a common language, allowing one agency to publish data from its case management system to the XML standard, which can then be picked up and parsed by another agency that requires this information.

Now all you need is a case management system that lets you export data into the NIEM standard and then a parser to put it back in.

Pretty neat and simple, n’est-ce pas?

Almost. (Let’s face it, if it really were that simple, I’d have nothing to write about and I’d just put up some comics to keep you entertained.)

There are a few problems to watch out for:

  • Before importing or exporting, the system must check the data’s security classification. A document requiring a classification level of Top Secret cannot be sent to an agency (or individual) with only Confidential level access. Perhaps only certain parts of the document are deemed to be Top  Secret, in which case, the publishing tool should be able to extract only those parts that are at the required access level.
  • Large amounts of data may need to be continuously exported to, or imported from, an external system. Every time an update is made to case data, it may be necessary to push this information out to other agencies. So it may be better to export/import only the changed data and update the existing data. This reduces the time and cost of transfer and would help to reduce duplicated data.
  • Data may be imported that already exists in the case management system. Checks need to be in place to handle matching data during import. When duplicate data is found, is it better to replace the data or create a new version of the existing data?

Armedia Case Management comes with a tool specifically to import from and export to NIEM that tackles these problems. Stay tuned for Part Two… The Solution, which discusses how ACM implements the NIEM publishing process.

Until then, here’s a comic strip to keep you entertained (don’t we all just love Dilbert)…

Think Alfresco from Documentum perspective –Take 1

July 14th, 2010 by Balaji Sampath

Open Source ...</ins>

When you work for a while in the software you get numbed to “technologies have come and gone…” occasionally though some become commodities and others trend setters. We have seen that with many products like Apache, Tomcat, Lucene, Drupal …etc that have stabilized and matured over the past years with the help of increased development from the open source realm. Wait! Did I mention the word “Open Source” and going to talk about the enterprise content management?

So without any more ado, we have Alfresco- catering to a rapidly increasing demand of the enterprise content management solutions which is built over the open source technologies such as Spring, Hibernate, and Lucene platforms. Having done years of Documentum development and several Alfresco projects of late, I think there are some interesting overlaps and differences of approach that I feel would make the developers get adapted quicker.

With the wiki site overwhelmed with Introduction, API’s, Development, Deployment and the Forums to answer all the questions regarding the issues faced during the project phase, I am here to talk purely from the developers perspective on what’s the key areas that I happen to witness the difference from the Documentum space.

The road map for my next series of blog is going to cover each of the areas mentioned below in more detailed, code abundant and developer centric approach which will answer the questions:

  • Does this feature exist in Documentum or Alfresco or both?
  • If yes, how different is the approach?

So with that preamble, and in no particular order, I give you my list of the key areas I got hands on and learnt how different Alfresco is:

Custom data model is the core for any enterprise content management solution. The use of “Aspects” as its core is the fundamental concept for content modeling in Alfresco. Although in the form D6, aspects was introduced, how different is the use and approach in Alfresco is something I will take a deep dive in my next blog.

Alfresco Web Scripts brings together the world of content repository and the web. Being a Documentum developer earlier ways of interaction with the repository have been either using DFC API’s or DQL. In Alfresco, Web Scripts provide RESTful access to content within the repository and we can build our own interface using java script. A custom move operation is implemented using the Web Scripts and the comparison of the implementation with the Documentum would be a something to be noted.

On my last project, we had requirements for the customers to be able to permanently redact Personally Identifiable Information (PII) from existing documents stored in the repository and version the original document upon save. For various reasons, we decided to integrate the 3rd party tool Daeja ViewOne module to provide this capability. I will discuss the topic as part of this blog series.

I started this series based on my experience implementing Alfresco projects and I invite you to share any of your experiences with any part of the road map wherein you run into interesting twists and turns? Did you drive off the road to get some help? I welcome your feedback as the blog takes its shape. See you all soon in Take 2.

Software design is in crisis

July 12th, 2010 by A.J. McClary

In the 90’s, when ECM solutions were rare, we could get away with designing solely toward requirements, but there is too much at stake nowadays. A recent study sampling various IT projects reported that:

  • 62% percent of projects fail to meet their schedules
  • 49% are over budget
  • 47% have higher than expected maintenance costs
  • And get this—25% are canceled before they are ever deployed!

If you’ve been in the software industry long enough, you’ve probably seen all of these things happen. The funny thing is, it doesn’t really come down schedule, cost, or requirements—it comes from bad design. When software companies think design, they’re thinking about contractual obligations and meeting commitments with their stakeholders. Here is a typical scenario:

Company wins contract. Client provides requirements. Company builds a solution, meeting the requirements. Testers validate requirements and application is deployed to a set of users. The users hate it and the client makes new requirements, company builds to those requirements, and the users hate the next iteration…and so on.

This can be resolved by utilizing user-centered design principles in your system development life-cycle. Software is not about code, it’s about people. Instead of our clients telling us what they want, we should be telling them what they need. As engineers, we can do a much better job building solutions then they can—that’s what they hire us for. To be successful, we need to incorporate user research, information architecture, interaction design, and usability testing into our process.

“Iteration 0” – 10 Tasks to Guarantee a Slammin’ User Experience

Let’s start with “Iteration 0”. This sprint is completely devoted to user experience. The point is to get out of habit of thinking of Java Beans and database schemas and start thinking about people. Here are tasks that need to be accomplished:

  1. Gather assumptions and requirements. Take some time to get acquainted with the requirements and begin to make assumptions based on your experience with the technology.
  2. Analyze competition. Familiarize yourself with the way your competition handles things. This is not necessarily the solution you should be striving for, but is excellent to have in your back pocket to show how your solution is better or to compare solutions to initiate change.
  3. Understand goals & tasks. Comprehensive user research, interviews, card sorting exercises, and contextual inquiries help identify user needs
  4. Develop personas and scenarios. Evangelize these with everyone on your team. They can be in the form of user stories, posters, work-flow diagrams, and profiles.
  5. Build a content strategy. Find out what content you have, what needs to be developed, what needs to be expanded, and what can be cut. Also create a schedule for delivering those missing gaps.
  6. Information architecture. It’s more than figuring out what content goes where. It’s also what information is most important to your users. Identify those needs and incorporate them into your design.
  7. Prioritize features. One of the greatest advantages of user centered design is that you often find some requirements barely impact your users. Those requirements can be re-prioritized so you can focus on what’s really important.
  8. Build wireframes and interaction designs. Setting expectations on functionality, how it should look, and how it should behave reduces future UI defects.  
  9. Design a prototype. Build something you can take with you to road shows that incorporates both visual and functional design. Update the prototype during future iterations so you always have an accurate portrayal of what the product will look like at launch.
  10. Validate usability. There are hundreds of techniques, including a usability inspection, paper prototyping, and eye tracking, but put something in front of your users frequently.

Points 8, 9, and 10 should be repeated throughout all future iterations until the project’s completion. When user experience drives design, you build products people love to use.

Documentum-Composer

July 6th, 2010 by Aparna Thimmavajjala

It was year 2004, when I was first introduced to EMC Documentum. As I first fired up the DAB IDE, I felt man this IDE is Unintuitive, slow and cryptic. Apart from learning the DFC API’s in Documentum, getting accustomed to DAB itself was an excruciating experience. Finally after three years Documentum Composer came as a savior.

I liked Documentum Composer for 3 main reasons:

1. It has better interface than DAB, and its easy to use providing support for keeping multiple projects open at the same time. You need not checkout and checkin the artifacts every time you make any changes only thing you will be doing is installation of the project.

2. It comes as combined feature of both DAB and DAI where in you create the DAR and install from the same IDE into a repository.

3. Composer is built on the Eclipse platform, and the installation includes a bundled Eclipse environment. One of the benefits of the Eclipse platform is that it offers a number of paradigms that are familiar to developers thus allowing users to identify the issues at the DocApp development level instead of installation level.

Composer helps to develop applications faster and easier by reducing the learning curve through user interface consistency and the familiar standards-based Eclipse tooling framework. Composer can be run in “headless Eclipse mode”, which enables command-line scripting and automation of project installation. This feature provides self-contained, fully automated deployment of projects into a repository, without the need for a previous DFC installation or DMCL client.

One thing that I like about Composer is the ability to install into multiple repositories, assuming they share a connection broker, without restarting and on the other hand ability to work offline. To install the application or migrate the data model a user would use DAI to install the docapp archive into one or more production Docbases, where as with composer you can do both the task in one single place without the need of DAI to deploy.

It is both an artifact project, supporting artifact development, and it is also a DFS project, supporting consumer and service DFS development.

Another feature that I liked about Composer is the ability to deploy java methods as BOF module without the need for the user to copy the class files under /dba/java_methods folder in the CS location and to be able to deploy on the java method server without having to bring down the content server. Also when Business Object Framework (BOF) came out in 6.0, DAB was extended to support creation of modules which served as “container” for custom BOF code.  However, you still had to have a java environment to build JAR files that contained BOF code.  In addition, any customizations to WDK/Webtop were not supported in DAB.  The WAR build and deployment process was entirely separate from docapp installation process. Composer is an effort by EMC to come up with a single tool that help developers to Configure Documentum artifacts, Create Business Objects, Build DFS Services, Deploy Documentum applications across multiple repositories.

Once you begin using Documentum Composer the benefits are easily evident. To name a few:

  • Developing applications quickly and easily
  • Learning curve is reduced due to the consistency of user interface and familiar standards of Eclipse tooling framework

Personally I consider composer a great gift to the Documentum developer community.