On the business of the business

What is business? For that matter, what is – or is not – ‘a business’?

Seems a kinda important question for business-architecture, doesn’t it? And yet no-one seems to ask it…

So let’s just do some proper enterprise-architecture thinking around this one – otherwise we’ll get the architecture into a right old mess. Again…

The usual answers I hear seem to revolve around an assumption that an organisation can only be called ‘a business’ if its focus is ‘making money’ – in other words some sort of commercial business. Yet in which case, what do we call other types of organisations? – ‘non-businesses’, perhaps? If so, why does almost every government organisation, or school, or charity, or even the local bowling-club, have people whose job-title is some variant of ‘business-manager’? And if only commercial organisations can be called ‘businesses’, what do we call the equivalent of business-architecture in those many organisations that, according that definition, aren’t ‘businesses’?

What I’d suggest, very strongly, is that this separation of ‘business’ versus ‘non-business’ is as artificial as the separation between ‘for-profit’ and ‘not-for-profit’ – and just as misleading, too.

The simple way out of this one is to recognise that ‘business’ literally means ‘busy-ness’ – the state or condition of ‘being busy’. In which case, every organisation must, by definition, be ‘a business’, because the whole point of an organisation is that it provides a context to coordinate people’s ‘busy-ness’ towards some shared aim. Every organisation has its business; every organisation is ‘a business’.

Hence in every organisation, the business of the business is whatever the business of that organisation happens to be – whether it’s focussed on monetary profit, or not. If it’s about ‘busyness’, it’s business.

Which means, in turn, that every organisation has its own business-architecture – whatever type of organisation it may be.

Business-architecture is the architecture of the business of the business – whatever that organisation and its business might be.

More practically, the part of the organisation that’s usually called ‘the business’ tends to focus more on the why and how of the business – rather than the who and when and where and with-what that tends to be more the focus of everyday operations. It tends to be about things like business-models, business-strategy, financials, forecasts, performance, monitoring, all the bigger-picture stuff. Hence, in turn, that’s where business-architecture would usually place most of its attention.

And hence, for practical reasons – typically because of the need for specific skills and suchlike – business-architecture will tend to be a domain-architecture focussed on that specific subsection of the organisation’s activity, rather than the unifying architecture-of-the-organisation-as-a-whole.

Which is why, for practical reasons, there usually needs to be a distinction between business-architecture – the architecture of the business of the business – and enterprise-architecture – the unifying architecture of the overall organisation and its relationship with its broader business-context, linking all of the architecture-domains together. There’s also the distinction that business-architecture tends to look inside-in or inside-out, whereas a true ‘architecture of the enterprise’ also needs to look outside-in and even outside-out.

So, in summary:

  • every organisation is also ‘a business’
  • the business of an organisation is whatever the organisation does, for whatever business-reasons and business-drivers
  • every organisation has a business-architecture that describes the structure and story of ‘the business of the business’
  • enterprise-architecture – as ‘the architecture of the enterprise’ – usually has a broader scope than business-architecture – as ‘the architecture of the business of the business’

I hope that makes things a bit simpler to work with?

