In Enterprise Canvas, we assert that everything is or represents a service. Ultimately, each service serves the overall vision or purpose of the shared-enterprise, which often extends far beyond the boundary-of-control of the organisation itself.

The values of the shared-enterprise derive from and express that vision or purpose. Hence these are values that the organisation must respect if it is be and remain in business within that shared-enterprise. For example, the TED vision of “ideas worth spreading” is expressed in practice through values such as responsibility, respect, clarity, connection, engagement, passion for ideas and production-quality – values that can be seen in practice in just about everything for which TED has either direct responsibility or oversight (such as the independent TEDx conferences).

In the sketch-notation for Enterprise Canvas, we typically model these as the ‘vertical axis’ through the service, connecting intent to real-world results:

In detailed practice and implementation, the values are expressed in more actionable form as principles. (See Chapter 23 ‘Principles’ in the TOGAF 9 specification for a good summary of how to define and structure actionable principles.) Principles are used to guide decision-making in the face of uncertainty at every level of abstraction, from strategy to tactics to real-time operations.

Value is what is passed around the enterprise, as exchanges between services, in order to achieve the overall aims of the shared-enterprise. In effect, exchanges of value within the enterprise align with and contribute to the values of the enterprise.

In the sketch-notation for Enterprise Canvas, we typically model most of these exchanges of value as the ‘horizontal-axis’ through the service, connecting with other services before, during and after each main-transaction. We would sketch a simple supplier-self-customer supply-chain model – such as is typical in Business Model Canvas – in a format somewhat like this:

To make better sense of that ‘horizontal’ flow of value, we often partition the service into a three-by-three matrix of ‘child-services’ – the matrix being formed from a time-dimension (before, during and after) and an orientation-dimension (inbound [service-consumption], self [value-creation] and outbound [service-provision]):

Often in modelling with Enterprise Canvas we’ll use generic labels for each of these clusters f ‘child’-services. For our purposes here, the cluster we need most to focus on is value-governance, which acts mostly (though by no means exclusively) on the back-channel, the ‘after transactiuon’ flows:

The service also needs to connect to other guidance-services, to help keep the flow of value on track to the enterprise-values. The guidance-services include:

• direction-services - the strategic, tactical and operational forms of classic ‘management services’
• coordination-services - guiding end-to-end connection of processes that intersect with multiple services, often across or between organisational silos
• validation-services - services that assist in building awareness, capability and action, and verifying and auditing that action, on ‘pervasive’ value-themes such as knowledge-management, health, safety and environment, efficiency, reliability, security and financial probity

In Enterprise Canvas sketch-notation we’d typically show the guidance-services like this, tagged with the respective symbol:

Of the guidance-services, probably ‘direction-services’ connect must strongly with the ‘Value Governance’ cluster of child-services, though by definition all of the guidance-services must connect with every part of the service.

So far so good: value connects to values.

Yet there’s another set of service-relationships that we must not overlook: the relationships with investors and beneficiaries. In Enterprise Canvas sketch-notation we’d usually show them like this:

Investors provide forms of value that are different from the forms of value that flow ‘horizontally’ around the shared-enterprise, but may be needed in order to start up, operate and maintain the service. The obvious example is financial investors, where the value of the investment is usually described in monetary terms. Yet there are many other forms of value that may be involved: for example, a community invests trust and, often, hope in an organisation doing business in its locality; families of employees may invest very real energy to keep them working there, and so on.

Beneficiaries receive some of the returned-value from the service, typically diverted from the flow in the backchannel, as a ‘dividend’ or suchlike. Again, the obvious example is value in monetary form, but again there are many other possible forms of value: civic pride, for example, or the shared pride of employees’ families.

Yet there are two fundamentally important traps to note here.

One is that the Investors and Beneficiaries may be different people. For example, an ‘externality’ occurs whenever one or more groups invest their own forms of value, but another group extracts all or most of the available value in one preferred form only, damaging or destroying most or all other forms of value. Again, the obvious example is financial: the community and employees invest their energy and their time, but the shareholders – as nominal ‘owners’ – claim the ‘rights’ to possess all of the returned-value, which somehow must also be converted to monetary form. A key role of value-governance is to identify such mismatches, and to bring them back into some form of balance that is acceptable to all parties – otherwise the service will fail over the longer-term.

