Software, particularly modern componentized, cloudified, scalable software, is complicated. We all know that, and for decades we've used simple graphic models of software to describe it (at a high level) to non-programmers. We used to call these "flow charts" in my day, and today we might call them "models." Models focus on major functions and the flow of activity, and they help us organize all this onrushing complexity.
A typical process step in one of these models might read "Validate the input data," and it's easy to visualize what's probably a complicated set of software tests as that simple step. Suppose we were to map the process step not just to software, but also to human review? After all, humans do validate data a lot, particularly if the "data" is something complex, like a financial analysis of a business proposition. In fact, the validation of that kind of proposition might be a team effort, in which case perhaps we could do what modern modeling does, and decompose our validate process step into smaller pieces, to reflect who does what.
The value of this approach is hard to see if you stay with the flow-chart model, but if you look at this as being computer models driving process automation software, you can quickly see the benefits. Modeling not only could organize complex team collaboration, but also harmonize automated and manual processes. To succeed, it has to address some critical issues, the biggest of which is the concept of asynchrony.
Neither humans nor the world we live in are orderly. We're bombarded by various outside stimuli every day, and we have to respond to them when they happen, even if the response is to put one on the back burner. One of the nice things about modeling processes is that you can model them to describe how asynchronous events are to be handled. What happens if, during Step A of your process, you get a call? Probably it depends on who called you, and you can describe that in a model.
You might be wondering what this would get you, though. The answer is that you can control your communications interactions based on your process state, as modeled, and the nature of the events. You're not confined to some low-granularity description like "I'm away" or "Busy." Instead you can be waiting for a specific call, or you can be waiting for that call but still responsive to other high-priority interruptions. If your tools know your granular state, they can serve you better and make you more productive.
Ultra-granular presence control is only one benefit. Think for a moment about a typical collaboration call. You probably start with something like "Did you have a chance to review....?" which references some document or report. In modeled collaboration, the report dependency could be communicated with the call, and you could even call the report up when the call is handled.
The notion of calling something up in reference to a call opens another interesting property of modeled collaboration, the value of being able to communicate events in an explicit way. At the end of our hypothetical review of a report, we might have multiple possible outcomes, including approval, rejection, referral, and return for revision. Wouldn't it be nice if our collaborative call was initiated by the exchange of a "tile" that identified the caller, the process step we're in, the document we're referencing, and the outcomes from which we can select? That way, our model could describe what happens when the call ends with one of the outcomes defined by the tile.
If collaborative sessions were able to receive possible "completion codes" from the process that invoked those sessions, and if collaboration users were then tasked with selecting the appropriate completion code at the end of each session, collaboration could be mapped into automated processes that included applications. That way, applications and human workers could be orchestrated by a common process model, and we could be sure collaboration fit into our IT framework.
The model could also support multi-agency project coordination. A task might say "hand off to supplier," which would send a message to a collaborative model in the supplier organization. That model could define possible responses, and the supplier could return the one that's appropriate at the end of its activity. Even customer end users could participate in a model-driven collaborative application, and play an organized role without having to be software or even modeling specialists.
Making this happen would pose some challenges. We do have the notion of model-driven architectures from people like those with the Object Management Group, and Unified Modeling Language can describe any collaborative application, including the human pieces. However, implementing a model-driven application would require a bit of integration on the part of the user.
Another missing piece is the notion of collaboration-linked tiles that communicate process context far beyond simple presence, and that act as a vehicle to report outcomes of human processes. Again, this exists, but not in an easy product package.
I think this is a practical mechanization of collaborative integration with business and IT processes. That means that easy or not, it's something the UC/UCC community needs to be thinking about and working toward.
(Note: You'll find lots of stuff if you look up "model drive collaboration" on Google.)
Learn more about Team Collaboration at Enterprise Connect 2018, March 12 to 15, in Orlando, Fla. Register now using the code NOJITTER to save an additional $200 off the Regular Rate or get a free Expo Plus pass.
Follow Tom Nolle on Google+!
Tom Nolle on Google+
