• Robustness – The stability of an application and the likelihood of introducing defects when modifying it.
• Performance – The efficiency of the software’s application layers.
• Security – An application’s ability to prevent unauthorized intrusions.
• Transferability – The ease with which an application can be transferred to a new maintenance team.
• Changeability – An application’s ability to be easily and quickly modified.

Cast has drawn some interesting conclusions in their report. Here are a few I found notable.

• The most secure applications seem to be large COBOL applications in the financial and insurance industry (that should be reassuring to everyone). The least secure applications were written in .Net.  Yikes!
• J2EE applications scored worst in performance, primarily because of misunderstood technologies and frameworks.  Another contributing reason could be the high degree of modularity inherent in J2EE applications.
• Transferability scores for applications in the government sector scored lower than in any other industry sector. Being a government contractor, this one strikes close to home. What conclusions or insights can be gleaned from this finding? One insight the report draws is that government agencies are spending ~73% (on average) of their IT budgets to maintain existing applications — more than any other industry sector. I ask you, where is the money in government IT contracting?
• Transferability and Changeability scores were highest for applications developed using a classic waterfall style methodology, as opposed to an Agile methodology. Whoa! I didn’t see that one coming. (Cast found that the other three categories, Robustness, Performance and Security, were about equal between waterfall and Agile methodologies.) Perhaps because Agile projects are in a continual state of refactoring that they are never in an ideal state to be transferred.

All of the deficiencies identified in this report are termed “technical debt” and have an average cost (according to Cast) of $3.61 per line of code to repair — except for Java, which rings in at $5.42 per line of code. That’s a lot of money and consumes an enormous amount of IT budgets.  For the roughly 365 million lines of code used in the study, that’s $1.3 billion of technical debt.

In conclusion, let me quote from Cast’s own conclusion, who I think said it quite well: “The observations from these data suggest that development organizations are focused most heavily on Performance and Security in certain critical applications. Less attention appears to be focused on removing the Transferability and Changeability problems that increase the cost of ownership and reduce responsiveness to business needs. These results suggest that application developers are still mostly in reaction mode to the business rather than being proactive in addressing the long term causes of IT costs and geriatric applications.”

The 22 page executive summary can be downloaded from Cast here.
http://www.castsoftware.com/resources/resource/email-campaigns/cast-report-on-application-software-health?gad=HPH

A long time ago I posted this blog.  I had not realized it was over a year ago, but I will continue on with more information around the Export.  I chose to use VB6 as it was the easiest way to start working against eRoom’s API’s.  John and I discussed whether we should attempt to migrate against the eRoom database tables or use its API’s.  It was decided to go down the path of using the API’s which should provide more flexibility going forward.  Though I do still like the idea of migrating from the database directly.

The design of the export piece is fairly simplistic.  Start at the top of the eRoom structure and walk each branch outputting all associated metadata into a well formed XML document.  The goal was to have as much data as required to recreate it all again in another eRoom instance.  [Note, we have not actually written a Load module for going into eRoom.]

For the most part, in the code, every object can be treated as an IERUItem.  This helps with creating helper functions as we can simply pass this object type about.  The next important step is to determine the properties that are part of IERUItem by which you can further derive information.  By doing this you open up a host of new goodies to delve into.

For example is this item a container.  To find out check the property isContainer (which is missing from API help document).  A container is a way of grouping other objects together.  Kind of like a folder.  If a room is being exported, first the groups and members are put into the XML, followed by properties relating immediately to the room, then a container element is identified.  The Exporter takes a depth first approach, so a list of all items in the container are identified and the process continues.

One thing to note, a visual debugger is your friend.  The API documentation is good up to a point.  Then you realize that some object properties were left out of the documentation or property values may not be quite what you expected them to be, like properties may not be instantiated if they are not relevant to the object.  Once the gaps are filled in it becomes quite intuitive working through eRoom structures.

