Work Units
Objective
At the beginnings there were only objects as given by nature; then men (and women) saw them as artifacts that could be made on design. As communities set on making more complex products, calling for differentiated and sequenced tasks, they began to think about collaboration, and finally about engineering processes; projects were introduced as an afterthought.
Work units must be defined in relation to processes (Lewis Hine)
In other words the meaning of work units is to be understood in relation to their arrangement into processes and they should be defined accordingly.
That is especially critical if the maturity of development processes has to be assessed and improved. For that purpose work units must be associated to well-defined inputs and outputs subject to sound metrics.
Work units: strongly worded, precisely assessed, continuously improved.
The objective is to use model driven engineering to define work units in terms of changes in development flows.
Views & Diagrams
The rationale behind architecture driven modelling is to consider contexts and systems as a whole and put all models under a common roof, from requirements to deployment. That approach can be compared to the standard four views of systems:
- Operational view: locations, agents, business objects and activities, events.
- Logical view: business domains and symbolic representation of persistent objects.
- Functional view: applications, business logic, user interfaces.
- Technical view: systems and components.
From Views to Workshops
When views are combined with MDA’s model layers, the corresponding workshops keep their identity across layers, even if the focus is modified: e.g, agents remain active physical objects from requirements to deployment, whatever their implementation, or messages are symbolic objects independently of supporting communication mechanisms.
When views are associated to customized tools, e.g UML diagrams, they can be used to define work units, e.g requirements capture (use case and activity diagrams), use case realization (sequence and class diagrams), etc.
Workshops and UML diagrams
Yet, while views are well suited for model management, they may be confusing with regard to development due to their non-procedural nature, e.g Class or Sequence diagrams can be used indifferently along the development process. But, as noted above, development processes are all about sequencing tasks and, for that purpose, work units must be directly associated to development flows.
Development Flows & Model Layers
Once business and technical risks are properly assessed, the organization of development workflows should distinguish between internal and external constraints:
- Internal (aka technical) constraints deal with contents: requirements, architectures, models, code, deployment, etc.
- External (aka organizational) constraints deals with responsibilities: stakeholders, users, administrators, contractors, etc.
Ideally projects should go “hand in hand”, with work units consistently defined on both technical and organizational basis. That is seldom the case, as illustrated by arguments about the respective benefits of Agile and Waterfall approaches. Yet, significant advances are possible if development profiles and strategies are designed along model layers.
Development Flows & Models Layers
While that’s the idea behind phased (e.g Waterfall) approaches, they often falls short of their objectives due to their coarse granularity: work units are just catch-all development phases without precise anchor to development flows.
From Development Flows to Work Units
Traditional approaches to work breakdown overlook the very issue they are supposed to deal with, namely process design:
- Waterfall approaches take for granted that one-fits-all organization and predefined activities can be configured to the needs of most of the projects.
- Agile approaches assume that expertise and best practices combined with responsibility and team work can do without explicit development processes.
Yet, steady grounds (duly defined procedures) and agility (lean and versatile processes) should bring cross benefits, providing engineering processes were designed from development flows.
Manufacturing processes, built from material flows and engineering constraints, have demonstrated the efficiency of flow-based approaches. As it happens, software engineering hasn’t followed suit and work units are still defined using customized versions of the same catch-all activities.
Work units should be derived from development flows
- Flow-based: work breakdown starts with production steps and builds processes bottom-up, depending upon constraints.
- Activity-based: work breakdown starts with one-fits-all organization, follows top-down with predefined activities, which are then entrusted with production objectives.
Flow-based development can be directly driven by users requests when these can be fully set under a shared ownership, otherwise cross dependencies between organizational units will have to be managed through models.
From Work Units to Development Processes
Work units for each architecture layer can be organized as trees built according a single blueprint:
- Roots support management, acceptance, and communication between layers.
- Intermediate nodes support specifications (top down) and integration and tests (bottom up)
- Leafs support the actual production of artifacts.
Execution is supposed to proceed depth-first from roots but the explicit management of sub-trees is to be set by organization: phased projects will manage all, agile ones will only manage the roots.
Work units are organized as trees
With work units directly rooted in development flows, tasks can then be organized according contexts and concerns: enterprise architecture and computation independent models (CIMs), functional architecture and platform independent models (PIMs) , software architecture and platform specific models (PSMs) , technical architecture and deployment models.
Development Artifacts and Work Units
With the benefits of such traceability processes can be organized according problems (what is to be developed) and solutions (how it may be done), e.g.:
- Migration: change of technical architecture.
- Refactoring: change of software architecture.
- New client application.
- New application: server and client.
- New service.
- etc.
Examples of development process building blocs: requirements to functional specifications (a); application (b); service (c); release (d); deployment (e); legacy (r).
