Contract Driven Modelling
Even if contracts may have to be enforced by law, their primary rationale is to frame agreements and support collaboration.
Along that perspective the use of models may bring significant benefits regarding:
- What is at stake, what is to be provided.
- When resources are to be make available and outcomes delivered.
- Who should be responsible, who should contribute.
- How participants should collaborate.
To be of any use, contracts must help to clarify expectations and commitments. While applied to standalone applications both can be set on flat level and managed directly between customer and provider. But projects involving different organizational entities, with concerns and agenda of their own, cannot be managed on a day to day basis because decisions are set in different contexts and time scales. In that case explicit milestones and sequences are to be introduced and contracts defined as to manage the consistency of commitments all along project life cycle. And that is best achieved through transparency and layered traceability provided by models.
The benefits of matching models and contracts can be found in both directions: on one hand models are built along clear lines of responsibility, on the other hand they provide a sound basis to contract validation.
Matching models and contracts can also be seen as a generalization of Test-driven development (TDD) to the whole development process:
- First, it brings about Design by contract as a supporting context.
- Then, if regression is to be avoided, contracts must be organized depending on their scope, nature and stakeholders.
- Finally tests and contracts must be set within model driven development. For that purpose it is necessary to translate the test-driven principles to modelling.
Finally, since contracts are about deliverables and prices, some common ground must be defined between them, and that can only be achieved with functional metrics computed from models.
When: Loops and Milestones
As convincingly argued by agile approaches, projects are best managed when customers and providers can collaborate directly, matching expectations and commitments within continuous development loops. Yet, since that’s not always possible, a good compromise should be to combine iterative development with milestones set along clear rationales, e.g:
- Dependencies between specific applications managed by organizational entities whose direct collaboration cannot be achieved.
- Non functional constraints, to be supported by technical architectures.
- Cross functional requirements, to be supported by functional architectures.
Models are to provide explicit and unambiguous descriptions of milestones to be used as invariants for safe iterative development.
Who: From Models to Tasks
Manufacturing processes, built from material flows and engineering constraints, have demonstrated the benefits of flow-based approaches both for in-house production and outsourcing. Yet, despite dealing with symbolic artifacts free of material frictions and impediments, software engineering hasn’t followed suit, with work units still based upon customized versions of the same catch-all activities instead of defined from deliverables.
- Flow-based: work breakdown starts with targeted deliverables and builds processes bottom-up, depending upon constraints on development flows.
- Activity-based: work breakdown starts with one-fits-all organization, follows top-down with predefined activities, which are then entrusted with production objectives.
Set within a model driven engineering framework, work units could therefore be defined directly in terms of models and development flows. That would befit a contract driven paradigm as functional metrics could be used to asses the tasks both for charge and value added.
How: Collaboration and Non-zero Sum Game
Given that engineering projects call for collaboration, their success is heavily affected by the framework governing the relationships between participants. Taking a cue from non-zero sum games, the corner stone of collaboration should be to establish a playground where one’s benefits don’t have to come from others’ losses.
On one hand customers specify the needs (b), pay for the outcome (c), and expect to benefit from its use (a); as far as they are concerned, success is measured by the return on investment (ROI), which depends on cost, quality, and timely delivery. On the other hand, providers design the solution (a), assess its cost (b) and set a schedule; narrowly defined, their success will be measured by costs. Hence, while stakes are clearly conflicting on costs, there is room for collaboration on quality and timing, and that will bring benefits to both customers and providers.
Collaboration stems from timely and trustworthy information; since engineering projects usually come with intrinsic uncertainties, players must be constantly and fully aware of their respective knowledge, expectations and commitments. That should make for lean models focusing solely on unambiguous and necessary descriptions.
- Non ambiguous: just like programs can be designed as to be testable, models should be built as to be open to refutation. Paralleling TDD’s “fail fast” principle, requirements should avoid generalizations in favor of conflicting assertions with clear-cut alternative options.
- Necessary: based on requirements organized by contracts, models should be sequenced as terraced fields. Paralleling the “You ain’t gonna need it” (YAGNI) with a “now” qualification, each terrace should focus on homogeneous outcomes with models pared down to necessary and sufficient artifacts.
Whereas those principles are meant to be applied to specific contents, contracts should primarily be mapped to models layers and set to coincide with quality checks.
Finally, if timely and trustworthy information is a necessary condition for cooperation, it is not a sufficient one, as players may be tempted to defect (aka cheat) if they think they can get over with it. Leaving out ethical considerations and invasive regulations, the best policy should be to make a convincing case for due diligence as participants should:
- Say what they know, mean what they say, say what they mean.
- Look at outcomes and deliverables, and check their validity.
- Listen to what others have to say, and take their concerns into account.