Currently, the user can export all of the communities or facilities, or selected rooms.  The design thought running behind this was to be in the position of exporting rooms to the repository of choice.  In other words, if marketing and legal have all their content within the same facility but would like them to be in separate repositories, this can be accommodated.  Actually it can be accommodated in a couple of  ways.  At the export setup, you can export specific rooms to be designated for specific repositories.  All of the necessary metedata will still be exported (i.e. users, groups, etc.) with each room.  The result is multiple export.xml files.  Then at ingestion time, the user would ingest each export.xml and associate it with the appropriate repository.  The other method would be to export all rooms and handle the repository association at ingestion time.

Some thoughts around improving the Exporter Tool is around further investigation into the eRoom XML Query interface.  This opens up more options for different programming languages and different thoughts around the overall export.  Of course, it could open up more gotcha’s as well  The next exciting installment around eRoom migration will be around the transformation tool.  Now that we have all this wonderful XML, what do we do with it?  This is were things really start to get interesting as what will the eRoom XML output be transformed into?

So who else has been looking at their eRoom environment wondering when and how they are going to migrate away from their legacy system?

Not surprising, the top 25 most dangerous programming errors contain some well known programming mistakes that have been with us for years (decades, in fact).  For example, the first error discussed in the report is SQL Injection.  Using
improperly escaped special characters in a SQL query, hackers can steal and/or highjack your data. Skeptical?  Ask Sony Pictures, PBS and MySQL.com, they were all victims of attack this year enabled by this common programming mistake.  It is
unfortunate, because with a little effort, this programming vulnerability can be easily mitigated.

Also, still in the top 5 is the classic Buffer Overflow problem. This mistake allows hackers to inject more information into a field or variable than it can handle.  The resulting “overflow” can contain malicious code and grant hackers access to your system, plant viral code, or simply crash your system.  Buffer overflows have been around for decades.  Too bad, since these too can
easily be corrected.

Other common mistakes include:  OS Command Injection, Cross-site Scripting, Hard Coded Credentials, Unrestricted File Uploads, bogus or flawed cryptography, and Open Redirects.  As detailed in the report, all of the errors are very simple to correct and prevent.  It would server everyone well — developers, testers, designers, managers and users — to be aware of
these errors, how to identify them, and most importantly, how to mitigate them.  Give it a read, it is well worth your time:  cwe.mitre.org/top25.

I have a project that I wanted to add a couple buttons that would allow the user to navigate away from a “Drop-Off” library to the libraries where files are directed by my content organizer rules. So, without thought to SP Designer I opened my VS 2010 and commenced to coding. The great thing about building your buttons in VS is the flexibility you have – but being so flexible means you have to build a lot even if you only want a little!

In this instance I only wanted my buttons in one library. Using VS2010 you start with an elements.xml file. Unfortunately the elements file can only point to a “type,” not a specific library or list. So, even though I only wanted to see my buttons in my “Drop Off” document library, all the document libraries would also display the buttons. You can certainly get around that by omitting the type and buttons and code them in or setting visibility, but I haven’t done that myself so I was less interested in getting the coding right and figuring out where to insert the coding.

Enter SharePoint Designer 2010. It provides an easy nterface for creating custom actions that aren’t complex. You can create buttons that will navigate to a form, initiate a workflow, or navigate to a URL. Even better, it only applies to the document library or list where you are adding the custom action – exactly what I wanted!

You can certainly add an image to your button – this was something I overlooked initially and was driving me crazy that I “couldn’t” add a button image! Well, of course you can add an image. Just move that scrollbar down on the side of the “Create Custom Action” screen to get to the “Advanced custome action options” – duh!

So, a couple limitations right off:

• You can’t create tabs, groups, or context groups with SP Designer so far as I can see
• SP Designer placed my buttons in the “Manage” group of the “Documents” tab. There does not appear to be anyway to direct your buttons to a specific ribbon group or tab that you might prefer.

In this case the SP Designer provided all the functionality I needed and saved me time I would have spent coding, testing, and deploying!

