Preamble
Iterative development, together with users’ stories, is arguably the cornerstone of agile methods as, in contrast to phased approaches, it combines incremental design and delivery of software components.
But iterative processes are not limited to agile and can be usefully employed by different development strategies insofar that the same activity (simple or combined) carried repetitively by the same organizational unit sharing responsibility, with iterations controlled by a set of conditions to be met and an exit condition (simple or combined) to be checked.
Software Development
To begin with, the specificity of software engineering must be underlined: compared to manufacturing processes, software ones come with few, if any, physical constraints, and that fluidity is clearly a critical factor for iterative development.
Nonetheless, software components don’t stay on virtual shelves but are embedded in actual products or used to run actual devices or systems, and that where frictions are to come forth.
That put software development at the junction between two perspectives:
- The business perspective is anchored to the real world through requirements, where frictions (physical or otherwise) may, and usually will arise. That perspective is said to be synchronic because objectives, constraints, and risks change along time, and software components must be continuously and consistently adjusted to changing requirements defined within time-frames set externally.
- The engineering perspective is like a lens projecting requirements into digital surrogates. It is said to be diachronic because once rooted into requirements, the design and implementation of system artifacts can live on their own time-span.
In between, architectures are meant to be both lubricant and glue, the former to smooth the alignment of business and systems, the latter to maintain the continuity and consistency of core business concerns and corporate identities. And since changes may take time, they must be set within a development frame:
- Business (enterprise architecture) perspective: time between requirements and deployment
- Engineering (systems) perspective: development of applications taking into account architecture and quality constraints.
That frame is to be the basis of iterative layouts.
Iterative Software Development
Iterative software development is best defined by applying the control loop paradigm to software engineering objectives:
- Scope and invariants are defined with regard to the enterprise architecture (synchronic) perspective.
- Increments are defined with regard to the engineering (diachronic) perspective.
- Exit conditions are defined with regard to business, functional, and technical requirements.
Each iteration is then to repeat the same set of different activities, carried jointly by a single team regrouping different skills and representing a collective authority and responsibility.
Defined with this layout, iterative processes are not off-the-cuff solutions to be applied to any circumstances but require specific conditions to be met.
Regarding scope and invariants (business, synchronic perspective), work units should coincide with the perimeter of symbolic representations, which means that iterative loops should not cross organizational units (stakeholder) or functional domain. That will also ensure the synchronization of changes in contexts and systems.
Regarding increments (engineering, diachronic perspective), iterations must be carried out independently of external circumstances, and products delivered continuously providing they meet exit conditions.
When these conditions cannot be achieved projects are to be fragmented according to domains (business perspective) or activities (engineering perspective).
Based upon a basic definition of tasks (requirements, development, deployment, architecture and quality) and the associated milestones, some archetypes of iteration patterns can be identified.
Development Cycles & Architecture Capabilities
Except for standalone applications, iterations must be bound by invariants set along architectural tiers: interactions are developed for given business logic (application layer), and applications are developed for given domains (persistency layer). As noted above, model layers and architecture tiers don’t necessarily coincide which can make iterative development difficult to manage.
That difficulty can be significantly reduced by anchoring iterations to homogeneous architecture capabilities, e.g 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.
Basic cycles can then be anchored accordingly:
- Local cycles deal with changes in business processes: new applications are added without changes to architecture capabilities (a,b). They are meant to be carried out under the authority of a single business unit and within a local time-frame, i.e are not bound to external events.
- Global ones deal with changes in enterprise architecture: organization, business, or platforms (d,b,c). As a consequence they involve the authority of different organizational units and are meant to be carried out within a global time-frame, i.e subject to external events.
For local cycles developments the loops are defined by incremental requirements:
- Invariants: backbone requirements of business objects and processes whose identity and consistency define the functional architecture.
- Increments: new functionalities or implementations.
- Exit condition: no more requirements
That’s the blueprint behind agile development approaches.
Overlapping Iterations
Overlapping (or simultaneous) iterations repeat only parts of development cycles, hence combining the authority of different organizational units independently of actual deliveries. As a corollary, development teams may be working on new subsets of requirements with previous ones still not be accepted. Using MDA model layers, one can identify three main archetypes of such iterative processes:
- Domain driven iterations: analysis and design are merged into a single loop in order to derive full functional (PIM) and technical (PSM) specifications from given uses case (CIM). That organization is recommended when a functional architecture has to be defined in order to support a representative or critical use case.
- Platform driven iterations: design and implementation are merged into a single loop in order to develop full implementation packages (PSM) from functional specifications (PIM). That organization is recommended when development is outsourced.
- Architecture driven projects deal with changes in enterprise architecture (organisation, systems, platforms). They are iterative by necessity because they must be carried out without disrupting enterprises performances.
Overlapping iterations clearly bring in a higher level of complexity, as perimeters, authorities, and tests may have to be managed independently; and since organizational procedures are no more available as abutments, iterations are to be defined directly on model contents and development flows, in other words on shared features.
On that basis iterations can mix business, engineering and operational processes across carried architecture layers according to capabilities, e.g:
- Business and organization: domain driven iterations.
- Systems functionalities: application driven iterations.
- Platforms: migrations.
Hence the control structure of iterative modeling:
- Invariants: A set of persistency and/or execution units.
- Increments: new features and/or operations.
- Exit condition: no more additional requests .
On a broader perspective, overlapping iterations must take into account the different lifespans of CIM artifacts:
- Business opportunities are by nature diverse and volatile. At symbolic level they are represented by applications. Since they are directly used by agents, domain driven iterations (possibly with prototyping) often bring significant benefits.
- Business domains are meant to secure a long-term basis for business development. In that case domain driven iterations may add to objects descriptions without affecting their semantics or identification mechanisms.
- Business organizations are the basis of corporate identities and valuation. In that case domain driven iterations may add to objects descriptions across domains.
Altogether, overlapping iterations should entail only local changes and as such should not introduce new architectural constraints. Yet, only a thorough definition of invariants may guarantee model validity, in particular for external consistency.
Iterative development, executable models, & model engineering
All in all, iterative development should always be set within a clearly defined development strategy, and take into account the logical tools supporting iterations, namely: patterns of representation (CIM/PIM) and implementation (PIM/PSM) on one hand, model transformation mechanisms one the other hand.
A particular attention should be given here to the meaning of “executable models”:
- Weak versions add some action semantics in order to support prototyping
- Language based solutions, e.g executable UML, use pseudo language like OCL or state machines and enable full code-generation.
- Domain based solutions use profiles and domain specific languages.
Set on a broader perspective, models can be either descriptive or prescriptive, but cannot be both. Hence, an executable model is either a simulation of a business process (descriptive) or an application prototype (prescriptive), the former being extensional (concerns are selective), the latter intensional (designs to be implemented).
In any case, executable models are models of computation and therefore useless for the organizational (CIMs) and architectural (PIMs) aspects. Besides engineering aspects, they can only be introduced once responsibilities and functional architectures are explicitly set. Then, model contents and execution platforms must be subject to distinct quality management. From that point of view, patterns and model translators, even if set independently of model contents and transformation tools, have contractual limitations and usually cannot to be used across organizational units.
Further Reading
- Models Transformation & Agile Development
- Agile Architectures: Versatility meets Plasticity
- Agile between Space & Time
- The Scope of Agile Principles
- How to Mind a Tree Story
- From Stories to Models
- Use Cases are Agile Tools
- Agile & Models
- Agile Falls
- Spaces, Paths, Paces (Part 1)
- Spaces, Paths, Paces (Part 2)
- Tests in Driving seats
- Projects as non-zero sum games