Business events and the work context
James Archer
Following an excellent Project Blast Off you helped us with there's an
issue I'd like some clarification on. We talked about a manager
needing to approve a certain process and you said that this could be
put inside the work context. My concern is that if it is put inside
the work context then it could be forgotten about, however if the
manager is created as an adjacent system that communicates with the
work context, then it is easy to find and remember as a business
event.
Why would I want to put the manager within the work context?
Best regards
James
Suzanne Robertson
The answer to your question depends on the work context because it is that
that defines the event to which the business use case (BUC) responds.
If the manager's approval is part of the BUC to another event then the
approval (carried out by the manager) is part of the BUC and hence inside
the work.
For example - Employee Wants To Take a Holiday
Then the input from the adjancent system called Employee would be something
like: Holiday Application
The manager carrying out the approval rules would be inside the work
The output to the adjacent system Employee would be something like: Holiday
Application Decision
If the event starts with the manager - For example Manager Approves
Application for leave:
Then the input from the adjacent system called Manager would be something
like Holiday Application Decision
The BUC inside the work would be carried out by whoever or whatever responds
to the event
The output would be something like a Holiday Confirmation or whatever the
BUC does
Another thing to consider is that a Manager or any other entity could be
inside the work in the case of one event but outside in the case of others.
This is because one entity can be involved in many activities and only the
activities that are germane the the work context under study are inside the
work.
I hope that this makes things clearer. Please continue the thread and I hope
that other Volere users have examples that will be helpful.
Kind Regards
Suzanne
==============================================================
Suzanne Robertson
suz...@systemsguild.net
www.systemsguild.com <http://www.systemsguild.com>
www.volere.co.uk <http://www.volere.co.uk>
New book 'Adrenaline Junkies and Template Zombies - Understanding Patterns
of Project Behavior http://www.dorsethouse.com/books/ajtz.html
==============================================================
James Archer
I think there is a bit of which came first the chicken or the egg
here. At a Blast Off workshop for a project I will not know whether
the manager's approval is going to be part of a BUC to another event
or an event in its own right.
My example is a manager is required to approve orders of equipment
above a certain value that varies according to the seniority of the
person placing the order (the prescriber).
My instinct tells me it would be sensible to start with the Manager as
an adjacent system for two reasons.
Firstly this is one way of ensuring the approval process for certain
orders is not forgotten.
At the workshop it took some probing before this approval mechanism
was mentioned by the business, so I'd want to be sure that process is
remembered by initially placing the manager as an adjacent system.
I accept that when we start to write the BUC's this process may
logically fit within the work and appear in the BUC of a different
event such as "prescriber orders equipment".
At this point I would re-draw my context diagram and remove the
manager and the input and ouput to the manager as they are now within
the work (I would only remove the manager as an adjacent system if
there were no other events associated with the manager).
If the BUC for "prescriber orders equipment" or the process involved
in gaining a manager's approval was becoming complicated, I would have
the option of creating an event called "manager required to approve
order".
Secondly I find the work context diagram an extremely powerful tool to
help the Business understand their work.
By placing the manager outside the work it means the process is
instantly visible. I would suggest that because it took some probing
before discovering there was an approval required in some
circumstances, that this is a process that requires some early
questioning. It may be that this process is rarely used or could be
handled in a different way such as notification to the manager rather
than requiring a physical approval.
I think I may be missing something here because the argument to
include the approval process within the work context is because this
is part of the work we will be studying makes sense but means that the
approval process is hidden - that makes me feel uneasy and want to put
the manager as an adjacent system.
Many thanks,
James
On Mar 11, 4:29 pm, Suzanne Robertson <suza...@systemsguild.net>
wrote:
> New book 'Adrenaline Junkies and Template Zombies - Understanding Patterns
> of Project Behavior http://www.dorsethouse.com/books/ajtz.html
>
>
> - Show quoted text -
James Archer
My scenario is that a manager needs to approve orders that are above a
certain value.
There are two reasons I suggest it could be useful to place the
orders is not forgotten.
At the workshop it took some probing before this approval
mechanism was mentioned by the business, so I'd want to be sure that
process may logically fit within the work and appear in the BUC of a
At this point I would re-draw my context diagram and remove the
there were no other events associated with the manager).
If the BUC for "prescriber orders equipment" or the process
involved in gaining a manager's approval was becoming complicated, I
approve order.
Secondly I find the work context diagram an extremely powerful tool to
help the Business understand their work.
By placing the manager outside the work it means the process is
instantly visible. I would suggest that because it took some probing
before discovering there was an approval required in some
It may be that this process is rarely used or could be handled in
a different way such as notification to the manager rather than
system would increase the likelihood of such opportunities being
taken.
Best regards
> New book 'Adrenaline Junkies and Template Zombies - Understanding Patterns
> of Project Behavior http://www.dorsethouse.com/books/ajtz.html
>