Let me tell you a story about SharePoint, Alfresco, design choices, and downloading files.

My Java-based application uses SharePoint 2010 to store files.  CMIS is the obvious tool for my app to talk to SP 2010, and in fact, CMIS and SP2010 work just fine together, as you may have gathered from my colleague Tim Lisko’s last few articles.

So it came time for me to write the download feature, thus allowing users to download the files stored in SP2010 from my application.  Chemistry makes it very easy to retrieve a file object by ID:

So I said to myself: OK, I’ll just construct a URL including the CMIS object ID, then I’ll pass that object ID straight through to my Java method.

All you guys that have used CMIS against both Alfresco and SharePoint (hi Colin!) know what’s coming next.

SP2010′s object ID looks like this: 42-512.  So my URL’s looked like this:

http://<host>/<context>/docs/download/2316/42-512

No problems here!  A nice valid URL, and my download code worked great!

So yesterday, I had an idea (actually, my boss had the idea). Let’s stand up the app against Alfresco!

Alfresco’s object IDs turn out to look like this:

workspace://SpacesStore/ecd60ff9-adbb-45fb-824d-9bc93aa61b0f

Which turned my download URL into this grim-looking thing:

http://<host>/<context>/docs/download/2316/workspace://SpacesStore/ecd60ff9-adbb-45fb-824d-9bc93aa61b0f

I’ll leave what happened when I clicked that link to your imagination (hint: it wasn’t pretty!).

Since I wanted to be up and running on Alfresco pretty quickly, I applied a short-term fix: I replace the colons and slashes in the object ID with strings that should not be part of any real object ID, and my download controller reverses the process.  Now my URLs look like this:

http://<host>/<context>/docs/download/2316/workspace-c!–s!–s!-SpacesStore-s!-ecd60ff9-adbb-45fb-824d-9bc93aa61b0f

The good: the download code works again.  The bad: I shouldn’t have to encode and decode my own download URL this way!  The ugly: as you can see, the aesthetics of the above URL leave a lot to be desired.

The long-term fix (by “long-term” I mean “by Monday”) is to not place the object ID in the URL in the first place, and use an opaque sequence-driven numeric database ID instead.  Then all my URLs will look like this, no matter what repository is in use at the moment:

http://<host>/<context>/docs/download/2316/42

Why didn’t I do this in the first place?  Well, I certainly should have.  For the most part I would never use a natural key such as the CMIS object ID in this situation.  I’m pretty sure I was trying to avoid a database lookup.  In the end I needed to do a database lookup anyway, but it never occurred to me to rethink my earlier design choices.

Consider this…do the following kinds of statements mean the same thing to everyone involved in your projects?

“We’re a RUP shop” ”They are CMMI level four”, ”This is an ITIL project”, “Our team is Agile”, “This client RFP specifies a Waterfall approach”.

RUP is a process framework whose creators intended it to be extended and individualized. CMMI levels are attained with great effort, but there is no assurance that they are adhered to or even appropriate in each project. ITIL is a vast collection of codified practices across multiple disciplines. “Agile” can just mean “we’re flexible” or it can suggest a strict adherence to SCRUM.  A Waterfall approach, one iteration and you’re done. Really? You and your team are all in the same boat, but are you sure you are all on the same page?

Danger sharpens the senses. What would our approach be if our lives depended on it? How would we heed Mr. Santayana’s warning? Would we all be in it together?

The Challenge:

Imagine this Associate Press headline:  First Team to ‘Barrel Drop’ Niagara Falls in Homemade Vessel Wins $1m. Maybe not even that far-fetched given the proclivities of today’s uber wealthy eccentric!  We may also find stories of some of the early Niagara barrel drop pioneers. Both tragic and fascinating. But what might we learn from them. Do they apply to us? And do we really need to go all the way to Niagara Falls to get it?