(Somewhen I’ll have to write a post about anti-clients, anti-value, anti-Investors and, especially, anti-Beneficiaries. But that, as they say, is another story for another time!)

The other trap is that whilst the Investors’ and Beneficiaries’ forms of value may be needed by or deliverable by the service, the values of the Investors and/or Beneficiaries may not align with those of the service’s shared-enterprise. In enterprise-architecture we do need to respect the drivers and needs of Investors and Beneficiaries, but it may be essential to keep the value-systems separate. If we don’t, we risk ending up with the kind of lethal mess where, for example, attempts are made to measure everything in monetary terms, blocking the actual forms of value that traverse ‘horizontally’ across the enterprise-space.

Michael Porter described one form of this trap as“the obsession with shareholder-value is the Bermuda Triangle of strategy, in which companies sink without trace”. There are many forms of this trap, though: look around at much of mainstream politics and politically-motivated regulation these days, or the sad disaster-area that is the ‘rights’-discourse… It’s definitely a real challenge for any enterprise-architect.

In short:

• values guide decision-making and appropriacy of choices within the shared-enterprise
• value is what flows around, through, to and from each service in the shared-enterprise

So in each architectural context, be clear what values and forms of value you’re dealing with, and how and where and why – and don’t mix them up!

A month ago we saw Open Group begin to re-frame their previous IT-centred approach to EA into a new style of ‘enterprise transformation’. (The conference was still more IT than anything else, of course, but at least it’s a solid move in the right direction.)

Then a couple of weeks back it was academic and EA-luminary Jeanne Ross making clear her opinion that enterprise-architecture does not belong in IT, under the CIO. To quote her interview in CIO.com, “companies need to acknowledge that ‘architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO’”.

And now it’s Gartner, at this year’s Gartner Enterprise Architecture Summit in London earlier this week. I wasn’t able to get there this time, as I’m currently ensconced in central-America working on a bunch of EA-related projects; but fortunately the indefatigable Gerold Kathan was there, sending out a whole stream of useful tweets:

• gkathan: #entarch has no value until it is acted upon – deliverables should not be confused with value #gartnerEA
• gkathan: customize and adapt your #entarch framework – industry frameworks should be used for inspiration, not perspiration #gartnerEA
• gkathan: bringing something new like #entarch into top level management is hard: they will treat it as enemy in the beginning #gartnerEA
• gkathan: “EDD” is impacting application lifecycle: “executive deficit disorder” – short term focus and irrational decisions #gartnerEA

But what really caught my eye was this little beauty:

• gkathan: you have to reach out the 4 walls of your organization – extended enterprise includes e.g communities #gartnerEA

To which I can only sigh ‘Hooray!’…

I’ve no idea which of the Gartner consultants it was who said it; and since Gartner itself seems to have a policy of not crediting ‘outsiders’, I’ve also no idea if that comment has any link to the various conversations I’ve had with Gartner folks over the years. But just for the record, here’s my version of the full scope that an organisation’s EA must address, all the way out beyond the market to communities and more:

I’ve used a few variants of that in my EA presentations over the years – such as ‘What is an enterprise?‘ and the very-popular ‘The enterprise is a story‘ – but that’s the core idea, anyway. Nice to see that Gartner too is at last officially acknowledging that kind of scope for EA.

On the other side, I ought to acknowledge another ‘big fish’ that sort-of got there quite a long time ago. I was trawling through my downloads on this little-used netbook, and came across a report from Infosys – ‘Enterprise Architecture Expands Its Role In Strategic Business Transformation‘ [PDF] – from way back in 2008. It seems that even back then, the IT-centrism that still dominates ‘the trade’ was beginning to be challenged a lot more than most of the ‘big fish’ would be willing to admit:

Architecture steps out of the scope of IT and becomes part of planning and implementing strategy. In 22% of responding organizations, architectural processes are already being used for general business transformation.

And there’s this in the report, too:

Transformation is implemented in multiple streams within multiple units and functions of the firm. Today’s approach of architecture – looking at everything outside of IT as ‘the business’, and trying to access it through fairly generic, coarse-grained models – is bound to fail. A future enterprise-architecture will be ‘the architecture of the enterprise’. It will need to address the whole organization and each of its functions through appropriate models which are meaningful to the specialists of each area, and help them drive transformation. This means that it will have to provide structured models to represent architectures for production, research, finance and HR – much as it has for IT.

