Tom Graves / Tetradian

Given the responses to my previous post ‘Guess I could do with some help here…‘, seems it’d be useful if I clarify a bit more what kind of help I most need. (Or we need, rather, as an industry and discipline: probably the only ‘I’-part here is that I seem to be one of the few at present who’s asking these questions?)

To be honest, we don’t need much help in thinking about the nature of enterprise-architecture or the like: that’s already well covered, and it’s actually quite straightforward anyway.

Where we need help is in rethinking the toolsets that we use for enterprise-architecture and the like.

To me it’s clear that if we’re to make sense of the enterprise, and support viable decision-making about the true whole-enterprise-scope within which our organisations operate, we’re going to need some kind of holographic approach to modelling.

We already have plenty of frameworks for enterprise-architecture. We also have plenty of methodologies to work with those frameworks. Each of those is constrained to some variously narrow view into this holographic space, and usually constrained by placing some particular point as ‘the centre’ – hence IT-centrism, business-centrism, health-and-safety-centrism and so on. And those constraints are useful in practice: no doubts whatsoever about that. So to my mind there’s nothing whatsoever that’s inherently ‘wrong’ about any of those frameworks or methods, other than their own occasional internal inconsistencies and than that they too-often position their own very limited perspective on reality as ‘the only possible’ view on reality. That’s the only problem there, and it’s very easy to fix, by acknowledging the value of a single viewpoint as a viewpoint yet also insisting on cross-viewpoint generics. We can choose anywhere as ‘the centre’, for some given purpose, yet must also insist that everywhere and nowhere is ‘the centre’, all at the same time.

Hence, as such, we don’t need any new frameworks or methodologies for enterprise-architecture. We have more than enough of them already, to be honest.

What we do need are better ways to manage and make sense of the information we have about this ‘enterprise-hologram’.

Which is where toolsets come into the picture. And that‘s the part that I really need help on – or we need help on, rather, because it’s definitely too large a context for any one person, or even any one group, to tackle on their own.

What we need most is clarity on the question we’re aiming to address. I think it’s an Einstein quote that says “if I had an hour to solve a problem, I would spend the first fifty-nine of those minutes on the question, and only the last minute on the answer” – because the right answer tends to fall out all by itself when we have clarity on the question.

One thing we do know, though, is that there are many different players all trying to tackle different aspects of the same enterprise-holograph – for example:

• enterprise-architecture and all the other domain-architectures and solution-architectures – an emphasis on structure and purpose, and how they link together to deliver useful value
• knowledge-management – an emphasis on how knowledge-items link together (especially narrative-knowledge, stories and ‘subjective truth’)
• change-management – how everything changes and can be changed over time
• process-management – how activities link together, and entities flow between them, to add value across supply-chains, value-networks and so on
• service-management – the human and technical aspects of keeping everything going and ‘on purpose’
• futures and other business-intelligence – how to trawl through the enterprise-space for sensemaking and the like
• simulation, ‘gamification’ and other skills-development – how to apply ‘what-if’ to any part of the overall context
• skills-management – identifying the skills needed, and the training and/or recruiting needed to cover present or future gaps
• performance-management – identifying required metrics and their impacts (especially, to avoid ‘gaming the system’)
• governance – identifying requirements and responsibilities, assuring assignment and ability to comply, and verifying compliance

In principle, yes, they’re all views or viewpoints into the same overall context. Yet each of those views also carries information or requirements that are specific to that view alone – in other words, more like an orthogonal dimension. And there are a lot of those distinct dimensions in there – an n-dimensional space, where n could literally be any number. (Certainly a lot more than are accessible in the simple flat images so typical of so many current ‘EA’-toolsets, anyway.)

Then there are all the different uses for all those distinct views: an architectural view shows us relationships between structure and purpose, for example, but do we need that view to decide on future strategy, to plan investment, to compare different implementation-options in trade-off analysis, to guide scenarios and substitutions in planning business-continuity and disaster-recovery? The views we’d use might at first seem similar, but the focus and emphasis and model-dynamics in each case might be very different.

At first glance this all might seem impossibly huge. Yet it’s not as hard as it seems. Most of the technology we’d need to deal with all of this complexity does already exist. Despite the huge spread of the overall toolset-ecosystem, most of the key software components we’d need are already easily available, at little or no direct cost, running on a wide-range of easily-available existing devices. Conceptually speaking, the underlying data-structures are straightforward enough: for example, it could be done with little more than freeform tagging in an object-database of some kind, with some kind of filters applied to the tagging. The same applies to search, and filtering: pretty much everything we need already exists somewhere, if we knew where to look. And even if display-technologies are not yet quite capable of showing a true n-dimensional holographic space, they’re certainly capable of simulating one. Given the right people and the right ideas, the technology side really isn’t all that hard these days.

But if the technology isn’t hard, the user-experience part is hard. And seems to me that that’s where we most need to focus our attention at the moment.

In many cases, we simply don’t have the right metaphors for model-relationships:

• some of it can be usefully described as a matrix – but it’s definitely more than a simple matrix as per Zachman
• there are some contexts in which a metaphor of hierarchical layers will sort-of make sense – but it’s definitely more than a simple ‘stack’ as per TOGAF or Archimate, or even a multi-axis matrix-stack as per CapGemini IAF
• there are flows of information and materials – yet it’s much more than a simple supply-chain
• there are identifiable relationships, including realisation, aggregation and so on – yet much of it tends to follow a modal logic of possibility rather than solely a simple true/false logic of presence or absence
• there are identifiable trails of derivation and decomposition – yet there’s more to it than a simple Zachman layering, or the classic ‘current state’ versus ‘future state’

And perhaps more important, we don’t yet have adequate user-interface metaphors:

