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.
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.
Aristotle’s Principle of the three unities
Likening processes to stories, work units can be defined using Aristotle’s three unities for drama:
- Unity of action: a work unit should have one main objective, be governed by a single authority, with one single outcome.
- Unity of place: developments should be executed into a space within which all resources can be addressed directly and accessed independently of physical constraints, and communication carried out without mediation.
- Unity of time: work units should be set within fixed and continuous time-frames and, once started, should proceed until completion independently of what may happen elsewhere. That is a necessity if innards and synchronization of tasks are to be managed independently of context contingencies.
Factors associated with contexts may also affect the sequencing of work units:
- Decisions falling under the authority of different organizational units.
- Geographical constraints bearing upon execution.
- Unpredictability of contexts and execution making intermediate milestones necessary.
Those rules are applied to project objectives in order to define work units and plan their execution.
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 and subject to sound metrics.
As far as software engineering is concerned, model based engineering frameworks can be used to define work units in terms of changes in development flows.
Layers & Views
The rationale behind model based system engineering is to replace procedural schemes by declarative ones and to define engineering processes in terms of artifacts transformation. That approach can be refined by regrouping artifacts and models according to architecture layers or views.
The layer perspective is best represented by the Model Driven Architecture (MDA) and its distinction between computation independent (CIMs), platform independent (PIMs), and platform specific (PSMs) models.
The view perspective put the focus on the nature of models and artifacts:
- Physical view: locations, agents, business objects and activities, events.
- Functional (aka Logical) view: business domains and symbolic representation of persistent objects.
- Application view: applications, business logic, user interfaces.
- Process view: systems, processes and components.
When views are combined with 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.
Customized tools, e.g UML diagrams, can be used to define work units, e.g requirements capture (use case and activity diagrams), use case realization (sequence and class diagrams), etc.
Yet, while views are well suited for monitoring and management, they may be confusing when engineering is to be considered, 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 Phased development models. Yet, significant advances are possible if development profiles and strategies are designed along model layers.
While that’s the idea behind phased 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:
- Phased 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.
- 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.
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.
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.
Work Units & Architecture Capabilities
Perhaps the most significant benefit of defining work units bottom up from development artifacts is that it brings engineering and architectures under the same declarative paradigm.
Taking a leaf from the Zachman Framework, capabilities can be organized around five pillars supporting enterprise, systems, and platform architectures:
- 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.
These capabilities can be directly refined across architecture layers:
- Business and organization: EA capabilities with regard to business environments and objectives.
- Systems and engineering: systems capabilities with regard to enterprise ones.
- Platforms and operations: platforms capabilities with regard to systems and enterprise ones.
On that basis it would be possible to define work units with regard to changes in capabilities:
Depending on the relationship between requirements and capabilities, developments will be carried out iteratively, step by step, or surgically according to the status of artifacts.
- Thread: Project Management
- Thread: MBSE
- Architecture Capabilities and Requirements
- Agile and Models
- Conceptual Thesaurus: Overview
- Conceptual Thesaurus: Typical Use Cases