Share via

Defining a basic Development Architecture

  • Article

What’s in a development architecture?

I've had this posed at several customers where no set practices are evident. More often than not an organic development process is adhered to. Regardless of SDLC methodology a development architecture I propose will industrialize your application with many benefits (not least of which is demystifying what those pesky developers actually do).

The Microsoft Software Development Centre at North Ryde has an exploratory outfit and model that implements a standard development environment for guaranteed results.

 I propose the following simple development architecture items that need identifying:

(Ill post a presentation on this topic later):

  • Development security

Development activities that lead to an application secure by design

  • Team Processes

Activities that lead to a collaborative development environment (e.g. work item allocation and reviews). These are manual and automated processes off the developer’s machine

  • Individual Procedures

Practices that the individual should during development (on their own machine) be applying to align with the team (e.g. backups, testing) . This should be documented and handed down as gospel to new and old developers alike

  • Development SOE

This addresses the question of what does the development need to start development? There should be a comprehensive list of steps outlining the base configuration for development for each of the applications being developed.

  • Development Tools

This refers to a standardisation, a list, of accepted tools that can be used for the job at hand. Uniformity will assist in reproducing the same results with the same development enhancements.

Outcomes of a successful Development Architecture:

  • Uniformity (transparent)
  • Team oriented (no single point of failure)
  • Best practice (no proprietary solutions)

Ultimately the same product could be developed without a development architecture but it would be incur more cost in development (getting the product out the door), maintenance (the ability to apply change requests), support (identifying and resolving problems) and reparability (the cost of fixing a defect).

If you don't industrialize your application development process there be too much product being returned to base, or costs pushed elsewhere to enforce quality.