• drag-and-drop for entities can be misleading – is it a class or an instance? how do we link back an instance back to a parent class? are we editing the instance only, or the whole class? are we affecting other instances elsewhere? or other versions of the same nominal instance? what happens if the parent disappears over time, but the instance continues as re-linked to something else?
• notations can be confusing – especially where the same nominal entity would appear in multiple views with different notations or visualisations or images
• aggregation (as in Zachman primitives versus composites, TOGAF ABBs versus SBBs [Architectural Building Blocks versus Solution Building Blocks]) can be very confusing – especially where entities can recombine in many different forms, and at different levels of abstraction or realisation
• zooming (as per Prezi) works well to describe a ‘containment’ or hierarchical concept of structural-decomposition – but it’s hard to make sense, if entities aren’t fully ‘contained’, or if there are more than two orthogonal axes
• timelines (as in Gantt-chart relationships, or Apple OS-X Time Machine backup/restore) provide a good means to step through time-related views – yet the views themselves may change over time
• multi-axis user-controls work well for up to three or four exactly-orthogonal dimensions – but become exponentially harder to use with increasing numbers of dimensions and other variables, and probably cannot cope when the dimensions themselves blur into each other

In short, we urgently need new user-interface metaphors to navigate through n-dimensional holographic space, where the nature of the space itself may change as we go.

(Oh, and it has to be easy to use, too, such that both the navigation and what’s visible in the view will make immediate sense to anyone. Of course.)

To use another Einstein quote, “Everything must be made as simple as possible, but not more simple”. Simple to use; yet actively dissuade overly-simplistic ‘solutions’ such as IT-centrism and the like.

That’s the challenge.

And that’s also where Agile and the like come into the picture – and, most of all, people who are experienced in Agile-style software-development for toolsets and the like. We seem to have quite a lot of methodologists and the like around here, who tend to be great on the theory. But what we need most are developers who know how to think seriously-sideways and put it into practice.

We can’t just talk it into existence: we need to get past the ‘talking about it’ stage now. Given the blunt fact that we’re very unlikely to get it right first time, we need something to play with, to test in real-world practice, to review and rethink our ideas, to help us clarify what the question really is that we’re facing here.

More thinking-about-thinking, about the theory and the like, well, yes, we’re always going to need it, it’s always going to be a ‘nice to have’, and so on. But right now, we’ve done more than enough thinking-about-thinking: it’s time to get down to the doing, of creating this new kind of toolset.

Anyone interested in helping with that? Please?

What is ‘Why?’ And why, anyway?

“Oh no, not again“, do I hear you cry? Actually, it’s not as bad as that: it’s not going to be yet another of those long tedious technical posts – honest!

(It is a sort-of technical question, I’ll admit. And, in the event, quite long. But interesting to just about everyone, I hope.)

What do we mean by ‘Why’? It’s a question that’s been puzzling me for quite a while – not least because enterprise-architecture is in some ways all about the shared ‘why‘ of an enterprise, and how we express that ‘Why’ in practice.

That kind of ‘Why’ is energising, and engaging. “Start with Why“, says Simon Sinek – and in terms of how things really happen in enterprise, he’s right. If we start with why, things do indeed happen, and usually happen well.

But then I look at the ‘Why’ column in Zachman: ‘Why’ is business-rules, it says. Gosh. Wow. Exciting… (To be honest, my heart just sinks. Doesn’t yours?) Business-rules? – seriously, where’s the fun in that? Kind of the exact opposite of engaging, really. Something’s gone missing there, clearly…

That’s not quite fair, of course. Up at the top, Zachman describes ‘Why’ as a list of Goals. Not quite as unexciting as business-rules. (But close…) Yet there’s something kinda odd here… kinda like a sudden sideways jump… different things all mixed up together in the same space…?

And I hit up against the same problem when working on the Enterprise Canvas concept, a year or so ago. The same Start with Why: the ‘vision’ for the extended-enterprise is the core ‘Why’ from which everything else flows. That ‘Why’ is emotive, it means something: for the right kind of ‘Why’, people are willing, even eager, to get out of bed way too early on a cold dark dreary workday morning. It matters. It sits above everything else. And yet, to make sense of the content and activities of the service that we’d represent on an Enterprise Canvas module, there’s that same dull boring ‘Why’ again: decisions, principles, rules and regulations, all that kind of stuff. Where’s the fun gone? How come we’ve lost the why from the Why?

I’ve been bouncing up against an answer on this in several previous posts over the past while, such as one about principles in enterprise-architecture, and another on the relationship between architecture, design and implementation. But perhaps a better answer came up over the past couple of days, when trying to unravel the anatomy of Archimate and, in particular, struggling to make sense of the split between what in Archimate they call Intentional Concepts versus Extensional Concepts.

Intentional Concepts are, as the name suggests, about intent. Extensional Concepts are about what we do with that intent – about how we extend that intent out into real-world practice. In Archimate, Intentional Concepts are entities such as Value, Meaning and Reason. And the important point is that these are viewed as separate from ‘the action’. Yet down in the details of that ‘the action’, we again come across another kind of ‘reasons’ – all those business-rules and so on. (Archimate doesn’t model any of that as yet, but that’s another story.) So again we’ve got this kind of sideways jump: ‘Why’ is above everything, as Intent; yet it’s also just another part of that ‘everything’, as Extension, the ways things work together.

The obvious answer: we’re dealing with two different kinds of ‘Why’. Or two different sides of the same ‘Why’, perhaps.

One side of Why creates a question: literally, it starts a ’quest’. For most of us, that’s the exciting bit.

The other side of Why is the answer to the question, the end of the quest. That was the question, here’s the answer: The Decision. End of story. For most of us, that’s when the fun ends: a sense of relief, perhaps, that there’s no more need to quest, but also, well, no more need to quest… Final. That’s it. Full Stop. (or Period, if you speak the US version of English). An ending, that somehow ends up in a bunch of rules, with No Questions Allowed any more. A Why To End All Whys.

Kind of like the braces round a mathematical function: a=func(x,y) and all that. The opening-brace ( begins the question: what’s x? what’s y? what do we do with them? – exciting, new, gosh, wow! And then we hit the closing-brace ) that ends the question: its kind of ‘nothing more to say’, really. We have the answer, the decision. Nothing more to do. Oh. Oh well. (Except that in much of maths, and in computing too, we have parentheses within parentheses within parentheses: q=some(func(x,y), also(y,z, andalso(b,c))) – quests within quests! Fun within more fun – hooray! )

