Dump the BDAT-stack!

For a viable enterprise-architecture [EA], now and into the future, we need frameworks, methods and tools that can support the EA discipline’s needs.

Yet there’s one element common to most of the current mainstream EA-frameworks and notations – such as TOGAF and Archimate – that actively blocks our way forward: the predefined, hardwired ‘stack’ of architecture-views that the respective framework acknowledges and supports.

There are a few variants, but the most common form is the ‘BDAT-stack‘ of Business-Architecture, Data-Architecture, Applications-Architecture, IT-Infrastructure (‘Technology’) Architecture:


It looks good, it’s clear, it’s simple, it’s easy to understand – and yet for most purposes it’s just plain wrong. The blunt fact is that any framework or notation that relies on the BDAT-stack is fundamentally unfit for almost any purpose in present-day enterprise-architecture.

What it was originally designed to do, and for which it was fit-for-purpose, was the architectures of large-scale IT-infrastructures. If all that you’re working on is technology-infrastructures for classic in-house ‘big-IT’ in industries such as finance, insurance, banking and tax, the BDAT-stack will do that job just fine. Yet that decreasingly-common need is all it’s fit for – and despite many claims to the contrary, it’s never actually been fit-for-purpose for anything else.

If we do try to use the BDAT-stack as if it’s fit-for-purpose for anything more than IT-infrastructure, it will always lead us astray – risking serious damage to the architecture, and worse.

But why? Where’s the problem? Doesn’t the BDAT-stack cover everything we need – Business, Data, Applications, Technology?

No, it doesn’t – though it’s true that many people in the EA field would still misinterpret it that way. But the blunt reality is that the BDAT-stack only makes sense as a descriptor for the context for IT-infrastructure – and should not be used for anything else.

The catch that most people still seem to miss is that the BDAT-type of frame is only a base-relative descriptor of scope – not of overall scope. In other words, it’s a context-descriptor frame that’s valid only for the domain at the base of the stack – which, in the case of the BDAT-stack, is that subset of technology that specific to IT-infrastructure:

  • ‘IT-infrastructure architecture’ is the actual focus for all architecture-effort
  • ‘Data-architecture’ is the architecture of the subset of data maintained on that IT-infrastructure
  • ‘Applications-architecture’ is the architecture of applications that are run on that IT-infrastructure
  • ‘Business-architecture’ is ‘anything not-IT that might affect anything-IT’ relative to that IT-infrastructure

The stack-structure only makes sense that way round – everything base-relative, looking ‘upward’ from the base.

We can’t run the stack ‘backwards’, or ‘downwards’: doing so puts artificial constraints on the scope – which is why TOGAF and its ilk so inherently and so automatically force us towards IT-centrism in every aspect of the architecture.

We can’t use the BDAT-stack to describe contexts for data-architecture, applications-architecture or business-architecture in their own right – to do it properly, each would need their own equivalent ‘stack’, placing that respective focus-area as the base of the ‘stack’.

The crucial point here, perhaps, is that the BDAT-stack is nothing special – it’s merely one instance of a generic architecture pattern, looking ‘upwards’ or ‘outwards’ from a chosen focus-area:

Hence for the business-architecture of an organisation, for example, we should not use the BDAT-stack, but another stack in which the organisation is the base of the stack:

When we look ‘downward’ from the service-in-focus, we need to be able to drill down into any or all of the services that support that service:

And a service may be implemented by any appropriate combination of people, machines and IT: for example, IT-infrastructure is supported by a vast swathe of other detail-layer services – such as described in ITIL, the IT service-management library – which explicitly include services provided by only by people, not other IT. Our architecture would be inherently incomplete if we were to constrain the description to IT alone.

For example, to describe a business-architecture, we’re likely to need to be able to see and describe any or all of the underlying services – whether or not they’re supported on in-house IT-infrastructure:

…whereas if we try to use the BDAT approach, it would only allow us to see or describe the subset of services that are built upon the respective IT-infrastructure:

