On business-architecture and enterprise-architecture – more detail

The key point from the previous post – ‘On business-architecture and enterprise-architecture‘ – was that we must stop misusing the term ‘enterprise-architecture’ for something that it isn’t.

And we can even fix TOGAF so that it doesn’t make that mistake any more.

There are some key things that TOGAF does get right:

  • architecture is iterative
  • architecture needs to connect big-picture aims with actual change at the operational level
  • even with an iterative structure, there is still a definite overall sequence to the work
  • technology (and IT in particular) is likely to be a necessary aspect of that work

Yet there are several key things that TOGAF still gets wrong about enterprise-architecture – even horribly-wrong, in some cases. These include:

  • the iteration-structure needed is not linear (as per the TOGAF Architecture Development Method [ADM]), but fractal
  • the focus for architecture-scope should not always be IT-infrastructure technology (as mandated by the BDAT structure that underlies ADM phases B/C/D), but instead allow any scope at any scale and any level
  • a review of current trends in technology (as per ADM Phase H) is not sufficient as, nor maybe even relevant to, a ‘benefits-realisation / lessons-learned’ after-action review for iterative-development
  • nowhere is the term ‘enterprise’ meaningfully defined (it’s not in ‘Definitions’, or anywhere else in the text)

That last point, about the meaning of ‘enterprise’, is where the current mess about ‘business-architecture’ arose, and is still evolving – mostly for the worse.

So let’s sort this out step-by-step.

First, ‘enterprise’. The core problem here, as per that previous post, is that there are two fundamentally different meanings of ‘enterprise-architecture’:

  • the literal meaning, as ‘the architecture of the enterprise’ (whatever ‘enterprise’ might mean – we’ll come back to that in a moment)
  • a lazy contraction of the term ‘enterprise-wide IT-architecture’ [EWITA] as ‘enterprise-architecture’ (as if IT is the only element in the enterprise that might need architecture)

Hence the first problem we face is that it’s the latter sense, not the former, that is embedded in TOGAF, FEAF, DoDAF, TEAF and virtually all of the ‘mainstream’ ‘EA’-frameworks, and in most discussions in the mainstream press. It’s also the reason why, at present, most who describe themselves as ‘enterprise’-architects still report to or below the CIO – not the whole board, as would be implied for the literal meaning of ‘the architecture of the enterprise’.

(For reference, our EA unit at Australia Post, more than a decade ago, did report to the entire board – and our remit was indeed ‘the architecture of the enterprise’.)

In short, most current usages of the term ‘enterprise-architecture’ imply something with a very different and much narrower scope than the term would literally mean. And the blame for that confusion lies squarely with the people who created and promoted those ‘EA’-frameworks – and yet who, now knowing that it is misleading and wrong, still promote that same mistake today.

One key outcome of that mistake is utter confusion about the relationship between business-architecture [BA] and enterprise-architecture [EA] – or, in short, where does business-architecture sit?

  • If we use the literal meaning of EA as ‘the architecture of the enterprise’, then BA is, yes, one valid and important sub-domain of EA. That’s how we get the apparent validity of the BDAT-stack, as used in TOGAF and elsewhere: EA as Business, Data, Applications, Technology. For this meaning, BA would be positioned ‘within’ EA.
  • If we use the lazy-meaning of EA as a contraction of EWITA, then BA provides the business-context for EWITA-as-‘EA’. In other words, BA as ‘the architecture of the business’ would be positioned ‘above’ EA.

Although the term ‘Business Architecture’ is used in TOGAF, it’s clear from a reading of ADM Phase B that it’s little more than a randomised grab-bag of ‘anything not-IT that might affect IT’ – and despite various claims to the contrary, it’s still not much about business-as-business. Which might at first seem sort-of fair-enough when we note that Open Group, in this example, is an IT-standards body – not a more general business-standards body. But the problem is that, in TOGAF, ‘business-architecture’ ends up being both a sub-domain within EA, yet also above ‘EA’ – both at the same time:

Hence the confusion. Lots of it.

So let’s disentangle that confusion.

The way out is two-pronged:

  • be clear about the meaning of ‘enterprise’
  • be clear about the fractality

(Doing so would also clear up the mess with ADM Phase H, as we’ll see in a moment.)

