All of these issues can be
mitigated by a clearly defined problem statement, that must be agreed at an
executive level.
What analysis can you do in the inception phase?
The inception phase is about getting the scope
right and driving out issues that need to be resolved before detailed work can
begin. It is also about setting out a plan to deliver things throughout the
subsequent phases of work.
Since change can effect both the
business and systems, there are two meaningful things that can be modelled here:
The scope of the business and the scope of the enterprise, and by extension the
scope of impact of new requirements or changes to business or enterprise.
The methodology used is similar
in both cases, since at a high level the problems faced are similar.
Enterprise analysis is distinct to system analysis
(although it uses many of the techniques employed by it). It needs to consider
(and challenge) both the business requirements and architecture, therefore the
team needs to be happy with understanding the language of both domains, and to
express their deliverables in a format both will be happy with. The following
figure illustrates this in the wider software engineering process:
Figure 1: Context of Enterprise and BPR
Note that whilst this may appear to be waterfall,
it isn’t as these deliverables gain maturity at different stages and at
different iterations.
What is the Codel Services enterprise analysis methodology?
The enterprise modelling methodology outlined by
this paper can be described as an agile, UML based, fusion
methodology. A little explanation as to what these terms mean:
 |
Agile: Whilst process is necessary to promote structure,
many methodologies get bogged down in formality and complex team structures.
This methodology is structured around small team and daily workshop lead
approach allows leverage of all team members. Whilst the methodology does
require a larger analysis commitment in the early stages, such resources are
kept small.
|
|
UML: this is the industry standard toolset for modelling,
and allows any practitioner to understand the terms used. To be successful
nowadays, any methodology must use it as its base. At its base the methodology
is Object Orientated (OO), and leverages in many of the well established
benefits this brings to software engineering but into the enterprise and
business domain.
|
|
Fusion: Often analysis methodologies don’t interrelate with
methodologies used by architects. This methodology acts as a bridge between
requirements, architecture, analysis (and design) and planning
|
Can be used for both system engineering and
business processes re-engineering reasons. The former is met with use cases
realisations with a focus on system change, the later with use case realisation
with a focus on business change. This is reinforced by the fact that at an
enterprise level the system is still meeting the same goals of the business.
Figure 2: Fusion Methodology
A common reason why enterprise based IT often fail
is that these disciplines are not integrated and not involved in the scoping of
programme.
This paper focuses on the
enterprise techniques. To see how the methodology can be used for BPR, please
read the companion paper: Business Process Analysis in the Inception Phase
©
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: info@codel-services.com
