Phased Yet Lean Processes

Preamble

Given their inclination to fall, phases may be a recurring bane of development projects. Agile solutions have emerged as a default option providing that projects can be fully and firmly put under shared ownership and their outcome delivered continuously. But even when such conditions cannot be met lean processes may still be achieved with the help of model based engineering frameworks.

Phased vs Procedural

Not all applications can stand alone and therefore be developed by a cohesive team of business analysts and software engineers delivering a continuous stream of programs. Among the reasons for that:

• Stakeholders and decisions-making may spread across organizational units.
• Engineering resources may not be available simultaneously and continuously.
• The schedules of decisions or deliveries may depend on expected but not forecast changes in technical, business, or regulatory environments.

Traditional approaches to phasing constraints (notoriously Waterfall) have suffered from a bureaucratic bias as they have tried to coerce every project into predefined tasks and procedures targeting standard outcomes and deliverables. And with regard of phasing concerns, the lack of flexibility and built-in mechanisms has been counterproductive: instead of making room for phased decision-making, procedural solutions have resulted in fixed requirements set upfront.

Procedural vs Declarative

Engineering processes are to be considered when, whatever the reasons, activities cannot be performed simultaneously. Whereas procedural approaches deal with the problem with predefined sequences of generic activities, declarative ones directly consider associated input and output flows and set conditions on their processing.

Instead of one-fits-all predefined tasks, work-units can be defined with regard to their impact on development flows. As a consequence processes can be freed of bureaucratic shackles and combine iterative schemes with phasing engineering constraints.

Model Based Engineering

Agile development models are meant to epitomize lean engineering processes as development flows are seamlessly and continuously delivered to customers without the need of intermediate products.  Assuming that good schemes have to provide good-enough options, the aim is to build cut-to-the-bone processes for sub-optimal conditions, namely even if agile constraints of shared ownership and continuous delivery cannot be fully satisfied. And that can be achieved with the help of MBSE built-in mechanisms:

• The challenge of distributed and differentiated ownership can be dealt with by adjusting the granularity of artifacts with regard to business domains, functional architecture, and platform deployment.
• The constraints regarding discrete and phased development and delivery are not to be confronted  upfront through planning but dealt with dynamically by balancing users’ drive with artifacts’ phasing constraints.

Lean processes can then be achieved by anchoring model based frameworks to their environment.

Phased Yet Lean Processes

Lean processes can be defined by timed delivery without the use of unnecessary intermediate resources or assets.

Agile development models do the job by putting users’ needs on the driver’s seat and doing away with intermediate artifacts other than code. But shouldn’t backlog items likened to intermediate artifacts ? And in any case compromises may be necessary if users don’t speak with a single organizational voice and milestones are needed to synchronize development flows. For that purpose model based engineering processes have to be coupled with their organizational and technical environments:

• Downstream automated transformation are to ensure just-in-time delivery without undue or redundant intermediate documents and models (aka development inventories).
• Upstream conceptual (or meta-) models are to ensure semantic consistency across projects.

From a broader perspective that will demonstrate the ultimate benefits of both agile and model based engineering approaches.

Further Readings

• EA: Maps & Territories
• EA: Work Units & Workflows
• EA: Legacy & Latency
• Focus: Enterprise Architect Booklet
• Ontologies & Enterprise Architecture
• Ontologies as Productive Assets
• Caminao & DoDAF
• Products, Projects, Processes
• Models Transformation & Agile Development
• Agile Delivery & Dynamic Programming
• Open Concepts
• Open Concepts Will Make You Free