First, the meaning of ‘enterprise’. Perhaps the most important point is that, from an architecture-perspective, ‘the enterprise’ is not the same as ‘the organisation’. I go into this in some detail in my post ‘Organisation and enterprise‘, but the simplest way to summarise the difference is to say that ‘organisation’ is more about structure, whereas ‘enterprise’ is more about story – the emotive intent, the drivers, that give that structure a reason to exist.

(Another way to view this distinction: ‘organisation’ is ‘that which we are organising’, whereas ‘enterprise’ is ‘that about which we are organising’ – the surrounding context for that which we’re organising.)

At the whole-organisation level, there’s a set of relationships that look somewhat like this:

But the key point is that this isn’t just about the organisation as a whole: instead, this is fully fractal. For example, if we think of any given service as ‘the organisation in scope’, then ‘the enterprise in scope’ is the respective overall context for that service. We’d typically describe this overall-context in terms of at least three distinct layers ‘outward’ from that service – transactions, direct interactions, and indirect interactions:

And, when we look ‘downward’ from whatever it is that’s our current focus for the architecture, the same also applies, fractally, with services within services within services:

So whilst use of the BDAT-stack entraps TOGAF into giving us an architecture that can see only this:

…what we actually need from a fully fractal enterprise-architecture is more like this:

…extending ‘outward’ and ‘inward’ with services implemented not solely by IT, but by any appropriate combination of people, machines and IT:

Which brings us back to the TOGAF ADM again, because there is a simple fix to the TOGAF ADM that could give us all of this – enabling the TOGAF ADM to tackle any architecture scope and scale, with any content, any mix of sub-domains, at any level.

(For what it’s worth, I first proposed this to Open Group back in around 2006 or 2007 – well before the sad missed-opportunity that was TOGAF 9. A full decade later, they still haven’t gotten round to fixing that fundamental mistake. Oh well…)

All it requires is one quite small tweak to the way we frame scope in ADM Phases B/C/D.

In the present ADM, each of those phases specifies a scope, as per the BDAT-stack: Business, Information-Systems (Data/Applications), Infrastructure. Then, for each of those phases, separately, we then apply to the respective predefined scope for that phase what is, in effect, the same set of views as earlier above: transactions, direct-interactions, indirect-interactions.

So yes, the standard ADM does sort-of cover the full context of the overall predefined BDAT-scope – which would be fine only if that predefined IT-centric scope is all we’d ever need to cover in an ‘enterprise’-architecture. And it covers even that arbitrarily-constrained scope only in a fragmentary way, with different domain-specialists carving out out their own separate views of the architecture. Which is exactly what we don’t want in an architecture-of-the-enterprise.

But why not just switch the whole thing round? – and require those domain-specialists to work together?

We can do that if we drop the BDAT-stack and its hardwired assumptions about scope – and instead identify in Phase the respective scope for each iteration, based on the business-question with which we started the iteration.

Then, given that iteration-specific scope, move progressively down towards the detail in Phases B/C/D, respectively covering big-picture or indirect-context (Phase B), direct-context (Phase C) and transaction-oriented detail (Phase D). In each case we gather the information we need for each relevant time-horizon – so-called ‘present-state’ versus ‘future-state’ and so on. Again, all of this is fractal, and, overall, looks somewhat like this:

Which, incidentally, also gives us the basis for a more meaningful (or at least mnemonic) relabelling for each ADM phase:

  • AAims – business-purpose or business-question for this iteration, plus success-criteria
  • BBig-picture – big-picture overview of scope implied by aims
  • CContext – direct context and stakeholders for the scope implied by the aims and revised at big-picture level
  • DDetail – detailed review at the transaction-level scope as implied by the aims and revised at big-picture and direct-context level
  • EEvaluate options – assess trade-offs, gap-analyses, time-horizons and more, for the full set of domains in the full revised scope
  • FFind solutions – define actions to implement the respective changes, with any implied fractality of actions
  • GGovernance – apply appropriate governance/metagovernance (Agile, Waterfall, whatever) to each of the identified actions for and within implementation, again iteratively and fractally (i.e. not so much DevOps as ArchDevOps)
  • HHow did we do? – enact after-action review for benefits-realisation and lessons-learned, in context of the success-criteria from Phase A, and to identify potential needs for future iterations

