Rethinking Zachman – the 'How' column

Moving onward across the amended Zachman framework, the next column is ‘How‘.

Zachman describes this as ‘process / input-output’, but again this is somewhat misleading. The true primitive here is function, in the mathematical sense. In other words something is changed between input and output: a=func(x,y) and suchlike. A process is a sequence of such transforms, a path through a set of functions threaded together in a meaningful way with events, data, objects and do on – and is thus a composite, not a primitive.

The list of inputs consist of two distinct types: the item(s) to be transformed; and the catalyst(s) which trigger or guide the transformation without themselves being changed.

The activity proper marshals the inputs, changes the state or condition of the items to be transformed, puts the changed items and the catalysts back into their proper places, and signals that the function is complete. For examples, think of a low-level software function, which retrieves its attributes from the stack, carries out the required transforms and other activities, then places its results on the stack for the next function; or in the physical world, a technician selects a casting to machine, configures up a lathe with a set of tools and settings, carries out the required transforms, puts away the machine-tools, and places the machined casting into the output tray for the next operator to carry out the next stage. In each case there’s also an internal decision to identify that the transform is complete.

Since functions act on things – How acts on What – the segments should be much the same as for the What column:

• physical: transform physical objects
• virtual: transform data
• relational: transform business-relationships – for example, to close a sale
• abstract: transform financials – for example, financial derivatives

(In principle there are also functions that operate on aspirational entities such as morale and values, but they’re so little understood – especially in large organisations – that it’s simplest to ignore them for now. Aspirational entities are important, though, as catalyst-inputs to relational functions.)

As with the What column, these are distinct segments: on its own, a software function will not change a physical object or a business relationship. But we can transform across segments with composites: software can change physical objects through an NC machine-tool, data supports changes in customer-relationships in a call-centre business-function.

Typical model-types are the classic functional-decompositions: a high-level function decomposes to low-level sub-processes which include subsidiary functions. The only complication here is that it’s not a straightforward primitive-to-primitive decomposition, as it is with a parts-breakdown, for example: a function (primitive) decomposes to a process (composite) which contains functions (primitives).

For architectural purposes it’s important to separate out the primitive function (How) not just from its surrounding inputs and outputs (What) and events (When), but also from the capabilities and responsibilities (Who) that enable the function. If we don’t do this, we end up with a blurred composite masquerading as a primitive – in other words, a future roadblock to change or improved effectiveness. This blurring is reflected in the history of software engineering:

• procedural programming: centred on function (How), but merged with capability (Who), data (What) and business-rules (Why)
• object-oriented programming: centred on data (What), with attached function, and again often with merged capability and business-rules
• service-oriented architecture: centred on function, usually without merged data and business-rules, but often with merged capability – i.e. implied or assumed

The ideal for service-oriented architecture is to show the linkages to capability, data and business-rules, but still keep everything separate and distinct. More on that when we get to the Who column.