There’s a subtle trap in that that view is still centred around the organisation – ‘inside-in’ or ‘inside-out’, rather than the essential ‘outside-in’ view indicated in the Gartner quote above –  but at least it’s a lot broader than the obsessive IT-centric view that predominated then, and is still all too common even now. Credit where credit’s due – and worth reading the rest of the interestingly prescient report, too.

Gettin’ there, anyway – slowly, perhaps a bit too slowly for comfort still, yet we are gettin’ there. Feels good.

Just Enough Detail.

To which people will, of course, immediately ask, “Okay, but how much detail is ‘Just Enough Detail’?”. And I’ll have to admit that there isn’t a simple. certain, predefined answer. You just have to kinda know when enough is enough, you know? – which is why it’s more art than science, I guess. And why experience – usually gained by not getting it right… – is so important here.

One thing I do know is that one of the most-quoted answers is usually just plain wrong for this. John Zachman has always said that we need to document everything in ‘excruciating detail’. In a sense, yes, he’s sort-of right, especially if you hold to his metaphor that enterprise-architecture is essentially the same as engineering an aircraft. (I happen to believe that that’s a seriously-misleading metaphor, but that’s another story.) Yet in the real world – even in aircraft-engineering, as I know from much first-hand experience – much of the detail won’t stay the same for long enough to make that ‘excruciating detail’ requirement achievable in practice. Tricky…

Reality is that everything changes, everything moves. And the more they change, the more the demand for ever-more-detail becomes a trap. And when the pace of change itself is accelerating fast – as is definitely the case in most enterprise-architecture contexts right now – the more dangerous that ‘too-much-detail’ trap becomes, and the more we risk falling into it.

Yet on the other side, not enough detail means we won’t have enough of an anchor for meaningful sensemaking or decision-making – so we risk making bad decisions on the basis of too many arbitrary assumptions. That’s not a good idea either.

Hence Just Enough Detail.

The point is that that ‘just enough’ of Just Enough Detail varies all the time, from context to context, depending on who we’re with, what we’re doing, what we’re aiming to do, the type and rate of change, and all manner of other factors. Take this example from one of my favourite ‘show this to clients’ books, Matthew Frederick’s 101 Things I Learned In Architecture School:

There’s actually not much detail in that image. There’s no detail at all of the wall – and yet that’s still enough detail to make out that it is a wall (and probably a white-plaster wall at that). Other than the outline, there’s almost no detail of the woman, or her clothing – and yet it’s enough to get a good sense of who she is, what she looks like. There’s a bit more detail of the church and its dome – enough to tell that it is Brunelleschi‘s masterpiece in Florence – and of the townscape around it. Not much detail, then – and yet that’s all the detail it needs to tell the story. Not too much; not too little; Just Enough Detail.

So, over to you: how much or how little is Just Enough Detail in each part of your enterprise-architecture? How do you show that Just Enough Detail to whoever needs to see the story?

How much does Just Enough Detail change between different layers of abstraction, between different audiences, between backbone versus edge?

How do you know when it’s too much detail, or too little? How do you know when it’s just right? – when it’s Just Enough Detail?

How do you learn this delicate, ever-changing balance of ‘just enough’? From where and in what ways do you learn that balance – without causing too much damage whilst learning it?

Just Enough Detail, always. An interesting challenge, yes?

This from an interview with MIT-CISR‘s Jeanne Ross in the current (29 April 2012) online edition of CIO.com:

Myth: CIOs should own enterprise architecture. Not so fast. CIOs often wind up accountable for the entire enterprise architecture, despite not typically having the authority or vantage point needed to create one that provides what the organization needs. This leads to a disconnect. “When the CIO owns enterprise architecture, it’s a bad fit,” says Ross. “IT is being asked to do something the organization isn’t committed to.”

In reality, companies need to acknowledge that “architecture says everything about how the company is going to function, operate, and grow; the only person who can own that is the CEO,” says Ross. “If the CEO doesn’t accept that role, there really can be no architecture.”

Yep, that’s exactly what we’ve been saying for, oh, well over half a decade now – with the full explanation of why we’ve been saying it, too. But now that the same is being said by such an EA-luminary as Jeanne Ross, perhaps there’s some chance that it might actually be heard at last?

Here’s hoping, anyway…

Uh, no. Not a good idea. Not just because it’s a really bad deal from our perspective, but much more that Reality Department really doesn’t work that way: there’s no short-cut to experience.