The latter probably wouldn’t even be able to include cloud-based services or customer-maintained IT – let alone human support-services or non-IT technologies. For a data-centre, for example, we can use BDAT to describe the computers, but not the building they’re in, or why the building is where it is; we could describe the network cabling, but not the power-cabling or the cooling-systems. What kind of architecture is that?

A stack-type description is useful – no question. But we need to start with an understanding of how stack-type frames actually work: they’re always base-relative. What we need is not the single BDAT-stack, but a strong understanding of the pattern of which the BDAT-stack is merely one instance. The classic BDAT stack describes only the ‘upward’ view from its selected focus-domain, whereas what we need is the generic ‘Jellyfish pattern‘ that gives us the ability to describe properly both the context ‘upward’ and the supporting-services ‘below’:

Hence, for business-architecture, what we need as a context-descriptor that is not merely the top layer of the BDAT-stack, but something that looks more like this:

The key takeaway here is that the BDAT-stack will not suffice for any form of enterprise-architecture other than for the single very narrow, very specific domain of in-house IT-infrastructure – and we need to stop pretending otherwise.

In short, for almost all enterprise-architecture, we need to dump the BDAT-stack, and use the Jellyfish-pattern properly instead.

Which leads us to another perhaps-worrying point. The BDAT-stack is hardwired into every aspect of the TOGAF framework, and many parallel structures such as the Archimate architecture-notation. Yet as we’ve seen above, the BDAT-stack doesn’t work as a context-descriptor for anything other than IT-infrastructure.

So we perhaps do need to hammer this point home: the BDAT-stack hardwires TOGAF and Archimate to be usable only for IT-infrastructure architecture. They cannot be safely used for anything else at all.

What’s even more worrying is that everything in the current TOGAF and Archimate is built around the BDAT-stack. Yet once again, the BDAT-stack doesn’t work: it’s completely misleading for almost all present-day enterprise-architecture. Worse, it also tends to give us some truly horrible conflations, all of which are again deeply embedded in both TOGAF and Archimate:

But if we take the BDAT-stack out of TOGAF or Archimate, nothing makes sense any more. Without the BDAT-stack, the framework, the method, the notation and just about everything else there kinda collapses into a pile of inchoate, incoherent rubble – a bunch of disparate entities and ‘best-practices’ without anything meaningful to hold them together. Oops…

Which in turn kinda suggests that it’s not just the BDAT-stack that we need to dump: we probably need to dump TOGAF and Archimate too. (But that, perhaps, is another story for another time?)

Over to you for comment, anyway.

