The cross-link is between VPEC-T and what I describe as the ‘market model‘ and ‘market sequence’.

Businesses operate within markets. And markets are, well, markets, y’know? As an enterprise-architect, the inadequacy of that common circular-definition has always irritated me, so for some while now I’ve used a description that’s rather more specific yet also more inclusive:

• markets are transactions – transfer of things, information, services and other ‘exchangeable items’, and other interactions that involve non-transferable assets (e.g. relationships, brands)
• markets are conversations – communication that may or may not link directly to transactions
• markets are relations – person-to-person (or person-to-abstract-entity) connections that link the players in the market
• markets are shared-purpose – the underlying reasons for the connections that provide the context for conversations that enable the market’s transactions
• each market is also itself – a distinct, identifiable entity that encapsulates and integrates all of those characteristics and attributes of ‘the market’

Conventional market-models seem to focus almost exclusively on the transactions, and any profits that might accrue from them. But this market-model shows us that those transactions only take place within a much broader and more complex context of interactions, such as in the market-sequence:

reputation / trust
-> respect / relations
—> attention
—–> conversation
——-> transaction / exchange
———> (profit) ——–:
trust / reputation <—:

It’s a loop: the whole sequence starts from and returns to trust (where reputation is a kind of trust-via-others), and which in turn depends on values and purpose. If we focus only on the transactions, it’s easy to miss the context in which those transactions take place – and thus misunderstand the true nature of the market.

In the book, VPEC-T is often shown as a kind of star-diagram, with each of its five elements focussing in turn on the central theme, such as an information-system or information-flow that’s being assessed. But we can also view it as a kind of bracketed sequence that also aligns well with the market-sequence above:

( Values ( Policies ( Event ) Content [-]) Trust )

(The ‘-’ in VPEC-T is often referred to as a kind of breath, a momentary pause, but it does indeed fit in the sequence at that point, and turns out to be surprisingly important, as we’ll see shortly.)

In effect, these line up almost exactly with the market-model as follows:

• Values align with the market-purpose – the implicit rules and reasons for relations in the market
• Policies determine the explicit rules for relations in the market, particularly in relation to specific types of Content
• Each Event triggers a conversation that encapsulates a transaction (for exchangeable items) or interaction (for non-exchangeable items)
• The Content is that which is exchanged (or equivalent) during the Event, in accordance with the Policies
• Trust is created or reaffirmed via complete integration, when the Content of the Event is in accordance with the Policies and the Values

The inner (PEC) loop matches up well with what ‘design-thinking’ guru Roger Martin describes in his book ‘The Design of Business‘ as ‘reliability’, whilst the outer (V…T) loop matches with Martin’s ‘validity’.

All of this applies to human transactions and machine-to-machine transactions. In IT web-service transactions, for example, we set up a protocol (Policies) that on receipt of an appropriate trigger (Event) enables the transfer of information (Content) – yet although the fact is often forgotten by system-developers, this also occurs within the context of a business-reason (Values), and will need to be validated and audited accordingly (Trust).

But that brief ‘breath’ (the ‘-’ between Content and Trust) is actually the closure-point for the inner (PEC) loop. If we’re not aware that there is an outer (V…T) loop, we can delude ourselves into thinking that the inner transaction-loop is ‘the market’ – which in the longer term will lead, almost inevitably, to an erosion of trust, and an erosion of the market itself. This risk is reinforced by the way that, in practice, the ‘-’ also represents the point at which the returned-value from the transaction can be identified and, optionally, transformed into an ‘extractable’ form – such as monetary profit. For those who are more interested in the profit they can make from the market, rather than the market itself, this provides a huge pressure to go back to the start of the inner-loop as quickly as possible – with results that are usually lethal in the longer-term.

Another key factor in this is whether the view is self-centric or market-centric. If the view is market-centric – in other words, the complete balance between the inner and outer loops – the emphasis will be on value-flow across the whole of the market: the concern will be that all participants obtain what they perceive as ‘value’, within the purpose and Values of the market, since this is what creates the Trust that drives the overall market. But if the view is self-centric – based solely on ‘I’ rather than ‘We’ – the emphasis shifts to an almost obsessive focus on the velocity of the inner loop, and on the selected subset of value that can be extracted from the transactions of the inner-loop: anything else – such as long-term strategy or trust in and from the market – slowly disappears from perception. In the latter context, apparently-’unpredictable’ events become almost inevitable: a disconnect from the strategic drift of the market, for example, or  ’anti-client’ rebellions against perceived ‘unfair’ Policies.

