Yet more on ‘No jobs for generalists’ [2]

Why do enterprise-architects and other generalist disciplines find it so challenging to prove the value of their work? Why does it seem that there are ‘no jobs for generalists’? And what can we do in practice to resolve this challenge?

First, though, a quick round-up of where we’ve gotten to so far:

• ‘On learning enterprise-architecture‘ – where all of this discussion started, exploring the skills needed for generalist disciplines such as enterprise-architecture
• ‘There are no jobs for generalists‘ – about why it’s so hard to get work as an enterprise-architect, and why most advertised ‘jobs’ for enterprise-architecture don’t actually have much to do with enterprise-architecture itself
• ‘More on ‘No jobs for generalists’‘ – exploring the implications arising from various responses to the ‘No jobs for generalists’ post
• ‘Yet more on ‘No jobs for generalists’ [part 1]‘ – about the underlying assumptions that give us so much trouble

And where we’re going:

• part 2 (this post): about structures and interdependencies between services
• part 3: about where and why Taylorism is a poor fit for many present-day business-needs – and some key implications that arise from that fact

In this part we’ll also start to explore how this can easily become or be seen as, uh, ‘political‘… and hence why we need to hold the focus strictly on the architecture – nothing else.

Remember that the primary role of enterprise-architecture is decision-support for others, not decision-making for others: that distinction becomes extremely important here… Within our professional discipline, we explore the implications of various structures and the like, and identify trade-offs between different implementations, but we should not attempt to foist our own political-or-whatever preferences on everyone else.

Architectural-analysis in this domain does surface a whole swathe of fundamental design-flaws not just in current recruitment-concepts and the like, but in concepts of management, market-relations, economics and current law: to put it bluntly, very little of what most people think of as ‘normal’ is actually capable of working well, or even at all, especially in the longer term. To say that to many people this is scary in the extreme is an understatement… and if we’re not careful, we get the backlash from exposing that fear. Unless we’ve been explicitly assigned the task, such ‘politics-stuff’ is the responsibility of other decision-makers, not ours: and often, in business, only if we have that explicit assignment from ‘the top’ will we have any viable defence. So please, do be careful about this: keep the analysis separate and distinct from the politics – otherwise you may well discover first-hand just how irrational most politics can be… You Have Been Warned, etc?

The simple model of work

In any social context, we need to share around the work and the resources of that context. Managing the balance and distribution of the work and the resources is the role of economics – literally, ‘the management of the household’. Perhaps the classic notion of an idealised economics is this:

from each according to ability;
to each according to their needs

People being what they are, of course, and reality being what it is, there’s potential for many, many, many arguments about the right-and-proper ‘from each‘ and ‘to each‘ that should apply in each person’s case… So an economic model aims to forestall most of those arguments by providing a set of prepackaged answers as to how the balance should work.

The current mainstream economic model – the one in which most of our organisations will operate – is a money-based possession-economy: we use some variant of money as intermediate tokens in extended-barter exchange of possessions. These exchangeable-possessions may be goods or services: so if we don’t have some form of ‘thing’ to sell, we can sell our labour instead. So, to put it in its simplest form, the basis for any kind of ‘job’ purports to be this:

do work -> get paid -> buy stuff we need

The reality, though, is slightly different:

do work that someone else will value -> get paid – > buy stuff

And it’s in that bit about ‘that someone else will value‘ where all manner of nasty ‘gotcha’-complications can arise…

[Since we’re looking mainly at the notion of ‘job’-type employment here, we’ll sidestep for now the huge complications around what needs to happen for people who can’t ‘work’ in that sense. Just note that they are part of the whole-enterprise picture of economics – a point that many ‘economists’ and politicians seem too often to forget…]

A simple linear view of economics would suggest that payment is linked solely to transactions for tangible good and services: it’s there, we can see it, we can touch it, so it’s worth paying for. This is the basis of the classic town-market, bazaar, souk or suchlike. We get paid when a tangible transaction completes.

Yet whilst that might work as a trading-model, it doesn’t work well enough as an economic-model: there’s a lot more to economics as a system than just its direct trades. This is reflected well in the common English pub-signs about ‘The Four Alls‘ or ‘The Five Alls‘:

• the ruler: “I Govern for all”
• the lawyer: “I Plead for all”
• the priest: “I Pray for all”
• the soldier: “I Fight for all”
• the ordinary man: “I Pay for all”

The same systemic point comes up as the basis for classic capitalism – the distinction between Capital and Land on one side, versus Labour on the other. Labour provides the ability to produce, in terms of ‘tangible transactions’, whereas capital provides the means of production – the landowner provides the services of the land, the factory-owner provides the factory, the ship-owner provides the ship, and so on. One step further back, the finance-owner provides the finance that enables the purchase of the land, the factory, the ship, or whatever. Capital provides services – not labour. Which leads us to a somewhat extended version of ‘work -> get paid’:

