How To Pick Development Models

Preamble

Development methods are tools, not articles of faith; picks should therefore be made on a case by case basis depending on the problems at hand.

JacobLawrence-builders2
Fitting Tools to Tasks (Jacob Lawrence)

To that end, swift and straightforward decisions should be supported by simple and robust principles.

Iterative vs Phased Development

Beyond the variety of methodological dogmas and tools, there are only two basic development patterns, each with its own merits.

Iterative developments are characterized by the same activity (or a group of activities) carried out repetitively by the same organizational unit sharing responsibility, until some exit condition (simple or combined) verified.

Phased developments are characterized by sequencing constraints between differentiated activities that may or may not be carried out by the same organizational units. It must be stressed that phased development models cannot be reduced to fixed-phase processes like waterfall. As a corollary, they can deal with all kinds of dependencies (organizational, functional, technical, …) while being neutral with regard of implementations  (procedural or declarative).

A straightforward decision-tree can so be built, with options set by ownership and dependencies:

EARoadmap_DeciTree

Shared Ownership: Agile Schemes

A project’s ownership is determined by its organizational footprint, i.e the entities that are to validate the requirements (stakeholders), and accept the products (users).

Iterative approaches, epitomized by the agile development model, should be the default option insofar as projects can be set under the authority of single organizational units, ensuring shared ownership and responsibility by business analysts and software engineers.

Projects set from a business perspective are rooted in business processes, usually through users’ stories or use cases. They are meant to be managed under the shared responsibility of business analysts and software engineers, and carried out independently of changes in architecture capabilities (a,b).

Agile Development & Architecture Capabilities

Projects set from a system perspective potentially affect architectures capabilities. They are meant to be managed under the responsibility of systems architects and carried out independently of business applications (d,b,c).

Transparency and traceability between the two perspectives would be significantly enhanced through the use of normalized capabilities, e.g from the Zachman’s framework:

  • Who: enterprise roles, system users, platform entry points.
  • What: business objects, symbolic representations, objects implementation.
  • How: business logic, system applications, software components.
  • When: processes synchronization, communication architecture, communication mechanisms.
  • Where: business sites, systems locations, platform resources.

It must be noted that as far as architecture and business driven cycles don’t have to be synchronized (principle of continuous delivery), the agile development model can be applied uniformly; otherwise phased schemes must be introduced.

Cross Dependencies: Phased Schemes

Cross dependencies mean that, at some point during project life-cycle, decision-making may involve organizational entities from outside the team. Two mechanisms have traditionally been used to cope with the coordination across projects:

  • Fixed phases processes (e.g Analysis/Design/Implementation)  have shown serious shortcomings, as illustrated by notorious waterfall.
  • Milestones improve on fixed schemes by using check-points on development flows instead of predefined activities. Yet, their benefits remain limited if development flows are still defined with regard to the same top-down and one-fits-all activities.

Model based systems engineering (MBSE) offers a way out of the dilemma by defining flows directly from artifacts. Taking OMG’s model driven architecture (MDA) as example:

  • Computation Independent Models (CIMs) describe business objects and activities independently of supporting systems.
  • Platform Independent Models (PIMs) describe systems functionalities independently of platforms technologies.
  • Platform Specific Models (PSMs) describe systems components as implemented by specific technologies.
Layered Dependencies & Development Cycles with MDA

That understanding puts the light on the complementarity of agile and phased solutions, often known as scaled agile.

Projects can then be easily profiled with regard to footprints, dependencies, and iteration patterns (domain, service, platform, or architecture, …).

Projects Coordination: Backlogs & Workflows

Whatever their nature (business, organization, architecture, development), engineering dependencies are to be managed. Putting aside fixed phase schemes, projects have to consider three types of coordination:

  • At project level, i.e when direct collaboration and shared responsibility can be achieved, backlogs are the option of choice.
  • Between projects, when cross dependencies can be aligned with architecture layers, backlogs can also be used.
  • Otherwise, i.e when projects dependencies cross architecture layers, workflows and roundabouts are to be introduced.
Backlogs can also be used between projects providing dependencies are layered

Conclusion: Phases & Processes

Whatever the approach, the objective is to define projects’ activities; hence the benefits of neutral profiles defined with regard to architecture layers and engineering contexts:

  • Agile, combining requirements, development and acceptance, and bypassing analysis phases (a).
  • Use of Commercial-Off-The-Shelf Software (COTS), starting with requirements, e.g with BPM, then carrying on directly to platform implementation, bypassing system analysis and design phases (b).
  • Architecture capabilities, from analysis of enterprise objectives, possibly but not necessarily with inputs from business and operational requirements, continuing with analysis and design of systems functionalities, before implementation (c).
  • Operational concerns, conducted directly through systems design and platform implementation (d).
Process profiles depending on objectives and contexts.

Basic options could so be fixed soundly and swiftly (a napkin could do) by project manager and stakeholder before being refined by teams’ analysts and engineers.

Further Reading

 

%d bloggers like this: