HomeProducts
 

 

    
21st November, 2001 
Agile System Development, Flexible Systems

Agile system development and agile modelling are the new buzz phrases for delivering working software systems. Even IEEE's Computer publication has included an article on the agile paradigm in the last couple of months. The nice thing about agile system development is that it delivers some pragmatism to the process of developing systems. It is important to stress here, that Agile System Development is not a software development methodology. It is a methodology on the development process. 
  
Agile development introduces some flexibility into the development process and applies some pragmatism into delivery. More importantly, it recognises what many of us have realised, that changes occur to requirements through the life of the development and that it is better to plan for change rather than to develop rigid systems to rigid specifications. 
 
Adopting this approach does require a change in mindset. When developing components, anticipate that the components may mutate. Rigorously collaborate with others in the development team to ensure that flow-on effects are communicated and the system adapts to the changes. The development of contingency architecture delivers long-term benefits, as flexible systems are more likely to survive environmental changes during the operating lifespan of the system. This can be likened to a kind of Darwinism, in that we are building evolving systems, and the successive iterations of refinements can produce the most robust solution for the expected dynamics of the operational environment. For business systems, where there is an understanding that business is a dynamic entity driven by market changes, such adaptability ensures that the business systems remain functionally appropriate with a lower maintenance burden.

However, like genetic evolution, components and systems can develop that reach an evolutionary dead-end. They become so specialised that they are unable to respond to environmental changes. Developers and architects need to recognise the warning signs and redevelop components appropriately. There are some guidelines that characterise adaptive systems that I have borrowed from software methodologists.
  1. Components must be loosely coupled. This allows changes in one component to minimally impact other components with which it interacts. Or alternatively, one component's function is minimally affected by changes in the components with which it interacts. This needs to be applied to inheritance and embedding as well. When inheritance extends through too many levels or the nesting of embedded structures becomes too unwieldy, the stability of the offspring must be considered with respect to changes in distant parent nodes.
  2. The structure of a component must be flexible and extensible, within the basic functional framework of the system or sub-system in which it operates. Essentially, a component must be able to survive mutation of form without sacrificing the functional requirements imposed by its environment. The simplest structures with the least inherent semantics are more likely to survive changes without significant degradation of its operation. Complex structures are more likely to introduce inflexibility through dependencies and internal interpretation.
  3. Interactions must be only sufficiently well defined and must be able to be articulated in simple terms without explicit mention of any implementation specifics. Keeping definitions of interactions as simple as possible, without referral to an implementation allows freedom and flexibility in the model developed. It allows conceptual views of the interaction without influencing the details of the implementation and introduces wider scope for innovative approaches to a solution. Defining what must be done instead of how it is to be done delivers the concept, free from the physical constraints of the component that is to achieve the interaction.
At higher levels in the system, interpretations of characteristics are made and interactions defined. Characteristics are only assigned meaning at the point they are used for decisions. In all other cases, the characteristics are purely data with no use. In this context, the business entities no longer create a rigid framework for the system. The entities can have new characteristics added, removed and ambiguities such as multiple values for a characteristic are supported. The entities are no longer constrained at the level of representation. The meaning of the characteristics is detached from the accessors of the data.

Unsurprisingly, these are not new sentiments. Perhaps they echo the re-usability paradigm except that proponents of agile development propose that we should re-use appropriate tools and that refinement of a system will occur throughout its development, if not throughout its operational life. Ultimately, we are endeavouring to produce a process that supports pragmatism and releases creative control back to the developers. And that makes good sense to me.