The problem is that most current ‘enterprise’-architectures are organisation-centric (or, worse, IT-centric), and hence tend to fall almost automatically into the inner-loop trap. For example, most attempts at enterprise-’vision’ are centred on the organisation – “to be the best of…” etc – rather than what a vision is actually for, namely to identify the Values and other drivers for the market’s outer V…T loop, and thus engage and maintain overall Trust. The outer loop also links the organisation’s strategy to the slowly-changing yet inexorable moods of the market – hence without proper connection to the outer loop, the organisation literally has no future. Serious indeed…

Unfortunately it’s proved quite difficult to explain all of this at a business-level, especially in words alone, or solely in VPEC-T terminology. One tactic I’ve found that does work is to link it to the Five Elements cycle that I’ve used in several of my models and workshops, such as described in Real Enterprise Architecture and SEMPER & SCORE. The link is that, in effect, the VPEC-T dimensions also represent – or at least align with – the focus and end-point of each of the five phases in the Tuckman-style cycle:

Note that in VPEC-T, ‘content’ actually has two distinct meanings: that which is carried into and worked on during the Event (what I call the ‘main-channel’ in the Enterprise Canvas model, which becomes the focus of activities in the Process phase), and the follow-up information and exchange that’s needed to ensure and verify completion of the inner-loop (what I call the ‘backchannel’ in Enterprise Canvas, carried through into the Performance phase). If we view Content as having both of these meanings, including the latter, the alignment with the Five Element cycle does make sense.

What also makes sense is the ‘-’ point in VPEC-T. Viewed through a Five Element lens, this occurs somewhen fairly early in the Performance phase, and represents a key decision: either to complete the full cycle by moving into the outer-loop to verify Trust, or take a short-cut back to somewhere in Policies (typically, assuming that overall policies are correct and that only Event-specific policies need be negotiated) in order to boost the velocity of the inner-loop. In effect, ‘-’ represents a choice: whether to go for short-term profit at the risk of long-term sustainability. (The ‘-’ decision also has an impact on other issues such as lessons-learned and broader benefits-realisation, but this is getting long enough already!) Using the same mapping between VPEC-T and Five Element, we can visualise this as follows:

Obviously this is a matter of finding the right balance: much of the time we can safely whip round the inner-loop at high speed, as long as we ensure that at some appropriate occasions we do indeed go round the full outer loop. A key part of enterprise-architecture, business-architecture and process-architecture is about providing contexts and processes that make sure that that outer-loop review and reassessment does take place. The practical problem is that pressures from the parasitic ‘shareholder’ system and ‘performance’-incentives can easily render the outer-loop all but invisible, making the choice at the ‘-’ point into an automatic or even enforced return to the short-term inner-loop rather than a proper considered decision in each case.

So that’s it: just another way to apply VPEC-T in enterprise-architecture practice. Hope it’s useful to someone, anyway: if so perhaps let me know?

Key point is that it connects exactly with whole-of-enterprise architecture: the architecture analysis phase – the ‘enterprise ontology’ – leads directly to enterprise software for information/process flow. So it’s not just ‘actionable enterprise architecture’ – to use a current popular buzz-term – but executable enterprise architecture. A few of the existing enterprise architecture toolsets are starting to get somewhere close to this – EVA NetModeler from Promis being perhaps the best example – but this comes at it from another direction entirely, and a more immediately usable direction at that.

That’s just the start. The key aim of Thingamy is to tackle the complex, near-chaotic, barely-repeatable process-flows that businesses really use in most of their work, and which to date have barely been addressed by existing enterprise software, precisely because they don’t fit the usual clunky true/false logic. The real-world processes that people use, in fact. Sigurd suggests that something like two-thirds of all business processes fit into this ‘barely repeatable’ category, yet almost all ‘enterprise software’ efforts to date have focussed on the ‘easily repeatable’ end of the scale, precisely because it is ‘easier’ (easier to sell to those who cling onto wistful dreams of ‘control’, too… :wrygrin: ). As with the comparison of analogue and digital – analogue can replicate digital, but digital can never do more than provide a abstraction of analogue – so too are the ‘easily repeatable’ processes merely a limited subset of the real ‘barely repeatable’ ones. So something that’s designed to tackle the ‘barely repeatable’ processes can also do all the ‘easily repeatable’ ones – yet much, much more. Definitely interesting…

To an enterprise architect, one obvious example of a ‘barely repeatable process’ is enterprise architecture itself. With many thanks to Sigurd, I’ve downloaded a copy of Thingamy, and over the next few weeks – time and sanity permitting – will have a go at implementing an executable version of my amended-TOGAF ADM, as one directly useful place to start. Watch this space?

[Many thanks to Sally Bean for her initial pointer to the 30megs site, by the way.]