Solution Development Lifecycle

The last article focused on the importance of having an architecture vitality process. This article expands the single element of that diagram labelled 'Solution Participation'.

Organisations should seek to find a rapproachment in their software development lifecycles between having no organisational process and being overly prescriptive, forcing teams to fit to an organisational process that leaves no room for innovation in working practice.

My own experience is that at the organisational level, a process loosely based on RUP - iterative, with shifting emphasis of application of varying disciplines as the iterations proceed - can support a wide variety of methods. Typically the organisation needs to specify compliance checkpoints - around acceptance of requirements, review of inception and construction architectures, and delivery to test. This can result in needing to make minor adaptations to the use of agile methods to accommodate compliance and traceability needs; in practice this is not a deal breaker for agile.

Below I have modelled how the use of Feature Driven Development can be used to realise such a solution delivery process - a project management approach which I find to be especially relevant for looking after shared enterprise components and services.