On business-architecture and enterprise-architecture – why this matters

Okay, so I’ve ranted somewhat that placing a supposedly-‘new’ business-architecture ‘above’ enterprise-architecture is a bad idea, and added some further detail on how and why I think it’s a bad idea.

But why does this matter? To anyone, really?

Well, first, it’s that there are some very real dangers in business-centrism. Jumping from IT-centrism to business-centrism is right up there in the upper realms of Definitely Not A Good Idea…

(For more on that, see the section on business-centrism in the post ‘Enterprise-architecture – a status-report‘.)

To get round that mistake, we need always to remember that in a viable architecture, everywhere and nowhere is ‘the centre of the architecture’ – all at the same time.

(See the post ‘RBPEA: The dangers of ‘anything-centrism‘ for more on that.)

Yet the real reason why this matters to everyone – and not just ivory-tower ‘EA-experts’ – goes a little bit deeper.

The real reason is stakeholders.

Who they are.

What they want.

What they’ll do.

What they’ll do to us, if we screw up. (As they perceive it – not us.)

Yeah, those stakeholders…

Ouch.

Does that get your attention now?

In which case, how do you identify your stakeholders?

(And no, that’s not a trivial question, is it?)

If we’re working at a solution-architecture level, this might not sound like a big deal. Who are your stakeholders? Well, there’s the project-sponsor. There’s the more senior people in the internal client. A consultant or two, perhaps. A few middle-managers somewhere; if you’re very unlucky, maybe even someone on the exec. But that’d be about it, usually. Pretty much all of them inside the company, anyway.

But as we move outward towards an enterprise-architecture level, holding onto the same assumptions about stakeholders is, again, Definitely Not A Good Idea…

That’s because the real definition of ‘stakeholder’ isn’t just ‘some business-person who thinks they’re important’.

The real definition is that a stakeholder is anyone who can wield a sharp-pointed stake in our direction.

And if we ever forget that – or if we ever forget just how many stakeholders we really have, out at the enterprise-architecture level – then we’d be heading blithely into a whole new world of pain

Let’s describe this visually.

At the start, we might we sit in the comforting self-centric view that the only stakeholders that matter are those inside our own organisation:

But when we start looking at our transactions, we might realise that, ooh, actually, suppliers and customers are, yeah, kinda stakeholders too, aren’t they? – yeah, they might wield a sharp-pointed stake at us too:

And what about prospects and competitors and regulators and standard-bodies and trainers and recruiters and journalists and other folks like that? – we don’t have transactions with them, sure, but we have interactions with them that can matter a lot. So yeah, right, that’s another whole load of sharp-pointed stakes we have to deal with:

If we think enterprise-architecture is just ‘business-architecture plus the IT-stuff’, that’s probably where we’d stop. But that’d be a mistake – a big mistake – because we need to go a whole lot further…

For a start, there’s the shareholders, aren’t there? – the ‘owners’? They kinda connect in a more indirect way, through a different set of channels, but we definitely better not forget about them as stakeholders:

Yet if we can break free of ‘The world’s dumbest idea‘, and recognise that there’s a lot more to business than just the money, we can then see that shareholders and suchlike are just one special-case amongst a whole myriad of other forms of investment in the enterprise as a whole, as a shared-story.

That’s when we start a more systematic exploration of our business-context – and begin to grasp just how many types of stakeholders we really have:

And, yeah, every single one of them has their own sharp-pointed stake held in hand.

Which they can – and will – wield in our direction if we get it wrong

See why this matters now, yes?

See now why business-centrism in enterprise-architecture might perhaps be Not A Good Idea?

You Have Been Warned…

