What do we mean by ‘business-architecture’?
One of the keys to breaking free from IT-centric ‘enterprise’-architecture lies in reclaiming the meaning of the term ‘business-architecture’.
In TOGAF and other ‘classic’ enterprise-architecture, everything revolves around IT: the IT is deemed to be the sole centre of meaning within the enterprise. Hence ‘business’-architecture is defined as a subset of ‘enterprise’-architecture, which itself is defined as a subset of IT-governance. And in practice, business-architecture is viewed as a near-random grab-bag of ‘anything not-IT that might affect IT’, without any real clarity about how that grab-bag is structured within itself, and with no acknowledgement at all about anything that might not affect IT. In other words, to be blunt, probably worse than useless: certainly not something that we could use at an enterprise level.
So the first step outward is to start to treat business-architecture as a form of architecture in its own right. That’s starting to happen now. There’s even a lot more explicit description from the ‘name’ consultancies such as Gartner and Forrester that some of this ‘new’ business-architecture may not touch IT at all. That’s good. Definitely good. People are at last beginning to break free from the trap of IT-centrism.
Yet there’s another trap that comes right after that one – and I’m seeing a lot of people falling straight into it. Business-centrism. Where ‘the business’ is deemed to be the sole centre of the architecture, around which everything else revolves. It isn’t: because in a true enterprise-architecture, everywhere and nowhere is the centre. It has to be that way: otherwise it isn’t an enterprise-architecture.
Which means that, to use Len Fehskens‘ schema, business-architecture is merely a domain-architecture, one of many other domain-architectures – just like IT-architecture is a domain-architecture (or a cluster of related domain-architectures, rather). It’s an explicit subset of ‘the architecture of the enterprise’, with responsibility for an explicit domain of interrelated concerns within that overall scope.
To me the domain is indicated by the inversion of the term: it’s literally ‘the architecture of the business’ – in other words, ‘the business of the business’, how its core business is organised and structured usually at a fairly abstract level. (Like most domain-architectures, it typically focusses at Zachman level-3, ‘Logical’, to use that common taxonomy.)
Given that description of boundaries, a core part of that structure represented by and maintained in the business-architecture is the business-model (or set of business-models). In the Osterwalder sense – which is the one I use here, though in perhaps a more extended sense than in Osterwalder’s Business Model Canvas – a ‘business-model’ is a structure, one that provides the central focus for ‘the business of the business’. It’s not much about vision or values, or strategy – those are inputs to the business-architecture. It’s not much about the details of business-process: that’s the role of process-architecture (these days often known as BPM, business-process management), or IT-architecture, or often both in parallel. It’s not about the physical structures in which those processes take place: that’s the role of facilities architecture, or the literal architecture of buildings. It’s not about the skill-sets or organisational structures to operate or manage those processes: that’s the role of HR and organisational-architecture. And so on, and so on. Business-architecture is about the architecture of ‘the business of the business’, and how it interfaces with all the other architectures – aided by enterprise-architecture, whose role is to ensure that all the different architectures play well together.
So I’ll admit I was a bit disappointed that Chris Potts‘ immediate response to my previous post was:
- chrisdpotts: @tetradian Let’s not confuse business model with business architecture. Our business vs how we are structured to achieve it. #entarch
Which to me indicates that there’s a serious confusion there: a business-model is a description of how we are structured to achieve our business. I was also a bit disappointed when Kris Meukens – another architect whose opinion I greatly respect – also piped up with an agreement to Chris’ remark above. Yet what I suspect, and suspect strongly, is that both have fallen into the trap of business-centrism, or perhaps of a kind of inverse-IT-centrism, where ‘business-architecture’ is now ‘the sole centre’, but again defined as ‘everything not-IT’:
- tetradian: @chrisdpotts @krismeukens to me it sounds like you’re mixing BA with EA? – expand/explain, please, perhaps with blog-post?
And again was a bit disappointed at Chris’ response:
- chrisdpotts: RT @tetradian: @chrisdpotts @krismeukens to me it sounds like you’re mixing BA with EA? | No.
Disappointed, because it doesn’t tell me anything at all – other than that I’m apparently ‘wrong’, in some unspecified way, yet with no way to find out how or why.
Okay, fair enough: I may well be wrong. Let’s assume that I am wrong: it wouldn’t be the first time, and I doubt it’ll be the last. 🙂 But it would be useful – to me at least – to have some understanding of how I’m wrong, why I’m wrong, and what I should do differently or think differently to get it right. I’ve summarised my understanding of business-architecture above – what is it, what its boundaries are, where it fits in with other architectures and with the overall scope of enterprise-architecture. So what have I missed? What am I not ‘getting’ here?
Or – in the perhaps-unlikely event that I’m not wrong – how could or should I explain it better to others, so that they don’t get it wrong?
What to you is ‘business architecture’? What do you mean by the term ‘business-architecture’?
Advice/suggestions, please?
Many thanks.
Any architecture operates with a set of artefacts and relationships(static and dynamic models, preferably executable) between them and the environment. In the case of EA, we use many different (business and technical)artefacts. For BA just forget about all technical artefacts. So, it is a question of the nomenclature of “business” artefacts and relationships (other artefacts?) between them.
Maybe we need a special subset of business artefacts to express the business model.
Will it work?
Thanks,
AS
Alexander – from that, should I understand that BA artefacts are simply the non-technical (i.e. non-IT) artefacts? Which in essence makes BA into ‘the architecture of anything not-IT’? Echoing the classic IT-centric view that ‘the business’ is ‘everything not-IT’?
If so, I disagree very strongly indeed, for the reasons explained in the post above. But I may have misinterpreted your meaning there, of course: if so, my apologies. Perhaps explain further, if you would?
Tom,
It seems to me that all this is more about the language of Enterprise-Architecture (and sub-sets) than the way the EA approach could bring some value to the enterprise (or some sub-set of stakeholders). Indeed, the energy follows the language, now more than ever, but I’ve seen a proper terminology applied and no results as well as vice versa. People tend to disagree on what EA or BA means but strangely there is a good consensus about what IT means.
And within EA the lack of rigour and consensus about basic concepts is amazing. Just compare the definitions of ‘model’, ‘view’ and ‘viewpoint’ in DoDAF2 (Vol.1, p. 19), ISO/IEC 42010:2007 (Annex B: Notes on terminology, page 14; page 3 and 4 resp.) and TOGAF9 (pp 33, 39, 40). I’m not going to the meaning of ‘artefact’ or add other popular standards like UML, where ‘model’ has entirely different meaning.
I admire the logic in your post. And that’s something I miss quite often in other EA sources. But I’d be even happier to read about some real-life examples of the consequences of the business-centric- or other EA traps. Well, if that’s something new, may be a have to wait a bit.
THANK YOU TOM!
Yours Truely,
Business Architecture Princess
@Pat Ferdinandi
a ‘business-model’ is a structure, one that provides the central focus for ‘the business of the business’. It’s not much about vision or values, or strategy – those are inputs to the business-architecture
Agree strongly. especially since a company can have multiple models. AND none of the models also talk about how the business is reflected in the eco-system (or full enterprise).
Tom,
As someone who is a practicing business analyst, but is seeking to increase my knowledge of enterprise architecture, I’ve been reading your blog posts and Twitter stream with interest. I always find your posts to be logical and articulate, as well as very broadly informed; surprisingly a rare combination.
I’ve been following your criticism of EA not being either IT-centric or business-centric for some time now and each new addition adds to my understanding of why you staunchly argue against both. With this post I get a powerful visual of EA not being a stack, such as in TOGAF, but rather a Venn diagram with domain architectures such as business architecture, IT architecture and BPM enclosed within them (without overlaps) and EA being about the holistic orchestration of them, with none of the domain architectures being more important than the others.
In this post you describe the core of business architecture as the business model “in the Osterwalder sense”. You acknowledge that it might be a more extended sense than the Business Model Canvas. I agree with this, as in some ways the Business Model Canvas is a subset of what a business model could be composed of. It was also a way of making the business model more systematised and easily accessible to a general audience. I find Anders Sundelin’s work to be a good reference for business models. However you seem to imply that business architecture is primarily about defining a business model, however you choose to define the business model. You then go on to say explicitly that vision, values and strategy are inputs into the business architecture. That last statement gave me pause. So I’m left with a question for you.
1. Where does defining the “ends” in the Business Motivation Model sense lie? I’ve always thought that was part and parcel of the business architecture. Is it another domain architecture separate from business architecture, or is it part of the EA itself and the various domain architectures are about how the “means” (the realisation of the ends) are achieved)?
A point of clarification, I disagree with your assertion that strategy is an input into the business architecture, as in my opinion a business model is about defining elements of your strategy. That is, I’m talking about the way you achieve your goals, not defining your strategic goals. I think Anthony Phillip’s Meaning of Strategy post provides a great explanation of this.
@Ivo Velitchkov – Ivo, thanks as usual. 🙂 What I get from your comment is that what we really need is a focus on realism – about what works and what doesn’t, without worrying too much about ‘purity’ of definitions and the like.
If that’s a correct interpretation, then yes, I strongly agree. I’m not that interested in finding ‘the one true definition of business-architecture’ etc. What I am interested in is in minimising the risks that arise when people don’t realise they have different definitions; in surfacing hidden assumptions within definitions; and clarifying the ‘fitness for purpose’ of different definitions, and again identifying the resultant risks (for example, in trying to use a finance-oriented definition in a non-profit context).
One thing I admire in your work is the focus on realism and real-world observation: “I’ve seen a proper terminology applied and no results as well as vice versa”. The reality, as you imply, is that ‘good’ ideas often don’t work in practice, whilst some truly atrocious methods of working do manage to survive and even thrive somehow, no matter how much we wish they wouldn’t… So yes, I do prefer to be as precise in reasoning as possible – because that’s one of the key means I use to surface hidden-assumptions and the like – but I’m also acutely aware that logic alone is not enough: we need real-world observation, and a kind of deep respect for the sheer messiness of the real world. And yes, I suppose I do focus a lot on theory – but I’m also acutely aware that theory needs to be linked to practice, in real-world practice, if it is to be any use at all.
You also say, “I’d be even happier to read about some real-life examples of the consequences of the business-centric- or other EA traps.” Unfortunately, we don’t have to look far. Go read the Chaos Chronicles: most of those failures are due to hidden-assumptions of the kind I’m describing here. The infamous example of the (UK) National Health Service IT-system. The few examples of business-process-reengineering that did succeed, because they didn’t fall into the trap of IT-centrism. Or, on a larger scale, the frequent failure of the the ‘aid to developing countries’ business-model, which in many cases resulted in a worsening of most economic metrics in the respective countries. And, of course, the flawed assumptions that drove the global financial system off the cliff a couple years back.
One of the problems is that those kinds of failures tend to be on such a large scale that it seems difficult for many people even to see them, let alone comprehend that it was the thinking that was flawed in each case – the conceptual structure of the system, rather than merely its operation. Another key problem is that many of the difficulties arise from the impacts of hidden assumptions – of which the whole point is the risks and implications are not understood precisely because the assumptions remain hidden from view (or are deemed so ‘obvious’ that few people recognise that they are only assumptions). This is why a formal discipline to surface such hidden-assumptions is so important in practice: hence the real value of enterprise-architecture, business-architecture and the like.
@Pat Ferdinandi – greetings indeed, oh Business Architecture Princess! 🙂
Agreed: to me, one of the key distinctions is that a business-architecture may indeed validly assume that ‘the business of the business is to make money’. At the enterprise-architecture layer, we can’t even take that as an assumption, even for a commercial business, because it needs to address the interfaces and interconnections with the broader ecosystem.
Incidentally, that’s another reason why business-centrism can be such a serious danger to the organisation and enterprise. If a business-architecture that assumes that ‘the business of the business is to make money’ is elevated to be the ‘enterprise’-architecture, it will all but guarantee the destruction of the organisation’s relationships with the broader enterprise. Not a good architecture for the architecture itself…
@Anthony Draffin – Hi Anthony, and thanks.
(By the way, your link to Anthony Phillips’s article was missing the URL. I’ve taken the liberty of editing your post to point to what I believe is the article you meant, but please check that I have it right? Many thanks.)
I agree very strongly with your point about visualising the architectures as a Venn-diagram rather than a stack. The only place where I would disagree is that the whole point is that there are overlaps between the domains – because that’s how they communicate with each other.
Thanks for the pointer to Anders Sundelin – very useful.
“[Y]ou seem to imply that business architecture is primarily about defining a business model, however you choose to define the business model” – well, sort-of. What I did say say is that it’s primarily about the architecture of ‘the business of the business’, for which a business-model (dependent on how you define that) is one of the key items. It’s certainly not the only one: for example, you refer to the Business Motivation Model, which is definitely another item in this domain. Business-architecture may well subsume organisational-architecture, to give another example – it depends how you choose to slice up the architectural Venn-diagram, really.
“You then go on to say explicitly that vision, values and strategy are inputs into the business architecture. That last statement gave me pause.” Hmm. Yes, you’re right, it was probably a mistake to phrase it that way – my apologies. It’s not a simple one-way feed: there is – in fact must be – an interaction between the domains here, such that business-architecture and business-models and business-motivation models and the like do feed back into strategy, into organisational strategic-vision, and sometimes even all the way back into broader-enterprise vision and values.
On your question “Where does defining the ‘ends’ in the Business Motivation Model sense lie?”, I think you’ve answered that yourself with your pointer to Anthony Phillips’ post: namely that “strategy means just the means and not the end”. Identifying the far-end of the trail of ‘ends’ is usually beyond of the scope of business-architecture: that’s where enterprise-architecture comes into the picture.
(It’s also why we need a distinct enterprise-architecture, to identify those ends of the broader-enterprise: though note that we identify those ends and their implications for the organisation and its business – we do not define them. That distinction is subtle, but extremely important! If business-architecture is taken to ‘be’ the enterprise-architecture – as occurs in business-centrism – then the organisation’s own assumptions and goals are taken to ‘be’ identical to those of the broader-enterprise: an often lethal exercise in circular-reasoning that is not recommended…)
“Is [defining the ends] another domain architecture separate from business architecture, or is it part of the EA itself and the various domain architectures are about how the “means” (the realisation of the ends) are achieved)?” In essence, yes – or rather, that’s usually the role of ‘the strategy department’, assisted in parallel by enterprise-architecture, as a kind of external-advisor. (To me EA should not attempt to define strategy: that’s not its job. I see it as primarily a decision-support function, not a decision-making function – because otherwise it would purport to override the authority of everyone else, right up to the CEO, which would not be likely to go down well! 🙂 ) EA provides the overall oversight-function; all the domain-architectures -business-architecture and so on – implement the context-specific aspects of the strategy (the ‘means’), though they also feed back into their strategy (real-world impact on the ‘ends’, as in that first diagram in the ‘Who is the customer?’ post referenced above).
“A point of clarification, I disagree with your assertion that strategy is an input into the business architecture, as in my opinion a business model is about defining elements of your strategy. That is, I’m talking about the way you achieve your goals, not defining your strategic goals.” I must admit I’m confused by this: to me you seem to be contradicting yourself within that statement, and the reference to Anthony Phillips’ post only seems to confirm this. Clarification, please?
Many thanks again, anyway.
@Tom, you are perfectly right for rejecting my oversimplified classification of enterprise artefacts as ‘IT-related’ and ‘non-IT-related’. I should be more explicit. My typology of business architecture artefacts is below (it is the last part of http://improving-bpm-systems.blogspot.com/2011/02/explaining-ea-business-architecture.html). Some of those artefacts are actually explicit relationships (or models and even, better, executable models) between others, e.g. processes are relationships between events, rules, roles, services, processes, data, documents, KPIs, etc.
Motivation artefacts:
– desired result, goals, objectives
– course of action, strategy, tactic/projects
Value and profit proposition artefacts:
– values, value-streams, value-chain, value creation, value system
– products or assets (tangible and intangible)
Organisation artefacts:
– organisation structure
– organisational roles
– governance structure
– supplier, peers, customers, regulation bodies, and other partners
– risks (?)
Execution (or operations) artefacts:
– processes
– services
– events
– functional roles
Knowledge/information artefacts:
– terms, facts (as codified knowledge), data, documents, rules, policies, analytic procedures
Performance artefacts:
– capabilities
– audit trails
– KPIs
By linking all of these artefacts via executable models will allow some validation of business architecture (something similar to validation that a plane will have proper engines to carry a required load to a required distance). Does it make sense?
Thanks,
AS
Tom
Interesting conversation here, but isn’t the root of the problem the fact that there’s a language mismatch between the domains of EA and general business discourse?
In the world of general business discourse, the term Business Model has a very specific meaning, as Chris has stated on Twitter (and also as used by Thomas Lawton in his Breakout Strategy talk at this year’s EAC). It means the way that the business actually generates value for the customer and revenue for the business and does have very little to do with IT (unless that’s part of the product/service)
In the world of EA, business model generally means any of a possible selection of representations of an aspect of the business (including operating models and links to information requirements) in order to be able to either understand it better, or decide how and what to change. So when we are talking to general business people we need to make it very clear which sort of business model we are talking about. Perhaps a convention of using capitalisation for the business strategist’s view of the Business Model could be useful.
The Business Model Canvas bridges these two worlds, as you have skilfully demonstrated with your work on it.
After pressing the submit button, I’d like to retract my comment about IT information and technology do of course allow the ability to generate new and interesting business models.
I’m clearly not having a very good day today. I should of course have said “new and interesting Business Models”.
@Sally Bean
Hi Sally,
Tom’s work bridges the worlds. I’m not sure if the business model canvas bridges the world. The BMC is used to help determine and document multiple business models a company can adopt. It’s not just ONE business model and the BMC doesn’t deal with the organization responsibilities within the ecosystem or how it really ties with IT-arch (oh my, am I allowed to even use the IT-arch term LOL)
… warning, i wrote this before coffee so I may have misunderstood.
@Pat Ferdinandi
Pat,
Fair point about the BMC. I guess what I meant is that it’s a way of representing business models in a structured and consistent format, making it easier to derive the organisational responsibilities and IT needs from a Business Model than it was before.
I’m confused as to why everything that comes out of IT – and no matter how you rephrase it, enterprise architect did come out of IT- has to be so complicated.
Penguins do a better job of differentiating themselves. I think you all have to go back to the drawing board and start over on this one.
@Sally Bean
agreed. (especially since I’ve had my coffee LOL)
@Loraine Lawson Best comment I’ve read on enterprise/business/digital architecture in years!
Taking architecture too seriously is a wicked problem in itself. Long live the Doodle Revolution: http://sunnibrown.com/doodlerevolution/manifesto/
@AS Alexander – apologies that it’s taken me so long to get back to you, and yes, that list makes perfect sense.
To me the important point is that you’ve described all of these artefacts at the appropriate level: it’s the business level, not the process-design layer or the implementation-layer. It also doesn’t actually deal with integration of all of the layers, but just the ‘business’ view of how everything works. That’s also what makes it business-architecture rather than enterprise-architecture.
@Sally Bean, @Pat Ferdinandi – Sally, yes, agreed, the definition that Chris quotes may be one that is (or has been) in common in business, but it actually doesn’t tell us anything that we can use. It’s only slightly more usable than the kind of ‘motherhood-and-apple-pie’ platitudes that people used to say about quality and the like. Fine in itself, ‘a worthy aim’ and so on, but the point of architecture – as you and Chris and others have said – is to provide a bridge between strategy and implementation, yet that type of description of ‘business-model’ doesn’t even get us to the ‘strategy’ starting-gate…
Which is where Business Model Canvas and the like come into the picture, because they do give us enough detail to get started on the architecture. It’s not so much ‘bridging the two worlds’, as that the one-line version is even a description of a ‘world’. That’s really my point here, I think?
Pat – yes (and thank you, of course!), my own work is about ‘bridging the worlds’. What I’ve been concerned with – as would be clear in the posts that follow this one – is about not merely bridging two ‘worlds’ in the business context, but every ‘world’ that touches that context. That’s what makes it enterprise-architecture rather than business-architecture. Or IT-architecture, of course. 🙂
@Loraine Lawson, @Peter Bakker – Lorraine, yes, will have to agree with Peter there: brilliant riposte!
Peter, I do take your point about being over-serious. Yet I’m reminded here of the Buddhist concept of non-attachment. Non-attachment is not the same as detachment: in effect, detachment is simply another form of attachment, an attachment to the absence of attachment, an attachment to negation itself. Ultimately non-attachment is also non-detachment. In the architecture sense, being under-serious is at least as much of a problem as being over-serious. Or, to paraphrase Einstein, everything should be un-serious, but not more un-serious than necessary?