So we do have two different kinds of ‘Why’ – and they go into different places in our architecture.

One kind of ‘Why’ – the question, the ‘(‘ – goes above the Zachman space, goes above the Enterprise Canvas, goes into Archimate as intention. Think of it as a row above everything, or a backplane, or something like that: whichever way we view it, it pervades everything.

The other kind of ‘Why’ – the ‘)’, the decision – goes into the Zachman space as just another column, goes into Archimate as extension. Each decision is specific, explicit: it literally cuts off other choices in that context. We can connect it to things, show how it affects other things, but it doesn’t pervade everything in the way that the question does.

In that sense, it does make sense to put them in different places. (And also – very important – not to forget the intention. Zachman ignores it, or loses it somehow in its strange sideways jump; Archimate all but abandons it, when it squeezes all of its Intentional Concepts into the literal meaninglessness of Passive Structure; and Business Model Canvas doesn’t even bother, but seemingly assumes that the only ‘Why’ that matters is ‘How do we make money?’ The ‘questing Why’ is literally emotive, the source of all motivation: if we don’t explicitly include it in our enterprise models, we’ve just shut out any reason for anyone to be engaged in our whatever-it-is. Perhaps not a wise mistake…?)

In another sense, though, it’s still the same ‘Why’. Just different faces – or phases – of the same quest. That’s where so much of the confusion comes, because often where we place it is more about how we choose to look at it than anything else. Looking ‘downward’, we see a stream of decisions: “because so-and-so… therefore… therefore… therefore…”. Looking upward, we see a stream of reasons: “because… because… because…” – ultimately ending up in the the unquestionable ‘Because!’ of the enterprise-vision or whatever. (I tend to place only that ultimate ‘Because!’ and its immediate implied-values as that uppermost layer of the enterprise-model; everything else ends up at various levels of that Extensional side-column of ‘Why’.) The Knowledge Genes structure also describes this Janus-faced relationship well, though in a different way: move leftward towards the question of Why, rightwards towards the decisions of How. The same ‘Why’, and yet different; a different ‘Why’, and yet the same.

Two kinds of ‘Why’.

That are also the same ‘Why’.

Now why is that, I wonder…?

The Archimate notation aims to be the standard to be used by everyone in enterprise-architecture and related fields. But what exactly is its anatomy – its underlying structure? And if it’s aimed at enterprise-architecture, what is it about that structure that makes it seem only to support IT-architecture, and in such an awkwardly IT-centric way?

(Apologies, folks, because, yes, this is going to be another one of those very long, very technical posts… Skip it if you’re not interested, of course, though I believe this actually is important for anyone involved in enterprise-architecture and the like.)

Read more…

More on translating Business Model Canvas to Archimate etc. (Yes, it’s another of those long, interminable technical posts – my apologies, though they are necessary…)

This one picks up on a couple of sort-of-mistakes that I’ve made in the previous post, ‘Questions on business-model to enterprise-architecture‘, and which need a bit more clarity in explanation. In particular, it’s about specific points in relation to two of Stuart Boardman’s questions:

• an Asset as a type of a Resource – specifically as a Resource for which “the respective service is responsible”;
• a Capability also as a type of Resource.

A key part of this relates to what goes into the Key Resources section in Business Model Canvas, and how we translate and model the respective items in Archimate.

This will no doubt be another long one – sorry… – hence more after the ‘Read more…’ break.

Read more…

You advocate starting (“for now”) with one Business Service. How are we to determine what this business service represents? If the typical enterprise had one single, tightly defined core business, it would be easy but as that’s not usual, I’m unclear how one would define this.

In the adaptation from Business Model Canvas to Archimate, if we start with one Business Service entity, that entity would then represent either the business-model as a whole, or else one of the subsidiary models in a multi-part business-model. If the latter, we would come back later and build equivalent cross-maps for the other subsidiary models. We ‘define’ the service only in the sense that we choose that as the place to start modelling: the content for that ‘service’ is defined already from what we’ve developed on the Business Model Canvas.

The reason for starting just with one Business Service entity is that, when we first start doing this kind of cross-map, it’s often complicated enough already just with the one. As we gain more experience with the cross-map process, we can go straight to a model that looks more like a real-world structure right from the beginning, but that level of detail can often seem overwhelming at first – especially to others when they see the model for the first time. We’ll almost certainly need to decompose it into multiple Business Service entities later, but it’s best to keep it simple at the start!

Why did you pick Activity as the genericization of Application? I see an activity as a much more fine grained thing. (IT) Applications typically perform many activities (and I’m only talking about externally visible activities here). That’s actually one of the reasons I am uncomfortable about the IT focus on applications rather than services. But that’s another discussion. This point might just be semantics, in which case don’t worry.

To use the famous phrase, “it seemed like a good idea at the time”… to me there’s nothing special about that choice of ‘Activity’ versus any other equivalent term. The main point was that I wanted a term that could describe the same something-being-done, as done by any combination of real-people, machine and/or IT – not just the strongly IT-oriented term ‘Application’.

You say a Capability is “the ability to work on specific types of asset”. Can you give an example? I’m not following what you mean by “working on” an Asset.

This relates to part of the rework I did some time back on making the Zachman columns fit more closely to what happens in the real-world, and specifically relates to what Zachman describes as the ‘Who’ column. To me Zachman’s column-structure has never made sense, because it kind of randomly conflates different things into the same spaces, and the ‘Who’ column is particularly problematic. Business-folks also tend to use terms such as ‘process’, ‘service’, ‘function’, ‘capability’ and even ‘unit’ as almost random sort-of-synonyms for each other but at different levels of abstraction or decomposition – a further muddying of the waters that really doesn’t help when trying to disentangle the resultant mess!

There are several fundamentally different things going on in that context:

1. What is being changed or used or referenced or otherwise worked on or worked with;
2. The rules that govern what changes are to take place, and how those changes should take place;
3. The ability to work on (create changes to) whatever-it-is;
4. The ability to make appropriate decisions about how those changes are taking place (the skill-level or decision-level).

Item 1 is what I term an Asset – more about that in a moment, when we look at Stuart’s next question.