21 Comments on “Dump the BDAT-stack!

  1. Hi Tom,

    I’ll not comment on TOGAF, but regarding ArchiMate I don’t think BDAT is built into it (neither the way around). One of the things I like in ArchiMate metamodel is that there is a kind of another meta- level built into it: the split between internal/external and the aspects (active/behavior/passive). This is the kind of good foundation IMHO and the biggest current issue is that this has been applied only for B/A/T, but this may change soon 😉

    The only other criticism I could make today is that you can’t have Business concepts directly linked to Technology concepts. The assumption that this is always through some Application things is an issue.

    But as you may know, ArchiMate 3.0 will be published later this year and should address some of these comments, so stay tuned 😉


    • “[R]egarding ArchiMate I don’t think BDAT is built into it” – it is (otherwise I wouldn’t have said so). It’s in Level 7 of Marc Lankhorst’s original metamodel; the Intentional/Extensional split (not Internal/External) occurs at Level 3 of Marc’s metamodel, and the Passive-Structure / Behaviour / Active-Structure split at Level 4. For more details on this, see my post
      Unravelling the anatomy of Archimate‘, or Marc’s original description of the underlying metamodel, referenced in that post.

      “[Y]ou can’t have Business concepts directly linked to Technology concepts. The assumption that this is always through some Application things is an issue.” – yes, that’s just one of many, many, many absurdities that arise from the imposition of the BDAT-stack (or close-equivalent, rather) on the Archimate metamodel. We’ve discussed these before – such as the impossibility of properly modelling ‘human applications’ such as Amazon’s ‘Mechanical Turk‘, for example.

      And yes, I will indeed ‘stay tuned’ for the Archimate 3.0 release. But given the huge letdown and missed-opportunity that was the release of TOGAF 9, back in early 2009, I’ll have to admit I ain’t holding out much hope for the level of change that’s really needed… 😐

      • “It’s in Level 7 of Marc Lankhorst’s original metamodel” – Yes, of course it is, but happens after the description of internal/external and active/behavior/passive. My point was more to say that in some ways, ArchiMate description could be split just before level 7, leading to a kind of meta-meta-model with which we could build meta-model for any purpose.

        Gerben published some time ago a post where he uses this approach to define what could be a physical extension: https://masteringarchimate.com/2014/07/04/reframing-archimate-about-the-physical-domain-layers-and-recursion/

        This approach could be used to further extend Archimate.

        “I’ll have to admit I ain’t holding out much hope for the level of change that’s really needed…” – Of course this will not be perfect, but some subtile changes inside might make it ahead of TOGAF in some aspects.

        • @JB: “ArchiMate description could be split just before level 7”

          Yes, it could. I haven’t yet seen Gerben’s post (yes, I’ll need to do so), but I went into exactly that type of metametamodel restructure in considerable depth in my ‘Unravelling the anatomy of Archimate‘ post. And yes, “this approach could be used to further extend Archimate” – but the only response so far has been thunderous silence (other than Gerben’s post, of course)

          On “might make it ahead of TOGAF in some aspects”, I thought OG’s whole aim was to align Archimate and TOGAF? In which case, how do we break Archimate free of OG’s clutches – because it’s the one thing most holding us back right now…

          • I’ll have to read your “Unravelling the anatomy of Archimate” post (just overlooked for the moment).

            Just one funny comment… Even if I really like Archimate, I saw this limitation early in my learning process: I worked for Lafarge Group where one of the main process is to create concrete using water, sand and cement and then transport this raw material to where it will be used to build e.g. a house… How the hell do you model this with ArchiMate 😉

  2. First, I think that the BDAT stack was invented for the middle (DA), and the contexts to both sides were added. BDAT stems from a time where humans did the work (processes, business layer), applications were used by humans, and infrastructure was the dumb stuff that was needed for the applications to run. The focus was on DA all the time, not on T.

    Second, I agree the BDAT stack has problems, especially because the split between DA and T has been rather artificial for quite some time, that is, it has a basis in management and culture (business-specific logic versus generic logic), not in the reality that one is trying to model. When is a program/system ‘application’ and when is it ‘infrastructure’? Sometimes it is a mix of both. And these days T is quickly becoming ‘just another DA’.

    And given the increase of automation at the ‘business level’ (which by the way in ArchiMate is a somewhat confused mix of ‘abstraction of DAT’ and ‘the human layer using DAT’) the line between B and DAT is blurring as well and this creates the ambiguity of B.

    The problem is not that we cannot extend BDAT to the physical (beyond IT). That is quite doable. Also stuff like Cloud is not really problematic. The problem is that we still culturally live in the 19th century and our view on machines (including IT) is likewise. But machines have become so independent as actors, that the cultural stack with humans on top has become problematic in a real sense.

    However, if you create a new metamodel and you generalise/abstract it enough that you might run into problems with the rest of humanity in terms of ‘able to think that way’. Though I guess a better approach is indeed very well possible.

    BTW, I think the BDAT stack, problematic, limited and sometimes confused as it is, can do rather a lot. I think I could model Mechanical Turk in ArchiMate just fine.

    • Many thanks, Gerben – a lot of good/important points here. It’ll take me something like a couple of hours to write a proper reply, and I won’t have that time until this evening at earliest. Just wanted to acknowledge straight away what you’ve said – I presume it’s okay if the proper reply can wait for a while?

    • Hi Gerben, and apologies for the delay in replying.

      On your first (“I think that the BDAT stack was invented for the middle (DA), and the contexts to both sides were added”), I honestly don’t know – about the ‘T’ end, anyway, though to my knowledge the ‘B’ end was added to TOGAF in v8.1 (around 2004?). The key point to me is that that type of stack is inherently base-relative (‘looking up from the bottom of a well’), and hence the moment we place ‘T’ at the base, that then automatically becomes the focus for the frame.

      On your second (“the split between DA and T has been rather artificial for quite some time”), agreed – and it will become even more blurred over time with the rise of IoT, self-configuring servers and routers, intelligent-sensors, memristors and similar ‘intelligent-hardware’ developments. (And that’s before we start looking at supposedly ‘physical’ technologies such as cars and egg-sorters…)

      Much the same applies to your third point (“given the increase of automation at the ‘business level’…”): agreed there too.

      On your next (“The problem is not that we cannot extend BDAT to the physical (beyond IT)”), agreed on all of that – and good point about persistence of the 19th-century view of technology. Yet I fear you’ve still missed the whole core of my critique of the BDAT-stack: that that stack-type is base-relative, not a descriptor of overall scope. Sure we can extend the scope in any direction we like – but doing so doesn’t resolve the ‘mistaking base-relative for overall-scope’ error that’s deeply inherent in Archimate and (even more) in TOGAF.

      On your next point (about meta-thinking and “you might run into problems with the rest of humanity in terms of ‘able to think that way’”), yes, I’m acutely aware of that… 🙁 Yet I’m also aware that in part it’s a pedagogic problem: children seem to be able handle abstracts far better than adults, which suggests that much of the ‘inability’ to think in abstracts arises due to poor (or, bluntly, atrocious) teaching-methods that are fundamentally unfit for present-day needs. That challenge is being tackled by others more in those fields, but we as enterprise-architects can do our part by making abstract / meta-thinking more accessible / understandable in any way that we can.

      On your penultimate point (“I think the BDAT stack, problematic, limited and sometimes confused as it is, can do rather a lot”), yes, we can do a lot with it: but because it’s so easy to mistake base-relative for whole-of-scope – as TOGAF explicitly does with its framing of ‘business-architecture’ as ‘the everything-else’ – then much of what we do with it will be misleading or just plain wrong, without any means to identify what’s gone wrong, or why. Incipient IT-centrism is merely one of the more visible faults that the BDAT-stack directly imposes on anyone who tries to use it for real-world enterprise-architecture – which may not at first seem to be much of a problem if we work solely and exclusively within a classic ‘big-IT’ domain, but very quickly becomes more and more serious a problem once we need to move anywhere beyond where those ‘big-IT’ assumptions would validly hold.

      On your last point (“I think I could model Mechanical Turk in ArchiMate just fine”), I would challenge you to prove that. I’d agree that it would be quite easy in Archimate to model it as a pair of IT-applications, from the Requester-side and Provider-side – but doing so would completely miss the entire point of the business-logic, which is that it is explicitly a ‘human’-application, in which both the ‘application’ and the underlying ‘technology’ are both human, not computer-based IT. And in its present form, Archimate syntax explicitly forbids us from doing that: human elements are allowed solely in the ‘Business’ layer, never the ‘Application’ layer nor the ‘Technology’ layer. (Sure, you can kludge it via a profile – but that means that it would no longer be syntactically-valid Archimate.) There’s more detail on this in my blog-post ‘On human ‘applications’ in EA models’: mismodelling Mechanical Turk solely as paired IT-applications is a really good example of what I mean by the BDAT-stack enforcing IT-centrism in a way that people can fail to see is happening…

      Anyway, hope that’s useful? – and thanks again.

  3. “Be aware of the focus, scope, and purpose of your modeling initiatives when it comes to picking the right process modeling technique. Keep in mind the interplay between techniques and tools.
    The act of modeling is of tremendous help, as many success stories reveal. It may, however, also be just a costly pastime if you do not know (or don’t care) why you model at all.”

    Problem is that most people/companies just pick TOGAF/Archimate because they are being told that’s the standard…

    • Really useful link, Peter – thanks for that.

      And yes, painfully true that “most people pick [whatever] because they are being told that’s the standard…”. Sigh…

  4. I’m a few days late spotting this, Tom but it’s still worth saying what an important article this is. I really like the way you make us focus on the base-relative nature of any stack.

    One of your most significant observations is that the BDAT approach “probably wouldn’t even be able to include cloud-based services or customer-maintained IT”. Drop the probably. I’ve come across too many, at best irrelevant BDAT models for both customer and supplier.

    I’d like to suggest that the problem lies not with the standards as such but the depressingly general idea that EA is an IT discipline. (Yes, of course the standards are part of the problem but they could change, were it not for the vested interests of large consultancies and of the typical CIO) A result is that most so-called EA programmes/projects are at best EITA and often not more than TOGAF phase E. In such a case bDAT is all you need. Worse still, the well intentioned EA, who tries to look at the whole business, often runs into push-back from “the business”, because IT should keep its damn nose out of it.

    • Many thanks for this, Stuart – and thanks too for the confirmation about the limitations of BDAT as applied to “cloud-based services and customer-maintained IT”.

      On “the problem lies not with the standards as such but the depressingly general idea that EA is an IT discipline”, we have a circular problem here, in that the most common supposed-EA ‘standard’ – and often the only one that people know – is an absurdly IT-centric standard from an IT-standards body that explicitly asserts that enterprise-architecture is a subset of IT-governance. If the only commonly-known ‘standard’ gets its that far wrong, it’s not surprising that we’ve been stuck in the wrong place for so long.

      As I see it, the only out of this mess – and that standards-body’s utterly-inappropriate stranglehold on the profession – is for us to sit down and get a new standard out there that actually describes the real domain in ways that are simple enough for everyone to understand, and inclusive enough for it to support a literal ‘architecture of the enterprise’ rather than solely ‘the architecture of a long-outdated form of enterprise-wide IT’. Rethinking the core of EA, and thence its application to business in general (i.e. commercial, government and not-for-profit alike, at every level and in every subdomain), is a key part of what I’m doing right now here in Mexico: I’m about ready now to begin publishing that, and inviting people to help move it (or something similar) towards a true replacement for the pseudo-‘standards’ that we currently suffer in EA. Watch This Space, perhaps? (And join in too, of course, if you would?)

      Thanks again, anyway – and do keep in touch.

  5. Hi Tom — I think maybe it was the LinkedIn version of this posting where I suggested a 180-degree mindset flip on BDAT. Let me make a couple of further suggestions in that vein.

    A while back I put myself through some coaching training, to acquire a bit of that skill. One of the things I learned was about changing habits. The bottom line seems to be that frontal assault on, say, smoking or over-eating, tends to engrain that neural pathways with the undesirable behavior. The effective alternative seems to be creation of new, desirable habits, rather than rehearsing the negative ones to try to break them.

    The possible lesson I’m suggesting is that maybe we’e better off to tone down the rehearsal of the negative aspects of TOGAF, BDAT, ArchiMate and the standards approach of The Open Group. Maybe we just need to focus on the new habits of thinking wider and deeper about architectures of enterprise, and maybe we need to find alternative institutions to promulgate those alternative habits of thought. Maybe we should focus on AEA rather than TOG or OMG. Or maybe as a fresh alternative, how about focusing on the service innovations represented by whole-of-enterprise thinking and enterprise-in-environment thinking under the auspices of ISSIP, the International Society for Services Innovation Professionals?

    For my own part, the habit of thought I’ve been rehearsing has been the mental move of EA into the role of diagnostician in the marketplace of enterprise health improvement services. There seem to be people interested in that approach, who don’t have to break bad old habits of thought.

    Does any of this make any sense at all?

    • Hi Doug – and yes, of course it makes sense. (You always do. 🙂 ) Agreed re the need to change habits – if only because trying to tackle the TOGAF steam-roller head-on is only going to get me flattened.

      Let’s be blunt about this: anyone who’s been in ‘the trade’ for more than a year or two will know first-hand that whilst the TOGAF/Archimate pairing is usable enough for ‘big-IT’ architectures, it’s fundamentally unfit for anything else. The notion that it’s appropriate for present-day EA – let alone for where EA is headed – is misleading at best. At the very least, it’s fundamentally inappropriate for an IT-standards body to play dog-in-the-manger for what needs to be a whole-of-business standard.

      So right now we’re at a bit of a crossroads: either we continue pretending that TOGAF is a viable ‘standard’ for what we need in EA, and, because it isn’t, watch the entire profession die; or else create an alternative that actually does fit the needs, and let TOGAF fall back to where it belongs, in classic ‘big-IT’. (Open Group’s new ‘IT4IT’ standard is perhaps almost a substitute in that sense – in which case TOGAF would become redundant.)

      My approach right now is two-pronged: make it very clear that any IT-centric metaphor or standard is no longer fit-for-purpose for EA, and explain how and why that is so; and work with others to develop an alternative that does fit our profession’s needs, for now and into the future. So far you’ve perhaps only seen the first prong; but over the next few weeks you should start to see more of the second.

      Again, I’m not attacking Open Group et al, and I’m not saying that TOGAF et al are inherently ‘bad’, or ‘wrong’, because they do have their value and use. All I’m saying is that if we try to use them in ways that, by their internal structure and suchlike, they’re inherently incapable of supporting, then the results will be misleading at best – and that that risks damage to the profession as a whole. If people can’t see the difference there, they perhaps shouldn’t be in enterprise-architecture? – because that’s the kind of precision and rigour that this discipline demands, surely?

      I take your point about aiming more at AEA than TOG – though given that AEA is actually an offshoot of TOG itself (it used to be called AOGEA, Association of Open Group Architects), it’s probably much of a muchness. To me, your point about connecting with ISSIP is likely to be more fruitful, though I don’t have any contacts there: do you have any that you might recommend?

      On “diagnostician in the marketplace of enterprise health improvement services” – yes, strong agree, in fact several of my tools, such as SEMPER, are specifically designed for that kind of purpose. If we think of EA as about maintaining the integrity and effectiveness of the structure and story of the enterprise in the face of dynamic change, then yes, it fits very well with a health-type motif or metaphor. And yes, we could shift over to there, given the right contacts and leverage-points and business-models and so on.

      What it wouldn’t do, though, is stop the ongoing damage that’s being caused by the misframing of EA as ‘an IT-discipline’: and from a health-perspective, we would need to apply preventive action against that at some point – preferably sooner rather than later. Which brings us back to where we started, doesn’t it? To be blunt, whichever way we look at it, we need to kill the cancer now, before it has any further chance to spread. Do you really see any viable alternative to that?

  6. I guess what I’m saying (kind of an icky metaphor, but maybe useful?) is to starve the ‘cancer’ through benign neglect, while putting as much effort as possible into positive alternatives that build our healthy mental muscles. Metaphorically speaking 🙂

    In terms of ISSIP, I am directly wired to the inner circle. The prime mover there is my all-time favorite manager, who largely formed the services research agenda for IBM, and is now IBM’s worldwide director of university relations. It is through that relationship that I got my book contract with Business Expert Press, for the All Services, All the Time book (which put me firmly in the category of ‘worst-selling author’ 🙂 )

    One way to start gaining visibility via ISSIP would be (maybe) to deliver one of the weekly presentations they host every Wednesday. If that’s at all of interest, we could have an off-line brainstorm?

  7. Hi Tom and thanks a lot for sharing your visions.

    I am currently modelling a university and I have not seen a problem in creating for example a process is used by multiple services in my metamodel. Is this something that the BDAT stack would not allow?

    But I do have a problem when trying to model for example working environment and it’s development, which is an important factor in most organizations. I’ve thought to skip all non-IT stuff but now that I’ve read your thoughts I am reconsidering 🙂 Would there be a way to model it with all it’s details? Can it even be modeled similarly to other processes since it is a different, supporting entity? Do you have any thoughts on that you’re willing to share?

    • The BDAT-stack is fine if what you’re modelling is IT-infrastructure. You can use it for other things too, as long as the end-point is IT-infrastructure – in other words you know that whatever you’re modelling will run on IT-infrastructure, and that no part of it does not bypass that IT-infrastructure.

      The point is that a stack-type construct is base-relative, like looking upward from the bottom of a water-well: you can look ‘upward’ to a broader scope, but if you look ‘downward’ from above the well, your view is constrained solely to the well itself. In the case of the BDAT-stack, the base is IT-infrastructure (‘Technology’), which means that anything at that level that isn’t IT-infrastructure just becomes invisible. For example, for a data-centre, you can model the IT-hardware – servers, routers, cabling etc – but you can’t model the racks or their physical locations, or the power-system or cooling-system, or even the building itself, because none of them are IT-infrastructure as such. For an assembly-line, you can model the sensors and the data-flows, but you can’t model the physical machines or the flow of physical objects. In short, it’s a mess…

      Archimate tries to kludge a way out of this mess with some truly horrible conflations: in particular, anything human ends up as ‘Business’, even if it’s logically at the same level as ‘Data’ (e.g. conversation) or ‘Technology’ (physical action). (I’m told that Archimate v3 will make these kludges easier to do, but unless it explicitly dumps the BDAT from its underlying architecture, it won’t actually resolve the mess.) TOGAF doesn’t even bother with the conflations: instead, it uses ‘Business-Architecture’ as a generalised, largely-undifferentiated grab-bag for ‘anything not-IT’ that might affect IT’, and ignores everything else – which is just plain daft. 😐

      As for what to do about this, there’s an old slidedeck of mine on ‘Using TOGAF beyond IT’ that might be useful – see http://www.slideshare.net/tetradian/using-togaf-beyond-it . It’s oddly scrambled on Slideshare, but might be okay if you download it – if not, let me know and I’ll email you a copy (I have your email-address from your post above). Otherwise I can schedule a Skype-call to walk through it with you – but note that I’m in Mexico at the moment, so there’s quite a big time-difference.

      Hope this helps, anyway. 🙂

      • Thanks for your reply and help. I will study your presentation and comment on it when I am back from my trip, in about a week. The presentation seems very interesting and looks to work correctly too.

        It seems that my fresh perspective on EA and non-it way of thinking might not be such a bad thing after all.

  8. Arriving a bit late to the party, I confess…

    I think that deep down inside, all entarchs are aware that TOGAF and BDAT are, ultimately, for developing IT-centric architectures. However, that common awareness diminishes nothing from the clarity of thought around perceiving TOGAF as the descriptor for IT context: I really like that definition and it draws some light into an area I was struggling with, namely the extension of the BDAT stack to fit other domains/aspects I don’t think fit too well (e.g., organisation transformation elements needed for the IT-centric architecture plans to be realised).

    I reckon that the industry, at least in the near future, will largely split into two paths: the first improving on our current IT-centric philosophy focusing solely on areas this philosophy remains relevant, while the other takes a more holistic whole-of-ent. approach to deliver EA value that’s relevant for the new business reality.

    I think the first path would naturally conglomerate on the IT-centric functions of organisations which would remain relevant for a few years to come. For example, I’m thinking IT4IT, which ties nicely a lot of the commonly used methods driven by an IT-centric philosophy.

    I’m currently seeing only a ‘more of the same’ approach to improvements from TOG (IT4IT, Archimate 3.0), so if no innovations are introduced, this path won’t remain relevant forever. But big organisations change slowly so there’s quite a bit of value to be had, especially for low-maturity organisations. For example, many big directorates in Australia’s state-level governments would fit that description perfectly, and I think would benefit from improving their operations in an IT-centric fashion.

    The second path (which I’ve yet to see a coherent methodology, only pieces of a potential one) would aim to support the new Digital philosophy with EA mindsets and approaches. Tom, I am hoping to gain some clarity on that path once I finish reading your series ‘Towards a whole-enterprise architecture standard’.

    The point I’m making here is that just because we now have a better way of doing things, doesn’t mean we can always execute on it. BDAT, TOGAF, Archimate, they are all far from being perfect, but they do have a good premise that fit a particular philosophy. Awareness and fit-for-purpose should always be our guiding principles, and in today’s reality there are still a significant number of organisations that follow that philosophy – we’ve to be pragmatic and improve them however we can.

    I wouldn’t use TOGAF / archimate for developing User Journeys to inform my business services, but not all organisations are ready for enterprise-wide customer-centric service design. So I think I wouldn’t dump BDAT, but I definitely won’t use it with organisations that are looking to adopt new business philosophies.

    On a personal level, I’m very exited that my role as entarch has a future with the new Digital philosophy. I am far from my retirement age, and really love what I do, so very keen to participate in that second path to EA conversations.

    • Hi Fernando – and thanks for joining the party! 🙂

      On “I think that deep down inside, all entarchs are aware that TOGAF and BDAT are, ultimately, for developing IT-centric architectures” – I’d agree that that may be so, but it isn’t helped by the constant pretence from certain players either that EA is solely about IT, or that IT is the only thing that matters (enough to require an architecture built for it, anyway). Given that nothing in that pretence is actually true, we as a profession still have a serious problem on our hands around that mess – and we do need to resolve it, somehow. Sigh…

      On “I reckon that the industry, at least in the near future, will largely split into two paths” – the short answer is that it’s already happening, for the reasons I gave in my recent ‘status-report‘ post: the mainstream ‘enterprise’-architecture frameworks won’t even serve the IT-related needs of the future, let alone the broader needs beyond IT.

      On “I’m thinking IT4IT, which ties nicely a lot of the commonly used methods driven by an IT-centric philosophy” – to me IT4IT seems to be what TOGAF should have morphed into in v9, back in 2009: a solid enterprise-wide IT-architecture framework, without any pretence that it was anything more than that. They didn’t have the courage to do that then, unfortunately: a pity, because it would have saved the profession from the need to backtrack from seven further years of a fundamental scope-error. (And yes, agreed that IT4IT has real value for organisations that still run big internal IT-estates: no doubt about that – from what I’ve seen so far, anyway.)

      On “BDAT, TOGAF, Archimate, they are all far from being perfect, but they do have a good premise that fit a particular philosophy” – yes agreed. The problem is that their promoters still relentlessly pretend that they cover a broader scope and spectrum than they actually do, or can – and that causes huge (and entirely unnecessary) challenges for everyone else.

      On “very keen to participate in that second path to EA conversations” – yes, please do! It’s crucially important, though, to remember that this ‘second path’ does still explicitly includes IT – it has to, and again, no doubt whatsoever about that. (The simple test is that if something’s in use within the enterprise, then by definition it’s in scope for the enterprise-architecture.) It’s just that it becomes merely one domain amidst all of the others, and interwoven with all of the others: important, yes, of course, yet also no more important than anything else, either. That’s really the key difference between those two paths, I guess: the ‘first path’ cannot let go of the idea that everything somehow revolves around IT alone, whereas the ‘second path’ fully accepts that IT is merely one domain amongst many – that “everything and nothing is ‘the centre’, all at the same time”.

      Thanks again, anyway, and do keep in touch!

Leave a Reply

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