In October 1829, Sam Patch, who called himself “the Yankee Leapster”, jumped from a high tower into the Niagara gorge below the falls and survived; thus began a long tradition of daredevils trying to go over the Falls. On October 24, 1901, 63-year-old Michigan school teacher Annie Edson Taylor was the first person to go over the Falls in a barrel as a publicity stunt; she survived, bleeding, but virtually unharmed. Soon after exiting the barrel, she said, “No one ought ever do that again.”

Does Annie Taylor’s warning sound familiar? By the way, several later daredevils did not fare so well, and it wasn’t until 1989 that a team of two successfully made the plunge, and by successful I mean they lived to tell about it, once they paid their fines and were sprung from jail.

How dissimilar is this fictitious challenge to the last internal project or RFP your team agreed to take on, knowing full well of the perils that await you, and of the rule bending you might engage, in order to assure your team’s success? In both cases success depends largely on user and sponsor acceptance of the project deliverable.  The aforementioned eccentric uber wealthy provocateur  will only pay up if your team goes down together and is the first to successfully live to tell the story! What approach would you take? Would you take lessons, learned and not learned, from Sam Patch, Annie Edson Taylor, and those who followed them over the waterfall?

As I studied the fate of many a Niagara daredevil (I blame the History Channel!), I marveled at how dissimilar each of their designs were, and wonder how closely each of their approaches mimicked current software development methodologies. From pictures I studied of actual “barrels” used in both successful and unsuccessful attempts, it appears none of them borrowed or learned much from those before them. In one tragic example, a daredevil attempted to repeat his successful Niagara plunge elsewhere, but he failed to adjust his requirements properly to the new environment.

On July 2, 1984, Canadian Karel Soucek from Hamilton, Ontario successfully plunged over the Horseshoe Falls in a barrel with only minor injuries. Soucek was fined $500 for performing the stunt without a license. In 1985, he was fatally injured while attempting to re-create the Niagara drop at the Houston Astrodome. His aim was to climb into a barrel hoisted to the rafters of the Astrodome and to drop 180 feet (55 m) into a water tank on the floor. After his barrel released prematurely, it hit the side of the tank and he died the next day from his injuries.

I learned many of these daredevils had used the non-iterative one shot “waterfall approach” that Winston Royce first described and warned us about in a software development article he wrote in 1970. He neither endorsed nor named this approach, but only observed that it had become prevalent as software started being used by people other than those who had written it. Winston thought it was a bad idea, instead favoring an iterative approach, but waterfall non-the-less became the adopted standard of the United States Military, and later, the standard of Governments, consultancies, and companies throughout the world.

An “If your life depends upon it” approach:

If it is your team chasing the $1m, or even $3m for doing the plunge three times in a row, would you use a pure waterfall approach to go over the waterfall, or would you gather all of the collective knowledge of your team and do something else?

My money, and life, is on an Open, Agile, ITIL, RUP Waterfall hybrid approach. So…this does sound like an attempt to string together as many buzz words as possible in an effort to sound clever. But…you maybe surprised to recognize that even if your most successful projects fall squarely in one camp, they do borrow from the rest, even waterfall.

Open: No romance for “not invented here, or by Microsoft, etc”. An open source approach frees a team to borrow well documented and rigorously tested code from the community and use it without the burden of procurement or finance. There is little or no hard cost to trying multiple options, and creating solutions using open source projects as tools and building blocks.

There are currently over 250,000 projects available on Sourceforge, complete with user generated reviews and adoption metrics giving the user helpful information about each project, and world class commercial support available for most enterprise offerings.

Similarly, there are numerous options for canisters [barrels] that could be dug out of salvage yards and re-purposed for the barrel drop “application”. How about old brewers casks or refinery tanks that could be fortified and made habitable? They are already built and readily available, I bet we could even get a bunch of specifications regarding strength and durability that would give us clues as to which is most suitable. Think “Junk Yard Wars”.