provide thing, work or service that someone else will value -> get paid

Note again that there are often huge arguments about who should get paid what, and who has the ‘right’ to decide who gets paid what – yet all of those arguments are outside the scope of the architecture. (Mostly, anyway…) We would describe parameters such as price versus value, the implications of those parameters and suchlike, and might well map out and model appropriate ‘solutions’ for those implications: but the ultimate decisions about which solutions to adopt are (fortunately?) a problem for politicians, not for us in our role as architects. Do not forget this point! – getting this wrong is usually best described as ‘not a good career-move’… 😐

Anyway, quick summary:

• a simple version of ‘work’ – and hence ‘job’ – centres around pay for transactions
• pay for transactions depends on having ‘something of value’ to exchange for pay
• delivering value depends on both the ability to produce (‘labour’) and the availability of appropriate means of production (‘capital’)
• a more systemic view of ‘work’ must encompass not just the content of that work – the direct, visible ‘transactions’ – but the whole context in which that work takes place

And, from Part 1 of this series:

• specialists focus more on content – the actual ‘doing’ of work
• generalists focus more on context – the ways in which different aspects of work link together

That much should be obvious if we look at work and ‘jobs’ from a systemic view. However, as we saw in Part 1, most people do not think in terms of systems: as in most variants of Taylorism, they think in terms of linear connections, linear transactions, linear outcomes, ‘this causes that’ – which causes most non-‘market-transaction’ work to become ‘invisible’. Hence what so often happens in practice is that every group outside of a simple ‘market’-type scope will attempt to assert that they are somehow ‘essential’ for everyone else: hence The Five Alls and suchlike, and the relentless clamour of competing-claims to be ‘more important’ than everyone else. We also get relentless gaming of price/value mismatches – and often ‘rent-seeking‘ games, too where the term ‘entrepreneur’ becomes its all-too-literal translation as ‘between-taker’ (‘entre’=’between’, ‘prendre’=’to take’). In short, it’s a mess – and a very ‘political’ mess at that.

To avoid getting trapped in the politics of work, we definitely need a more architectural approach to what’s going on here. And if we’re to make any architectural sense of this mess, we’ll need some kind of systemic approach that provides consistency across the whole space of ‘work’, yet will still ‘make sense’ for a more linear mindset. In my own architecture-practice, this comes down to two parts:

• use Market Model and Market-Cycle to describe the scope and context of work
• use Enterprise Canvas to describe the interdependencies of work in that scope and context

Let’s start by exploring more about the broader scope of ‘work’.

Market-model and market-cycle

For the background, we’ll need a few key definitions and assertions.

[Note that none of these definitions are arbitrary as such: there’s a lot of work behind each of them, as described throughout this weblog and elsewhere. However, note that, strictly speaking, they are only a specific set of ‘lenses’ that make certain things more visible, and perhaps make other things less visible as a consequence. All of what follows will proceed as if the assertions are ‘true’, but that’s not the same as saying that they are ‘true’: that distinction can be extremely important… Remember that we’re working systemically here, recursively, and with full acknowledgement of inherent-ambiguity – not a simple Taylorist-style linear notion of ‘true-or-false’.]

First, we use an intentionally-open physics-based definition of work: work is the rate at which energy is expended.

In human terms, human work is anything that people do: dig a ditch, solve a technical problem, build a business-relationship, or help others reclaim hope from despair – whatever it is, it’s all work.

In those same terms, a ‘job’ consists of being engaged in doing some form of human work; hence ‘self-employment’ will typically consist of doing a ‘job’ on behalf of oneself, and ’employment’ typically a ‘job’ on behalf of someone else.

For simplicity we assert that all work is delivered as services. In this view, a product or ‘thing’ is, in effect, a ‘proto-service’, a resource to enable self-delivery of a service.

The effective value of that work – often expressed in terms of ‘effectiveness‘ – would depend on themes such as purpose or intent, separate and distinct from the work itself.

An enterprise consists of any number of services coordinated towards some overall aim or intent.

An organisation provides a structure through which services may be coordinated towards the aim of an enterprise.

[The architectural importance of drawing a distinction between ‘organisation’ and ‘enterprise’ has been a key theme of my work: see, for example, ‘Enterprise, organisation and the Olympics‘ or the slidedeck ‘What is an enterprise?‘.]

An organisation employs a person in a job for the purpose of creating and delivering value towards the aims of the enterprise(s) with which the organisation is associated. In effect, a ‘job’ consists of delivering services on behalf of the organisation, to add value to the enterprise, in terms of the values of that enterprise.

Value is added to and moved around the overall shared-enterprise within the context of a market, and beyond – the Market Model:

The Market Model actually applies at every scale: for example, ‘the organisation’ could be anything from a single business-team or even an individual, all the way up to a multinational corporation or an entire country.

The visible transactions (the blue arrows in the diagram above) take place between the organisation and its suppliers and customers. The services that enact these transactions are often described as the organisation’s ‘profit-centres’.

Other non-visible transactions and interactions may take place anywhere within the organisation, its ‘supply-chain’, market or extended-enterprise. Where acknowledged at all – and many are not – the services that enact these interactions are often described as the organisation’s ‘cost-centres’.

Visible-transactions are typically identified as such – i.e. perceived as ‘visible’, or as ‘real work’ – where they align with the organisation’s view of value. However, such transactions take place within a broader context of what the enterprise views as ‘of value’: business-critical interactions take place both before and after the transaction itself. We can typically describe this in terms of distinct phases and interactions within the Market-Cycle, or Service-Cycle:

• before there can be a transaction, we need to have the customer’s attention;
• before their attention, a relationship with the customer, or at least their respect enough to listen;
• before relationship, either trust, or reputation as proxy for trust.

These also link strongly with the dimensions of the VPEC-T framework (Values, Policies, Events, Content, Trust), which we might show in somewhat-modified form (with an emphasis on completions rather than content) on the service-cycle as follows:

Note, however, a key distinction in perspective in how these ‘non-visible’ interactions will perceived within the business-architecture:

• linear view: these interactions are separate from the transaction – i.e. a ‘cost’ or ‘overhead’, to be avoided or eliminated wherever practicable
• systemic view: these interactions are integral to the transaction – i.e. transaction-profit depends on the completeness and effectiveness of the entire set of interactions

Much the same applies as we unravel the interactions at the far side of the transaction, where we need to complete:

• the tasks (process) of the service itself
• the overall transaction (for example, the organisation is paid)
• satisfaction of customer-attention (customers feel that they have been heard)
• renewal of customer-respect (respect of customer, and by customer)
• renewal of overall mutual-trust

A systemic view accepts the necessity to take account of and support all of these interaction-types (and more, as we’ll see later), together with a strong balance between the different timescales and time-horizons of strategy, tactics and operations:

Or, in a more visually cyclic form:

However, the linear-view focusses only on a subset of the service-cycle – the segment that it identifies as ‘the market’, centred solely around the visible-transactions. For example, classic ‘push-marketing’ focusses primarily on grabbing the attention of prospective customers, regardless of whether those ‘prospects actually want the attention of the organisation in that way; and ‘performance’ is measured primarily in terms of completion from the organisation’s perspective – not the perspective of anyone else.

The result is what I often describe as the ‘quick-profit failure-cycle’, in which an over-focus on short-term profit leads to over-reliance on a ‘short-cut’ back to ‘Attention/conversation’ (in the Preparation phase of the overall service-cycle) – leading directly to the loss of viability of the business in the longer term:

Remember that this applies to everything, to the ‘business-model’ of every service – and hence, in turn, every ‘job’ that enacts those services. Or, to put it the other way round, if we want to prevent that kind of business-failure – and many others like it – every ‘job’ must be able to ensure the ‘completeness’ of the respective service-cycle. We need to be able to describe the interdependencies of that service – that ‘job’ – a way that ensures the viability not only of the ‘job’, but of the entire enterprise within which that ‘job’ would exist.

And for help on that, we can turn to the Enterprise Canvas model.

Service-interdependencies and Enterprise Canvas

Enterprise Canvas starts from one of the key assertions we’ve seen above: that everything in the enterprise is, delivers or represents a service.

Every service exists to add value to the enterprise, and, as in the first diagram above, every service sits at an intersection between ‘horizontal’ flow of value around the various players in the enterprise (primarily ‘the market’) and service to the values (plural) and principles that express the aims and purpose of the overall shared-enterprise.

And since everything in the enterprise ‘is’ a service, we can model everything in essentially the same way.

We describe the content of the service – what it uses, what it does, how it does it, and so on – in terms of assets, functions, capabilities, locations, events and decisions:

(I won’t go into the full detail of that here – there are plenty of other posts here that cover it, and it’s also described in depth in the book Mapping the Enterprise.)

The crucial point here is that, in essence, a service consists of bringing together a set of functions – the interfaces and ‘black-box’ description of what the service will deliver – with a set of capabilities – the ability to do the work inside that ‘black-box’. And they’re not the same: we forget this fact at our peril, because it’s fundamental to all system-redesign, and much else in anything to do with change in enterprise-architectures.

When we design a machine, it’s often easy to think that service, function and capability are synonyms of each other, because they’re often constructed together, ‘all of a piece’. And it’s true that we can sort-of get away with this conceptual short-cut if we’re only dealing with machines or machine-like IT-systems. Taylorism explicitly describes every ‘job’ in this way, as a distinct ‘unit of production’ – which is yet another reason why Taylorism and IT-centrism are so often found as fellow-travellers.