22 Comments on “On the business of the business

  1. You and I often confront the same questions and come to similar conclusions. On this one, though, we differ significantly. I gave a talk last November to the Minneapolis chapter of the Association of Enterprise Architects titled “What is Business such that it can have an Architecture?”. I’d be happy to share it with anyone who’d like a copy.

    I don’t want to try to reproduce the whole argument here in a comment. Boiled down to its essentials though, adopting the interpretation of business that you propose here has two adverse consequences — first, we can no longer use the word that the rest of the world understands, and routinely uses, to mean commercial activity or commercial organization, to mean those things in the context of enterprise architecture. Second, there would then be no useful distinction between business architecture and enterprise architecture — for what else is enterprise architecture about if not the business-as-primary-concern (what iy call “the business of the business” of an enterprise?

    You try to make a distinction that I simply do not get:

    “every organisation has a business-architecture that describes the structure and story of ‘the business of the business’”

    “enterprise-architecture – as ‘the architecture of the enterprise’ – usually has a broader scope than business-architecture – as ‘the architecture of the business of the business’”

    I fail to see the difference. How does “architecture” differ from “structure and story”? What goes in the “architecture” that does not go in the “structure and story”, and vice versa?

    The problem is that “business” as commonly used has three meanings, each of which is useful. I call these three meanings “business-as-commerce”, “business-as-commercial-organization”, and “business-as-primary-concern”. Picking one of them and saying we must always and only interpret “business” in the context of enterprise architecture in this one way is not going to work. Theoretically it would make things simpler, but as the old saw goes, “the thing about theory and practice is that in theory they’re consistent, but in practice they’re not”.

    len.

    • Len – many thanks, ‘cos there are some really important points here.

      @Len: “The problem is that “business” as commonly used has three meanings, each of which is useful. I call these three meanings “business-as-commerce”, “business-as-commercial-organization”, and “business-as-primary-concern”.”

      Those distinctions are really important – not least because, as you warn elsewhere, these tend to get conflated, with very unfortunate consequences for both business-architecture and enterprise-architecture. The most common result of that conflation is the problem I described above: that only commercial-organizations do ‘business’, and that therefore all other types of work either don’t count (as business) or don’t matter (because there’s no monetary-profit in it) or even that they don’t and/or shouldn’t exist (which is just plain stupid). The only way out of that mess is for both enterprise-architects and business-architects is to stick strictly to the ‘busy-ness’ sense – a focus on the activities and drivers behind ‘the busy-ness of the organisation’. Your ‘business-as-primary-concern’ is close, but usually places too much emphasis on themes such as the profit-motive (i.e. ‘primary-concern’) rather than the broader interactions and interdependencies that enable it to happen (i.e. ‘busy-ness’). We also need to view ‘business-as-commerce’ simply as a subset of all of that that has a commercial/monetary-profit focus (‘concern’ and ‘busy-ness’ as for-profit), and ‘business-as-commercial-organization’ as a subset of organization (i.e. structure-for-purpose, not activity).

      @Len: “You try to make a distinction which I simply do not get” (etc)

      I think there are two things that are going on here, one of which is definitely my fault: the bit about ‘structure and story’. To clarify, every architecture is about the intersection of ‘structure and story’ in the respect domain and/or context: there’s no difference between enterprise-architecture and business-architecture there, other than in detail and scope. Apologies for my inclarity on that one.

      The other point is that I’m fairly certain you’re conflating ‘business’ and ‘enterprise’: it is essential – and, I reiterate, essential – to draw explicit distinctions between them. (You can use alternative terms if you prefer, but the distinction must be made.) The reason why we must make that distinction is that if we don’t, we fall straight back into the old TOGAF trap of treating a single domain as the sole centre of the overall architecture, but this time with business-architecture rather than IT-infrastructure architecture as that arbitrary ‘sole centre’.

      This is actually an extension of the same conflation you’ve noted above, between ‘business-as-commerce’, ‘business-as-commercial-organization’ and ‘business-as-primary-concern’ (and also as conflated with ‘busy-ness’). Etymologically, the two words ‘business’ and ‘enterprise’ are not synonyms, but are fundamentally different: ‘business’ is literally ‘busyness’, about (possibly)-directed and/or (possibly)-intentional activity, whereas ‘enterprise’ is about emotion, ‘the animal spirits of the entrepreneur’, about the drivers for ‘busy-ness’.

      If we treat ‘business’ and ‘enterprise’ as synonyms – which unfortunately most people still seem to do – we end up automatically in a double term-hijack, in which the ‘big-picture’ enterprise (‘outside-out’) is subsumed into the self-centric desires and needs of the organization (inside-out’), and that the only possibly reason for any activity (enterprise) is ‘making-money’ (‘business-as-commerce’). There’s then a strong tendency for the architecture to become almost exclusively self-centred (‘inside-in’) and for ‘the business’ to treat all others ‘outside’ the organization itself as either objects or subjects of the organization (a literal ‘ignore-ance’ of the mutual-relationships‘ implied and required by ‘outside-in’ via links through ‘outside-out’). The result is a business-architecture that really doesn’t work, and a blurry notion that business-architecture and enterprise-architecture are the same thing. (TOGAF’s persistent mis-handling of ‘business-architecture’ really hasn’t helped in this, I’d have to add – first absurdly IT-centric, then absurdly pseudo-business-centric. Bah… 🙁 )

      The way out of this mess is to treat business-architecture as a domain-architecture – the architecture of ‘the-business-of-the-business’ (primarily ‘inside-out’ perspective, compared to the ‘inside-in’ perspective of TOGAF 8’s focus on IT-rationalisation and the like) – whereas enterprise-architecture is the whole-of-context architecture – working on the integration of inside-in, inside-out, outside-in and outside-out, working with a scope that is necessarily broader than that of the organization alone. (Hence why I say that enterprise-architecture develops an architecture for an organization but about an enterprise – again, they’re not the same scopes.)

      To me perhaps the archetypal business-architecture artefact is Business Model Canvas: it summarises ‘the world’ as seen from ‘the business’s perspective. As per my previous post, it tends to view ‘value-proposition’ in self-centric terms, “stuff we can sell” rather than “that which supports the broader shared-enterprise”, and its perspective is almost exclusively ‘inside-out’: it doesn’t (much) describe customer-journey or anything ‘outside-in’, it barely acknowledges even the existence of ‘outside-out’ (beyond ‘the market’, for example), and it doesn’t go down into the detail-levels where we need a solid ‘inside-in’. All of which is fine for a domain-specific business-architecture – but is not enough for a whole-of-context enterprise-architecture. That’s the distinction I’ve been trying to make.

  2. A confusin typo got by me:

    In “(what iy call “the business of the business” of an enterprise?”

    “iy” should be “you”

    And there’s a missing right parenthesis, so this should read:

    (what you call “the business of the business”) of an enterprise?

    Apologies,

    len.

    • My commiserations, Len, and no apology needed (not for me, anyway). (And I can hardly complain, ‘cos my writing here is all too often litered with typos and worse… my apologies to all on that… 🙁 )

      Typos are a fact of the writer’s life, I guess? – do what we can to keep them at bay, but keep it just to that. Same with enterprise-architectures, of course? 🙂

  3. In the world of mapmaking the purpose of the map defines the scale: “Map scale will be determined by your goals for your map. Map scale affects how much of the earth, and how much detail, can be shown on a map.” (quote from Making Maps, Second Edition: A Visual Guide to Map Design for GIS).

    I think the same applies to architecture, the purpose of the architecture defines the scale, not ambiguous terms like enterprise, business, organisation, infrastructure, system of systems, system or whatever.

    • @Peter: “I think the same applies to architecture, the purpose of the architecture defines the scale, not ambiguous terms like enterprise, business, organisation, infrastructure, system of systems, system or whatever.”

      Point taken, though when we do use such terms, surely they should be unambiguous, at least amongst ourselves, in the same way that units and suchlike for map-scales are unambiguous? That’s really my aim here – much as I’ve done with other terms such as service, process, capability, function, asset and suchlike.

  4. Peter writes:

    “In the world of mapmaking the purpose of the map defines the scale”

    I’m not sure if this in response to Tom or to me, but I take this as a statement supporting context sensitivity rather than “one size fits all”.

    I’m also not sure what the enterprise architecture equivalent of map scale is; whatever it might be, I’m having a hard time imagining how it is any less “ambiguous” than the language we use to talk about EA.

    My position is that the use of such language is unavoidable, and that we must therefore adopt a common vocabulary that we use consistently. Tom’s proposal for a single interpretation of “business” (what I call “business-as-primary-concern”) seems to me to be an example of the “one size fits all” approach, and to make more trouble than it mitigates. I’m arguing that business-as-primary-concern is only one of three useful interpretations of “business”, and that it’s not the right one for defining business architecture. I’m curious as to what the map-scale-analog is that you would use to define business architecture.

    I’m always surprised by the readiness within the EA community to minimize the significance of the language we use to talk about the discipline. This seems to be unique to our profession.

    len.

    • Hi Len,

      My reply was a general reply and it was certainly not my intention to “minimize the significance of the language we use to talk about the discipline”. I was just thinking aloud that we should follow a different route to reach some agreement on how we should name or label different kind of architectures.

      I think that it is better to discuss the differences in the purposes of architectures and how those difference affect the levels of detail(the scale). That should enable us to label (and show examples of) different kind of architectures.

      And maybe the outcome will be that we will see Enterprise Architecture as an Atlas Maior (http://en.wikipedia.org/wiki/Atlas_Maior) which binds all different architectures that are relevant for an enterprise.

      • Peter – nice reference to Atlas Maior! 🙂

        In that sense, I would think of business-architecture as description of a country, or even a city, whereas – as you say – enterprise-architecture is not so much a single map as the cross-referenced container for context-specific maps. In other words, an atlas.

    • @Len: “Tom’s proposal for a single interpretation of “business” (what I call “business-as-primary-concern”) seems to me to be an example of the “one size fits all” approach, and to make more trouble than it mitigates.”

      I take your point about ‘one-size-fits-all’, but that’s not actually what I’m doing, and I think you may have taken me to be saying something that I’m not. (See my replies to your earlier comments on this, because some that would also apply here.)

      There is a need for precision in language, especially amongst ourselves. To give another all-too-common example, business-folk can perhaps be casual and careless in the way that they use ‘business-process’ versus ‘business-function’ versus ‘business-capability’ as different-level synonyms for each other, but we can’t get away with that kind of carelessness – not if we want our architecture to work. The only ‘one-size-fits-all’ bit is that I’m trying to clarify what exactly the word ‘business’ in the term ‘business-architecture’ actually means – because if we’re careless about it, we fall straight back into the TOGAF-style trap of treating some single sub-domain as the sole centre of ‘enterprise’-architecture.

      @Len: “I’m always surprised by the readiness within the EA community to minimize the significance of the language we use to talk about the discipline. This seems to be unique to our profession.”

      I don’t think it is “unique to our profession”, it’s just that enterprise-architecture is still a very young discipline and is, in consequence, often severely lacking in discipline. What worries me is that – to me, at least – your complaint here is actually defending and reinforcing that tendency, by allowing architects to be continue to be casual in the ways in which they blur and conflate fundamentally different terms and concepts. I strongly agree that we share very similar overall aims and concerns, and I’m really grateful for that: yet to me you seem to be going direct against your own aims here, which just does not make sense. I’m not sure we can sort this out in the comment-columns of a blog-post, but it certainly seems like something we could (and should?) discuss next time you’re out London way?

      And throughout all of this, thanks very much for taking me seriously enough to challenge me on this – I really do appreciate it.

  5. Peter replies to me:

    “And maybe the outcome will be that we will see Enterprise Architecture as an Atlas Maior which binds all different architectures that are relevant for an enterprise.”

    Yes, absolutely; this requires the community to be more openminded about what enterprise architecture broadly includes, rather than focus on one specific concern. Elsewhere I have described this, referencing the folktale about the six blind men and the elephant, as recognizing what the “elephant” of enterprise architecture is.

    Tom is in fact trying to do this, but I disagree with him that his proposed definition of “business” is the right way to do so.

    len.

    • @Len: “Tom is in fact trying to do this, but I disagree with him that his proposed definition of “business” is the right way to do so.”

      Yes, that is indeed what I’m trying to do – and I hope I’ve clarified more about why that particular insistence about the sub-term ‘business’ in ‘business-architecture’, enough to at least reduce your disagreement there?

      Once again, to both of you, many thanks!

  6. Tom admonishes me:

    “The other point is that I’m fairly certain you’re conflating ‘business’ and ‘enterprise’: it is essential – and, I reiterate, essential – to draw explicit distinctions between them. (You can use alternative terms if you prefer, but the distinction must be made.)”

    Wow — make my head explode.

    If you’ll pardon the expression, NFW.

    Go reread my 3 part blog post “Different Words mean Different Things” where I very clearly and very emphatically distinguish between “enterprise” and all three of the conventional interpretations of “business”.

    More on the rest of your reply later.

    len.

    • Okay, Len, the ‘NFW’ rebuke is duly accepted. 😐 🙂 And, and, and…

      I’ve re-read Part 3, and yes, I really like and appreciate that the last view of ‘enterprise’ that you present is “the idea of enterprise as human endeavor will emphasize the role of people, and be built around the sociology and psychology of individuals, groups and organizations, especially leadership and management as means to achieving organizational goals”.

      On the point about “emphasize the role of people” and “built around the psychology and sociology” as much as around tech and suchlike, yes, there we definitely agree.

      On that there needs to be clear distinction between ‘business’ and ‘enterprise’, we also definitely agree.

      Where we don’t seem to agree at present is in the overall focus and what ultimately we need to understand ‘an enterprise’ to be. Where I’m saying the conflation still occurs – and I’ll admit that I phrased it badly above, because it’s much more a conflation of ‘organization’ and ‘enterprise’ – is around EA “as means to achieving organizational goals”. That part of the role of EA, I’d obviously agree with: after all, ‘the organization’ is the one that’s commissioned us to do that work, so it should be their goals that we emphasise and most aim to satisfy in the end. But the point I’m on about is that there’s a ‘something’ – which is what I call ‘the enterprise’, and that others call ‘the extended-enterprise’ or ‘the ecosystem’ or ‘the story’ – that is necessarily than ‘the-organization-as-enterprise’ – and it’s that that still seems to be missing from your Open Group blog-descriptions.

      Consider the IEEE-1471 definition of ‘enterprise’: it talks about the possibility of an enterprise as a consortium and suchlike – in other words, somewhat beyond the boundary-of-control of this organisation – yet in effect in still just an organisation on a larger scale, an ‘inside-out’ view of the overall context, with ‘external’ customers and/or suppliers. What I’m talking about is the whole context – not just ‘inside-in’ (as per IT-specific TOGAF-8) or ‘inside-out’ (as per the ‘business-architecture’ views of TOGAF-9) but also ‘outside-in’ (customer-journey and suchlike) and ‘outside-out’ (the overall extended-enterprise or ecosystem or whatever’s view of itself). To put it at its simplest, we won’t be able to either support or achieve the organisation’s goals without a solid understanding of the goals and drivers of the broader and, often, much-broader context within which the organisation operates.

      That last definition of ‘enterprise’ that you gave does include that essential human component, yes; but it doesn’t seem to include any reference to this broader space. In my own work, as you know, I typically include three further layers of ‘enterprise’ beyond ‘the-organisation-in-scope’: first the immediate transaction-oriented supply-chain or value-web; then the broader market, which includes competitors, analysts, regulators and suchlike who may not transact but do have direct influence or impact on the feasibility of achieving the organisation’s goals; and then the extended-enterprise or ‘story’ or broader milieu that is impacted by the organisation and its goals, and can in turn have impact on the organisation, though often via more indirect means – and such means often having far greater impact on the organisation in the days of distributed social-media.

      If our models don’t have a grasp of this whole space – and the perhaps-subtle yet utterly-crucial distinctions that apply between these sort-of-layers – then we’re actually putting our organisations at risk. This is especially true if we conflate all of those layers of ‘enterprise’ together, and/or dismiss or ignore as ‘irrelevant’ the interactions and drivers and impacts of the ‘outer’ layers of broader-market and extended-enterprise. Yet, in essence, that’s what your definition of ‘enterprise’ does: it kind of subsumes everything into an organisation-centric ‘inside-out’ view. It’s that that I’m critiquing here: unlike many others in the present ‘mainstream’ of EA, I’m not complaining that your distinctions go too far (such as by dethroning IT as ‘the sole centre of everything’), but that in my view they still don’t yet go far enough.

      Again, overall, we do know that we’re both pushing in the same general direction for ‘real-EA’; there’s a heck of a lot that we do agree on around that. The distinctions I’m pushing here are – I’ll freely admit – quite subtle-seeming at first, and I’m also well aware that they don’t make any sense at all for many EA-folks. Yet I’m also adamant that they’re absolutely essential for the overall EA-discipline – though I don’t we’ve quite come to agreement on that point yet?

      At least with you I know I can talk about these often abstruse-seeming themes – and I really do appreciate that you take me seriously on this, hence many thanks indeed! 🙂 So let’s keep talking, yes?

      Again, many thanks.

  7. Sigh.

    You write:

    “Where I’m saying the conflation still occurs – and I’ll admit that I phrased it badly above, because it’s much more a conflation of ‘organization’ and ‘enterprise’ – is around EA “as means to achieving organizational goals”.”

    But that’s not what I said. I didn’t say EA is a “means to achieving organizational goals”, I said that “leadership and management as means to achieving organizational goals” are things that enterprise architects ought to be aware of. There are a lot of things that are, strictly speaking, not part of the discipline of enterprise architecture as such, but that are necessary adjuncts to the practrice of EA.

    It’s quite likely that you do not agree with the concept of enterprise I articulate in my blog, and I’m OK with that. I said very early on in part one that I expected such disagreement.

    You write:

    “But the point I’m on about is that there’s a ‘something’ – which is what I call ‘the enterprise’, and that others call ‘the extended-enterprise’ or ‘the ecosystem’ or ‘the story’ – that is necessarily than ‘the-organization-as-enterprise’ – and it’s that that still seems to be missing from your Open Group blog-descriptions.”

    I think there’s something missing in the sequence “that is necessarily than”, but I suspect the missing word is “bigger” or something like that.

    Be that as it may, I do not accept, and cetainly did not articulate, the concept of ‘the-organization-as-enterprise’. My blog post very clearly distinguishes organization from enterprise and states that an organization is a means of realizing an enterprise. This does not make them the same thing. An orchestra realizes a symphony by performing it. We don’t have a concept of “orchestra-as-symphony”, because doing so confuses (conflates) two things that are quite distinct.

    I am not missing the idea of “something bigger than” your “organization-as-enterprise”. I don’t need it, and quite deliberately omitted it; indeed, I quite deliberately avoided it. The concepts of enterprise and organization in my blog post accomodate what you seem to think I have overlooked. They are recursive concepts. An organization can comprise many smaller organizations. An enterprise can comprise many smaller enterprises. And the mapping between these “component” enterprises and organizations need not be one to one.

    You continue:

    “Yet, in essence, that’s what your definition of ‘enterprise’ does: it kind of subsumes everything into an organisation-centric ‘inside-out’ view.”

    All I can say is “no, No, NO!” That’s not what my model implies. There is no reference to “organization” in my definiton of enterprise. You are asserting connections that are not there. I don’t know why you find it necessary to do this — what I wrote does not say anything that implies, never mind requires, your interpretation. The only connection I made between enterprise and organization was that an organization is typically the means by which an enterprise is realized. This statement, which you are certainly free to disagree with, nonetheless implies nothing about the identity or conflation of the two concepts.

    You continue:

    “It’s that that I’m critiquing here: unlike many others in the present ‘mainstream’ of EA, I’m not complaining that your distinctions go too far (such as by dethroning IT as ‘the sole centre of everything’), but that in my view they still don’t yet go far enough.”

    If you think that, it can only be because you are misinterpeting them. Are you sure you’re not still carrying some interpretive baggage from that “mainstream”?

    Please go back and reread part one. If you can cite specific words in my proposed definitions of enterprise and organization that imply or dictate your interpretation, I will gladly rewrite them. I tried very hard to avoid exactly the kind of thinking you are attributing to me.

    Respectfully,

    len.

  8. BTW,

    “Go reread my 3 part blog post “Different Words mean Different Things””, to which you reply “I’ve re-read Part 3”

    does not mean “go reread part 3 of my blog post…”.

    The really important stuff about the distinctions I am making, and why, is in part 1.

    len.

    • Len, I apologise. This one’s gone on so long that I’ve seriously lost the plot about any part of this: what I do get, though, is that you seem to be both frustrated and angry with me about it, and that all I’m doing is making it worse every step of the way.

      You’re someone I deeply respect, both professionally and personally, and I’ve clearly made a complete mess of this, so I need to make amends: yet right now it’s 4am, I’m churning about the whole thing, and, again, it seems I’m digging myself deeper into the mess with every word I write.

      Given that I’ve lost the plot here even on what we’re nominally disagreeing about, would you help me unravel this one, please? And, again, my apologies…

  9. For me the most interesting bit of what Len writes on http://blog.opengroup.org/2012/12/04/different-words-mean-different-things-part-1/ is his definition of an enterprise:

    So, enterprise means “undertaking” or “endeavor,” especially one that is relatively ambitious […] ,the essential properties of an enterprise are people and their activity in pursuit of explicit intent.”

    This makes an enterprise almost identical to this definition of “expedition” taken from The Free Dictionary:

    1a. A journey undertaken by a group of people with a definite objective: an expedition against the enemy stronghold; a scientific expedition to the South Pole.
    1b. The group undertaking such a journey.

    Now it is not hard to see why map-making is so important to enterprise architecture!

  10. Peter observes that the definitions of enterprise and expedition are similar.

    The key difference is the presence of the word “journey” in the definition of expedition, wehre it is expected to be interpreted literally. To whatever extent an enterprise makes a journey, it is metaphorical, though an expedition will almost certainly be an enterprise.

    Peter’s observation may have been whimiscal, but this kind of “these words have similar definitions so we can treat them as synonyms and use them interchangeably” is exactly the kind of linguistic imprecision that gets us into trouble when we need to make distinctions that matter.

    len.

    • Hi Len,

      Being Dutch I’m not sure what you mean by “whimsical” in this context so I hope it is not too negative 🙂

      I was only surprised by the resemblance between the parts of your enterprise definition I quoted* and the expedition definition. That resemblance triggered some kind of “aha” moment because it instantly made it clear to me why map-making is important to enterprise architecture.

      I deliberately said “almost identical” instead of “similar” because I don’t have the intention to use them interchangeably, it is just some kind of reasoning by analogy based on the similarity that both definitions as I quote them mention people, undertaking and definite objective/explicit intent. Besides, I don’t think anybody would want to use the phrase “expedition architecture” instead of “enterprise architecture” 🙂

      *The enterprise quote is not complete as I indicated by the usage of […], therefore I provided also the link to your original article where the full definition, which I support, can be found.

      • My apologies Peter. I should not have written “this kind” as if to imply that you were doing the kind of “synonymizing” that my original three part blog post warned about.

        len.

  11. Tom — I’m not angry. Our respect is mutual. I am frustrated, though, because I am almost certain you really do understand the points I’ve been trying to make, and more importantly, agree with them, and our facility (or lack of same) with words is getting in the way of our jointly arriving at that conclusion.

    What I am trying to do is create a well-defined vocabulary that supports a much more broadly inclusive concept of enterprise architecture than the conventional wisdom currently supports, and that also allows us to make distinctions that I believe are necessary to prevent us from wiring unspoken assumptions into these supporting concepts. Doing so requires that we adopt this new vocabulary without bringing along any of those unspoken assumptions. What has been frustrating for me is that you have repeatedly asserted or implied, in one way or another, that I am still carrying that old baggage, when I have very deliberately abandoned it. I see this as as much my failing to be clear as you failing to understand.

    I suggest we take this off line; you know where to reach me.

    len.

Leave a Reply

Your email address will not be published. Required fields are marked *

*