This might not be a direct correlation to the open source movement, but it’s close. How many web applications are out there that are “pure Microsoft”, yet leverage the open source Hibernate project for persistence? Uh, pretty much all of them.

Agile: We could study the successes and failures of previous Niagara drops, treating those as initial iterations, and continuing with an iterative approach, tossing a few of our own iteratively developed designs over the Niagara after having equipped them with crash test dummies and sensors borrowed from nearby abandoned automotive plants. Unless it is a complete failure, our first prototype eventually becomes our production model, presumably with minor changes and additions in subsequent test iterations all the way up until “production”, and then perhaps even between  drop [iteration] two and three.

This notion was first explained to me by an old friend and colleague, Jon Kern, who in 2001 co-authored the Agile Manifesto. He and that cadre have come a long way since, and we owe them a great deal. Words to live and work by, and in this case, literally. Reprinted below verbatim.

We are uncovering better ways of developing software [barrels]by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software [barrels] over comprehensive documentation

Customer [inhabitant] collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

And regarding testing, and the Agile/”Extreme” notion of build the test before the code, well, Niagara Falls itself is the test, and it certainly is already built.

ITIL: The Information Technology Infrastructure Library delves into some pretty specific managed service delivery disciplines with a collection of well documented practices, but at its core it is a simple framework for producing repeatable results. ITIL prescribes an approach where one enters and addresses lowest hanging fruit in a continuous cycle of Strategy, Design, Transition, Operation, and Continuous Improvement.

Just makes too much darn sense not to use the ITIL foundational framework to approach this challenge. Keep in mind we are planning for a second and third drop. ITIL owes much to W. Edwards Deming.

RUP: Rational Unified Process is an iterative process framework which supports a one size and shape does not fit all approach to process, but does provide a standardized language around which groups can define and communicate their approach. We owe the term “Use Cases” to, Ivar Jacobson, one of the “Three Amigos” of RUP. He once told me that he blamed the term on his poor English skills, stating that what he really meant to say was “usage” cases. Creating a shared understanding the desired usage of a deliverable is central to success in delivery, and is a central element of RUP, and if RUP is not “Agile”, it is certainly iterative, and with RUP, everyone agrees on what the definition of “is” is.

Waterfall: One shot at requirements analysis, design, implementation, testing (validation), integration, and maintenance? No thank you. But on the other hand, how much iteration is required? Seems in this case the requirements are fairly binary. A reasonably safe and reusable Niagara barrel suited for five occupants and built on a low budget. Hence the statement which I have heard often repeated has some validity here, “a waterfall approach is best in situations where the requirements are well defined and unlikely to change”.

We think Annie Taylor took a pure waterfall approach (pun unavoidable) as no evidence to the contrary exists.  But would you?

Why? Because you have to get right down to the user level and find out what they need and the context about how they think about the information.

So, let’s think about structured data and how it affects the user’s ability to locate and use the information in the content management system; in other words the search function. The textbook approach is to define the search precision and recall ratios for the system. Search precision being defined as the ratio of relevant (as judged by the user) items retrieved to the total number of items displayed in the search results list. And recall being defined as the ratio of relevant items retrieved to the total number of relevant items in the area being searched.

I mention these terms and definitions because I know many of my traditionally IT trained professionals like to follow the textbook and have their workshops and whiteboard sessions and generate flow maps and UML diagrams. But, in projects I’ve been involved with, the terms search precision and recall are never mentioned. However, here is the typical search discussion I’ve witnessed:

• Interviewer – Ok, how do you want to search for these documents?
• Interviewee – Well I search all the time for data A, data B and data C and it sure would be nice to search on data D and data E.
• Interviewer – Ok, great, we already have identified attributes for data A, C and E, we’ll make them searchable for you. And we’ll add searchable attributes for data B and D.
• Interviewee – You know sometimes I don’t really know the data to search on but I am looking for some text inside the document, is there any way I can search on text?
• Interviewer – Oh yes this system has the ability to do text searches on any documents added to the system.
• Interviewee – Great!