Item 2 is what I term a Function, because it’s essentially as in a mathematical function – a=resultofdosomethingwith(x,y). It defines the parameters that will be used (i.e. providing labels for Asset-types), but in essence everything else is encapsulated inside the function (i.e. black-box).

The specific combination of item 3 and 4 is what I term a Capability, because it’s the ability to do something at a specific level of skill and decision-making. (This is similar to the way that Stuart defines it below – “the ability to perform some activity/task/service” – but with a bit more specificity and taxonomic precision.) In the human context, capabilities are often clustered or bundled into Roles and/or Responsibilities – the latter of which are, literally, ‘response-abilities’. That’s the human side of skill and ability, which is why it fits as more consistent meaning at the detail-layer than Zachman’s ‘Who’.

We bring a Function and a Capability together to form a Service. On its own, a Function is always abstract: it needs a Capability to make it actually do something. And on its own, a Capability literally has no function: the Function provides a context in which the Capability can be put to work. A Service may present the same Function interface but with different underlying Capabilities – hence, for example, a Service that can handle any level of insurance-claim, with low-value claims processed entirely by IT-based Capability but higher-value claims requiring human intervention with a different Capability implementing a higher skill-level and decision-making authority.

A Process is just a sequence of changes provided by Services, that are regarded as related in some way (hence ‘choreographed’ etc). It may be a predefined sequence (as in most IT-driven processes); or it may be almost entirely freeform, requiring high skill-levels; or anywhere between those two extremes, using any appropriate combination of human, machine and/or IT capabilities.

This is yet another example where IT-centrism has scrambled people’s understanding of what’s actually going on here. The problem arises because Function and Capability and, often, Process, are all blurred together within a software-application, whereas in a human or even a machine context the distinctions are much more necessary and explicit. We need to be able to distinguish between them for key architectural concerns such as trade-off analysis for implementations or load-balancing, and business-continuity/disaster-recovery.

When you say an Asset is a Resource for which “the respective service is responsible”, how do we determine which service that is and what does responsible mean?

A Resource is simply something that can be used in some way: anything that exists in some form or other is a potential Resource for some kind of business-model. A resource becomes an Asset within some type of ownership-model: in the crudest possible sense, it’s an Asset if we own it. Some things – air, for example, or time – can be resources but can’t be Assets because we can’t own them as such.

We then hit up against the complexities of contrasting different ownership-models, particularly possession-based (i.e. what we’d usually think of as ‘property-rights’) versus responsibility-based. I won’t go into those distinctions in detail, but in essence all of this actually revolves around roles and responsibilities. The whole point of the business-model is we say that we will deliver the Value Proposition via the Channels to the Customer Segments. If we expand that statement into more precise taxonomic detail, what it means is that we declare responsibility (‘response-ability’) to deliver value to the shared-enterprise, by doing something (Key Activities) with Assets (i.e. resources for which we also have responsibility), and then, via some defined mechanism (i.e. Channels), passing the responsibility for those value-added Assets to the enterprise-stakeholders referred to as ‘Customer Segments’. That second definition probably seems horribly long-winded and pompous, but that’s the level of detail that we actually need when we’re going to design a real-world implementation.

I’m uncomfortable with Capability as a Resource. A Capability seems like an abstract concept, the ability to perform some activity/task/service. A resource is something that gets used – whether consumable or not. I realize that, if I’m right, we may have a gap in the Business Model Canvas, which doesn’t seem to have a place for Capabilities.

Perhaps the best way to explain this is that well-meant phrase “Our people are our greatest asset”. (In reality, it’s the relationship with the person that is the asset, but that’s another story.) The point here is that the skills and abilities of the person, the machine, the IT-application or whatever – the set of available “ability to perform some activity/task/service” – is definitely “something that gets used” in the organisation, and hence ‘resources’ from the organisation’s perspective. So it’s not a gap in the Business Model Canvas – it’s what we would include under the Key Resources banner.

In fact in general one of the things you’ve done (deliberately or otherwise) is to highlight a weakness in the Canvas, when it comes to dealing with extended enterprise. I mentioned this in another comment. Of course it’s possible but it requires one to think outside of the boxes (boundaries) in the Canvas. In particular the relationship with Partners seems to be unidirectional and rather more resource than service based. By doing the mapping this becomes clearer. So either we say that it’s OK just to work with the Canvas’s implicit support for extended enterprise or we need to address that (or rather ask Alex Osterwalder to do so). The first option means from my perspective that we then need to find a way to handle it explicit in the Archimate (or any similar) mapping. You were dealing with some of these issues in your post on non-profit enterprises and the Canvas.

There’s a real danger of being unfair here, so I ought to reiterate that Business Model Canvas works very well indeed for the task that it was designed to do. That task is about getting people to think and innovate about how their business-model operates, in a kind of integrated, big-picture way, all with the simplicity needed for rapid brainstorming and pre-prototyping and the like in a free-form workshop or cafe context. To me it’s a business-architecture tool, with a very specific purpose: we really have no right to complain that it isn’t a good fit for whole-scope enterprise-architecture, or for detail-layer implementation, because it was never designed for those kinds of uses.

If we need to link it into methods and tools and the like for those other uses, it’s our responsibility to get those cross-mappings to work – not Alex’s. That’s what this bunch of posts has been about: going downward to Archimate and suchlike, and upward to Business Motivation Model and beyond.

The same applies to using Business Model Canvas for business-models for government or non-profits. The fundamental structure of the Canvas is geared towards commercial organisations, and there’s nothing wrong with that. If we want to use the Canvas outside of a commercial context, it’s our responsibility – not Alex’s – to make the appropriate amendments. (Alex did set up a website a couple of years back to explore ‘business-models beyond profit‘ – and although it doesn’t seem to have gone any further in the last eighteen months or so, I know he does have a deep personal interest in that space.) So again, we do need to be fair here.

The only ‘weakness’ in the Business Model Canvas as such is its implicit asymmetry on the Key Partners side of the model: in my opinion those relationships need to be understood as exactly symmetrical with the Customer Segments side, not least because we can make or break a business on supply-side as easily as on customer-side. That asymmetry also makes it more difficult to visualise a full supply-chain, or the role of the business-model within an overall value-network. Much the same applies to its orientation towards resources rather than services, and (especially in the Canvas’ implementation in the BMTBox iPad app) the low priority given to modelling of flows and transactions.

