How to Triage ECM slowness

Who’s the first team a User calls when the ECM application slows down? The ECM team of course. But, nine times out of ten, slowness is caused by effects of other systems. Whether it’s the database, network, or the User’s open applications, sluggish performance has many sources.

Question: who’s working on what client, in what environment, and where?

Network: we were fixing something

From Who: multiple sites simultaneously, or one building?

Large companies with multiple buildings most likely have networks that are somewhat patched together leaving some Users with networks that are performance subpar. Also, some areas of the company may be hugging bandwidth with applications that are dragging the whole network down.

Database: This won’t impact the application…

From Who: All applications that use that db server, or one application?

Typically, the database server is a shared environment thanks to our buddies who consolidated individual servers at the expense of “decoupling”. This shared environment could at the mercy of reporting for BI initiatives slowing it down. If it’s an Oracle RAC, sometimes the nodes don’t reboot as advertised. The shared environment of tier 1 applications, could put the other lower tiers at risk because the lower ones will not be the priority if there’s a business outage.

Backups: we were trying to restore another application

From Who: One application or many?

Backups might happen late at night during “off” hours, but there’s still a performance hit on databases and file stores. There’s also the possible wave of activity after a recovery that clogs all downstream applications.

Security: we were hacked

From Who: One app, or many?

With new layers of security applied comes extra processing thus potential for slowness. This is usually agreed upon at the design stages, but complained about after implementation.

Virus protection: half of our share drive files are encrypted

I’ve had many times when I’m looking for causes of slowness on my PC or on a server, only to find out that the task manager is showing a huge percent of CPU being used by the virus protection software. Hint: Double check when the full scan is scheduled.

User’s 5k open applications: who me?

If one User complains, log onto their PC and check out what applications they are running (assuming they didn’t close some while they waited for you). Try closing and opening Outlook. What’s in their startup folder? Check their browsing history for views and downloads.

Service Desk: this is a routine patch

Even when the Service Desk is being proactive with mandatory testing of patches to Windows or IE, there are always issues, especially with interaction of multiple open web browser (“no footprint”) applications.

Upshot

When you get blamed for slowness of your ECM application have a script of questions to ask to triage the issue. Check the possible larger issues first and move toward the User at hand. Slowness happens because everyone wants information faster, that is, in our zealousness to always get faster we stumble occasionally.

Unpacking a Workflow

Unpacking the idiosyncrasies of a lifecycle/workflow can be daunting. Many times a well designed “1.0” workflow will turn into a “2.0” nightmare. I have seen workflows with so many connections between tasks and rules that it looks like all the tasks are connected with no rhyme or reason.

Documentation

Good documentation can provide an excellent resource and general direction of the workflow. However, with large process automation projects, the documentation is usually provide for the initial implementation and left stranded thereafter.  Determine how obsolete the information is before reading it too closely.

Structure            

Worse Case: Over time, workflows can turn into spider webs. Once they are built it becomes easy to make small tweaks and fixes. These work great and the business is happy, but in the long run can get out of control. How do you document “small” changes?

Best Case: A solid naming convention makes easy to traverse through the decision branches.

Look for repeating patterns of rules and actions. These could help minimize what looks complex but is actually a bunch of redundant activities.

Naming Conventions

Hopefully the naming of the lifecycles, work queues, rules, actions, properties, etc., makes some type of logical sense. A lot can be implied in a formal name convention, for example, a lifecycle name of “HIM - Validation” which shows the department (“Health Information Management”) and the objective (“Validation”). Depending on the workflow application prefixing with “smart” hierarchical keywords is best practice, so hopefully they did it!

Search

If your workflow tool has the ability to search for specific component names and presents the results in an actionable way, figuring out workflow specifics just got easier.

Rules and Actions

Rule names can be precise and consistent, or obsolete and sporadic. If you have the former, you are lucky. This goes for actions as well. Both of these may be copied (linked) to other locations, so be careful of making changes in one spot only to be burned by the other part of the workflow that just broke.

Properties and Keywords

Many workflows rely on saving status and regular expression values to the document’s attributes/keywords. It’s important to create a matrix on how these values are set and where they are used in the process. By “properties” I mean the temporary values that are used by the workflow for calculations and routing (and logged) by not saved to the document.

Logs of workflow actions

By viewing logs you may be able to decipher some of the paths that documents take into and around the workflow. Depending on the settings, these traces might show what actions took place, when, and by whom.

Decision Trees

These are made up of combinations of rules and actions. Rules usually have a true or false outcome. Building complex decisions can mean stacking many of these rules together to provide an eventual processing outcome.

Visual representation

Whether in a tree format or a more graphical view, following the progression of a workflow visually can be very useful. With complex workflows this view becomes too chaotic looking. Splitting up the visual representation into meaningful chunks may help figure things out.

Users, Groups, and Roles

Listing out groups and roles, and matching them to activities will show certain expectations of actions. Each group/role will have permissions and privileges which will provide a clue as to how the users interact with the processing of documents.

Document flows

Running documents through a workflow is obviously one of the most practical ways to decipher workflow behavior. As an admin user keep in mind that you will be able to do and see many parts of a workflow that Users won’t be able to see.

Figuring out what a workflow does can be a very frustrating activity. Hopefully, some of the above techniques will make it more tolerable.