Work Units


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.

Unity of action, place, and time (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.

Aristotle’s Principle of the three unities

Likening processes to stories, work units can be defined using Aristotle’s three unities for drama:

  1. Unity of action: a work unit should have one main objective,  be governed by a single authority, with one single outcome.
  2. 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.
  3. 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:

  1. Decisions falling under the authority of different organizational units.
  2. Geographical constraints bearing upon execution.
  3. 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.

Work units: strongly worded, precisely assessed, continuously improved.

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.

Work units can be defined with regard to architecture layers: business, systems, platforms.

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.
Work units can be defined by engineered artifacts and corresponding views

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.

Workshops and UML diagrams
Workshops and UML diagrams

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.

Development Flows & Models 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.

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:

  1. Roots support management, acceptance, and communication between layers.
  2. Intermediate nodes support specifications (top down) and integration and tests (bottom up)
  3. 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.

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.
Capabilities can be defined across architecture layers with regard to business, engineering, and operational processes

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:

Requirements & Capabilities: new locations (a,f), new applications (b, d), new processes (c,e).

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.

Further Reading


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.