But I do acknowledge both of those as trade-offs to preserve simplicity: that kind of structure does make it easier to focus on this organisation’s business-model, without getting too distracted by anyone else. For the Enterprise Canvas, I made different trade-offs: it’s explicitly symmetrical, and it’s explicitly designed around services, but it is also more complex – especially once we use it to go into recursive service-decomposition or inter/intra-service coordination or flows-modelling or role-mapping or values-dependencies and the like. It’s designed for those uses, and Business Model Canvas isn’t – but that doesn’t make Business Model Canvas ‘wrong’ as such. Using Enterprise Canvas for multi-layered enterprise-modelling also requires a different mindset and skillset, than those needed for roughing out business-models on Business Model Canvas – the difference between whole-enterprise architecture and domain-specific business-architecture, in fact. Sure, we can use Enterprise Canvas to develop business-models, and it actually fits that need very well: but it’s not specifically designed for that purpose – whereas Business Model Canvas is. ‘Horses for courses’, really.

I hope that makes some degree of sense, anyway, and that it answers those questions well enough for now?

Yes, I admit it: I’ve been kinda pouring out the posts lately. Sorry…

But why all this fuss about business-models and enterprise-architecture? What’s the point about the bottom-line not being the baseline to work from? If everyone’s selling something to someone, is there really any difference between a for-profit and a non-profit business-model? And who would want to go from Business Model Canvas to Archimate, anyway? Is anyone interested in any of this technical stuff?

I suppose it all comes down to this quote from Chris Potts:

The devil is in the detail, but the angel is in the architecture.

People like building business-models. It’s wonderfully abstract, and it’s fun – like playing with model-trains, where the passengers are only imaginary and the trains really can run on time. Unfortunately (or fortunately?) the real world is a bit different from that…

Real-world detail can break the best-looking business-model without even breaking out a sweat. We need to know that detail – or at least have a better sense of that detail – before committing ourselves and others to a lot of hard work and ultimate heartache.

Yet we also need to avoid drowning in the detail – otherwise we’ll never get started. Analysis-paralysis, and all that.

Which is where architecture comes into the picture. Formal discipline, yet without overt formality. Patterns help us break through the problems. We simplify, without being simplistic. And we model to reduce the muddle, to cut through the chaos and complexity of all that devilish detail.

Perhaps even more, it’s about the story: the story of each action, and the story of the enterprise itself. If we get clear on the story, the sensemaking becomes a lot simpler.

As I understand it, architecture comes down to a single idea: everything works better when they work together, in pursuit of purpose, a clear aim in mind. Everything connects with everything else. It’s the detail of how everything connects with everything else, of how we get everything to work with everything else, that I’ve been focussed on here.

A lot of detail, I know: but sometimes that is the nature of the beast. Fact is that architecture isn’t all nice pretty abstracts and nice pretty pictures – sometimes there is a lot of petty picky detail, and sometimes we just gotta face that fact… sorry…

Hope it’s been useful to someone, anyway?

The previous post, ‘From business model to enterprise-architecture‘, turned out to be another of my monster essays. Sorry…

The detail’s there if you need it, but if you just want to do the translation from Business Model Canvas to Archimate, without worrying too much about the ‘Why’ behind it, here’s the short version.

Step 1: Start with a business-model on Business Model Canvas

That part’s straightforward enough for most folks here, I imagine?

Step 2: Separate out the players on the business-model

Start an Archimate diagram at the Business layer (the ‘Why’ layer).

Represent each Key Partner from the Business Model Canvas by a Business Actor entity on the Archimate diagram.

Likewise, represent each Customer Segment by a Business Actor entity.

(We will also need Business Role and Business Interface link-entities for each of these business-actors, but we’ll come back to that in a moment.)

The remaining cells of the Business Model Canvas – this organisation – can for now be represented by a single Business Service entity.

Step 3: Expand the detail for the interfaces of the business-model

Represent each Value-Proposition offer by a Product entity, optionally with an associated Value entity to describe why this offer would be of value to a customer-segment. Link these Product entities to the organisation’s Business Service.

Represent each Customer Relations item and Channel with the following:

• Business Interface entity, linked on one side to the organisation’s Business Service, and on the other side to a Business Role assigned to the respective customer-segment Actor
• Business Interaction entity, also linked to the Business Service and to a customer-segment’s Business Role
• Business Object entity – indicating the content of the flow between the organisation and the customer-segment, optionally associated with a Meaning entity and/or Contract entity – linked to the respective Business Interaction

Represent each Revenue Stream in a similar way, as a ‘back-channel’ through which value is returned to the organisation. Each back-channel will include its own Business Interface, Business Interaction, and Business Object, with the latter probably linked to the same Contract as for the respective Business Object in the main transaction channel.

Repeat the same process on the supplier-side, with matching Business Interface and Business Role entities for each Key Partner, and Business Interface, Business Interaction, Business Object and Contract entities for each external Cost Structure item. The respective channels and supplier-relations services are only implicit in Business Model Canvas, but you’ll need to add the respective Business Interaction and Business Object entities on that side, together with any needed Contract entities.

Step 4: Expand the Key Activities

Extend the Archimate diagram down to the Applications layer (the ‘How’ layer). In particular, we’ll use this layer to model the Key Activities in the Business Model Canvas.

We have a problem at this point: Archimate’s ‘Applications’ layer only knows about IT, and we need it to cover a much broader range of types of ‘How’. This is because an activity in a business-model could be done by any combination of people, IT and ordinary machines, and to understand the trade-offs between different ways of doing things – different types of ‘How’ – we need to model them in much the same way in each case.

To do this, we need to change the Archimate entities for this layer from the IT-specific ones in the standard, to more generic ones that will work with any type of implementation. In most cases, all we need to do is change the prefix of the name from ‘Application’ to the generic ‘Activity’. This gives us the following entities to model our Key Activities:

