How to Get Ahead in Architecture
Lightweight Process
Once we have reached the point of specifying components in the architecture (Proof of Concept, Migration Roadmap), the requirement to manage the endeavour and commitment to quality both decree that there should be repeatability in the process of developing these components. Introducing and maintaining complex process models, particularly in environments where ad-hoc measures currently prevail, is risky and unpopular.
* * *
Managing the development of components in a new technical environment poses serious challenges. Developers and others who may already have significant experience in the old ways of doing things resist the cultural changes required to work to consistent standards. A large and legalistic delivery process will be resisted as an unnecessary imposition, and a waste of time.
The presence of standards documentation doesn’t seem to help: often these are pitched at an inappropriate level (how many spaces to indent a statement), they are hard to introduce into an existing development culture, and enforcing these is an unpopular task.
Therefore:
Identify a minimal set of requirements for process. State these clearly and in terms which are relevant to the developers using the process. Make it easier to follow the process than to ignore it.
* * *
A key part in the effective implementation of such a process is the provision of tools which co-operate in support of the process (Tools Support Process). Process descriptions must be readily accessible to developers (Website). One of the deliverables of a Proof of Concept should be an initial definition of this process, supported by the process deliverables as generated by the POC.
© 1998 David Harvey
Created 6 September 1998
Last updated 6 September 1998