Scope & Purpose
Engineering projects can be characterized by their scope (systems or enterprise) and purpose (business value or architecture assets):
- Business value, for the fulfilment of requirements rooted in the specifics of business processes as defined directly or through use cases
- Architecture assets, for the fulfilment of requirements defined across business processes, through models or system cases
Four basic templates can thus be defined:
- Application level, for self-contained projects developed directly through the application workshop without using intermediate models (a)
- Process level, for business applications with overlapping footprint developed from use cases through the application workshop (b)
- Domain level, for developments affecting business domains without changes in anchors (c)
- Business level, for developments affecting business domains including anchors (d)
Fences can then be defined accordingly:
- Business cases (BC), between enterprises and environments
- Use cases (UC), between enterprises and systems, with Agile cases (AC) for stand-alone projects without organizational or technical dependencies (ensuring shared ownership continuous deliveries)
- Function cases (FC), between systems
- Technical cases (TC), within systems
Indicative remits can be added but details are best defined by enterprises’ organization.
Development Models
Beyond the variety of methodological dogmas and tools, these templates can be associated with two basic development models, iterative (a), for stand-alone developments free of cross dependencies; and Model-based (b,c,d), for requirements with architectural dependencies
Iterative developments (aka Agile) are characterized by the same activity (or a group of activities) carried out repetitively by the same organizational unit sharing responsibility, until some exit condition (simple or combined) verified.
Phased developments are characterized by sequencing constraints between differentiated activities that may or may not be carried out by the same organizational units. It must be stressed that phased development models cannot be reduced to fixed-phase processes like waterfall. As a corollary, they can deal with all kinds of dependencies (organizational, functional, technical, …) while being neutral with regard of implementations (procedural or declarative).
A straightforward decision-tree can so be built, with options set by ownership and dependencies:
