Objectives
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.
Footprints
If development processes are to be properly designed, assessed, and improved, the output of work units has to be associated to some metrics of system functionalities. That can be best achieved if the granularity of work units is aligned with well defined segments of development flows.
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 set independently of specific 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 phased processes.
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
Model driven engineering is often associated with the engineering of models themselves, be it by transformation, interpretation, or code-generation, not to speak of reverse engineering.
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. On that account two basic options are to be considered:
- Agile development processes put the focus on collaboration and collective responsibility. Project teams encompass all the expertise and authority to carry out the whole of development. That should be the default option when shared ownership and continuous delivery can be achieved.
- Phased development processes are used when organizational of technical dependencies preclude shared ownership or continuous delivery.
Phased solutions are often associated with Waterfall and its poor track record. But phased solutions don’t have to be designed top-down from predefined activities; instead the phased work units can be set bottom up from development flows.
When systematically applied at project inception that kind of analysis would help to decide between agile and phased options; it could also be used to refactor projects as to set apart architecture driven developments.
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 organization (agile vs phased), milestones, and planning.
Hence, if projects are to be mapped to development patterns, they should be characterized with regard to architecture capabilities and layers.
Taking a leaf from the Zachman Framework, architecture capabilities can be organized around five pillars supporting business (enterprise), functional (systems), and technical (platform) layers:
- Who: enterprise roles, system users, platform entry points.
- What: business objects, symbolic representations, objects implementation.
- How: business logic, system applications, software components.
- When: processes synchronization, communication architecture, communication mechanisms.
- Where: business sites, systems locations, platform resources.
On one hand, organization will depend on cross dependencies:
- 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, i.e 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.