esjewett.com

As I was reading about Google's new Google Visualization open-wire protocol API (a mouthful to be sure) and new research from Accenture indicating that "millennials" route around enterprise IT departments (don't I know it), my thoughts turned to how IT can architect its systems so that they to stop behaving as roadblocks for information workers and start behaving as enablers.

I still believe that the basic problem is one of control, but the technologies are emerging to allow for architectures that satisfy demands for control without hamstringing capability. I'm thinking of standards like OAuth and standard APIs OpenSocial or the Google Visualization API here.

A couple thoughts on this topic:

• Trust (between systems) in the enterprise has been all or nothing. With the emergence of SaaS and the integration of consumer services, this approach doesn't work anymore. Access delegation capabilities are becoming essential. OAuth is part of the answer to this issue. Standards, architectures, and UIs that can handle multiple delegation are probably the end-state solution.
• System plug-ability or mash-ability is a key component. No single vendor can deliver adequate functionality for information workers, thinkers, or process innovators across industries. Areas like these are simply not well enough understood or structured to provide a delivered solution. Real SOA and mashups, allowing users to define the architecture by dynamically plugging and reorganizing information and process flows between systems are the answer here. This type of self-service SOA for data and process is the next step after self-service reporting on data that the user can't really do anything about. Since we haven't totally figured out how to the reporting yet, I'm not optimistic that we are getting close here, but it's a goal worthy of some work. Thingamy is one view of this world on the process side. Yahoo! Pipes and Tarpipe are examples of this on the information side.

This post has turned into more of a note to myself than anything else, but there's a long tradition of using a blog for this type of activity, and since I can't seem to post in any other way, I might as well throw this up!

I've been playing around with a business process platform called thingamy lately. It's an impressive piece of work. As with all software, it has a long way to go, but the path is fairly clear. I'm looking forward to the day when it is interoperable enough that I can use it as an everyday tool.

For me, the really interesting thing about thingamy is not so much the tool or the technology (Java, semantic, etc.) as the thought behind it and the difference of approach to a well-known problem, which has gotten me thinking (yet again) about process design and some of the problems in that area. Thingamy is built around the concept of a barely repeatable process (BRP), a concept that almost immediately causes one to recognize that the cost of instituting processes is too high and current process platforms are not sufficiently robust.

What's a process?

A process is a set of tasks and decisions that is part of the daily work of getting the job done. If you work in the average office, you deal with processes on a daily basis - checking out a conference room, asking a question of a colleague, getting a new keyboard to replace your broken one. If you don't work in an average office you deal with process too, but it might not be as recognizable as such. Some of these processes are more human than others, some are more repeatable than others, some more useful than others, but they all share the trait of being steps that result in getting something done.

In many organizations there is a belief that processes like those described above should not range free through the organizational structure as in the days of yore. Rather, they should be corralled into technology systems where they can be properly monitored and maintained. The efficacy of this approach to process is debatable, but it is not much debated. It is these organizations and these types of processes that I'm talking about below.

The cost of process

One of the largest hurdles to turning an organic process in a business into a technology-supported process is the time and money involved in doing so. In most medium and large companies with current ERP systems a person who sees an opportunity for improvement in a process or for the creation of a new process is faced with the daunting task of justifying an expense that totals in the $20,000 - $500,000 range.

That's a big number. Let's back that up:

This is an example of a workflow/process build estimation tool tailored to SAP's workflow technology. For the simplest possible workflow (5 steps), it provides an estimate of 32.5 person-days for the technical build. This does not include a myriad of things that require significant effort, like business process design and testing, or ongoing maintenance. I use this example not to pick on SAP (estimates on a similar order of magnitude hold for most process development environments) but to show the magnitude of the problem. (Hat tip to Jim Spath for making this available and Susan Keohan for blogging about it on SDN.)

Those who read the BRP link above will now say, "that makes it nearly impossible to justify the creation of processes that will only be used by one person or by a small department." Those people are right, but it's worse than that: this cost also stunts the ability of an organization to conceptualize, test, and grow processes. A lot of process growth that occurs naturally is organic, starting with one or a few people as a trial and then spreading out to the rest of an organization once benefit is realized. The high initial cost of process mostly precludes this sort of organic, exploratory process-building.

Thingamy certainly takes aim at the difficulty and cost of creating a new process and maintaining existing processes. Process creation is surprisingly easy and robust (we'll get to this later). Check out the video on creating an expert consultation process in under 20 minutes. The flow isn't complete, but it would be conceivable to iterate development on this flow 3-4 times in a single day; more if the person building the flow is also the person who will be using the flow.

Robustness of the process tool

Thingamy is also a robust process building tool, once you figure out what the heck all the pieces are doing. This is important because a lot of no-code business process modeling tools trip up on branching, looping, or interfacing problems and end up requiring code. Additionally, they have often so over-loaded their visual representations of processes that it is next to impossible to model anything but the most simple process.

For a basic example of this complexity, take a look at these "Email voting process" outlined here. The email voting process itself is made up of a several other processes such as the "Collect Votes" process, each of which are of similar complexity and is completely invisible from the overall process view. Thingamy's textual representation, focus on robustness of process description, and process re-usability is an example of another, apparently better, approach.

Onward and upward

Those are some gripes about the current state of business process systems where I see some light at the end of the tunnel. There are also areas like personalized processes and exploratory process-building where I think the hurdles above exist but the tools haven't even begun to attempt to address the problem.

What areas do others see where improvements could be made? What interesting tools haven't I seen?