Elaborate end-to-end scenarios
Taking a component view of these responsibilities,
we can define the scope to meet this goal (so far) as:
Figure 9: Scope of solution
So for each component can see what is new,
what will be changed, and what will be unchanged (but will nonetheless
be referenced in an end-to-end delivery). Of course this will build up
as further goals are analysed, and additional responsibilities
This model is built directly from the
previous one, with no additional maintenance required. Since each
responsibility looses the context of the scenario it was from, it may be
necessary to reword some of them so that they are all self evident.
Whilst the above model shows the scope of the
entire phase of work in terms of impact on components, it is also useful
to show for each goal what the impact would be, and also the
dependencies between them. This way planners can asses the complexities
and costs associated with a goal (to see if it is worth pursuing), as
well as determining an embryonic iteration plan (see section 4 use of
deliverables for more information).
Like the previous model this model is built
directly from the enterprise scenarios with no additional maintenance.
It does offer a slightly more architectural focus and may reveal
inadequacies in the analysis not spotted so far.
Prototype dependency model for goal
Since interfaces are often neglected as a planning activity, this model
already highlights these.[i]
This is a really powerful model and shows
how in order to meet a single goal lots of things are impacted in a
number of ways. Already the scope is becoming much clearer.
Having defined interaction and
responsibility in the end-to-end scenario as a starting point, it is
important to ensure that these make sense on the own accord.
Whilst these have identified in these
end-to-end scenario, all we have at this stage is a name. These are
briefly analysed to see if the responsibility is genuine (it is
after all very easy to draw arrows on a model!), and if so what it is
trying to achieve, and its likely complexity/benefit.
This forms the initial responsibility
specification, an example of which is shown below:
Figure 11: Example - “Initial”
validation rules for new products
The goal of
this responsibility is to select and apply the appropriate
validation regime to apply for the new swap products
New product expansion
number of trades that can be accepted
We will see also later in the methodology
that these can sometimes be mapped to existing deliverables where the
project is an extending phase one.
Present the findings
The strength of structured modelling is that a
problem can be described in many different ways. It is important to
communicate any detailed analysis to as wide an audience as possible.
The example in
Figure 8 may contain terminology that may be inappropriate, or
not relevant for some reviewers. It is however a simple matter to turn
this into a model that matches the needs expectations of the reviewer.
This is shown in the following figure:
Figure 12: Example of how a
detailed process can be presented
It is enough to use implicit interfaces – it is enough just to
identify that they will be impacted (at this stage can call “trade
management” interfaces – update above to show this – although when
become explicit want to lose this). This will be taken further for in
the description of explicit interfaces.
Synchronicity can also be described to show the flow or loss of
control in order for a responsibility to be fulfilled. Asynchronous
responsibilities are shown as half arrows and suggest that the
narrative can continue with some loss of control. The example shown
here are the multiple entry points of entering a trade can occur
concurrently and the acceptance can occur concurrently since it is
likely in batch. However in order to be accepted all the sub
responsibilities (shown full arrow or synchronous) must be fully
completed before control can be resumed.
At this stage don’t attempt at describing things in generic terms. The
example here is stated from a swap perspective, but perhaps after
defining scenarios for some of the other products in the new initiate,
some commonality can be defined. It is recommended this is done in
later in inception or in elaboration, with responsibilities such as
“new initiate trades” identified. It is still best to keep the
specific examples (revising consistency as appropriate), so in
planning a single “new initiative” trades could break down into
specific responsibility “swaps, energy, options” or whatever
Responsibilities are described in a active sense, avoid (unnecessary)
terms like “supply…”, “manage…”, “process…”
The scenario also avoids decision points such as “IF/THEN”. Any
conditionality is implicit in the responsibility descriptions, and
other cases are covered in the alternative flows.
2002-2005 Codel Services Ltd
This paper has been prepared by
Codel Services Ltd to illustrate how structured business modelling
can help your organisation. Codel Services Ltd is an IT Consultancy
specialising in business modelling. If you would like further
information, please contact us at: Deryck Brailsford, Codel Services
Ltd, Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom.
Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: email@example.com