Objectives
Assuming that everything and everybody outside a project will hold its breath between inception and completion is arguably a risky bet; what is to happen if the paths from requirements to deployment are affected by changes in business or technical contexts, not to mention what may happen within projects. Such hazards are compounded by scale, as large undertakings entails the collaboration of several teams during significant periods of time. The first option is clearly to prevent such collateral damages by refactoring projects accordingly. When that’s not possible phased approaches are to be introduced, with milestones used to ensure that expectations are matched to commitments.
Rationale
Project sequencing can be defined equivalently by milestones or by intervals in between (phases, stages, etc.) The former perspective is to be preferred as it is less prone to methodological connotations and it can be based upon clear and unambiguous rationale, internal or external to project.
Internal justifications deal with project objectives, resources and achievements, e.g:
- Scale: milestones are set by thresholds, measured for instance by function points.
- Time-boxing: milestones are set by periods, for instance every week.
- Test driven: milestones are set by quality thresholds, measured for instance by number of detected errors, performances, etc.
External justifications deal with contexts and associated risks. Milestones are introduced when confirmation or consolidation are required or when adjustments are to be expected.
- Business context: objectives being set by market opportunities, change is the rule more than the exception and therefore should be built into project management. Yet, requirements cannot be managed on a continuous basis and commitments must be sequenced by milestones.
- Technical contexts: technologies and innovations are not always predictable, and when they are, options may be altered by organizational mutations. Dependencies between functional and non functional requirements should therefore be identified upfront and associated with milestones.
While internal justifications may be set along methodological preferences and dealt with at project level, that is not the case for external ones, which are clearly set by project objectives and contexts. As such they are meant to be negotiated between project teams and stakeholders, which do not necessarily share the same methodological creeds, if any. Hence the need of milestones to manage expectations and commitments along time.
Milestones and Architecture Driven System Modeling
Milestones can be set specifically for each project, along predefined project life-cycles, or selected from standard development patterns. The first option is not of much help and the second one is based on the one-fits-all bureaucratic fallacy, but the third one opens the way to proper design and assessment of engineering processes.
As should be expected with architecture driven system modeling, milestones are to be based upon architectural concerns. Starting with objectives, requirements can be regrouped in four categories:
- Business requirements are defined by stakeholders in charge of business units, business domains, or support units. They are set relative to enterprise architecture.
- Functional requirements are defined by organizational units managing the resources. They describe the part played by symbolic systems in support of business requirements.
- Quality of Service (QoS) requirements describe how systems are to be used independently of business contents.
- Technical requirements describe how systems are to be implemented independently users’ experience.
Quality of service and technical requirements are often defined as non functional requirements.
Depending on organizations and methods that classification may be refined further but, as it is, it provides a backbone crossing the three basic categories of processes to the three basic architecture layers:
- With regard to business processes milestones can be defined for (1) domains and activities, (2) roles played by supporting systems within organizations, or (3) quality of service
- With regard to engineering (aka development) processes, milestones can be defined for (1) project requirements, (2) system functionalities and, (3) software architecture.
- With regard to services management processes, milestones can be defined for (1) locations, (2) services to be supported and, (3) releases deployments.
On that basis, engineering milestones may include all levels, from requirements to implementation, according to functional footprint:
- Local execution units (entry points)
- Shared execution units (applications).
- Persistency units (aka entities).
- Midleware and Services
Alternatively, they may also be limited:
- Integration: due to mutations in organizational or technical contexts architectures are to be modified independently of business requirements.
- Migrations: the impact of organizational or technical mutations is confined to implementations and doesn’t affect architectures or business requirements.
It must be noted that, while integration and migration patterns will usually modify users’ experience, corresponding milestones should not be confused with quality of service requirements.
Milestones and Model Based Systems Engineering
Misguided understandings of software engineering often dumps milestones together with Waterfall as compared to Agile approaches .
But Waterfall is a red herring that deflect attention from the basic alternative, namely iterative vs phased development schemes.
That comes from phased schemes being confused with procedural ones, namely engineering processes set top-down from predefined activities. But model based systems engineering (MBSE) is meant to enable declarative solutions to phased development, with processes defined bottom-up from work units and the status of artefacts.
On that account, milestones are to provide the glue between architecture and business driven projects:
The former to be rooted in business processes, usually through users’ stories or use cases. They are meant to be managed under the shared responsibility of business analysts and software engineers, and carried out independently of changes in architecture capabilities (a,b).
Milestones as glue between Agile & Architecture Capabilities
The latter to be focused on architectures capabilities. They are meant to be managed under the responsibility of systems architects and carried out independently of business applications (d,b,c).