Skip to main content

AOW Textbook, the book that may never need to be.



Prologue

A few months ago I was thinking about one day writing a book that would describe the best practices that those who implement Action Oriented Workflow or use a framework that implements it could refer to. It would provide an extensive history of how I discovered the action landscape and in my implementation of Action Oriented Workflow sought to model it using an efficient distributed computing framework. A thread on Facebook in which I mentioned casually one day needing to "write a book" on the subject led me to play a bit in photoshop and produce the image shown above.

This is a virtual textbook cover of what I'd imagine the book to look like...complete with fake reference to a real publishing company (an inside joke given I once worked there) but the book cover itself may reference something that will never need to be in terms of a formal set of best practices for workflow modeling, as explained below.

On the path to the action landscape...

Though I was working in the publishing space at TheStreet.com I had already started thinking of more holistic ways to think about managing work in organizations.  They came from seeing parallels between the task of managing the xml transformation feeds in the publishing system and how I could create an abstraction that would allow me to use hierarchical management (in part using xml) to manage ANY relations between entities. I had these ideas starting in March of 2000 and had implemented a relations based architecture in the ad management tool that I was given the task of designing at TheStreet.com a few months later.

That tool had the seeds of the idea in the form of individual database tables mapped to the main Entity types of the system and then one relations table that kept a record of how the one to many relations between those entity types varied from instance to instance. Pretty standard relational db model but I saw it as something that could be generalized beyond just for managing ad blocks on pages but for managing pages....or servers..or html files or bank accounts....or anything ......if some deeper kernel of invariance between all those Entity types could be found. This kernel of invariance would be found over two years later during my AgilEntity development as the idea of action. The action landscape, I realized was invariant to all types of Entities and was hinted at by traditional relational database construction in the common pattern used to build such systems...the CRUD approach...but CRUD was insufficient.

Building action into the machine...

 These new ideas became the basis for beginning AgilEntity (then the system was named "Entegra DPS" for distributed processing system but I changed the name just before 2004 to reflect the generality it was able to achieve as I realized it could model more than just a publishing system.) Initial coding started the week AFTER 9/11 on September 17, 2001 but I didn't get to the point in the development of the framework that I was building the workflow management system for the Entity formalism until nearly 2 years later.

While working,  it became clear that routing actions between human agents is a scale invariant transformation of the problem of the brain routing chemical signals between neurons and other brain cells. I didn't realize that until after I'd wired together a working implementation of an explicit Action Oriented Workflow and then could see clearly the connections which I modeled using linked spheres of potential actors on a 'stage' as shown in the attached image. I would come back to the brain neuron analog later.

I finished the implementation of explicit AOW around  2004 according to my vss notes and also projected an extension to the paradigm that would allow it to engage *implicit* workflows by eliminating the need for formal construction of the stages as described to detail in the AOW white paper, this would be accomplished by taking a measure (action delta) of completion accuracy after an action is routed to a worker and then storing that delta as a memory for future potential routing events.


The workflows would then have stages which had an ad hoc set of actors ("agents" in the white paper) who could *potentially* perform the action. I star "potentially" because that  alone was a major innovation. By enabling a loose coupling between the action and the potential committing agents I make action resolution resistant to real world blockages like users not have the right permissions and users not being available to do work at the moment they are routed it. It seems counter intuitive to slightly break the workflow in this way but what it does is provide *flexibility* that speeds convergence over the set of all possible action routing scenarios.

Further, In the explicit AOW model those agents have to be manually added to the stage but in implicit AOW the action workflow designer can simply indicate that the stage uses the users contact list...it's this change that makes all the difference in terms of ease of building workflows  since it eliminates the requirement that the workflow designer know who should or should not be added to each action stage and turns that over to the social graph created as work associated or friend associated connections are made.

Anyway, I didn't get to building out the implicit AOW implementation until mid 2011 after quitting my job at McGraw Hill after getting back from a trip to Venezuela and I still have UI implementation to finish...as I've been juggling survival cats almost consistently since then.

The reason the book cover may be for ever virtual is now clear, in the explicit AOW world the need to know which coworkers need to be in your  action Stages as you build them is a requirement and as such there are best practices (some specified in the AOW white paper) that should be employed to ensure that actions do indeed converge on agents within the organization that can perform them, it was still possible for an action in a badly designed set of workflows to have an inordinate convergence time to an agent who can perform them. Thus providing ample fodder for a book describing how not to build bad Workflows with vertical by vertical modifications depending on the type of workflows those verticals would find optimal.

The implicit workflow extension via the invention of the Action Delta Assessment algorithm which implements the mechanism,  removed the need to know specifically who could specifically be routed a work and instead makes it "any one in my contact list who has the optimal action delta value for this routed action". This would work across any workflow in any vertical industry as the ADA algorithm learned what was efficient for that process with whatever agents engaged in the social workflow built on users dynamic contact list without need for formal modeling to that vertical...thus no need for me to write a book describing how to optimize workflow design to each vertical.

From work routing actions to dynamic cognition...

Moreover, I suspect that the real time nature of this comparison between the commit potential of agents in an implicit workflow is mathematically identical to the real time chemical calculation that is done when a neuron fires off an action potential down its axon to any distally connected neurons.

This realization has led me to continue to investigate how modifications to AOW can be utilized to create not just an intelligent learning process in an action routing system but by mapping action routing to sensory data, fully dynamic cognition. I have since written a great deal on the importance of ways to self connect potential dynamic cognitive minds to ensure their functionality is not pathological. Writings on the importance of emotional and autonomic modulation have culminated in my formal description of what I call the Salience Theory of Dynamic cognition and Consciousness. I wrote an initial state diagram in 2011, that in my conception may emerge dynamic cognition, shortly after finishing the ADA class implementation in AgilEntity but I won't be getting to building code for that for several years at least as I try to use AOW and AgilEntity as the basis of a first disruptive solution to a common and well known vertical industry.

Links:

http://sent2null.blogspot.com/2011/12/how-does-idea-form-autonomics-memory.html

http://sent2null.blogspot.com/2013/05/ada-on-road-to-dynamic-cognition-how-is.html

http://sent2null.blogspot.com/2013/02/on-consciousness-there-is-no-binding.html

http://sent2null.blogspot.com/2013/02/emotions-identity-crisis-in-our-brain.html

http://sent2null.blogspot.com/2012/03/integrated-information-does-not-equate.html

http://sent2null.blogspot.com/2012/02/with-completion-of-ada-action-delta.html



Comments

Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer

Significance?


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…