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 subsequently 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:

1. Unity of action: a work unit should have one main objective,  be governed by a single authority, and complete with one single outcome.
2. Unity of place: a work unit should be executed into a single space ensuring that all resources can be addressed directly and accessed independently of any physical constraint, and that communications can be carried out without mediation.
3. Unity of time:  work units should be set within fixed and continuous time-frames (i.e under a single clock) 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.

Aristotle’s units can be directly associated with key factors governing software engineering, e.g:

• Decisions falling under the authority of different organizational units (1).
• Geographical constraints bearing upon execution (2).
• Unpredictability of contexts and execution making intermediate milestones necessary (3).

They will help to define project objectives and work units, and then to decide between agile and phased development models.

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 (built from sequenced predefined activities) by declarative ones (governed by the status of artefacts), and to design engineering processes in terms of artifacts transformation. Set at enterprise level, that approach has to be refined according to layers (artifacts) or views (models).

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 models:

• Enterprise view: locations, agents, business objects and processes, events.
• Functional (aka Logical) view: business domains and symbolic representation of persistent objects.
• Application view:  applications, business logic, user interfaces.
• Systems view: operations, resources, processes and services.

When views are combined with 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

Assuming that relevant business and technical risks are properly assessed, the organization of engineering workflows should distinguish between the origin of constraints:

• Internal constraints deal with contents: requirements, architectures, models, code, deployment, etc.
• External constraints deals with responsibilities: stakeholders, users, administrators, contractors, etc.

Ideally projects should go “hand in hand”, with work units consistently defined on both perspectives. 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 made from predefined activities, with unspecified anchor to actual development flows.

From Development Flows to Work Units

Traditional approaches to work units breakdown overlook the very issue they are supposed to deal with, namely process design:

• Procedural schemes like the V-Model (not to mention Waterfall) take for granted that one-fits-all organization and predefined activities can be configured to the needs of most of the projects.
• Iterative schemes implicitly assume that phased processes are redundant, i.e that expertise and best practices combined with responsibility and teamwork can deal with every kind of project.

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.

A simple comparison illustrates the benefits of a flow based approach:

• Flow-based: work units breakdown starts with production steps and builds processes bottom-up, according to the nature of artifacts and engineering constraints.
• Activity-based: work units breakdown starts with one-fits-all organization, follows top-down with predefined activities, with documented objectives and constraints.

Flow-based schemes so appear at the root of lean and just-in-time
processes, ensuring traceability and transparency from customers as well as providers perspectives.

From Work Units to Development Processes

As noted above, work units are to be defined across workshops and architecture layers (technical, functiona, and organizational); the same blueprint can be used to organize work units into dynamic trees within each workshop:

1. Roots support management, acceptance, and communication across 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.

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 to 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 artifacts is that it brings engineering and architectures under the same declarative paradigm.

Taking a leaf from the Zachman Framework, architecture 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 and crossed with processes:

• 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 their impact on architecture 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.

Work Units & EA Workflows

As noted above, work units are to be defined with regard to architecture layers (platforms, systems, organization) and development model (iterative or phased). While these factors are often related, large and complex organizations have to manage both self-contained projects set across architecture layers (usually with some kind of agile scheme), and transverse ones set across business units.

The difficulty is that changes in architectures can neither be carried out iteratively (due to external dependencies) nor with usual procedural schemes:

• Scope cannot be fully defined up-front, if only because the whole enterprise, including organization, could possibly be of concern.
• Fixed schedule is to be avoided, lest each and every unit, business or otherwise, would have to be shackled into a web of hopeless reciprocal commitments.
• Different stakeholders may come as interested parties, some more equal than others, but none with undisputed prerogatives.

In order to ensure the continuity, integrity, and consistency of enterprises business activities, projects affecting architectures capabilities are to be defined as workflows combining autonomous and cross-functional
development. That is to be achieved with model based framework managing work units according to the status of associated artifacts. Using a roundabout metaphor:

1. Self-contained projects are carried out independently until business dependencies have to be taken into account and quality conditions are met.
2. Work units concerned are then displayed on a blackboard (given access to a roundabout) and developed in sync according to dependencies.
3. The release (exit) of work units is conditioned by acceptance, yet doesn’t necessarily coincide with immediate deployment.

As a concluding note, flow-based work units appear as the thread bringing together agile development schemes and model based systems engineering.

Further Reading

• Thread: Project Management
• Thread: MBSE
• EA: Work Units & Workflows
• How to Pick a Development Model
• Architecture Capabilities and Requirements
• Agile and Models
• Conceptual Thesaurus: Overview
• Conceptual Thesaurus: Typical Use Cases