How to Get Ahead in Architecture

Having a Lightweight Process is, however, not sufficient. Even minimal requirements from a process, if not supported by appropriate level of automation, will be met inconsistently if at all.

* * *

As a side-effect, a manual process can easily become self-justifying. With too much personal effort devoted to adhering it, those responsible for process definition and implementation becoming avid keepers of the flame, while its users come to resent it for the reduction in effort available for what is seen as "the real work". Note that the danger is equally acute for the process owners as for its users: it is dangerous for an architecture team to be seen as legalistic adherents of an inflexible process.

We find that the best support for process is supplied by lightweight and flexible tools which can be incorporated with minimal disruption into the day-to-day work of implementers. Teams and individuals will have developed different ways of working: if these are effective it is important that the tools can be incorporated into the diversity of process, not that tools constrain them. Facilities provided by such support tools (in order of scope) include

• Templates for documents and code
• Uniform build and delivery mechanism
• Integrated configuration and version management
• Workflow driven by the development process, with automated build and notifications generated for key events

Templates can be customised for an organisation or an individual project, and development environments enhanced to make automatic use of these templates. A simple example from the world of software build and configuration: when developing a system of make files or similar build scripts to be customised by adding and edition further files, provide scripts or make targets to create template versions of these subsequent files.

Any group development effort is impossible without a repeatable software build and delivery mechanism and without tools to manage versions of software source. Relying on Integrated Development Environments (IDEs) to perform software builds is a poor strategy for repeatability, as knowledge of the build environment is hidden in the multitude of options and configuration settings of the tool. Moreover such tools fail where development and delivery is cross-platform. A well-organised shared directory structure supported by readily configurable scripts is (currently) much more effective as support for group development: modern IDEs are readily customisable to invoke such scripts.

Version control should be transparent to developers. This implies a choice of tools to hide (where possible) the mechanical processes of checking files out, changing and committing them to different locations behind the normal process of accessing and editing these sources. Where such tools are sufficiently capable, significant events in the lifecycle of sources (such as making a new baseline version across a component) can give rise to automatically-generated notifications, extending to regular or event-driven instigation of software builds. Depending on the level to which the support is being provided, it can appear that the effort to define, implement and maintain such a process is unproductive. The goal to keep in mind is the ease of integration of the tool support into the ways people work: when done well, the reward is significant.

Therefore:

* * *

Proof of Concept can also take steps towards defining tool support for the process, at least at the lower levels of scope. In order to have third-party tools collaborate in process support, it may be necessary to Nurture Vendors.

© 1998 David Harvey

Created 6 September 1998
Last updated 6 September 1998

Home
Email