Development Patterns & Strategies
Roadmaps are solutions to development problems defined by organizational context, requirements, and resources. If development process capabilities are to be managed, assessed, and improved, for instance using the CMMI framework, those solutions must be measured against some objective criteria regarding development goals on one hand, development strategies on the other hand.
For that purpose projects are to be profiled in terms of development patterns and development strategies, selected respectively for objectives and contexts.
It must be noted that development patterns and strategies are not to be confused with domain profiles, which refer to model contents, nor to features like size or complexity.
If development processes are to be properly designed, assessed, and improved, the granularity of their work units must coincide with segments of development flows bearing objective measurements of system functionalities.
Based upon architecture levels (business, functional, technical) and functional tiers (local, shared transient, shared persistent, communication), it is possible to anchor development flows to core functional artifacts across model layers:
On that basis projects can be grouped into three broad categories:
- First, one would find technical projects, i.e those without business requirements. Those projects would deal with configuration, deployment or maintenance (PSM>Implementation) or be justified by platform evolution (PIM>PSM).
- Then, come projects whose requirements don’t affect symbolic architectures as set by persistency and control units. Changes are limited to features and rules of existing objects and processes (CIM>PSM).
- Finally there will be projects whose requirements initiate development flows directly targeting the symbolic architecture.
On step further, those stepping-stones can be used to describe project footprints. For example, a new application supporting new activities performed by roles already defined with existing applications:
The next step will be to associate footprints with work units and workshops.
From Footprint to Work Units
As development patterns deal with products, development strategies (as defined by processes) deal with projects, i.e with the definition and sequencing of work units. At first, the definition of work units is based upon technical as well as organizational considerations:
- Technical considerations deal with the contents of development flows: what is given, what is to be developed. Since decisions are meant to be made beforehand, iterative (or spiral) sequencing can be combined with agile principles, subject to development patterns as described above.
- Organizational considerations deal with responsibilities and must take into account organizational constraints set at corporate level. Some can be adjusted to development needs (e.g outsourcing vs internal development), some cannot be avoided (e.g requirements validation, deployment, etc.). Since organizational constraints involve decisions and commitments they usually entail waterfall sequencing.
When put together, technical and organizational contexts determine project contexts and objectives:
- Requirements are expressed by stakeholders and can address the full scope of systems seen as black-boxes within enterprise architecture.
- Functional architectures are designed by domain administrators; their objective is to consolidate symbolic representations and services supporting business processes.
- Applications are designed by software architects; their role is to define the implementation of functionalities with regard to platforms
- Configurations are managed by system administrators; their role is to deploy systems and components with regard to uses and resources.
Using a bottom-up definition of work units, development footprints can be directly translated into project organization.
With a clear traceability between models and development tasks comprehensively and consistently distributed along architecture layers, it will be possible to define metrics and manage quality according the specificity of each layer.
From Development Patterns to Development Strategies
With models organized according architectural concerns, project profiles can be defined as engineering paths across model layers. As a simple example, given a set of requirements, including for platform, a basic strategy will develop a standalone application by:
- Identifying domain persistency units (a1).
- Describing execution units, aka use cases (a2).
- Detailing attributes and operations (a3i).
- Designing persistency units (d1).
- Designing execution units (d2).
- Designing units details and possibly changing or extending them (d3i).
But that approach remains limited due to the lack of reasoned traceability between development patterns and projects organization. Hence the benefits of defining development tasks bottom up from development flows.
Development Patterns and Architectures
Development patterns set along views remain focused on software and ignore system perspective, in particular the different architectural layers. That is doubly inconvenient because a project architecture footprint is arguably a primary factor to consider for milestones, organization, and planning.
Hence, if projects are to be organized along a model driven engineering perspective, they must be characterized accordingly, which can be achieved with architecture based development patterns.
On one hand, assuming a given architecture, it is necessary to establish the footprint on system tiers:
- Are the persistency representations to be affected ? at unit level (entities or constraints) or locally (references or attributes) ?
- Are the shared applications to be affected ? at unit level (process or control) or locally (operations) ?
- Are the standalone applications to be affected ? at unit level (events or roles) or locally (features) ?
On the other hand, one needs to identify the origin of changes and their propagation along model layers:
- Configuration projects target system physical implementation. Symbolic representations (CIMs & PIMs) should not be concerned.
- Full cycle projects start with business requirements, continue with system functional and non functional requirements, and conclude with platform implementations.
- Functional projects deal only with the ways systems support business processes.
- Migration projects are meant to change implementations, ie support the same functionalities with a different platform.
Finally, the two perspectives are to be consolidated, in other words one should verify project consistency, e.g adding new persistency units should lead to new execution units, or new roles should lead to new transient features.
- Enterprise architecture deals with organizational and operational contexts: locations, agents and organization, business objects and activities, events.
- Functional architecture describe systems functionalities with regard to business processes: business domains and symbolic representation of persistent objects.
- Software architecture describe applications with regard to functionalities: business logic, persistency, user interfaces.
- Technical architecture: describe systems and components with regard to applications.