One of the critical success factors of a content management system is user satisfaction with the search and retrieval. Research consistently indicates that most users won’t make more than two or three attempts at finding the information they need. (Think about your own experiences using Google.) Search is typically driven by structured data. Fail to pay attention to the structured data driving the search functionality and you’re already placed one of the critical success factors at risk.

I never use the terms search precision and recall anywhere in the design criteria. The terms are just too hard to use quantitatively and what’s relevant to one user may not be relevant to another user. But the concepts need to be firmly in mind when users are being interviewed about their search preferences and habits. Users are remarkably tolerant of search as long as they get the expected results. Unless searching using a unique ID field like document number, users expect to sift through a results list to find the document of interest. How big result listings are they willing to sift through to find the document they are looking for? 10, 50, 100 results? That’s the blend of precision and recall you’re looking for in the interviews.

Much of my work has been in the area of engineering information in the utilities and oil and gas sectors. A favorite attribute that everyone wants to search is the equipment tag number. Drawings show equipment tags; procedures describe operation, maintenance and testing of equipment; specifications and calculations provide design information for equipment; vendor information tells how to maintain and order spare parts for equipment and so on. Lots of great indexing options! Great let’s add those attributes into the data model.

Stop! This is where the dirty works kicks in.

Does anyone index that information now? No, then how will the information get into the new system? What’s the source of the equipment tags? Is it validated? Who will be responsible for the information? When will it be complete and how will it be maintained up to date?

Users will tolerate the search feature up to a point. But, when an attribute is available for searching that sets the expectation of a high search precision it should be fully functional. If there’s little indexing or controls to support the search attribute then two bad things can happen. User frustration starts to set in or worse, a business decision is made without a possibly key piece of information. It is our responsibility as the content management professionals to do the dirty work and let the client know the possible implications of adding this attribute.

So let’s say the user community is ok with a low search precision % but high recall % listing for the equipment id search example. (Or in other words a result listing of 50.) How does a good structured data design support this result?

See my next blog entry: structured data and a business classification scheme in support of search and other design features…

• 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.

So, how can you achieve “doneness” in software development? There are, presumably, lots of ways…and likely at least one or two not based on divine intervention! Based on our experience, doneness in development (particularly in large projects) is not as much to do with having a cadre of stud developers but having a thorough, systematic and review-laden process that is consistently adhered to. Who knew?!

Here is the gist of our approach to doneness (formal review steps are highlighted in brackets—cannot proceed to subsequent step unless review passes successfully):

Code Design

1. Document requirements (or change to requirements) to scope level
2. Get client signoff (FORMAL REVIEW)
3. Document code design, changes to object model, peer review
4. Review design (FORMAL REVIEW)
5. Update system design document

Implementation

1. Implement test cases
2. Implement compiled stubs
3. Review Stubs (FORMAL REVIEW)
4. Implement services
5. Integration code
6. Code review (FORMAL REVIEW)
7. Update documentation
8. Documentation review (FORMAL REVIEW)
9. Implement review changes
10. Final commit and addition to main build

The case management system may not and probably should not be the evidence management system; however it should integrate with the evidence management system.  At a minimum, the case agent(s) need to understand the chain of custody of evidence associated with their case.  It would be better if it provided richer features like allowing the case agent to request evidence for charge out, reporting on state of evidence within case, electronic representation of evidence (i.e. picture) or etc.  The evidence administrator ensures that the evidence can be found when it is needed for whatever reason. 

The case management system should provide records management services. If deigned correctly, this will be transparent to the case agent.  As you clearly stated in “The People of Case Management”, the system has to make it easy for officers to document their investigation.  The records management system will ensure that the case adheres to the organization’s retention and disposition policies.  The records administrator maintains the file plan with its associated policies and enforces them during the lifecycle of the case. 

The evidence and records administrator supports the case agent by ensuring that physical and electronic material is tracked and available during the lifecycle of the case.