13 Comments on “On business-architecture and enterprise-architecture – why this matters

  1. Picking back up here on my comment on the post before last (http://weblog.tetradian.com/2017/07/03/on-ba-and-ea/#comment-8545):

    I think you’re answering my question. Essentially, I’m wondering about the building blocks of a true EA vs. EITA.

    BDAT works well for EITA: business concerns (ideally) dictate applications (services) that generate and use data and are also steered (again, ideally) by that data; all of which runs on technology. The rubs are an improper focus on tech (as you’ve mentioned), and that, even in an organization with a high-level of digitization, there’s not 100% concordance with these pieces and the actual enterprise. It’s more like a Venn diagram with two circles rather than one – there’s intersection, but the fact that there are two circles rather than one should give pause to anyone thinking the “traditional” EA models the actual architecture of the enterprise.

    It seems like an analogous stack for the architecture of the enterprise would be something like EMO, or perhaps EMOI (ecosystem/enterprise, market, organization, & information), which your last diagram mostly covers. The only thing “missing” (at least in terms of being explicitly called out) is information.

    • Thanks, Gene (and yes, apologies for being so far behind in replying…)

      On “the building blocks of a true EA vs. EITA”, in some ways they’re actually the same – either abstract-capabilities or abstract-services. (For building-blocks I prefer capabilities, because it’s easier to spot affordances; services are better for as-is or for explicit designs.) The issue is then one of scope, the breadth/coverage of the set of capabilities/services: true-EA covers a wider scope than EITA. That’s really the only difference.

      The catch, of course, is that it’s somewhat fractal: EITA covers much the same physical scope as true-EA, but in a kind of spotty way, addressing only a smaller subset of the overall concerns and needs. So to people who only think in terms of IT, their ‘EA’ looks as though it covers everything – which in reality it doesn’t. Therein lies the trap that so many people still fall into.

      Note that this isn’t about IT as such: you’d describe yourself as an ‘IT-person’, I think? – and yet you don’t fall into that trap. Neither does Ruth Malan, who describes herself as an IT-architect. Neither does Simon Brown, who covers an even narrower set of capabilities/services as a software-architect. The point is that all three of you know that a) IT doesn’t cover everything; b) there’s a lot more to an enterprise than just its IT; and c) the human concerns always come first – that IT is only ever an enabler, not the reason itself. The problem we face is that a lot ‘IT-people’ still get some or any of those points…

      And that’s where stack-type frames such as BDAT give us so much grief – because they create the illusion/delusion that content (the BDAT set) is the same as scope (the total world-elements touched-by / implied-by the BDAT-set). Once people make that conflation, we end up with the mess that TOGAF makes of ‘business-architecture’, where ‘anything not-IT that might affect IT’ is deemed to have exact equivalence to ‘the architecture of the business of the business’. Which, yes, is just plain daft…

      Yet it’s a trap I see you at risk of falling into, right here – and Peter and Len in their comments below. The problem is not the BDAT-stack itself, because that ‘stack’ is just a set of related filters or lenses through which to explore scope. Instead the problem is that of conflating the filters with the scope. And that’s exactly what you risk doing with your EMO/EMOI stack; Peter risks doing with his GBOI stack; with his PSCCV set.

      Hence the whole point of this series is to remind us all that we need to identify the scope first, via the business-question; and only then apply our filters/lenses, with crosschecks for completeness upon the filter-set itself. That makes sense, I hope?

      On “The only thing “missing” (at least in terms of being explicitly called out) is information” – I’d regard that more as ‘content’, which we would assess almost separately, using those EMOI etc checklists as a guide. For example, look at my ‘Services and Enterprise Canvas review’ series, starting at its ‘Introduction‘ – particularly part 5, ‘Service content’.

      • I think it’s sinking in now. The problem is attempting to create a stack where, perhaps, one doesn’t exist. With BDAT in EITA, there is a natural hierarchy with Business needs driving Data architecture and Application architecture, which are dependent on Technology (hardware). Take one of the lower blocks out of the equation and the higher ones suffer. With EA, if I’m (finally) getting your point, there’s no equivalent hierarchy of dependent components.

        “you’d describe yourself as an ‘IT-person’, I think? – and yet you don’t fall into that trap. Neither does Ruth Malan, who describes herself as an IT-architect. Neither does Simon Brown, who covers an even narrower set of capabilities/services as a software-architect.”

        I try and I’m flattered to be sharing the same bucket with Ruth and Simon.

        • Yep. There is no actual hierarchy: the apparent hierarchy ‘exists’ solely because we choose to believe that it exists.

          In essence, it’s just an artifact that becomes ‘visible’ solely from a specific perspective – much like it’s possible to construct an illusion of a Penrose Triangle from a single viewpoint, but it doesn’t work from any other viewpoint.

          The BDAT-stack appears as a ‘meaningful hierarchy’ only from the perspective of IT-infrastructure, and only when you explore IT-infrastructure in context of data, apps and ‘the-business’-as-anything-not-IT-that-might-affect-IT. It doesn’t work meaningfully as a ‘hierarchy’ from any other perspective: it’s actually impossible for it to do so. For example, try using the BDAT-stack to explore the architecture and operation of a data-centre: there’s nowhere in the ‘stack’ to consider very real concerns such as power, cooling, cabling, access, maintenance-processes / maintenance-skills (ITIL etc), weather-proofing, vermin-proofing, physical-security, whatever, that are at the same ‘level’ as IT-infrastructure (because ‘physical’) but invisible because they’re not ‘IT-boxes’.

          There is no hierarchy. Once we get rid of that delusion of ‘hierarchy’, we then have a chance to be able to think, and to see what’s actually going on. But as long as we still stick with that delusion, we’re stuck. That’s the choice we have here.

          (And yes, many people will prefer to stick with the delusion, regardless of the consequences, because it all makes things seem so much ‘simpler’ than they actually are. Oh well, we did try to warn them… 🙁 )

          • This is turning into a theme – I’ve got a post in the “under construction” phase re: simpler to simplistic via over-abstracting until the abstraction and the thing become disconnected and I spent the morning in a great twitter conversation along the same lines!

  2. Gene

    I find that using GBOI works quite well, and can be applied fractally as Tom advocates:

    Governance model
    Business model
    Operating model
    Information model

    I am currently exploring the adequacy of this in an IoT based, disrupted market context for an enterprise to see whether it “stands up” or needs some further refinement and development.

    • Thanks, Peter. Your GBOI set is useful for many types of contexts – no doubt on that. My concern, as I said to Gene above, is that there are some real risks of conflating the content of those lenses with the scope to be covered. That’s why I’m careful to separate scope from lenses: start from the business-question, identify potential scope and stakeholders with that three-layer set (transaction, direct-interaction, indirect-interaction), and only then consider the lens-sets that would be needed in order to assess the needs of the initial business-question.

  3. Back in 2011 I proposed, in a number of talks I was giving at the time, an alternative stack that, while BDAT-like in concept, was neither business nor technology focused. It was BDAT-like in the sense that the layers built on one another — the top layer was implemented using resources provided by lower layers, and so on down to the bottom layer.

    The layers, from the bottom up, were:

    Physical and intangible assets — these are the “givens” of the enterprise. Everything is built up from them.

    Systems (in the most general sense) and services (in the most general sense)

    Collateral flows (this is the stuff that flows between the systems and services, as inputs, outputs and controls)

    Capabilities — the flow of collateral through systems and services makes it possible to “do things”, including creating new assets, and appropriately adapting other layers to changing situations. Peter’s GBOI model would be realized in this layer, if thinking in those terms were appropriate for a given enterprise. Remember, I am thinking of enterprise as any complex, people-intensive undertaking.

    Vision, Mission, Strategy and Goals — the things the enterprise wants to do and the ways it prefers to do them.

    • Thanks, Len. Yes, as I’ve just said to Peter above, sounds useful. (I’m surprised it was as late as 2011 – we would have been talking about this since at least 2007 or 2008, surely? I don’t think you were in the discussion on this at the OG Lisbon 2006 meeting, though – I remember thinking that I was the only person in that small group there who didn’t speak Dutch! 🙂 )

      What I’ve just said to both Gene and Peter also applies: I’m wary about any ‘layer’-type model, for the reason that it makes it all too easy to conflate lenses with scope. And I wonder, too, just how much the ‘layers’ really are literal layers, rather than ‘perceived-relationships-that-we-choose-to-see-as-layers’? – because there are some fairly important implications that arise from the difference between those two. (The classic BDAT-stack, for example, is primarily the latter rather than the former – it’s a choice to see the so-called ‘layering’ that way, rather than a hard-and-fast ‘fact’.)

      Personally, the only layering I’m comfortable with is the extended-Zachman that I use with Enterprise Canvas. And that’s because something distinct and identifiable is added at each layer ‘downward’: Z0 identifies the overall ‘story’; Z1 consists only of lists of (optionally-categorised) items needed for that story; Z2 adds relationships between items in those lists, and overviews of what passes between items across those relationships; Z3 (‘logical layer’) gives us abstract details about how to implement the items and relationships; Z4 (‘physical layer’) gives concrete details about implementations; Z5 gives us exact details for intended deployment, right down to run-time; Z6 gives us a history of what the actual configurations and outcomes were at run-time (which may well be different from the Z5 plan).

      Beyond that, most would-be ‘layering’ to me seems to be a confused conflation of layering as per above, together with clunky labelling of decomposition and suchlike, and a whole load of other casual imprecisions and carelessnesses with ontology, taxonomy and the rest. The three of you here (you, Peter and Gene) are a lot more careful than most in the field seem to be, and yet I’m still seeing the risks that you maybe haven’t done enough to counter against those kinds of conflations (especially when others are let loose on your layer-models…). And the same could be said of me, of course (though in my defence I do try darned hard to make my frameworks as bullet-proof as possible).

      So how could we do this better? If we’re going to use layered-models or sort-of-layered lens-sets, what can we do to prevent them creating the kind of chaos that the BDAT-stack has done, when others try to use them without the decades of experience that you/we each bring to the story?

  4. >I’m still seeing the risks that you maybe haven’t done enough to counter against those kinds of conflations

    I can’t speak for Peter or Gene, but for me there’s so much “warning” (i.e., “beware of thoughtless misuse”) context that applies in this space that I think it’s unrealistic to try to “user-proof” ideas, by explicitly reiterating every aspect of that context in every situation where it might apply. I have railed repeatedly about the fact that models are deliberate oversimplifications of complex realities, and that they have inherent limits of applicability. There is a bounded set of things for which they are useful approximations, and a much larger set (the universe less that set) for which they are not. Being a competent practitioner entails understanding that difference operationally. Assume an implicit “for professional use only” in everything I offer for consideration.

    Regarding the particular model I offered above, it was depicted as a layered model solely to make it easier for the BDAT dogmatists to imagine an alternative. I actually think of the model as a network, not as a set of layers, where each “layer” is connected to every other layer, and have in fact depicted it as a mesh, where it is one possible (not the only) way to organize the warp and weft of the mesh

    len.

    • Thanks, Len. I think the key phrase here is “I actually think of the model as a network, not as a set of layers, where each “layer” is connected to every other layer” – that’s really important, and needs to be emphasised at every possibly opportunity. The moment someone thinks it’s solely a stack, it risks breakdown, for exactly the same reasons as for the BDAT-‘stack’. (In fact the same applies to BDAT: if we reframe it as a mesh, it stands a much better chance of being more usefully robust.)

      • The other thing that I believe is “risky” is the dogmatic belief that there is one “best” model that is “universal” in applicability, and that adoption of this model means we need no longer consider other ways of thinking about the problem, especially ways that are particularly well suited to a particular problem. I find it ironic that a community that often thinks of itself as generalists is so wedded to “one true way” thinking about its own methods.

        len.

Leave a Reply to Len Fehskens Cancel reply

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

*