John Newton, Alfresco Founder and CTO, has started a blog. He’s started out strong with insightful posts on his work with the AIIM iECM initiative, big picture ECM architecture issues, and the ECM market in general. I’m looking forward to more. Go, John, go!
In his latest response in our ongoing discussion about the problems with workflow, James Robertson makes two excellent points:
- People often abuse “exception” or “fast track” workflows; and
- Flexibility in who performs a workflow step is often a key consideration in creating adaptable workflows
Regarding the abuse of exception workflows, this is sort of a damned-if-you-do-damned-if-you-don’t situation. At some clients content authors/content managers have considerable power with regard to how and when their content is published. When you automate the process, depending on the publishing scheme you’ve implemented (e.g., batch versus real-time), some of that power could be diminished. If you don’t implement exception-handling workflows you’ve decreased the service level and increased frustration.
One answer is to implement a “fast track” workflow that bypasses normal approval processes and goes straight to the public site. As James points out, this has the potential for abuse. I would like to think that abuse could be easily identified and dealt with.
This type of exception handling wouldn’t be appropriate in all situations. The higher the potential for abuse or exposure to risk due to the wrong thing getting fast tracked, the less you’d want to take this approach.
The second point James makes is that, often times, there are an exceedingly large number of factors that play into who should be involved in a particular workflow step. There are a couple of things you can do here. The workflow technology being used has got to allow for the programmatic determination of the workflow step performer (one or more specific individuals, groups, roles, etc). In my opinion, that’s table stakes for a usable workflow solution. Assuming that is the case and assuming the business rules are reasonable, you can programmatically determine the performer.
If the factors are so numerous or complex or subjective that the performer cannot easily be programmatically determined, the person who starts the workflow can be empowered to manually choose the performer. (Again, assuming the underlying workflow solution allows this, but this seems like a fundamental feature). I know there are business cases where letting someone pick who performs a task are simply out of the question, but it is something to consider.
If you can’t code it and you can’t trust the initiator to pick the performer then it certainly will be difficult to create a practical number of workflows to handle the process.
I agree that when processes are not highly-formalized it can be tough or impractical to implement a workflow that deals with all possible scenarios. I agree that formalized workflows are probably not appropriate for the content authoring stage which is usually highly collaborative. And exceptions will always exist–it helps, for example, if you can put an emergency or “fasttrack” workflow in place to handle some of those situations where there isn’t time to go through the normal process.
I disagree, though, that a completely new metaphor is needed to implement something like task management. What is a task? It’s really just a step in a process. James is looking for a way to have the number and type of tasks be more ad hoc. For that why not implement one single-task workflow for each type of task with the performer being selected by the person who initiates the workflow?
For example, James gives “review”, “update”, and “add additional detail” as three examples for types of tasks. If someone wants one or more folks to review a piece of content, start a “review this content” workflow. If content needs an update, start an “update this content” workflow. Don’t think you can name all of the types of tasks you might need? Implement a generic “action needed” workflow that the initiator could further define in workflow comments or instructions.
It just seems like it’d be easier for everyone (vendors, customers, developers) if we could stick to the well-known workflow metaphor.
Optaros has followed up their fairly recent open source WCM white paper with an overview of the leading open source document management solutions called, “Unleashing the Power of Open Source in Document Management”.
People new to document management but not necessarily considering open source might still want to take a look at this. Almost half of the paper is on general document management.
Alfresco recently hired Kevin Cochrane away from Interwoven to help them get their WCM offering rolled out. TechTarget.com has an interview with Cochrane.
Trying to get caught up on non-biz-related blogging, here are my latest CD acquisitions…
Kicking Television: Live in Chicago, Wilco. Love it. If you are a fan of the newer Wilco stuff (Yankee Hotel Foxtrot, A Ghost is Born, etc.) you have to get this. There are even a couple of tracks from the Mermaid albums.
Live at Stubb’s, Matisyahu. Matisyahu is a reggae artist who happens to be a hacidic jew. Heard his single on a Paste compilation (Heights, I think) and liked it a lot. How can you go wrong with reggae?
Heavy Ornamentals, The Gourds. My favorite Gourds album in a while but may still not be as good as Cow, Fish, Fowl, or Pig. This one somehow seems a little less “out there” than previous Gourds albums–I can’t put my finger on it.
dither, moe. I seem to be on a “jam band” kick lately. This is my first moe. album. (Yes, there’s a period there–not sure why). It’s a little less funky and maybe even less jam-y than I hat expected/wanted. A couple of the tracks could actually get airplay on mainstream radio.
Pizza Deliverance, Drive By Truckers. I like this album a lot. It is a remaster of some old stuff by DBT. It’s much more alt.country than their later “70’s stadium rock” releases.
One Step Closer, The String Cheese Incident. First taste of these guys. I like it and I’ll keep buying their albums but I don’t play this one over and over. Maybe my problem is that I tend to compare all of these jam band albums to Phish which leaves me feeling a little disappointed.
There will be a Light, Ben Harper and the Blind Boys of Alabama. I’m not a fan of gospel by any stretch of the imagination but I love Ben Harper and this is a great album. Ben’s got a new one coming out March 21.
Okemah and the Melody of Riot, Son Volt. Son Volt is back and I couldn’t be happier. I do like Jay’s solo stuff but the straight rock-and-roll sound of Son Volt is my preference. Go for the “dual disc” option to get music on one side and a documentary on the other.
Get Behind Me Satan, The White Stripes. If you liked the previous White Stripes albums you’ll like this one because it is very much the same. But hey, it works.
Ship it! A Practical Guide to Successful Software Projects, Jared Richardson, William Gwaltney. A short book and an extremely quick read. The book is a set of tips for practical improvements software development teams can make to their project execution. The general tips are no-brainers: use automated builds, source code control, bug tracking, etc. But the specific advice on how to implement these is very good. The authors provide tips for getting started as well as how to know when you’re doing it right. Even though our practice is doing pretty good on most of this stuff I still found several good nuggets worth implementing. We’ve ordered copies for the whole practice.
Go To: The Story of the Math Majors, Bridge Players, Engineers, Chess Wizards, Maverick Scientists and Iconoclasts–The Programmers Who Created the Software Revolution, Steve Lohr. The title says it all. This book reads like a collection of magazine articles arranged in rough chronological order on topics starting with Fortran and eventually making its way to the Open Source movement. This book can be enjoyed by readers with or without technical backgrounds. Those in the tech industry will probably find some of the stories insightful but you’ll have to put up with the occassional explanation for the non-techies in the audience (like what WYSIWYG stands for or the broad brush description of object-oriented programming).
I am Charlotte Simmons, Tom Wolfe. This was the first time I’d read Tom Wolfe. I loved it. He’s got quite a unique and engaging style of writing. The novel is about a small town girl who graduates at the top of her class and learns a lot about the real world at college (major understatement). The secondary characters–a basketball player, an intellectual elitist, and a fraternity member–have stories that are intertwined with Charlotte’s. I found that those archetypes ran pretty true to life. The book is sort of like the movie Crash–there’s something not to like about each of the characters. It’s a long book but quite a page turner. Unlike some books that sort of fizzle out at the end, this one left me really keyed up–I was really frustrated. Not with the writing or the ending per se but with the characters. It’s not often I read something that makes me want to strangle one or more of the characters. That’s a good thing.
I began the transition from racquetball to squash this afternoon. One of the downsides of the Hitachi Consulting acquisition was that our Navigator-paid health club membership was no more. Unfortunately for a few of us regulars, there just aren’t that many courts around. The place Nav paid for was one of the few choices, but hard to justify with Christy already having a membership closer to home. So, I added on to Christy’s membership at Lifetime where squash is the only option.
My first stop was to a few sites to learn the rules (World Squash) and the difference between squash and racquetball.
First, the racquet. A racquetball racquet looks like a stubby tennis racquet. A squash racquet looks more like a badmitton racquet and has a smaller head. I was worried it would take some getting used to but the transition was very natural so no worries there.
Next, the ball. In racquetball, the livelier the ball, the better. In squash, apparently, the really good balls are extremely dead (In fact, I have no idea how you know when your squash ball has gone bad). The first time I dropped the squash ball on the court I knew I was in for something different. It hit the court with a thud, maybe bounced a half inch off the court and just sat there. A racquetball would have bounced about fifteen times, bounced out the door, and down the hall. The ball does get a bit more lively as it heats up during warm up and game play. A squash ball is significantly smaller but that didn’t bother me.
Balls are rated by their bounce. Double yellow dots indicate that the ball will need lots of action to get it going. See this site for more on ball ratings. Of course I thought “pro” was marketing speak for “our best ball” so that’s what I got. I don’t know if that’s what most beginners do. We’ll see.
Finally, the court. The court is smaller than a racquetball court but because you aren’t getting much bounce you’ll swear you are running the same amount if not more.
A squash court has several markings not present in a racquetball court. In racquetball you can serve anywhere between the two lines on the floor. Left side, right side, center, it doesn’t matter. After hitting the front wall, a serve can land anywhere in the back half of the court. During play, the ball has to hit the front wall but can hit any other side wall including the ceiling.
A squash court, on the other hand, has two designated areas from which your serve alternates. A served ball must hit the front wall (in a specific area, see “service line”, below) then land in the opposite quarter, like tennis. After the serve the rules are like racquetball except for the out lines which I’ll discuss shortly.
The part that takes more getting used to is the “tin”, the service line, and the “out” line. The tin is, literally, a piece of metal that runs across the bottom of the front wall. It’s OB. This is good for two reasons: First, anything hit that low could never be returned. Second, it eliminates the problem in racquetball when you have to rely on the “squeak” to know if the ball hit the floor first or the wall first. When a ball hits the tin you know it. The problem for us racquetballers is that a really low shot is a really great shot, usually, so I was whacking the tin with some regularity.
The service line runs across the front wall about halfway up. The serve has to hit the front wall above the service line but below the out line.
The out line runs around the entire court at varying heights. Anything on or above that line is also OB. That rules out ceiling shots, high shots off the side wall, and long lobs that come off the front wall and hit high on the back wall. But, again, because of the dynamics of the ball, we didn’t see too many balls hitting that high unless they were really bad shots.
See the World Squash court diagrams to get the picture.
I’ll miss racquetball. When I was really in the zone I felt like I had time to slow down and analyze the shot before making it–picture “bullet time” photography a la The Matrix. My racquetball mantra was always “patience”. Maybe once I settle in to the Zen of Squash I’ll be able to recapture that.
Today after hitting around a bit with Christy to get used to things I was able to pick up a game with a guy who plays regularly. I was happy to find it was every bit as physically and mentally challenging as racquetball. (And I was happy to see that some of my racquetball skills were still put to good use–he didn’t skunk me).
One thing that killed me was corner shots. In racquetball if someone puts it in the corner you can usually dig it out because there’s enough bounce left for you to get under it. In squash maybe good players can dig out a corner shot but I found that if I let him get to the corner I was dead. Another was the back wall. Hitting off the backwall is a common racquetball shot. A successful back wall shot is more geometry than muscle. In squash you’ve really got to crank it to have a hope. I never saw my opponent try it. I tried several times out of habit and never came close.
So there’s another acquisition transition item taken care of. On to the next one.