Note again that – unlike the standard TOGAF-ADM – all of this is fully fractal:

  • it can be applied in exactly the same way for any scope, any scale, any level, any type of implementation
  • iterations can be nested to any required depth, with each iteration taking the exact same form
  • the same overall method is applied in all domains – business, security, branding, applications, finance, data, skills, applications, buildings, IT-infrastructure, whatever
  • the same overall method is applied to all modes of implementation – every possible combination of people, machines and IT

That fractality might at first seem somewhat complex, but its pattern-based approach actually makes management of views into the overall architecture vastly simpler than with trying to predefine every possible type of scope. Hence, for example, that same fractal pattern underlying the actual set of relationships behind the BDAT-stack:

Yet when we look at business-architecture, the pattern indicates that it’s not the same as that above, as implied by the BDAT-stack, but more like this:

This fractality also helps us make more sense of the CIO’s view of the business-world – which doesn’t properly match up with the BDAT-stack at all:

And even for IT-oriented architectures, we could say and show much the same for IoT (Internet of Things), cloud, mobile, embedded, wearable, distributed-AI and many, many more.

We get all of that, and more, if we dump the BDAT-stack from our architecture-frameworks, and instead use proper, meaningful relationships between ‘organisation’ and ‘enterprise’.

Enough on that for now: over to you for comment, perhaps?

