Approach
Home Business Change Analysis & Design Agile Testing Templates About us

Introduction
Approach
Enterprise Planning
Enterprise Elaboration
Refine - Analysis Classes
Refine - Combined
Which Approach
Uses of Deliverables
Other Methodologies

What is the background of inception phase?

Before considering the deliverables, the context in which the inception phase is operating must be understood. This could be either:

bullet"blue sky" – i.e. replacing a legacy system, or introducing a new service
bulletextending an existing phase

Depending on which one applies different challenges will occur.

Table 1: Issues in inception phase

“Blue Sky phase” type projects

“Extending phase” type projects

·     there are less issues of politics,

·     but then determining the architecture can be more time consuming,

·     preconceptions and issues can pervade (and set a negative tone for the inception phase),

·     work must be shown extend on the baseline set in the previous cycle (both upstream and downstream) which can be a challenge since the quality of these can not be assured.

·     scope and integrations problems were a characteristic.

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:

bullet

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.

bullet

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.

bullet

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

By utilising the methodology will achieve following tangible benefits:

bullet

Promotes visibility and traceability and impacts of change in any of the above (e.g. impact in  planning constraint such as time-boxing on requirements)

bullet

Elicits early discussions on themes that matter in the whole of cycle.

bullet

Defines scope in terms of impact on likely architecture and the business

bullet

Shows responsibility in terms of system change; business change and other development activity (e.g. configuration, data loading etc)

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

Back Next

© 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