Approach - Enterprise planning

To illustrate the methodology an example showing how a back office in an investment bank wishes to build upon on an overrunning earlier delivery, but is struggling to articulate the scope of this work.

It has stated that its problem domain is to increase the trade acceptance services as well as improving overall efficiency.

Please note that any examples shown in this document are illustrative only.

Determine the scope

In planning a phase of work, there must be a common sense of purpose underpinning this – there must therefore be some business process objective or end goal involved. Therefore to determine the scope of the initiative its goals must first be understood.

It is important that these goals are end to end objectives relating to the problem domain rather than some means to an end. Some typical end to end objectives for the bank relating to the problem in hand are:

	“want to increase market share of trades processed”
	“want to increase range of added value trade processing activities“
	“concerns about secure access to information”
	“concerns about inflexible client access to information”

It is best to categorise these into goals that benefit a specific part of the organisation (e.g. service) and ones that benefit the business as a whole (these are often intangible in nature). So using our example the bank has the following goals:

Figure 3: Example of services related goals

Figure 4: Use Case model showing generic goals

Note that these goals are relatively verbose. This is deliberate since it must be self evident from the goal what the benefit is as these goals must be discussed and agreed upon at a board level. For example the goal “Increase number of trades that can be accepted” could be described as “Accept Trade”, but misses the fact that the objective is not just to accept them, but to increase the range of trades to be accepted to further aid the revenue opportunities of the bank.

This is articulated by brief goal description of it, together with any benchmarking success factors, the latter is important since if clear benefits cannot be stated at this stage then the goal is probably not an end in itself.

Figure 5: Goal benchmarking

1.1.1.1 Increase number of trades that can be accepted

The objective of this goal is to broaden the range of products that ABC bank accepts in order to increase revenue.

Benchmarking factors

1. Ability to accept 75% exchange traded equities

2. Market share of trade processing increasing to 25%

Determine a candidate architecture

What are components for planning purposes?

Achieving enterprise goals will typically involve a large number of people and their systems working together. Whilst an integrated approach considering both the people and system side of things is possible, as the focus in this paper is on the system side of enterprise analysis only these system stakeholders will be considered.

So what are these system stakeholders? They can be considered to be the building blocks of the enterprise, and are often treated as components.

However the focus in describing these components is identifying all the autonomous (e.g. outsourced) or quasi- autonomous (part of organisation but have own budget hierarchy etc) building blocks of system delivery rather then identifying each and every component for design purposes. This is an important distinction and allows the methodology to be used for planning, resourcing, outsourcing and vendor selection. For example the presentation layer or infrastructure would not normally be considered components in the classic sense, however if these are to be separately managed then they should be treated as one for planning purposes.

Categorising these components can help in assessing their impact as the ability to affect change on core components will be different to those of external systems. The following figure shows such a categorisation:

Figure 6: Prototype components

Eliciting components

If the project is an extending phase then such a component architecture (and its management grouping) should already be in place. For blue sky projects, the architects would typically have a prototype one in mind – and referencing this early on can rapidly test its validity or practicality (it certainly will help for ITT). Even if this is not the case, the enterprise often reflects the business view (e.g. for example the “trade management” service in the business may be identified as a major building block of the business environment, which would logically lead to (as a reasonable guess) to “Trade Management Component” to support these services). This is not a coincidence, but reflects a good cohesion in component selection – they service a purpose after all

Describe the goal

Once an understanding of the scope of the goals and a candidate architecture established, the problem domain can be described.

This is done by describing at a high level what needs to be done and by whom. This business narrative can be written by the business themselves.

Figure : Use case description

End to End Scenario: Increase number of trades that can be accepted

Narrative

ABC front office system sends ABC generic back office system a new vanilla swap trade from the expanded product set

ABC generic back office system ensures trade meets internal back office standards for information completeness and accuracy by applying correct formatting rules.

ABC generic back office system ensure details of trade are valid by applying the appropriate swap specific validation rules, utilising any appropriate swap specific market data rates.

ABC generic back office system calculates the risk both from the companies and the counterparties perspective. This is done by applying limit checks….

Etc. etc…..

Analyse end-to-end scenarios

The prototype components described earlier will interact with one another behind the scenes in the above business narrative.

This interaction can be described in a series of end-to-end scenarios that meet the goal. In the above example one scenario could focus of a trade running through the process in an STP manner, whilst another set could identify all the exceptions that could occur.

The important thing is that in order to interact with one another we are explicitly giving (and naming) the prototype components responsibilities to fulfil a stage of the workflow. Either a component can fulfil this responsibility entirely by itself or it interacts with another to complete it. A partially completed example is shown here:

Figure 8: Use Case Realisation showing a end to end scenario

1

2

3

4

6

5

Explanation:

This is the same text as from the previous section. It is possible for an entirely model driven approach where the text in last section is actually entered straight in here – in fact it could be done after this model.
To meet the goal components must interact, working outside, in. Ask yourself can it fulfil the goal on its own, if not then who does it collaborate with.[i]
These responsibilities[ii] are then described in a verbose[iii] manner to describe the impact on component to fulfil this collaboration – the arrow points to the component who has the responsibility.[iv]
In the case of an extending phase, new, and changed responsibilities are shown to further asses the impact. Unchanged responsibilities are also shown to help give structure to the scenario.
Any outstanding issues, assumptions or questions formally become part of the model and remain there until resolved.
The shape of arrow shows if responsibilities is synchronous – i.e. the flow of control cannot be passed on until all collaborations are successful. Others are asynchronous meaning that no control is implied.

The following narrative illustrates how these scenario can be read:

The component “common interface” has the first part to play in achieving the goal of increasing trades accepted (in this scenario swaps). In order to accept these into the back office system they first need a way in. By allowing a greater number of routes in, “common interface” has met its part of the goal. To complement the STP route, (which in this scenario is unchanged) due to their nature, swaps by their nature also have a number of trades that cannot be handled by STP. Such can only ever be entered in manually, hence some new infrastructure is required to support this.

Once the trade has gotten in to the system, the next stage is to evaluate to see if it can be accepted for the back office system to process. This is the next way in which the goal of increasing number of trades can be satisfied, by broadening the number of checks that can occur.

Trade management (the main driver of this end-to-end scenario), takes responsibility for this acceptance process. However in order to validate them it requires an understanding of how these new trades are structured, an changed impact on the reference data repository. By continuing to follow the scenario, further impact can be established. Defining scope in this way can be very useful. How this impact can be formally represented is shown in the next section.

Early uses of the model:

It should be already apparent from such an approach that:

	Skeleton versions of these scenarios can be quickly put together in multi-discipline workshops.
	The analysts should make every endeavour at this stage to ensure that there is cohesion in the goal – hence the deliberate attempt to continuously back-reference the goal in the above narrative. For example the goal here is to broaden the ways new trades are accepted. It shouldn’t cover things like making the screens more flexible since this would (in this case) be covered by the goal empower user. i.e. each responsibility must be a mean to realising the end goal in question.
	The architects should recommend architectural analysis patterns such as low coupling, high cohesion, façade. The latter shown by how the common interface operates here

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 (for now)

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 assigned.

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.

Define Dependency

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.

Figure 10: 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.

Define responsibilities

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” component specification

Apply 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

Complexity: Low

Benefit: Medium

Initiative: New product expansion

Goal: Increase 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

Footnotes[i] 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.

[i] 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.

[ii] 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

[iii] Responsibilities are described in a active sense, avoid (unnecessary) terms like “supply…”, “manage…”, “process…”

[iv] 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.

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: info@codel-services.com