But when we deal with people, this short-cut does not work: instead, the capability resides in the person, and is then matched up with a function to deliver the service. And a real person will have many different capabilities that can be used and re-used in many different ways – and extended, too, through training and skills-education. In short:

• a machine or IT-system usually implies a one-to-one correspondence between capability and function
• a real-person usually implies a many-to-many correspondence between capability and function

Or, to put it another way:

• we buy machines for their functions, and the respective in-built capability to deliver that explicit functionality
• we hire real-people for their capabilities, and their ability to apply those capabilities to any required functions

If we use only one subset of each person’s capabilities, by assigning each person solely to a single Taylorist-style ‘job-description’, we’re not likely to be using that person’s capabilities at best effectiveness. (It’s probably not going to be much fun for that person, either.) In much the same way that, in Part 1 here, we saw that we need to focus on education rather than mere ‘training’, we need to hire for capabilities, not ‘functions’.

The other key role for Enterprise Canvas here is that it gives a means to map out the interdependencies that underpin any viable business. To do this, we start with a simplified version of Stafford Beer’s Viable System Model [VSM], and link it to that assertion that ‘everything is or represents a service’. This tells that, for every service that delivers some functionality (what VSM describes as its ‘system-1’), it not only has its interfaces to its service-providers (‘supplier’s) and service-consumers (‘customers’), but it also must have subsidiary support-services that:

• direct and link it to the larger strategic, tactical and operational plan (roughly equivalent to VSM system-5, -4 and -3)
• coordinate it with other services (roughly equivalent to VSM system-2)
• keep it on track to enterprise-values (‘validation’ – a much-extended version of VSM system-3*)

In effect, all of these types of subsidiary-services are orthogonal to each other:

Although Taylorism would bundle all of these other services under the management-banner, it’s essential the we respect the differences. The direction-services do align quite well with Taylorist assumptions, but the others don’t: the coordination-services operate primarily between the Taylorist silos; and the validation-services must often be separate and distinct from management – a separation that in some cases, such as for financial-audit, may well be mandated by law. (The validation-services are sometimes described as ‘pervasive-services’, because alignment with enterprise-values is ultimately everyone’s responsibility, and hence the services to support that must pervade everywhere throughout the enterprise.)

So, in simple visual form:

Note that, almost by definition, many of the tasks in the coordination-services and validation-services are generalist, not specialist: they link between, not deliver ‘within’. But note also that, again, most of these tasks do not even appear on the Taylorist radar: which might just be a problem?

In short, the classic Taylorist ‘org-chart’ view of the enterprise – with its overly-simplistic split between ‘managers who do the thinking’ versus ‘workers who do the doing’ – is a dangerously incomplete view of what actually needs to happen within a viable enterprise. It’s the primary reason why so many organisations are crippled by a management-structure that doesn’t match up with how the work is actually done within the organisation, and also why it’s so difficult to describe end-to-end business-processes that traverse across multiple silos. Anyway…

Another theme that’s missing in Taylorism – or rather, is sometimes implied but never actually mentioned – is the role of and relationships with enterprise-investors. In Enterprise Canvas, we not only include this, but in fact split that investor-relationship into two parts – investors and beneficiaries – because at the whole-enterprise scope they’re not necessarily always the same.

Again, all of this applies to every service, at every level of granularity. So when we put all of this together – the ‘before, during, after’ of each transaction; the parts of each service that focus on receiving value from suppliers, creating value, and delivering value to customers; the guidance-services for direction, coordination and validation; and the investor and beneficiary relationships – and include all of the key detail, we end up with a visual-checklist of interdependencies that looks like this:

Or, if we expand it out into a bit more detail, more like this:

Which, I will admit, might seem a bit too much like overkill: but in fact it does summarise all of the key interdependencies, service-relationships and subsidiary-services that every service would need to identify. And, in turn, every ‘job’ that would implement that service.

Sometimes a subsidiary-service will be included within the internals of the service itself; in some cases – particularly with validation-services – it may or must be somewhat external; in some other cases – such as with coordination, investors and beneficiaries – it will be external by definition, at least in part. But all of those services need to exist somewhere, and like the interfaces and the like through which the respective service can access them.

[This isn’t all that hard to model, by the way: the full instructions and checklists are in the post ‘Enterprise Canvas as service-viability checklist‘.]

A Taylorist version, though – a conventional ‘business-school’ view of the business – would look more like this:

Which should warn us straight away that there are some real problems here… And that’s what we’ll turn to in the next part of this series.

In the meantime, though, any comments/suggestions so far? Over to you, as usual. 🙂