Threads and beads and events and contents, oh my.

[Seabird]

In thinking about the threads and beads model, I was drawn to software
that is used to model chemical compounds. If you squint at it just
right you could view the Events as atoms within a complete molecular
structure. If we one of the more complex -anes we can have a large
number of beads and (perhaps) use the branches to represent different
behavior after the firing of an event - essentially the different
business effects.

In some of the examples that I have seen, the flow of goods through an
express delivery system illustrats someof the needs.

We clearly have a set of operational behaviors - picking up packages,
loading, unloading, delivering, sorting,weighing,... We have an
information stream that attempts too be a proxy for this - so someone
not involved in the delivery "process" (stream of actual events) can
get some knowledge about the package state/location. This is by
definition a proxy, and will frequently be out of step with the
reality. No matter it is as good as it gets.

Then we have the effect on "the money". Every event in the physical
movement of a package incurs some cost. At various points in the event
sequence (along the wire of physical movement), the financial systems
may sit up and take notice. "Aha, we have discovered that the package
has been picked up, let's recognize the revenue in financials".
Followed swiftly by a ruling that says, "No we will recognize revenue
when the item has been delivered." Major change in financials, almost
none in operations. Imagine if operations had to wait for financials
to say, "Hang on don't load the plane, I haven't finished pricing the
item an recognizing revenue." That's just nuts!

There is no doubt in my mind that we need to keep the threads focussed
on their own scope and recognize that we need to move into other,
asynchronous threads periodically. That isn't techie speak for we must
have an ESB, it is business speak for ensuring that the organizations
units with the appropriate authority can get what they need done and
remove friction from each other. So we only introduce "friction" or
"brakes" into a thread when some business condition demands it. For
example, "We have checked your credit and we aren't picking up any
more from you until you pay your bill." That kind of feedback/
capability is necessary to have, and becomes an integral part of the
thread of delivering packages. It isn't just a financial thread that
is kicked off independently.

[nigelp...@googlemail.com]

See my in-line comments == :

On Nov 1, 1:13 pm, Seabird <seabir...@gmail.com> wrote:
> In thinking about the threads and beads model, I was drawn to software
> that is used to model chemical compounds. If you squint at it just
> right you could view the Events as atoms within a complete molecular
> structure. If we one of the more complex -anes we can have a large
> number of beads and (perhaps) use the branches to represent different
> behavior after the firing of an event - essentially the different
> business effects.

== this is exactly the type of molecular model I had in mind when I
drew Fig 1. (on http://groups.google.com/group/vpec-t/web/threads-beads-images).
One slight
== difference is that I see the 'Atoms' as Beads of Capabilities or
Services that are triggered by real-world events rather than events
themselves.

>
> In some of the examples that I have seen, the flow of goods through an
> express delivery system illustrats someof the needs.
>
> We clearly have a set of operational behaviors - picking up packages,
> loading, unloading, delivering, sorting,weighing,... We have an
> information stream that attempts too be a proxy for this - so someone
> not involved in the delivery "process" (stream of actual events) can
> get some knowledge about the package state/location. This is by
> definition a proxy, and will frequently be out of step with the
> reality. No matter it is as good as it gets.

== I agree. In example each "operational behavior" could be a Bead of
capability/service. So a "Picking Up Packages" Bead would have a
"Shipment Picked-Up"
== Event associated with it/recorded by it and a "Transport to Depot"
might have a "Delayed in Traffic" Event associated with it/but NOT
recorded by it. This way we == keep the Events separated from the
details of the activities carried out in a Bead and allow for both
internally generated 'My Bead' Events (e.g. Shipment Picked == up to
be handled the same as externally generated "Out there somewhere"
Events (e.g. Traffic delay) the same way.
== Fig 3. shows example Events as triangle shapes associated with two
Beads and how they might relate to Policies (certifcate graphic) and
Content (face/book
== graphic).

>
> Then we have the effect on "the money". Every event in the physical
> movement of a package incurs some cost. At various points in the event
> sequence (along the wire of physical movement), the financial systems
> may sit up and take notice. "Aha, we have discovered that the package
> has been picked up, let's recognize the revenue in financials".
> Followed swiftly by a ruling that says, "No we will recognize revenue
> when the item has been delivered." Major change in financials, almost
> none in operations. Imagine if operations had to wait for financials
> to say, "Hang on don't load the plane, I haven't finished pricing the
> item an recognizing revenue." That's just nuts!

== Nice build on the financials aspect!

>
> There is no doubt in my mind that we need to keep the threads focussed
> on their own scope and recognize that we need to move into other,
> asynchronous threads periodically.

== Yes, yes and yes!!

That isn't techie speak for we must
> have an ESB, it is business speak for ensuring that the organizations
> units with the appropriate authority can get what they need done and
> remove friction from each other.

== I like the 'remove friction' meme

So we only introduce "friction" or
> "brakes" into a thread when some business condition demands it. For
> example, "We have checked your credit and we aren't picking up any
> more from you until you pay your bill." That kind of feedback/
> capability is necessary to have, and becomes an integral part of the
> thread of delivering packages. It isn't just a financial thread that
> is kicked off independently.

== I think this resonates well with the VPEC-T experience of my
colleague (and member of this group) John Schelsinger
== = any thoughts John?