Enterra CTO on Ruleset Automation
by tdaxp ~ August 8th, 2006
“Building Rich Internet Applications for Workflow and Process Monitoring,” by Doug Todd, SOA Best Practices: The BPEL Cookbook, http://www.oracle.com/technology/pub/articles/bpel_cookbook/index.html.
Lady of tdaxp found this Chinese-language translation of an article by Enterra Solutions Chief Technical Officer Doug Todd. While the page, hosted on Oracle’s servers, includes all sorts of oriental characters that are incomprehensible to this monolingual, a quick Google search discovered the original article which explained screenshots such as:
Approving a Ruleset
The article, which also discusses Javascript Web Services (“AJAX“) and related technologies, is primarily focused on how Oracle technology allows business to automate rulesets, or business processes:
More and more organizations are automating their key business processes to increase operational effectiveness. However, even automated processes require manual interaction for two important reasons: to advance a process to the next step (workflow), and to provide real-time process visibility for end-users (process monitoring).
Consider a business process for opening a new bank account. First the customer provides necessary details (name, address, SSN, initial deposit) to open the account. Once the process kicks-off, the customer will want to track the status of the request and respond to any additional queries from the bank. This process requires workflow to enable customer participation, and process monitoring so that the customer can track request status.
Oracle BPEL Process Manager facilitates basic workflow capabilities and process activity monitoring. But just as important, by extending its exhaustive API interfaces for interacting with processes, instances, and workflow, it is possible to build a single, rich internet application (RIA) that enables advanced workflow and process activity monitoring. This advanced workflow capability could enable zero-latency communications between user and process, whereas advanced process activity monitoring could transmit real-time process status information to the workflow so that appropriate actions could be taken.
…
Oracle BPEL Console provides a Web-based interface for deploying, managing, administering, and debugging BPEL processes. It’s an administrative tool designed using JSP pages and servlets that call the BPEL Process Manager API. Consequently, you can easily develop your own RIA console using the API to provide a business-level, process-monitoring interface.
Enterra CEO Steve DeAngelis linked to a more conceptual overview by CTO Todd earlier this summer:
Resilient Workflow with Oracle and Enterra
August 11th, 2006 at 12:00 am
Sonny,
Thanks for that great explanation and analysis! I agree with you about unity of command not being something new. I merely pointed out that Schwerpunkt was Boyd's example of the principle.
Your point about the dangers of technology-enabled micromanagement was a good one, both in military and business terms. They're better used for improved monitoring and appreciation (in Boyd's terms).
Isn't part 4 of your defense of EBO overdue at FX-Based?
Cheers,
Mike
August 11th, 2006 at 12:00 am
Mike,
I am looking forward to your book!
Sonny,
Mike's right — get cracking on part four!
August 9th, 2006 at 12:00 am
Dan,
BPEL is nice, but certainly nothing revolutionary. Having built workflow applications since the early 90's, I've seen the 'New Bank Account Opening' process automated several times. For some reason that seems to be every vendor's favorite example.
In most workflow applications the technology has always been the easy part of the project, particularly with complex processes. [ Complex, not complicated, as in: Designing the control system for a modern aircraft - complicated; flying that plane from LA to NY on any given day - complex ] You know from systems theory that the control system for any process is by necessity more sophiticated than the system itself, and most organizations don't want to go to the trouble of analyzing and designing such a system. It's easier to insert people as the control systems, since they're very adaptable and self-programming (OODA!).
That decision leads to an exponential escalation in overall system control complexity, since the new control mechanism has to be more sophisticated than the brains of all of our human control points! I think that this was the fundamental flaw of Hammer and Champy's original Reengineering model. They tried to make complex systems into complicated ones, expecting people not to act in complex ways (which turned out to be a fatal assumption in most Reengineering projects, by Hammer's own admission).
Workflow automation requires making rulesets explicit in order to be automatable/controllable. Boyd said that explicit rulesets severely limit the adaptability of the system under control of the ruleset, which is a weakness in competition of all sorts. Paradoxically, this is a benefit in high-volume transactional processes, such as new bank account opening, where regulatory restrictions and auditability are paramount. Most of those applications have already been automated using previous generations of technology. BPEL is just an evolutionary extension of that technology. Nice, but a very secondary factor in the success of workflow applications.
August 9th, 2006 at 12:00 am
Mike,
I agree. I like your line “They tried to make complex systems into complicated ones, expecting people not to act in complex ways.” I made similar comments in my post, “Dashboard Confessional.”
What is your view of Sonny's comment on that post,
'”Centralized control, decentralized execution”. A basic doctrinal tenet of the USAF, that can – to some degree – be applied to other non-military enterprises, particularly those that deal with crisis situations like terrorist attacks, natural disasters, or reconstruction in a chaotic, hostile, or non-favorable environment. … '
?
http://www.tdaxp.com/archive/2006/06/14/dashboard-confessional.html
August 10th, 2006 at 12:00 am
Dan,
I came back to see if you responded to my comment, and there are 75 new posts. You are one prolific dude!
It's funny you ask about crisis situations. Mark Brady of Fouroboros and I are writing a book titled “Moonshots and Tsunamis”, and have done a fair amount of thinking about management theories. Having decided to live my life using complex/complicated as a central model, and having said that John Boyd is THE authority on management of the complex, I have to go back to “Patterns of Conflict” to attribute my thinking.
I think that Boyd would consider Curtis' remarks to refer to the Schwerpunkt model of warfare, in which Central Command defined the overall mission and then gave subordinates the authority AND RESPONSIBILITY to successfully carry out the mission in whatever way they saw fit. Central Command then evaluates results and changes mission objectives based on new information, but continues to delegate action to subordinates.
As long as “central control” allows smaller unit initiative, things will work. But the human tendancy for micromanagement in a crisis must be actively managed.
Mike
August 11th, 2006 at 12:00 am
Mike, Dan,
Air Force wise” centralized command, decentralized execution” is pretty much how we operate 24/7 (with very rare exceptions). And we've been running combat ops continuosly 24/7 since 1991. This tenet, of course is not “black and white” meaning, there is always some flexibility built into it. Subordinates units have to operate under rules of engagement (ROE), law of armed conflict (LOAC) and other restrictions meaning that they are just not allowed (for good reason) to do whatever they please once they enter the battlespace or operational area. Of course, self-defense (and some targets of opportunity, etc) are taken into account when formulating and implementing these restrictions. Even within the centralized command, decentralized execution framework there is considerable flexibility. Different operations require different levels of attention and restrictions from the command entity. For example, an operation in an urban environment is bound to have more restrictions attached to it than one conducted in a spaserly populated area.
Mike's remarks are spot on. The only thing I would add is that whenever I think of “Central Command” I think of the specific US Combatant Command that handles operations in the Middle East and the Horn or Africa. “Command entity” is probably less confusing, but that's just my quibbly preference.
Micromanagement is part of the danger (especially with all our “collaboration tools” and C4ISR systems), but's that's why we stress leadership over mere management. Part of being a leader requires that you trust your subordinates to do their job. This is particularly important in contigency situations. In my experience, a hazy command structure is never an advantage when it comes to a contigency. Unity of command is actually a principle that predates Blitzkrieg doctrine by thousands of years. The Greeks and the Romans operated under this pronciple. Napoleon reffered to it as “the first necessity in war”.
Regarding the technology aspects and the snazzy tools, to run a successful operation, you need to realize that no matter how good the technology, people-to-people relations is how you get things done as a leader.