• Activity Object (generic of Data Object): represents an object (or subject) to be created, accessed, changed, deleted or otherwise worked on in a business-activity – may be physical, virtual, relational or any combination of those as required
• Activity Service (generic of Application Service): the ‘exposed’ part of an activity that connects with a Business Function in the Business layer
• Activity Function (generic of Application Function): a ‘chunk’ of activity that is visible only within this layer
• Activity Interaction (generic of Application Interaction): a unit of behaviour where two or more components or modules come together to act on an Activity Object
• Activity Interface (generic of Application Interface): a point where an activity can connect with its environment – particular to access or exchange Activity Objects
• Activity Module (generic of Application Component): a defined unit of activity in a structural sense, such as specified in an ISO9000-style Work Instruction
• Activity Collaboration (generic of Application Collaboration): a temporary configuration of two or more modules to perform collaborations

Link these entities as appropriate, using the respective standard Archimate relationship-links.

Step 5: Expand the Key Resources

Extend the Archimate diagram down to the Infrastructure layer (the ‘With-What’ layer). In particular, we’ll use this layer to model the Key Resources in the Business Model Canvas.

One of the frames we use extensively in our own enterprise-architecture is an extended and adapted version of Zachman, which uses the categories Asset, Function, Location, Capability, Event and Decision. In general, the Key Resources section in Business Model Canvas relates to Assets, Locations (physical, virtual, relational, and various combinations), and Capabilities (the abilities or facilities used to the work or within which or through the work takes place).

Again, the Archimate standard only knows about Assets, Locations and Capabilities that relate to IT: we need to extend this to include any other types we may need in the business-model – including buildings, machines, and individual people’s skills.

An Asset can be defined simply as a resource for which the respective service is responsible and can put to use as required.

A Capability is the ability to work on specific types of Asset using a specific level of competence and skill.

A Location is a node within some type of location-schema. Locations may be of any asset-type or resource-type, or any combination of these.

A network is a schema that describes a set of Location nodes, specific relationships between those nodes, and, often, the types of Assets than can be transferred on pathways of connection between those nodes.

An infrastructure is thus a clustering of Assets, Capabilities and Locations, often in network-relationships.

Given these, we would represent the Key Resources via the following Archimate entities, adapted as appropriate:

• The Artifact entity may represent any type of real-world Asset.
• The Infrastructure Service entity may represent the exposed available behaviour (Capability) of any cluster of related Assets, Capabilities and Locations, linked to any Activity Function in the Application layer.
• The Infrastructure Interface entity can represent the exposed interface for an Infrastructure Service, as linked to any Activity Interface in the Application layer.
• The System Software entity is merely one very specific example of a generic Capability entity, and can be used (preferably retitled) to represent any Capability.
• The Device entity represents a type of Asset that can be used in and for specific activities, as ‘active structure’: a hammer, a power-drill, a fork-lift truck and an ordinary ‘dumb’ telephone are a Device in this sense.
• The Network, Node and Communication Path entities respectively represent a schema for connections between Location nodes, a node within that schema, and a connection-path through which specific types of Asset (Artifact entity) may be transferred between nodes.

As in the Application layer, the types of relationships that Archimate permits between these more generic entities and their derived specialisations should remain essentially unchanged.

Step 6: Apply enterprise-architecture disciplines as required

Use standard enterprise-architecture techniques – such as the methods and tactics outlined in TOGAF Phases B-D – to review the resultant architecture portrayed in the Archimate model(s), and make any recommendations for changes to the business-model itself.

Use standard project/architecture techniques – such as the methods and governance outlined in TOGAF Phases E-G – to define and monitor change-projects to implement the agreed business-model.

Okay, I think I’m finally getting somewhere, on looking for a way to connect a business-model to enterprise-architecture, to provide a full link between top-down intent and bottom-up real-world constraints.

This specific part goes from the business-model downwards, from Business Model Canvas to Archimate, and thence to BPMN, UML and other detail-layer models. (There’s another part needed to link upward, connecting that work back up through Business Motivation Model and the like to the core shared-enterprise, but I’ll have to deal with that in another post.)

As you’ll see, I’ve had to twist Archimate somewhat in a few places, to provide workarounds for its current IT-centrism, but otherwise everything exactly follows the existing standards. The keys that enable and to some extent validate those adaptations are two assertions:

• everything is a service (an assertion supported explicitly by the design of Archimate itself)
• everything is recursive (a principle that enables pattern-based modelling, such as the concept of ‘layers‘ used in Archimate, TOGAF etc)

The ‘how-to’ that follows after the break is the current outcome of a lot of exploration over the past weeks, months and years, a lots of posts and conversations on this blog and elsewhere, and a lot of in-person discussion with a lot of people, many of whom have explicitly asked to remain anonymous. I do believe it’s in a usable state right now, but it should still be regarded as ‘in beta’ at best: use with some caution, and please send me any feedback and suggestions.

In parallel with both Business Model Canvas and Archimate, this may be considered to be under a Creative Commons licence. It’s probably not yet stable enough to attach to a CC license-type in a formal manner, but for now please assume non-commercial, share-alike and attribution-requested for the parts described here.

More after the ‘Read more…’ break, anyway.

Read more…

Still plodding away on ideas for a systematic process to translate a business-model in Business Model Canvas down into real-world architecture and implementation. (This links up with quite a few previous posts, such as ‘More on business-models‘, ‘Enterprise-architecture – let’s keep it simple‘ and ‘Is Archimate too IT-centric for enterprise-architecture?‘)

[Note: this is a work-in-progress post, not a finished piece - I really do need discussion on this one!]

What’s come up this time is the usual struggle with the so-called ‘architectural layers’ in common EA frameworks such as TOGAF and Archimate:

• Business
• Applications (in Archimate) or Information Systems (in TOGAF)
• Infrastructure

The problem is that, for me, these are ridiculously incomplete, and lead directly to IT-centrism – where IT is deemed to be the sole centre and basis for everything. That IT-centrism what creates most of the much-lamented ‘business/IT-divide’.