Yes, it all looks simple enough – in fact that’s the whole point. A lot of simple visual summaries, and surprisingly simple-seeming methods, too. Yet it only looks simple because we’ve been through a heck of lot of hard work to make it that way. Hard-won experience, won the hard way through years and years of practice in many, many different contexts, getting it ‘wrong’ time and time again, in many, many different ways in order to get it right.

The real trap is that these simple-seeming ideas and methods aren’t simple rules, prepackaged sense-making and decision-making that will always work in every context. These are simple principles, simple guidelines, the kind of easy-to-memorise information that helps decision-making in real-time, in circumstances that are subtly different every time. (See my SCAN posts for more on these distinctions.) If you try to use them as ‘rules’ for inherently-uncertain contexts, without understanding why those principles apply, or how they need to be tweaked every time to match each different context, you’re going to be in real trouble – along with everyone else around you. Not a good idea…

The same often applies even to things that really are ’rules’. Take that example of perhaps the greatest simplification ever made: e=mc². All the core information you need to build a nuclear power-station is right there in that equation: but there’s a heck of a long way – a heck of a lot of engineering-experience – to go from that one equation to building a nuclear-power station that actually works.

Same with everything else, really: simplification is essential, but can also be deceptive – especially when people mistake ‘simple’ for ‘easy’…

Which is also why I get a bit hot-under-the-collar about the current proliferation of ‘certification-schemes’ in enterprise-architecture and elsewhere. Some of them are genuinely valuable, but others – to be blunt – are little better than money-spinning scams, in terms of the actual value that they (don’t) deliver. And the crucial distinction revolves around the role and recognition of experience.

For example, the TOGAF Foundation and Archimate Foundation certifications have real value. They verify that the respective person has a credible command of the terminology and language – a requirement that matters a lot for communication across a dispersed and disparate team.

Likewise the ATAC certifications should have real value, because each explicitly tests practical experience in the respective area.

But unless they’ve changed it in the past year or so, the full TOGAF certification is delivered through the absurdly-inappropriate mechanism of a multiple-choice test. And to my mind, that’s not merely useless, it’s actually worse than useless, because it’s exactly how not to test for the kind of experience that that type of competence requires. (When I did the TOGAF 8 exam some years back, I almost failed because I answered several key questions correctly in terms of real-world experience, rather than the theory-based wrong-assumptions that the test thought were ‘right’.) The result of that kind of pseudo-test is a bevy of people who can wave a certificate around, but have no idea how to do the work in any real-world context.

A good training-course can make all the difference, and the better training-providers do take up some of the slack here. (I’ll wave a flag at this point for John Polgreen at Architecting The Enterprise, who’s been doing sterling work for years on adapting TOGAF for the US-government context.) Yet none of that competence carries through anywhere into the actual test: so unless we know each of the training-providers, we have no way to tell whether a candidate does actually know what they’re doing, or merely that they have a piece of paper to prove that they know just enough to get into real trouble, but not enough to get out of it again.

In effect, right now, the full TOGAF certification is of less real-world value than the Foundation certification – which is both bizarre and sadly pointless. And I’ll hasten to add that I’m using TOGAF here merely as one example amongst many: it may well be that most of the so-called ‘certifications’ in this field are even more meaningless than that. And the results can be seen everywhere in the trade…

In short, it’s a mess.

What we need to be testing for is genuine understanding of a context, and the ability to adapt for uniqueness. And that calls for much, much more than can be covered in a crude multiple-choice test delivered through a mindless machine. Sure, that kind of test is cheap, and relatively easy to administer: but it’s also all but meaningless for anything than foundation-level rote-knowledge. It really does take years of painful practice to develop the experience needed to do this work well: and if this trade is to gain the credibility that it needs, we need to stop pretending that we don’t need to test for that experience.

Time to re-think how we do this, and how we respect this, too: there’s no short-cut to experience.

Is the EA the DJ?

He doesn’t tell people how to dance.

He provides the music for them to dance to.

He sets the mood.

He sets the tempo.

http://www.youtube.com/watch?v=oq71rV2FXSI

http://www.electronicarchitecture.co.uk

Listen. Feel. Connect. Interact. Imagination. Innovation.

Just thought it was an idea worth sharing, is all.

In the past few days I’ve had a fair bit of struggle to get clients to understand the difference between a linear-sequence with a beginning, a middle and an end, versus a true cycle where the end of one sequence links to or becomes the start of the next.

Cycles are literally cyclic: they’re not just linear sequences, they repeat, often in self-similar ways that are rarely ever quite the same. And the problem is that there are a lot of so-called ‘cycles’ that aren’t cycles at all. Some examples:

• Tuckman’s ‘Forming, Storming…’ lifecycle
• Adizes’ organisational lifecycle
• Gartner’s hype-cycle

At root, these are just linear sequences. For example, Tuckman’s ‘Forming’ stage (purpose) leads to ‘Storming’ (the all-too-necessary-yet-often-avoided people-stuff), thence to ‘Norming’ (planning and preparation) and ‘Performing’ (the actual process of delivering the project). And there it stops: if we’re wise, there’ll also be a final ‘Mourning’ or ‘Adjourning’ phase (closure, completions, lessons-learned), but as far as the individual project is concerned, that’s it. The End – the end-point of a linear sequence.

It’s not a cycle.

To make it a cycle, we need to be able to link the end of one sequence to the start of another: ‘Adjourning’ feeds into and informs the ‘Forming’ of the next project.

Once we have a true cycle, iteration-effects such as complexity and emergence start to appear; continuous-improvement becomes possible; agile self-adapting strategy in a fast-changing environment starts to make sense.

Yet those benefits only become available or visible where there’s a true cycle – not merely a one-shot linear-sequence that happens to call itself a cycle, but isn’t.

Cycles enable visibility of iteration-effects; one-shot linear-sequences don’t. And it confuses the heck out of people that we can have those two very different types of structures arbitrarily assigned the same name.

So if it’s only a linear-sequence, call it a sequence. If it’s a true iterative cycle, call it a cycle. If, like Tuckman’s project-lifetime model, it’s a sequence that can also be linked back to itself to create a true cycle, call it a sequence when it’s a sequence, and a cycle when it’s a cycle. Don’t mix them up!

In short, if it’s not a cycle, don’t call it a cycle. Please?

Yet is all as it seems? I’d have to admit that the conference-programme does worry me a bit. Despite the presence of a fair few people with a broader view than just IT – Alex Osterwalder, Len Fehskens and Stuart Boardman, to name just a few – so much of it still seems to be the same-old search for the ‘next big thing’, the next soon-to-fail IT-based magic-bullet: currently ‘Big Data’, mobility, cloud, cloud and more cloud. Oh well.

A bit of history might be relevant here. Back at the start of the 20th century, the electric motor was the great ‘next big thing’. Huge excitement! – huge hype! – the electric motor will solve everything! No doubt that it transformed industry: freed at last from that terrifying tangle of belts and pulleys, machines now placed wherever fits the workflow, smaller, more compact, more convenient. A whole new infrastructure to power it, control it, monitor it, measure it, manage it.

(Sounds familiar, perhaps?)

And finally, when electric motors were literally everywhere, embedded in almost everything, the realisation that although the electric-motor is an important enabler, it’s only an enabler: isn’t the enterprise itself.

The enterprise isn’t solely about machines, or information, or ‘making money’: it usually includes all of those things somewhere within the overall picture, but first and foremost it’s about the hopes and desires and aims of people. If we ever forget that fact, there’s no space for enterprise – and hence nothing against which enterprise-architecture, or enterprise-transformation, could ever make sense.

As Simon Sinek puts it, any enterprise-scope work must always start with ‘why’: the ‘how’ and ‘with-what’ come later in the story. And for enterprise-architecture that ‘why’ must always be about the whole of the scope – not solely about some arbitrarily-selected subset. Open Group’s TOGAF is excellent for enterprise IT-architecture; yet its rigid focus on IT (as defined in sections B, C and D of its Architecture Development Method) renders it problematic at best for anything else in the enterprise-architecture space. It’s fixable, as I’ve explained at various Open Group conferences and elsewhere over the past five years or so: yet still that kind of update has not been applied to the ADM, and in that sense TOGAF 9 represented a sadly-missed opportunity. As a profession, we need to do better than that.

To give some idea of what I mean by ‘the enterprise’ – and hence its architecture and its transformation – take a look at some of the projects I’m exploring at present in Latin America:

• a medium-sized brewer needing to resolve problems with internal theft
• a large manufacturer addressing multi-way ‘cultural translation’ between Asian ownership and executive, US management and methods, and Latin engineers and workforce
• a government department working with a film-producer to use social-media to break the cycle of mutual distrust between police and schoolkids and teenagers in the slum-districts
• an NGO wanting to use the ubiquity of cell-phones as a means to improve health-care in widely-dispersed indigenous communities

It’s likely that in each of these contexts, an enterprise IT-architecture will play some important part: but the IT itself is not the sole focus of the overall task. To make any of those transformations work, we need to start from people, not IT – start from enterprise as enterprise – and keep that whole enterprise in mind at every moment.

It may well be that enterprise-architecture is dead – but if so, it was killed by inanely inappropriate IT-centrism, in Open Group and elsewhere. As we move to a nominally broader-based enterprise-transformation, could more effort be made to ensure that we do not repeat the same IT-centric mistakes? Please?

• oscarberg: IMO #socbiz is primarily a mindset&way2see business in increasingly connected & digital age

I think he’s exactly right there: in essence, ‘social business’ is a different mindset about the way a business relates with others, and also with itself (as in the now seemingly-all-but-forgotten ‘Enterprise 2.0′).

But there’s a real booby-trap there that it’s essential to avoid (and that too many people did fall into with ‘Enterprise 2.0′). And that’s that this is not about the technology: it’s about the connections.

Okay, we’ll be fair about this, and agree the new digital technologies are important, as enablers of connections that would otherwise be hard (but not impossible) to set up via other means. As Andrew McAfee once put it, we’d have to agree that “it’s not not about the technology”.

Yet in social-business the connection is what matters: the ways we connect are always of secondary importance relative to that core focus.  If we ever lose sight of the fact that the technology is merely an enabler of connection, and not the connection itself, we’d be in real trouble real quick, with no way to see why we’re in trouble. Oops…

Something always to keep in mind here, please?

[A collection of notes that I made somewhen around May 2010 that I don't seem to have published before, and seem to be relevant now as I explore my own business-model. (Not an April-Fool joke, by the way. ) ]

A culture [enterprise-culture] is a set of prioritised values and goals – usually ill-expressed, conflicting, a muddled-mixtures of tacit and explicit. (Can be revealed by POSIWID – ‘the purpose of the system is what it does’.)

An enterprise begins with a vision.

A vision is a single emotive idea (a ‘parti‘, in architectural terms).

Values are used to identify what is and is not aligned to the vision.

The vision is the heart of a story; the enterprise is that story.

The organisation does not define the story - the enterprise does.

The organisation can choose which story to serve, and its role in serving that story.

The values of the enterprise provide a means to identify [and measure] alignment to the story.

The organisation can change its choice of enterprise to serve; yet doing so may (will) disrupt the values and prioritisation of values on which the organisation at present depends.

The story is the journey itself – there is no ‘final destination. (If there is a goal, the story will end, and likewise the reason for the organisation’s existence; so if there is a goal, plan from the start as to what will happen when the story ends.)

The structures and strictures of the organisation are a means to serve the story.

If you change the choice of story, you’re asking every person in the organisation whether they want to be [remain] in the organisation – to reconsider their ‘reason to be’, in relation to the enterprise and organisation. Not a trivial change!

Every person is ‘in’ multiple enterprises – prioritises which story (or stories) they serve.

To be successful, an organisation provides a clear prioritisation of stories.

The enterprise determines quality - what quality is. The vision is the ultimate anchor of quality (as per ISO-9000).

In the market-model, markets are:

• transactions (physical)
• conversations (virtual)
• relationships (relational)
• purposeful (aspirational)

Markets are all of these things, all together. (There’s a crosslink to here to effectiveness: for example “cheap, easy, gets all the shopping done in one go” etc.)

Market-sequence or market-cycle:

• reputation (also crosslink to vision); trust and respect (relational dimension)
• brand is ‘pre-packed reputation’
• attention and conversation (shift to virtual dimension)
• is often the preferred starting-point in the cycle (hence advertising, pre-brand)
• transaction (physical dimension), profit as ‘extracted value’
• transaction-only is (overly-simplistic) machine-model of the market
• needs full completions – customer, market, shared-enterprise – to complete the cycle and (re)affirm reputation

Hence ‘cost’, ‘profit’ etc are multi-layered – determined by the values of the enterprise.

[A possibly-useful item from the archives - hope it's of some value to someone, anyways.]