Upwards and sideways from business-model
The past few posts in this series have focussed on moving ‘downward’ from the business-model, towards implementation, such as might be modelled in Archimate notation. That’s an aspect of the business-architecture / enterprise-architecture interface that makes immediate and practical sense to most people.
Yet to complete and verify the business-model and its proposed implementation, we also need to look upward into the extended-enterprise, and sideways into other aspects of the business-architecture space – otherwise the business-model could well fail in ‘unexpected’ ways. This post explores how to do that exploration, using the Enterprise Canvas frame as a checklist and guide.
(This is an adaptation of material that’s explained in more detail in my books The Service-Oriented Enterprise and Mapping the Enterprise, but there should be enough here to use straight away without needing to refer to either of those books.)
This’ll be another long one…
Let’s assume again that we’re starting from a business-model that’s been mapped out in Business Model Canvas. From there, we know how to cross-map the business-model into Enterprise Canvas, and adjust the model for the various asymmetries and incompletenesses in the original Business Model Canvas layout:
That core frame in Enterprise Canvas allows us to explore in more depth the various flows that take place (or need to take place) before, during and after the main transaction – sometimes with different people in different roles for different parts of the same nominal transaction and relationship:
Yet that central core of the Enterprise Canvas is only part of the frame and its implied checklist. There are also the service’s relationships, interactions and transactions with its various investors and beneficiaries:
And also its relationships and so on with other services that provide various forms of guidance – direction, coordination and validation:
Hence the total context that we need to address when assessing a business-model is not solely the central core that maps directly to Business Model Canvas, but a rather broader scope, as in this ‘kitchen sink’ summary:
To make sense of these additional relationships and support-services we need to look out into a broader space than that which we explore with the mainstream mapping into Archimate. In effect, we need not only to look ‘down’ into the Archimate space, but also look upward into the extended-enterprise, and sideways into how an enterprise is managed in real-world practice. In other words, a viable business-model, built on viable services.
Remember too that the Enterprise Canvas is recursive: everything is a service, and each of those services has the same structural interdependencies and flows. Hence what we’ll explore here applies not just to the overall business-model, but to every ‘child’-service and sub-service that we’ve previously identified and mapped in our Archimate models. This consistency in recursion is what will make the business-model efficient, effective, reliable and robust.
Investors and beneficiaries
An Investor is a party that puts various forms of value into the service – often as part of the ‘pump-priming’ to get the business-model started. It’s a similar role to that of a Supplier, except that the main flow goes the opposite direction, into the Value Outlay (‘Cost Structure’) cell, rather than removing value from that cell (such as payment for products provided or services rendered) via the back-channel.
A Beneficiary is a party that extracts various forms of value from the service, usually as the ‘excess value’ over and above that needed to operate the service (business-model) itself. It’s a similar role to that of a Customer, except that the main flow goes the opposite direction, from the Value Return (‘Revenue Stream’) cell, rather than providing value to that cell (such as payment for products provided or services rendered) via the back-channel.
Note that investors and beneficiaries are not necessarily the same people, and also that many different types of energy, resources and other forms of value may be invested and/or returned, again often in different forms.
For example, a bank-manager will not usually invest their own personal funds in a bank-loan – the money invested is that of the bank, and behind them the bank’s depositors and shareholders. But the bank-manager does place their own trust and reputation on the line in making that decision – and that trust is a form of investment that does need to be acknowledged as an investment. Note that repaying that investment in monetary form is usually called ‘bribery’, and is usually very illegal… 🙂
To give another example, a city-council may well invest actual funds, or proxies for funds such as a tax-rebate, to a company ‘setting up shop’ in the district. The city-council itself does not get a direct monetary dividend, but receives the dividend in the form of local employment – hence reduced social stress etc – and also more money flowing around the community in general. The dividend can perhaps be sort-of translated into strict monetary terms, but often doing so leads to people kind of missing the point… the flows and transforms are usually more subtle and more complex than a simplistic ‘monetary account’.
It’s also essential that an appropriate balance is established between investors and beneficiaries, that is understood by all parties to be acceptably ‘fair’ – otherwise the entire business-model will be placed at risk, especially in the longer term. The common ‘shareholder-only’ model, which ignores almost all non-monetary investment and assign absolute priority to the so-called ‘owners’, may all too often in practice turn out to be a parasitic structure that can quickly kill the host – the business and its business-model. In the process, it can also poison the ecosystem against itself, creating a type of ‘immune-reaction’ rejection of any equivalent-seeming business-model in the future, even if benign.
Note that these issues can only be identified by use of an enterprise-architecture that applies an ‘outside-in’ whole-enterprise view, rather than solely an ‘inside-out’ business-centric view.
Quick summary of suggested questions to use in this kind of assessment:
- What energies, resources or other items are or need to be invested in this service (business-model)? From what or whom (the investors) will these be provided, or made available? Via what relationships and transactions? Using a VPEC-T assessment, what values, policies, events, content and trust would apply to each of those relationships and transactions?
- What energies, resources or other items are or need to be returned or extracted from this service (business-model)? To what or whom (the beneficiaries) will these be provided, or made available? Via what relationships and transactions? Using a VPEC-T assessment, what values, policies, events, content and trust would apply to each of those relationships and transactions?
- In what ways are the invested energies and resources used and/or transformed within the service? In what forms is ‘excess value’ extracted and returned from the service as dividends to its beneficiaries?
- What forms of assessment and governance are used to ensure that the balance of investment and dividend is acceptably ‘fair’ to all parties?
It’s important to note that this is fully recursive: this type of analysis applies not only to the core service (the business-model) but to all of its ‘child’-services, facilities and resources used within its real-world implementation.
Guidance – an overview
All services that deliver anything to any other part of the overall shared-enterprise will rely on other services to keep them ‘on track’ in relation to the overall enterprise. These relationships and interdependencies need to be identified as part of the assessment for viability of the business-model.
Obviously, there are many different methods and techniques to do this. The framework I most prefer for this purpose is based on the long-proven Viable System Model [VSM], with specific adaptations and extensions to address certain change-management and quality-management themes that apply in the non-hierarchical value-systems in a whole-enterprise business context. (This extended model is described in more detail in my book The Service-Oriented Enterprise.)
The VSM describes these inter-service relationships as ‘systems’, in a recursive or ‘fractal’ structure in which each service interacts with other ‘systems’ yet also contains aspects of those ‘systems’ within itself. All of the ‘systems’ and inter-system relationships need to be in place and functioning well in order to ensure viability of the overall service – hence ‘viable system model’.
This may take some explaining… especially why it’s relevant and important to implementing a business-model…
Probably easiest to start from the old Taylorist model of work, as an explicit split between ‘brain’ and ‘brawn’. There’s a complete separation between the roles: brain thinks, and doesn’t do, whilst brawn does things, and doesn’t think. Or not allowed to think, anyway.
We can see this illustrated in a standard BPMN diagram. We start off only describing the work:
But we soon discover that we can’t make it work in practice unless we also think about how it’s managed:
In most real organisations, this is structured in a hierarchical fashion, with managers who manage collections of ‘reports’ – middle-managers or line-managers – who manage their own clusters of subsidiary functions and services:
So far, so Taylorist. Managers think, workers do, and there’s a complete separation between them – especially if the ‘workers’ are IT and the managers are real people, as so often will seem to occur in a typical BPM (Business Process Management) context.
Yet there’s another hidden layer in Taylorism: the basic model tells us the How and the With-What of an organisation, but never really the Why. This is because Taylorism is built on a ‘machine’-metaphor – ‘the organisation as machine’. And a machine doesn’t have a Why: it just is. Its purpose – if it has one – comes from outside of itself: and in the machine-metaphor for business, that purpose comes from the ‘owners’. Who, again, are deemed to be entirely separate. Owners own, managers think, workers do. The work is done by the workers on the orders of the managers for the profit of the owners. Simple, really.
Too simple, because in reality it doesn’t work very well. Sure, at first glance it seems it’d be very efficient as ‘a machine for making money’, but in practice the rigid hierarchy and active prevention of feedback from the real-world means that it’s very slow and cumbersome as a decision-making model – and unreliable, too. We can sort-of get away with this when the business-context is static, or close to static; but as soon as the market or context requires any kind of agility or responsiveness, it will almost immediately grind to a halt in ‘analysis-paralysis’. Instead, as Deming and others demonstrated so well, almost all aspects of inquiry and decision-making need to be distributed throughout the structure. And connection to purpose likewise needs to pervade every part of the structure, so as to enable principle-based decision-making in real-time response to the real-world chaos on the shop floor.
To make it work, we need to shift metaphors, from ‘organisation-as-machine’ to ‘organisation-as-organism’. Hence viable systems, viable services, viable business-models: in a quite literal sense, we need to ensure that they can come alive, support themselves, adapt themselves, because ‘classic’ Taylorism is simply too slow to survive in a fast-changing world. Given this, we can see that every aspect of our business-model – every sub-unit in the enterprise – would need to do, or have access to some means to do, all of the following:
- to do its task – in other words, deliver its services
- to sense and report on its perception of its internal and external environment
- to remember, using some kind of repository of knowledge about its past
- to coordinate its activities with other systems and services
- to plan its activities in some way, coordinating strategies and tactics with others
- to adapt to and, where possible, improve its own environment and operation
- to maintain a sense of purpose, to contrast its present condition with a desired future condition or direction
If we want to build an architecture that will truly support our business-model, this is the true scope of what we have to be able to describe. The basic business-model on the Business Model Canvas will describe the ‘do’ part: that’s straightforward enough. It’s linking it with everything else that gets tricky…
Stafford Beer’s Viable System Model provides us with a framework that can help us do this. The ‘official’ version is probably too ‘theoretical’ for most people’s taste:
Yet the ideas behind it are simple enough. Every service, or the business-model as a whole, contains or links to a set of functions or ‘systems’, as follows:
- system-5: maintain policy, purpose and identity
- system-4: research and report on the external environment, and develop strategy
- system-3: plan and manage the operations activities
- system-3*: monitor and verify by sporadic audit of activities
- system-2: regulate and coordinate activities with other systems and services at a tactical level
- system-1: do the allotted task of the overall service, and sense and report on the internal environment
A glance back at that earlier list would show that the VSM ‘systems’ explicitly cover most of those requirements: as we’ll see later, the items about knowledge and memory, and adaptation and improvement, are handled by an expansion of the roles of the VSM’s ‘system-2’ and ‘system-3*’.
This is recursive, or fractal: every ‘system’ incorporates or encapsulates all of the other ‘systems’ in some way, everything contains or links to everything else, to support everything else as an interdependent whole.
Admittedly, it’s a lot to try to grasp all in one go, in order to model how to ensure that a business-model would be viable. But we can in fact simplify it right down to something that does make immediate sense in practice:
In this variant of VSM, each service has its set of subsidiary services or ‘child-services’ with four possible categories of functions:
- delivery-services: task-delivery or delivery-support
- management-services: service-management and direction
- coordination-services: ‘horizontal coordination with other services
- validation-services: functions to keep the overall service on track and aligned with enterprise purpose
Delivery-services are the VSM’s ‘system-1’. They’re what we’ve modelled already in the business-model, and downward into Archimate. In reality, everything is a ‘delivery-service’, of course; but what we need to explore here are the interdependencies and roles that services need in relationship to each other, which in effect is everything other than the ‘delivery services’.
Management-services (better described as direction-services, because it encapsulates more than just management alone) are what we would expect from Taylorism, plus quite a bit more. The VSM splits these into three distinct parts (‘system-3’, ‘system-4’ and ‘system-5’), as we’ll see in a moment.
Coordination-services manage the choreography between services, and also the choreography of change. Classic Taylorism tries to merge all of these services under the ‘management’ umbrella, but it doesn’t work, because the whole point is that they’re needed to bridge between the silos, and hence cannot actually exist solely within them. In real-world practice, this often surfaces as a combination of a shadow-network of ‘fixers’ who manage somehow bridge the silos, and IT-systems and the like that provide automated means to do the same. The VSM’s ‘system-2’ addresses only one aspect of run-time coordination, whereas we will need to cover a broader scope.
Validation-services (sometimes called ‘pervasive services’, because they need to pervade through everything) are about quality – about ensuring that the business-model and each service within the business-model aligns with what is actually meant by ‘value’ in the Value Proposition. Classic Taylorism again bundles all of these under the ‘management’ umbrella, but they need to be at least partially outside, if only because many of them are subject to legal or regulatory mandates which must be beyond management ‘control’. The VSM’s ‘system-3*’ addresses only one small aspect of this, to do with random-audit, whereas again we’ll need to cover a much broader scope.
Although the VSM itself focuses on management and the information-flows needed for management, the real tension of importance in the enterprise is between purpose of the overall shared-enterprise (the single top-level ‘system-5’) and the expression of that purpose in real-world practice (the multitude of ‘system-1’ entities at the outermost edges of the VSM hierarchy-tree). Everything else – including management, and including the business-model itself – is just a support-service towards that end.
Given all of that background, let’s look at what’s needed to ensure that the business-model will be viable in practice – and continue to be viable over the longer term.
Guidance – direction-services
The VSM splits the overall direction tasks into three distinct components, which we might summarise as ‘Run the Business’ (‘system-3’, or ‘Inside/Now’), ‘Change the Business’ (‘system-4’, or ‘Outside/Future’) and ‘Develop the Business’ (‘system-5’). We need to ensure that our business-model either includes or has access to services that can support all of these needs.
- Who or what will provide run-time management for the business-model – such as to plan and manage the operations, allocate resources, and collate and interpret performance-reports, and make run-time tactical decisions?
- Who or what will guide changes to the business-model – such as to research and report on the external environment, and develop strategy?
- Who or what will keep the business-model on track to the vision and values of the organisation and of the overall shared-enterprise – such as to maintain policy, purpose and identity?
- Via what means – the ‘How’ and ‘With-What’ of business-services and business-processes – will all of these requirements be enacted in practice?
- Who or what will provide coordination and choreography for all of this?
- Who or what will provide governance for all of this?
Use these questions iteratively across all aspects of the business-model and its implementation, as previously modelled in Archimate or the like. Create any models as required: the Business Motivation Model (or Nick Malik‘s Enterprise Business Motivation Model) may provide useful advice here. The present version of Archimate provides only rudimentary support for this – such as attaching Meaning or Value entities to a Business Service or Business Role via an is-associated link – but the upcoming Archimate v2 is expected to better support via a new Motivation extension.
Guidance – coordination-services
As standard, the VSM (via its ‘system-2’) addresses only one aspect of inter-service coordination, namely run-time trade-offs between services at the same level within the same silo-hierarchy. To get a business-model to work well, especially over the longer term, we need much more coordination that that. We could summarise the overall requirements here under the same three headings as for the Direction-services: ‘Run the Business’, ‘Change the Business’ and ‘Develop the Business’. In effect:
- ‘Run the Business’ coordination connects run-time management (‘system-3’), the balance between its delivery-services (‘system-1’), and the ‘process-choreography’ with other delivery-services under the direction of other silos both within and beyond the organisation
- ‘Change the Business’ coordination connects external-oriented strategy (‘system-4’) and internal-oriented tactics (‘system-3’) to address the needs for and execution of change, both within this silo-tree and across the direction-services of other relevant silos both within and beyond the organisation
- ‘Develop the Business’ coordination links policy and purpose (‘system-5’) with strategy (‘system-4’) to address alignment of strategy, policy and standards across the broader scope, and to adapt to and, if possible, guide changes within the broader business-ecosystem
We again need to ensure that our business-model either includes or has access to services that can support all of these needs:
- Who or what will provide run-time coordination for this business-model, within the various components and processes of itself, with its customers, and with its suppliers and other partners?
- Who or what will guide the execution of change to the business-model – such as via project-management?
- Who or what will define, guide and coordinate longer-term change, to develop and adapt to changes in the broader context for the business-model – such as via portfolio- or programme-management?
- Via what means – the ‘How’ and ‘With-What’ of business-services and business-processes – will all of these requirements be enacted in practice?
- Who or what will define or provide the standards, protocols and policies to guide all of this?
- Who or what will provide governance for all of this?
Use these questions iteratively across all aspects of the business-model and its implementation, as previously modelled in Archimate or the like. Create any models as required: the present version of Archimate provides only rudimentary support for this, but the upcoming Archimate v2 is expected to better support via a new Projects extension.
Guidance – validation-services
As standard, the VSM (via its ‘system-3*’) addresses only one very small part of keeping the organisation and organisation on-track to its values, namely random-audit to verify performance-reports and the like. To get the business model to work well, and to align and remain aligned to the desires and needs and expectations of its broader business-context, we will need a much broader value-management structure, with strong consistency across its management of all forms of value relevant to and within the enterprise. Some common business-examples of value-themes include:
- quality – including exception-handling, issue-tracking, corrective-action and process-improvement
- privacy, security and trust
- health, safety and environment
- ethics, social-responsibility and legal compliance
- cost-effectiveness and waste minimisation
- knowledge-sharing and innovation
- whole-of-enterprise efficiency and effectiveness
We can summarise these requirements under four headings:
- Create awareness – identify and describe each value-theme, why it’s important that that value-theme should be managed within the business-model, and how it could and should be done in practice
- Develop capability – implement training and education around the value-theme, and also embed support for the value-theme within automated processes, with emphasis on what to do in real-world practice at run-time
- Apply skills – execute at run-time the required actions to support the expression and protection of the value-theme, and record the results of each action (or inaction)
- Monitor and verify – ensure that the value-theme has been supported in practice, and review to identify what needs to be further improved
Support for values always needs to be managed as a continuous-improvement cycle, as in the classic Deming/Shewhart PDCA (Plan / Do / Check/ Act), where the ‘Check’ phase emphasises both inspection (external) and introspection (individual/internal). Value-management is different from conventional Taylorist ‘control’ in that there is no single ‘right answer’, yet an almost infinite number of ways to ‘get it wrong’ or ‘get it not-quite-right’, and also an infinity of different ways to ‘do it better’. Since almost all of these themes revolve around personal responsibility and personal commitment, the focus here is not so much on ‘best practice’, but on individual capability and improvement as well as systemic change: Deming’s ‘14 Principles‘ and the related ‘Toyota Way‘ provide important guidance for design and review here.
- Who or what will identify the full set of value-themes that would apply to this business-model?
- For each value-theme in scope, who or what will assist in creating awareness of this value-theme throughout the design, implementation and execution of this business-model, both within the organisation and with its customers, suppliers and other partners?
- Who or what will assist in developing and/or embedding the skills and capability to execute run-time support for each value-theme in scope?
- Who or what is responsible for executing the required support for each value-theme at run-time? Are they fully aware of and capable of enacting those responsibilities at run-time to the standards required? Via what means – the ‘How’ and ‘With-What’ of business-services and business-processes – will all of these requirements be enacted in practice?
- Who or what will monitor and verify compliance (and more) to the required standards of support for each value-theme in scope?
- Who or what is responsible for ‘closing the loop’ to support continuous improvement on each value-theme in scope?
- Who or what will define or provide the standards, protocols and policies to guide all of this?
- Who or what will provide governance for all of this?
Use these questions iteratively across all aspects of the business-model and its implementation, as previously modelled in Archimate or the like, and create any additional models as required. The Business Motivation Model and Enterprise Business Motivation Model can provide some support in this: note, though, that both are structured on an ‘inside-out’ (organisation-centric) view, whereas many of the most important aspects of value-themes are only visible from an ‘outside-in’ (extended-enterprise) view. Again, the present version of Archimate provides only rudimentary support for this, but the upcoming Archimate v2 is expected to better support via a new Motivation extension.
That’s it for now. Comments/suggestions/improvements, if you would?
SCiO has put a Viable System Model Guide (Jon Walker) online: http://www.scio.org.uk/resource/vsmg_3/screen.php?page=0cybeyes
Many thanks for the pointer, Peter – very useful indeed.
I can only deal with this in bite size pieces, so in reacting to something at the beginning I may be missing something explained later. That’s by way of an excuse.
I like the investor/beneficiary idea a lot. When we deal with extended enterprise the concepts of supplier and customer are at best limiting and can be misleading. If we treat all of these as roles, we can avoid the imprisonment of the “is a” construct.
One of the things I like most about this is that it helps us to think outside the bounds of a single enterprise. That’s essential if we are to represent extended enterprise in a useful way. X enterprise (and virtual or social enterprises even more so) involves value networks as opposed to value chains.
What such a network looks like depends on the viewpoint of each participant. But it remains a network. Lots of enterprise (and IT) architects seem to have difficulty understanding this. In IT, with the steadily greater role of the internet, there’s no excuse for this. But still the overwhelming majority of so-called Cloud Reference Architectures are entirely focused on the single enterprise (usually a provider). One can come up with various (somewhat cynical) explanations for this but that doesn’t make the problem go away.
What some of us try to emphasize is the presence of an ecosystem of parties, in general delivering and consuming services to and from more than one other party. I think that the ecosystem concept is equally valid for enterprise architecture. The kind of roles you’re defining provide semantics for the ecosystem.
To explore the relationships further, I like to use the example of the app store/app developer/iPad(Android, whatever) relationship. An app developer is a business, which is a supplier to an app store. Or maybe it’s a resource, which is very interesting, because then we have a good example of a resource (seen from the app store enterprise perspective), which is external to the enterprise. But the app developer is also an investor, because he/she/it injects value into the app store enterprise’s propositions. Even if Apple didn’t make a cent from selling apps, their existence (assuming people find them interesting) is an important part of the case for the iPad (and iPhone for that matter). And the developer is also a beneficiary, in part because they make revenues via the app store (not from Apple but from the actual customer) and also in part because if it sells via the Apple app store, it can also be sold via an Android app store. And that in turn means that they are a partner in two or more separate extended enterprises (I may be taking liberties with the terminology a bit here). But also, seen from the perspective of the app developer enterprise, Apple is an investor in their business, because Apple provides the platform for the sale of their products. (Before anyone objects that this is just an eShop, it isn’t. An eShop is a like any other shop except it has an internet rather than a physical presence. Like any retailer, it buys from a wholesale provider and sells to its customers. The buying and selling processes are disjoint. An app store is a partnership selling essentially a joint proposition). Of course the same applies to any other app store operator, because all of them are primarily concerned with selling other things (mostly hardware or mobile phone subscriptions) and not with the revenues from the apps themselves.
So what I want to be able to do is represent all these different views and to be able to illustrate the world from the perspective of the different roles the participants can play. Which brings me right back to the beginning (phew). The concepts are brilliant. We need to improve the representation.
I tried previously to express what I saw as a limitation in the Business Model Canvas, which you correctly refuted. Those of us able to (literally in this case) think outside of the box don’t have a problem using the Canvas in the context of Extended Enterprise. You’ve provided some good examples of this. But the representational form is very much oriented to the single enterprise. That makes it susceptible to bad teaching and bad practice. That’s not the fault of the Canvas but it’s still a problem. I have tried with little success to create an ecosystem representation based on single enterprise iconography. Imagine a picture with a whole bunch of Canvases representing different participants in the ecosystem. Doesn’t work. With slightly more success I have produced models using a different form of iconography. But my visual skills are limited (to put it mildly). Plus those models could only support very limited semantics. In a way this paragraph is a contribution to the specification of requirements for a toolset and belongs in a different blog. I believe we need a representational form, which allows us to create multiple views. An ecosystem wide view with limited semantics would be fine if it could be seamlessly (sorry about that word) linked to more specific views with richer semantics. So we can have the big picture to establish context and we can have various views of the ecosystem seen from the individual enterprise perspective and catering for the different roles of that enterprise (and its partners) in the ecosystem. No need to try to capture all the semantics in one picture. No point in trying. And if the representation form changes, as you have suggested, going downwards towards solutions (IT or otherwise), that’s just fine as long as the semantics survive the transition.
And with that I’ll pass the ball back.
@Stuart Boardman – Stuart, this is brilliant – exactly the kind of critique/peer-review that I really need, picking out the limitations of some of the ideas, and extending others in ways that I hadn’t seen.
You’re right: what we’re really talking about here is the semantics of a value-network, with a myriad of roles that can be viewed in different ways depending on the viewpoint. One of the points I was trying to get at is that the notion of ‘Supplier’ or ‘Customer’ – as in Business Model Canvas – is really just service-provider or service-consumer (respectively) as seen from a single viewpoint within a value-network. The core theme of the market-cycle is that that structure of relationships applies to every player in the extended-enterprise: some may not have much if anything in main-transactions (i.e. are ‘non-clients’) and in some cases the main flows may go in the opposite direction (as with investors and beneficiaries respectively, relative to ‘Supplier’ or ‘Customer’), but the service-in-focus has an implied relationship with all of them by virtue of the fact of being in the same overall shared-enterprise.
I really like the way you’ve portrayed the Apple-style apps-ecosystem. By the way, note that both the AppStore and the Android Market could or would usually be portrayed as being in the same extended-enterprise, if we look at that enterprise from the software-developer’s perspective.
On “the representational form is very much oriented to the single enterprise. That makes it susceptible to bad teaching and bad practice”, I’m not sure here whether you mean BMCanvas, EntCanvas, or both? – or, for that matter, whether you mean organisation-as-enterprise, or ecosystem/extended-enterprise? The answers would be kinda different in each case… 🙂 If you mean BMCanvas and organisation-as-enterprise, then yes, it does to tend to push a ‘single-organisation’ view (what we might call a ‘business-centric’ view), which I would likewise agree risks being problematic, for exactly the reasons you describe. And the asymmetry of the BMCanvas makes it difficult to use multiple Canvases – one of the problems that EntCanvas is specifically designed to resolve.
“Imagine a picture with a whole bunch of Canvases representing different participants in the ecosystem. Doesn’t work.” – I don’t understand why not? Feels like I need a bit more explanation of what you see as the problem there. The way I see it is that it’s just an n-dimensional space or holograph which we can rotate and pan and view from any perspective or any viewpoint (and which can be compressed to three or even two dimensions if required – think of
Prezi as a simple two-dimensional zoomable analogue for this). Each of the Canvas entities floats within this space, with links to all of its relations in the overall value-network. Some of those links are direct, and carry some kind of value-flow; some may only be indirect (as would be the case for most links between competitors in the same market, for example).
In fact one of the themes I’ve been working on is a way to move around in this space, arbitrarily focusing on different entities as the current ‘This’, and doing the usual architectural analysis from that viewpoint; then moving on to another one, as appropriate. (We don’t ‘do a Zachman’, trying to describe every single possible thing in “excruciating detail” – but the point is that we can do a deep-dive anywhere as required.) There’s an interesting subtlety in that Zachman-style layering actually implies multiple variants of the same hologram, at different levels of abstraction vs realisation – but again, in effect that’s just another dimension. Likewise ‘as-is’ to ‘to-be’-style shifts are just mappings into one or more additional dimensions of time etc.
We wouldn’t expect people to hold all of that in their heads – that’s too big an ask. (Okay, not for some people, but certainly applies to most, I think? In my own case, I can grasp all of it as a conceptual structure, but not so so well when it’s full of real-world content!) But we’re not asking them to do that: that’s what the toolset-repository if for. Until we get some kind of holographic display, everything that we ‘see’ would be a filtered extract, specific to the chosen context. Which in some cases might end up looking almost exactly like a BMCanvas or a TOGAF-tyle ‘four-architectures’ – but we’re not inherently constrained to those views, as in too many ‘EA-toolsets’ at present.
The same applies to the semantics, of course: we record to the level of semantics required, and return and display the semantics likewise. It all depends on what’s needed in each view, for each given purpose. There’s an important complication in that we’ll often have different levels of detail across any given context or view, but as long as the toolset-architecture is set up to cope with that fact (i.e. has selectable levels of semantic rigour), then it shouldn’t be a significant problem.
Apologies if I’m rambling again? – but I hope that answers/extends/replies-to your comments above adequately enough for now? And thanks again, of course.
Thanks Tom. That’ll do for now and leaves enough material for further discussion/development. The only problem with “a bunch of Canvases” is the too much semantics for one image problem. Holograms would indeed be good. Hmmmm.
I’m away from this afternoon until Tuesday evening and will not (repeat not) be looking at any form of electronic communication (apart from text messages on my mobile:)). Instead I shall be spending time with old friends at one of my favourite jazz festivals (in Antwerp). Music is, as Pharoah Saunders once said, the healing force of the universe.
@Stuart Boardman – “Instead I shall be spending time with old friends at one of my favourite jazz festivals” – how very wise, good sir! 🙂
(And I trust you will be remembering that music is not [solely] a spectator-sport, and will have your trusty sax with you? 🙂 )