The corollary is that, because IT is placed as the centre for everything, and applications only run on IT, everything else has to be lumped into ‘business-architecture’, because it’s the only place it can go. Hence in TOGAF, for example, high-level business-strategy is bundled together with mid-level process and detail-level manual work-instruction, without any kind of distinctions between them, solely because it’s ‘not-IT’. And technology and infrastructure that isn’t computer-based – lorries, fork-lift trucks, assembly-lines, plumbing and wiring and even the buildings within which everything operates – don’t even get a mention anywhere.

This brings serious problems even in IT-specific architectures: for example, how can we usefully describe the overall architecture of a data-centre without mentioning power-supply or cooling or access-pathways? What’s the point of arguing about instant-on virtualization for data-servers if it takes a minimum of six months to construct the building that houses them? How do we describe disaster-recovery processes for when the IT is out of action, when the only metamodels available to us can only describe IT? To anyone doing real enterprise-scope architecture in the real-world, the myopic inanity of IT-centrism gets really frustrating after a while…

Hence why I’ve been ranting and raging so much about the limitations of TOGAF and the like over the past few years. It’s not because I’m ‘anti-IT’ – as some people have dismissed me – but because I’m trying to get things to work in the real world. A messy, chaotic, uncertain world in which IT is often unreliable at best, irrelevant at worst, and which, for the most part, is not centred on IT. Sigh…

So, in short, the conventional concepts of so-called ‘business-architecture’ are an unusable mess, and the ‘application’ and ‘infrastructure’ so-called ‘layers’ are too narrow in scope to make practical sense for anything other than the most IT-centric of IT-architectures. Hence, also in short, not so much useless as probably worse-than-useless for most real-world purposes.

Which means that we need to start again. Properly.

But from where? Using what as the layers?

(Or do we even need layers at all? Is even the idea of ‘layers’ misleading?)

There’s the Zachman layers, of course: Contextual, Conceptual, Physical, Logical, Implementation, Operations. That does make practical sense as a description of the process of change, but perhaps not so much about the architecture itself – the interrelated, interconnected structure of that which is in use.

What about structural-decomposition – from abstract to detail? Well, yes, that’s useful, certainly, but it doesn’t really tell us much more than Zachman does, and doesn’t help us to differentiate between different kinds of ‘thing’ – the distinctions that come up, if somewhat erratically, in Zachman’s columns of What, How, Where, Who, When and Why.

The ‘Why’, though, does lead to another suggestion: Simon Sinek’s principle of ‘start with Why’, and its layering of Why, How and What.

Because if we start with Why, and tweak the ‘What’ slightly to ‘With What’, we end up with an almost exact match to the Archimate / TOGAF layering – but this time a layering that is not IT-centric. And which also lines up with key parts of the Business Model Canvas:

• Why? – about the choices and Value Propositions that drive ‘the business of the business’
• How? – about IT-applications, ‘manual’-processes and any other Key Activities that enact those choices and needs
• With What? – about any machines, equipment, buildings and other infrastructures and Key Resources upon which or through which those activities take place

At first glance this has some parallels to the long-established CapGemini ‘Integrated Architecture Framework‘ [IAF]:

(I have a vague recollection that there’s at least one more EA framework that uses a similar Why / How / With-What structure, but right now I can’t remember whose it is… – my apologies to that person, anyway.)

But if we look more closely at those layers in IAF, it’s clear that they’re just a re-labelling of Zachman layers, with the old TOGAF-style layers sideways-on, and deeper ‘cross-cutting themes’ such as security and governance further behind. (And actually that’s quite a good way to put it – which we’ll come back to in a moment.)

The point here is that if we use that Sinek-style categorisation of Why, How and With-What, we can cover just about anything that’s needed in the architecture: it doesn’t assume that the end-point is only about IT. And it still lines up well to Archimate: hence business-information (linked to Why) is represented in Archimate as a Business Object, its usage in processes (linked to How) is a Data Object, and its physical form (as a With What) is a Representation. Archimate doesn’t as yet have any entity to represent generic ‘physical Thing’ or ‘thing that flows through processes’ – such as we’d need to represent a parcel in a logistics context, for example – but the Why / How / With-What structure makes it easy to understand that Representation, Data Object and Business Object are just IT-oriented specialisations (in the UML sense) of each of the respective generic entities. It works.

But should we use layers at all – especially scope-defining layers such as ‘business’, ‘application’ and ‘infrastructure’? In a sense, the IAF suggests not – any fixed notion of ‘layers’ is misleading. A better way to describe is to say that the ‘layers’ are merely areas of emphasis of attention: we separate those areas in order to ‘black-box’ the internals of an area of scope so as to focus our attention on the interfaces between those areas of attention. The IAF shows a very good way to visualise this, with sets of viewpoints that are in effect orthogonal to each other. The only problem there with the IAF is that, yet again, it constrains the overall scope to IT alone – which renders it too limited for whole-enterprise architecture. If we imagine that, rather than that catch-all column labelled ‘Business’, we could have as many columns as we need – and as many ‘backplanes’ that we might need, equivalent to the existing ‘Security’ and ‘Governance’ but covering all values in context for the enterprise – then something like IAF would make good sense.

I would suggest, though, that that simple categorisation would be a good place to start:

• Why – ‘business’
• How – ‘applications’
• With What - ‘infrastructure’

Use each of these not-quite-layers as a viewpoint for focus into the overall enterprise context, and use an adapted version of Archimate or an equivalent to model both within those ‘areas of interest’ and to explore the connections between them.

Okay, that’s it for now: over to you, if you would?

Archimate aims to be the standard notation for enterprise-architectures. But has it become too IT-centric to be usable for that purpose? And is there any way we can get it to break out of the IT-centric box?

These questions came up for me whilst exploring the architectural processes we could use in expanding a business-model developed in Business Model Canvas out into the detail needed for real-world implementation. Archimate should be the obvious standard to use in describing an overall architecture: but at present it’s not so much IT-oriented as almost entirely IT-centric, and a real-world business-model involves a lot more than just IT. Yet if the only available standard only describes the IT, what on earth can we use to describe everything else? And how can we link everything else back to the IT? Therein lies the problem.

Let’s step back a bit. More like a decade, actually.