Posted in Business, Enterprise architecture Tagged with: , , , , ,
16 comments on “On business-architecture and enterprise-architecture – more detail
  1. Peter Murchland says:

    Tom

    In the same way that using enterprise when we mean enterprise-wide creates problems, it seems to me that your use of shared-enterprise introduces yet another conflicting use of enterprise, and some associated problems.

    a) the enterprise pursued by an organisation (as an example) is far narrower than the shared-enterprise you have represented
    b) one cannot architect the shared-enterprise, so I wonder why you use the term at that “level”, as this will only introduce further confusion

    As outlined by many thinkers and authors, design (and architecting) of a system requires attention to the “containing system(s)” – so there always needs to be attention to the environment in which an enterprise is pursued and an organisation operates. Extending the “scope” to encompass this aspect is not necessary (imo).

    • Tom G says:

      Thanks, Peter. As I’ve explained many times on this, we in effect architect for an ‘organisation’ (‘that which is organised’, i.e. the ‘service-in-focus’, in a service-oriented approach, as per above), but about an ‘enterprise’ (‘that which provides the context for that organisation’, i.e. typically/advisedly all the way out to ‘indirection-interactions’ for the service-in-focus). That distinction answers both of your objections (a) and (b) above.

      It strikes me as odd that you haven’t placed those objections before, since you’ve known and used my work for a fair while now, and the answers just above have been core to my work for many years. And unlike a lot of people in ‘the trade’, I have been careful to declare my assumptions and terms (e.g. see post ‘Declaring the assumptions‘ (Jan 2015), slidedeck ‘What is an enterprise?‘ (Dec 2009) and post ‘Organisation and enterprise‘ (Sep 2014), and post ‘Fractals, naming and enterprise-architecture‘ (Sep 2014). And whilst you say that “Extending the “scope” to encompass this aspect is not necessary (imo)”, you know that I’ve long explained –
      again, many, many times – exactly why it is necessary. So unless something significant has changed for you in, say, the past few months, why do these objections arise only now? I don’t understand…

  2. Len Fehskens says:

    >the iteration-structure needed is not linear (as per the TOGAF Architecture Development Method [ADM]), but fractal

    My understanding of the meaning of fractal is that the same pattern repeats at all scales. I don’t think that’s what you mean.

    I argued in a webinar I gave a few weeks back that design (and thus architecture) is an inherently nonlinear process, and that linear methods, even with the introduction of iteration, are inherently ill-suited to design. My experience as a designer has been that the way I design is neither linear nor “fractal”, it is based on the opportunistic application of heuristics that are chosen based on one or more patterns that characterize the current situation. There may several heuristics that might apply in any given situation; it doesn’t matter what order you try them in as long as eventually you find one that allows you to make progress. So what happens “next” is non-deterministic. If you think of the boxes and lines of a method “process flow” as not being a representation of activities sequenced in time, but instead as information structures (the boxes) that “want to” maintain a set of relationships (the lines) among themselves, it is easier to see that the information structures can be populated in any order, as long as the necessary integrity and fitness for purpose relationships are closely enough approximated that the design converges on satisfaction of all the relationships as it evolves.

    len.

    • Tom G says:

      Thanks, Len.

      “My understanding of the meaning of fractal is that the same pattern repeats at all scales. I don’t think that’s what you mean.” – no, you’re right, it isn’t. The crucial distinction revolves around the word ‘same’.

      If we assume that it is “the same pattern” – and especially if that pattern always assumes the same content, as per the BDAT-stack – what we get is simple linear iteration. It can loop round any number of times, and even nest to any degree, but it cannot move outside of its own predetermined box – especially so if the assumed content or ‘visibility’ is hardwired, as again we see with the BDAT-stack.

      The distinction – and I think this is what you’re aiming for here? – is that for fractals, the pattern is not the exact same each time, but is instead ‘self-similar’. It both is and is not ‘the same pattern’, both at the same time. That’s what gives us the need for “the opportunistic application of heuristics”; that’s what gives us “what happens ‘next’ is non-deterministic”. And there’s also the intersection between potentially many self-similar patterns applying in the same nominal context. That’s what gives all of our range of options, coming at the same nominal context from many different directions (‘holographic-architecture’ etc). That’s what gives us the possibility of change, beyond the arbitrary constraints of ‘the known’; that’s what gives us the ability to work with dynamic changes in “integrity and fitness for purpose relationships” (rather than static hardwired ‘fitness-for-purpose for only this-moment-now’, which is the best we can get with linear methods). That’s what gives us the possibility of understanding “[process-flow etc] instead as information structures (the boxes) that ‘want to’ maintain a set of relationships (the lines) among themselves”.

      In short(er), linear/simple-iterative uses the same pattern, often with the same predefined content-constraints (i.e. the kind of iteration/nesting we see in many programming-languages); whereas non-linear/fractal uses self-similar patterns, often intersecting in complex combinations within the same overall context (e.g. views/viewpoints in a hologram, all and none of which are ‘true’).

      Does that fit better with your position above?

  3. Len Fehskens says:

    >The distinction – and I think this is what you’re aiming for here? – is that for fractals, the pattern is not the exact same each time, but is instead ‘self-similar’. It both is and is not ‘the same pattern’, both at the same time

    Yes, exactly, my bad for being glib.

    And yes to all the rest.

    As you note, what is fractal is the opportunistic application of heuristics. Thanks for that insight.

    len.

    • Tom G says:

      Thanks, Len. Glad it made sense.

      One further point I’d throw in, though, is that there’s an additional distinction, between heuristics and fractals. On its own, an heuristic may apply to just one level of just one context (hence e.g. ‘best practices’ and suchlike). What makes it fractal is that we get the same/self-similar pattern/heuristic that occurs/sort-of-repeats in multiple levels and/or multiple contexts.

      That’s important, because that’s what allows us to simplify. Different heuristics in each context is actually harder – it leads to ‘complicatedness’ that people then try to reduce to simple linear-type rules, which is where things really get into a mess. But if we can find the fractality in a broad, multi-layered, multi-scope / multi-stakeholder context, that means we can use the same general pattern with each stakeholder-group, for example – which makes communication between stakeholder-groups a heck of a lot simpler (the right kind of simplicity – simple, not simplistic 🙂 ) and a lot less prone to translation-errors and suchlike.

      The catch is that working with fractality always demands at least some level of skill and discernment, to find the right contextual balance between ‘same’ and ‘different’, and the right ways to work with the heuristics etc of the resultant ‘the different’. That’s where those non-linearities so often pop up, for example. So for business-folk still pushing the Taylorist dream of de-skilling everything, reducing everything to predictable (‘profitable’) algorithms, fractality is something they definitely don’t want – even though the context won’t work well without it. Oops… 🙁 🙂

  4. Len Fehskens says:

    >The catch is that working with fractality always demands at least some level of skill and discernment, to find the right contextual balance between ‘same’ and ‘different’, and the right ways to work with the heuristics etc of the resultant ‘the different’.

    Yes; in my talk I pointed out the skills necessary to exploit this way of thinking about design (and thus architecture) include:

    A rich set of patterns and the heuristics they suggest.

    The ability to recognize these patterns in a wide variety of contexts [this includes at different scales].

    The ability to apply these heuristics in a wide variety of contexts [again, including at different scales].

    The ability to add new patterns and heuristics, and extend the applicability of known patterns and heuristics, based on experience.

    Modulated tenacity (“knowing when to let go”).

    >That’s where those non-linearities so often pop up, for example. So for business-folk still pushing the Taylorist dream of de-skilling everything, reducing everything to predictable (‘profitable’) algorithms, fractality is something they definitely don’t want – even though the context won’t work well without it.

    Yes, the talk was titled “The Siren Song of Linear Thinking”, and I pointed out the one of the siren songs that managers would find very difficult to resist is the idea of linear (and mistakenly thought of as “deterministic”) methods as a means to deskilling. As I put it:

    When linear thinking fails, it fails badly. Sometimes it’s not just a bad approximation, it’s completely wrong.

    Worse, it fosters certain problematic illusions, the most dangerous of which is that it is possible to de-skill an expert capability. Being able to follow a recipe does not make you a professional grade chef.

    len.

  5. Peter Murchland says:

    Tom

    A couple of elements to my response – perhaps first, what has changed / why now?

    As with anyone’s view of EA, there is a lot to it. What you have presented over the years has been rich, thought-provoking, and a significant contributor to my learning, understanding, articulation and practice. That means, for me, that to take on board all that you offer, I have determined to “live with” various elements that do not sit well. Sometimes, just parking them, so that I can come to grips with other elements. Sometimes, recognising that as I understand more, I might see things in a different light and hence some of the questions and issues may resolve themselves, so to speak. Sometimes, simply saying “I can live with this” for the time-being. There is not sufficient value in devoting time and effort to understanding as yet. This latter element is what is in play around “shared-enterprise”, etc. For me, this has never “sat well” – but has not been important enough to give attention.

    Why raise it now – because it occurred to me that this stance creates a problem for me, and may do so for others, and may be an area that you need to give closer attention. So, I thought it best to give it visibility, provide the feedback and see where it leads – either to learning and change for me, for you or for both of us.

    A second element to this is that I think I am better able to articulate my concerns now that I might have been able previously. Also impacted by dealing with a range of issues leading to more clearly articulating the distinctions between a business system (enterprise), information system and IT system for some business analysts who seem to only focus on the IT system. So, there are some current issues becoming drivers for attending to the question of “containing systems” which are not within scope to be able to design or architect but which are important to consideration of the system-of-interest that is being architected and designed.

    • Ian Glossop says:

      Differentiating between “Information Systems” and “IT Systems”.

      As an academic exercise to get BAs (and others) to distinguish carefully you simply have to ask the question: “And how would you implement this Information System if you did not have modern Information Technology available to you?” That should provoke them into thinking about the differences.

      The the required reading is Checkland’s “Information, Systems and Information Systems” – after which they should be clear.

    • Tom G says:

      Thanks, Peter.

      Perhaps the best way I can see to tackle this is to go back to your concerns from the previous comment, because yes, it is forcing me towards something of a rethink:

      “a) the enterprise pursued by an organisation (as an example) is far narrower than the shared-enterprise you have represented
      b) one cannot architect the shared-enterprise, so I wonder why you use the term at that “level”, as this will only introduce further confusion”

      What’s wrong – agains as I see it – is that I still haven’t properly explained what I mean by ‘shared-enterprise’. (I hit much the same problem of incomplete explanation earlier today, with someone who’d tried to interpret a SCAN mapping as a normal time-series graph – which, unsurprisingly, made no sense to them at all.)

      On your a), by ‘shared-enterprise’ I mean ‘that which links all shareholders together within this context’. If we can identify that, then it gives us unifying element as a means to make sense of all of the disparate drivers for all of the disparate transactions and direct- and indirect-interactions in the context. If the service-in-focus (aka ‘the organisation’) looks at itself as ‘inside-in’, and at ‘the world outside itself’ as ‘inside-out’, then this shared-enterprise looks at ‘the organisation’ in terms of ‘outside-in’, and at itself as ‘outside-out’ – its story as itself, whether or not ‘the organisation’ actually exists.

      On your b), yes, you’re right, we can’t architect the shared-enterprise itself, in the sense that we can’t architect (in the sense of define or ‘control’) a shared-story that doesn’t belong to us and could exist without us anyway. Yet what we can do is understand the factors and sub-stories and drivers that underpin that shared-enterprise, and in that sense architect how we choose to interact with it. That’s not the same as attempting to ‘architect’ the story itself – I presume that distinction is clear enough?

      Re the ‘levels’ bit, this is simply a way of distinguishing between three distinct types of interaction – transaction, direct-interaction, and indirect-interaction – which would apply fractally/recursively to/with any ‘the service-in-focus’. They’re ‘levels’ only in the sense that the interaction-types are different and (usually) distinct. For example, in classic IT-oriented ‘enterprise’-architecture, these are elements that IT-infrastructure transacts with (data/applications), that it has direct-interactions with (management of IT-infrastructure (much as per ITIL) and indirect-interactions with (aka ‘business-architecture’) – in other words the BDAT-stack. At a whole-of-organisation level, these are the elements that the organisation transacts with (‘supply-chain’), has direct-interactions with (‘the market’ etc), and more indirect-interactions with (‘the community’, ‘government’ and suchlike; also ‘investors’ and suchlike).

      So when we talk about “distinctions between a business system (enterprise), information system and IT system”, think of each of these as a ‘the service-in-focus’, each with their own transactions, direct-interactions and indirect-interactions. How do these ‘layers’ intersect, when we compare, say, ‘business-system’ to ‘IT-system’? (Short-answer: the former’s transactions will be the latter’s direct- and/or indirect-interactions – which is exactly what we see when trying to disentangle the mess that the BDAT-stack makes of mainstream ‘EA’.)

      Once this starts to make sense, it then becomes glaringly-obvious as to why having the BDAT-stack as the core of our so-called ‘EA’-frameworks is such a bad idea: it imposes an arbitrary set of assumptions about relationships and interaction-type that sort-of make sense when our only interest is IT-infrastructure, but are flat-out wrong for the whole-of-organisation level. That’s why all of this stuff that I’ve been working on for all of these years – it’s to make the fractality actually work, when the BDAT-stack etc actively prevent it from doing so.

      One suggestion I could ask: take a look at my 2015 post ‘Declaring the assumptions‘. Then please let me know which of those assumptions don’t “sit well” with you – and, if you can identify it, why they don’t ‘sit well’ with you. (Note the point emphasised in the post that “this does not imply that anyone who holds different assumptions is ‘wrong’”!) That should give us something to work with, so that I can reframe or rethink this into a form that actually works. That’s the hope, anyway! 🙂

  6. Ian Glossop says:

    Good discussion on “fractality”.

    To add a different dimension: as said “fractal” means roughly self-similar at different levels (of magnification for real fractal patterns).

    But here is the rub – in enterprise architecture there is a degree of “uncertainty” – meaning lack of definite knowledge – that varies according to level. Pragamatically and heuristically you may arbitrarily fix some aspect of the architecture – e.g. we shall not introduce more than three new products this year – but this is different from knowing precisely and in detail what the future is going to be.

    So architecting is a fractal game with uncertainty.

  7. Peter Murchland says:

    Tom

    On first pass, I am comfortable with your assumptions and implied constraints. There are a couple of areas where I might choose slightly different wording, but largely, I think we are on the same page.

    I note, though, that there is no reference to shared-enterprise.

    There is plenty of reference to contexts, to fractality, to direct and indirect context.

    I think that aspect that may be “tripping” us up is that there is a need to incorporate relationships to elements beyond the enterprise in the models / views and associated narratives – so the architecture must necessarily describe things in the context that are relevant to the enterprise.

    I also think that the relationship and interaction with the ecosystem within which the enterprise is pursued entails a different set of parameters and considerations, because the ecosystem is not being architected – if it is, then the focus of the enterprise has been shifted.

  8. Peter Murchland says:

    Perhaps I should add – the use of the business model pattern is the key means by which I bring attention to the connection between the enterprise and the ecosystem in which it exists and is pursued. By that, I mean more than the simplistic view represented in Business Model Canvas – but that it is a reasonable place to start. It is also a good example of how a key pattern and artefact is required to attend to elements within and without (using the old meaning of “without” as the opposite of within) the enterprise.

  9. Interesting diagram showing the two types of Business Architecture. I normally call the inner one “Organisational & Chamge Architecture” – which is everything non-IT. HR folk and Nusiness-led programme directors like this distinction. With the increased use of SaaS, this also helps the discussion between configuration activities and more technical (integration) activities that might require a bit more IT nouse. There is also an outer layer to the outer ring – which is eco-system or industry-specific achitecture which has things like regulatory & environmental constraints. Great discussion, thank you. Lorne

Leave a Reply

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

*