Archimate started out as means to solve some real architectural problems for users of large IT-systems in the Netherlands. A consortium of academics, IT-consultancies, business-users and government was brought together, to address how to link all the different layers of the IT-domains together, from the business needs, down through the IT-applications and data, all the way to the actual IT-infrastructure that supported all of those needs. In other words, the usual IT-oriented layering that we see in TOGAF and so many other ‘enterprise’-architecture frameworks.

That kind of layering does make perfect sense if the focus of concern is IT, and if the business of the business revolves primarily around information. In other words, it fits well with IT-architectures for information-centric businesses such as banking, finance, insurance and tax – hence the reason why the usual Archimate ‘demonstrator’ is an imaginary insurance-company called ‘Archisurance’.

But this doesn’t make sense – or rather, is far too constrained and constraining – if the focus of concern is anything other than IT, or for any type of business whose business is not centred solely around information. Which latter, in reality, is the case for most businesses – if not all of them, once we start looking at the deeper detail of most business-models.

Which means that, for those of us involved in real enterprise-scope architecture, business-architecture, security-architecture, process-architecture, or any kind of architecture that touches just about anything other than IT, we have a problem here. A big problem.

A problem which in some ways is actually getting worse.

Which means it’s a problem that, collectively, we need to do something about, right now. Urgently.

Why do I say it’s getting worse? Well, take a look at this section from Chapter 2 of the original Archimate Primer [PDF], from back in 2004:

In the enterprise-architecture modelling language that we propose, the service concept plays a central role. A service is defined as a unit of functionality that some entity (e.g. a system, organisation or department) makes available to its environment, and which has some value for certain entities in the environment.

It’s clear that ‘service’ here is intended to be generic – not solely IT. And service-orientation is a certainly good place to start for whole-enterprise architectures.

The chapter-text continues with a brief summary of that all-too-common IT-oriented layering of ‘Business’, ‘Application’ and ‘Technology’. The accompanying diagram and text, though, do make it clear that there’s more to the context than IT alone, and that we do need to take the broader enterprise into account, beyond just the organisation itself:

The Business layer offers products and services to external customers, which are realised in the organisation by business processes performed by business actors. … On top of the Business layer, a separate Environment layer may be added, modelling the external customers that make use of the services of the organisation (although these may also be considered part of the Business layer).

So far, so good. It’s about services, and about the broader enterprise; it’s IT-oriented, but not IT-centric as such.

Yet somewhere, things started to go badly wrong, from an enterprise-architecture perspective.

Somewhen around 2008 or so, with the aim of making the still-somewhat-prototype standard more available worldwide, Archimate was transferred to the ownership and aegis of the Open Group. That move no doubt seemed sensible enough at the time: but the problem is that the Open Group is an IT-standards body, not an architecture body – and that built-in orientation towards IT starts to show even in the very first sentence of the Archimate version 1.0 formal standard, published in 2009:

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization.

And by the time we reach the standard’s chapter on Enterprise Architecture, that all-too-common IT-centrism is in full flood:

The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. Further, it details the structure and relationships of the enterprise, its business models, the way an organization will work, and how and in what way information, information systems, and technology will support the organization’s business objectives and goals. This makes IT a responsive asset for a successful modern business strategy.

Today’s CEOs know that the effective management and exploitation of information through IT is the key to business success, and the indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

You could just about get away with that kind of myopia in 2009, though even then its absurdity was beginning to be more widely recognised. Two years later, it’s probable that most members of Open Group would acknowledge that there are some serious limitations there, and many – such as Len Fehskens and Microsoft’s Mike Walker – are much more overt in asserting the need to break out of the IT-centric box.

In short, we need an Archimate for enterprise-architecture – not just IT-architecture. We need – and need urgently – an Archimate that isn’t all-but-uselessly IT-centric.

And yes, the good news is that a new version of the Archimate standard is due for release Real Soon Now. Hooray!

The bad news is that this new version isn’t likely to help much at all. If anything, it’s likely to make it worse…

I’m not a member of the Open Group or the Archimate forum, so I’m not directly involved in the update. But from what I hear from colleagues who are involved, the new version will be just as IT-centric as the old one. That text above apparently remains completely unchanged in the new standard: which means that its definition of ‘enterprise’-architecture is not so much out of date as just plain wrong. I’m told there are a couple of new sections to the metamodel: one is on motivation, to sort-of link it to the well-known Business Motivation Model; the other is about projects and dynamics, linking to and in some ways improving on the TOGAF 9 metamodel. I gather that there are a few new generic entities, such as Location, which would be not so much useful as essential. And Product, which used to be defined as “a coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers”, is now apparently defined in even more rigidly IT-centric terms, as something like “a collection of financial or information services, with a contract that gives the customer the right to use the associated services”. Which doesn’t leave any space for descriptions of physical product or service, or relationship-oriented services – which is what most businesses actually deliver.

In other words, fine for the relatively small subset of enterprise-architecture that focusses around IT, but almost useless for anything else.

Which is not good news for enterprise-architecture.

So what can we do about it?

One option, I suppose, is to yell loudly at Open Group, and try to make it evident even to the most IT-obsessed of their big-consultancy members that this is nowhere near good enough. Sadly, I don’t think that’s going to work…

Another might be to ask the original Archimate group – Telematica Instituut and others – to retrieve the standard from Open Group, so that we actually have a chance to make it work again. Sadly, I don’t think that’s going to happen either.

Another option might be to use the Profiles facility in Archimate to define a much broader metamodel, particularly around the physical and relational analogues to the information-space that IT partially covers. That at least is doable – but the problem is that without a standards-body to coordinate all the various needed extensions, we’ll soon have no standard at all. Not a standard that we could for interchange, anyway, and not one that we could get the vendors to standardise on, to at last enable us to move architecture-models between the various vendors’ toolsets. Yet it doesn’t seem to be in Open Group’s interest that this essential work takes place, and at present there’s no-one else to take on that role.

Which at present, and for the foreseeable future, leaves us without a notation/exchange standard that we can use for enterprise-architecture. Again. After all these years. Sigh…

Over to you, folks: any ideas for anything that can get us out of this metamodel mess?