Enterprise-architecture as vectors

A great conversation yesterday evening with a former colleague from Sydney, Robert Phipps. Rambling over a range of enterprise-architecture themes: about the distinctions between organisation and enterprise, about the role of values in the defining vision (or ‘venture’, as he put it – a useful term), about the flow of value around the shared-enterprise, and the usefulness of Business Model Canvas but its limitations for a not-for-profit government department – in other words, all the usual EA topics. 🙂

But there was one almost throwaway remark he made that caught my attention, that could be a very useful avenue to explore: the enterprise composed not of entities but vectors.

(He’s been brewing on this theme for quite a while, it seems, but unfortunately hasn’t written much about it as yet – will chase him to do so when he gets home from his holidays!)

What excites me here is that this could be a way to break enterprise-architecture discussions out of the wretched trap of talking about supposed states – ‘present-state’ versus the non-existent ‘future-state’, and so on. In effect this model uses the old physics metaphor of particle versus wave, but applies it to enterprise-architecture. The usual ‘components’ or ‘building-blocks’ are like particles, and hence it’s easy to fall back into the language of ‘states’. But if we see the same quantum-like entities in a guise of wave rather than particle, this suggests the notion that everything has a vector, a trajectory of change, with direction, velocity, even with its own mass or inertia – but not a ‘state’. A project or whatever doesn’t change the organisation from ‘current state’ to ‘future state’: instead, it provides a vector that points towards a particular direction at a particular speed. The vector does sort-of imply a ‘future state’ at an arbitrarily-chosen future point in time, but that kind of frozen-time snapshot belies the dynamics of what’s actually going on. And vectors intersect: hence whilst a single vector may point to a ‘future state’, the interaction of all the vectors will inherently take the overall system someplace else.

Architectural alignment also makes more sense in the terms of this metaphor, too: we’re not lining up a bunch of particles, but aligning the vectors. Or, another way to look at this would be in terms of Brownian motion: all the different vectors coincide and intersect and interact to drive larger, more visible ‘particles’ (business capabilities, perhaps? or even the organisation as a whole?).

Just seems a nice idea, anyway. Comments or suggestions, anyone? (And if so, let Robert know via Twitter at @robert_phipps ?)

19 Comments on “Enterprise-architecture as vectors

  1. This brings in the idea of a photograph versus a movie. It’s movement. We are so used to taking and telling a story as a point of time versus the story of going between points.

  2. Tom, thanks for sharing this idea of Robert’s. As I read your brief description, I could see how it might help with better describing the value of initiatives and projects to move the business forward in the environment that it does business in.

    Thanks very much … I will be looking for a post by Robert.

    Cheers, Leo

  3. Agree with the fact that state is not a good representation, yet vectors… not sure about that either. It does however points out that we must look at EA as a dynamic thing. Hence I generally refer to it as a rolling holistic or having a trajectory.

    It sits along the lines with what a lot of people use at the moment in the BPM and BA space. “As Is” and “To Be”…. as there is nothing in between.

    Nice to say that a company is about people…. Not so much so. A company is about the orchestration and choreography of its resources, which can be dissected into entities or particles if you like. People are just there as an supporting mechanism.

    Interesting though.

    H

  4. Pat – yes, a useful distinction between photo vs movie.

    One point I get from Robert’s idea of vectors is that it helps us to refocus on the dynamics of the organisation. Far too often current EA methods and toolsets tend to reinforce an entirely false and misleading notion of ‘snapshots in time’ – future-state, intermediate-state and so on. We need to break free from that: a ‘vectors’-type approach won’t be the answer to everything, but it would certainly help.

  5. Peter – “a company is about people not vectors or particles”. Yes, in most ways, strongly agree – especially if anyone starts to view people as ‘things’ again, rather than as people.

    There are some contexts, though, where a ‘vector’-type view can be useful. Take a look at this clip from Koyaanisqatsi: if you imagine the people as particles in a kind of human Brownian-motion, what are the underlying vectors that impact on and impart those flows? And what is the human experience of being in that kind of flow? Now expand that up to an enterprise-scale, with all of the interactions of people within that enterprise as flows: it’s not ‘the answer’, of of course, but it’s a useful way to explore what’s going on, and how to describe it to others.

  6. Leo – thanks for the thanks! 🙂 As I’ve said, this is primarily Robert’s idea, not mine: I’m perhaps adding my own perspective on it, but I would definitely refer you to Robert for the detail.

    The good news is that that detail is probably coming a bit quicker than I’d expected: Robert’s on a longish vacation with family, but it looks like he’s been encouraged by the very positive response that he’s had via here to his ‘vectors’ concept: he’s promised a lengthier post soon. Will let people know via the usual channels when he does it post it, of course.

  7. Henk – perhaps it’s not so much whether a vector concept is more ‘correct’ than a particle-type approach, but more whether either is useful in any given context.

    The whole point of the particle-vs-wave dichotomy in physics is that in essence they’re mutually incompatible: each is a way of describing the entity (or whatever you might want to call it), but it’s not what the entity is. And each has its limitations: if we describe the entity as a ‘particle’, we can tell where it is, but not where it’s going; if we describe it as a wave, we can tell where’s going, but not where it is – and in fact it’s important to remember that in that view it ‘exists’ simultaneously on all possible points in vector. ‘Particle’ or ‘wave’ is just a map: and the map is not the territory, the entity is not actually either wave or particle, but something that somehow encapsulates both, and a lot more besides.

    I’d agree it’s sort-of true that, from a company’s perspective, we can sort-of say that “people are just there as a supporting mechanism” for the company to marshal its various resources. But as Peter says, that view has even more hidden dangers than the ‘particle’ or ‘state-based’ view of process or anything else. Whilst the company itself may be a structure of rules and responsibilities (which, by the way, ultimately always lead back to people), the broader enterprise, by definition, is a human structure, made up of very human feelings and commitments. We can’t remove the people from our view of the enterprise, because the people are the enterprise. The fact that so many companies do indeed attempt to ignore all of the human aspects, and try to force everything instead into an IT-centric, rule-bound myth of ‘control’, merely indicates just how out of touch with reality so much of existing ‘enterprise’-architecture happens to be. Sigh…

  8. The idea of looking to the enterprise architecture with a difference lens is very interesting. This kind of dynamic view based on changes would complement the static view based on states. Definitely worth digging into this. So content is great.
    About the context I happen to agree to the previous critics. Analogies are very useful for inspiration but as useful for communicating ideas or transferring knowledge. Similarities of two domains are very limited, not only that but because we’re not expert on one of the topics (otherwise that wouldn’t be analogy, more like an ‘obvious’) and our understanding is also limited and it varies from person to person. I almost cannot follow the arguments about wave vs particle, I guess I have a very different view of it. For example for me, quantum physics is all about states, difference to classical physics is that the state is a vector, but this vector has nothing to do with _change_ as in enterprise, it’s merely a mathematical construct nothing to do with reality. On the other hand, from my perspective better analogy would be Hamiltonian mechanics which ‘provide a new and equivalent way of looking at classical mechanics’ based on momentum instead of location (in Lagrangian mechanics). http://en.wikipedia.org/wiki/Hamiltonian_mechanics But these are just analogies, if I think about it a little more, most likely I’ll find out actually they’re not similar or I don’t know enough about the topic to go in more detail.
    Shorty topic is interesting, but enterprise architecture and quantum physics are not really very similar.
    Oh, by the way, if you check out this beautiful rotated cynefin-like diagram of physics domains you may think that enterprise architecture is matching to quantum field theory: http://en.wikipedia.org/wiki/File:Physicsdomains.svg

  9. Clearly the word “vector” is just a metaphor. But I agree that EA needs a more robust way of talking about change.

    A typical enterprise is teeming with lots of different change initiatives, some of which may be formally constituted as “projects”. Each one is based on a false or simplistic theory about the current state of the enterprise (AS-IS), and a naive or optimistic theory about the future state of the enterprise (TO-BE). As the vector metaphor suggests, these projects and other change initiatives interact (compose themselves) in usually unpredicted and possibly unpredictable ways. Sometimes the initiatives merely cancel each other out, leaving the essential characteristics of the system largely unaltered. (The ability of complex systems to preserve their identity and deep structure in the face of efforts to change them has been studied by many systems theorists, including Meadows, Beer and Maturana.) However, the participants in these projects usually resist perceiving the full richness of what has happened; they try to convince themselves and their bosses that the intended outcomes have been more or less achieved, and that something else is now required. Thus the cycle begins again.

  10. Tom. This is an important message and a good metaphor. To expand further on the quantum physics aspect, we’re could say we’re talking about (target) architecture as a probabalistic state. The value of a “to-be” architecture is then primarily to help us understand the benefit being realized by the steps along the way. We know that the world will have changed around us (as it does with increasing rapidity) before we get there. So a good target is one that allows for change and uncertainty, whereas a good interim state needs to deliver concrete value within a timeframe that takes account of the change cycle.
    Personally I’m no fan of “as-is” models either. I’d rather put the effort into what the phase 1 result will look like. In my experience that’s often the most effective way of avoiding the false/simplistic view, which Richard mentions. Not suggesting the problem is then solved but it helps, because people are then focused on what needs to change.

  11. @Peter Bakker – Peter, thanks for the link to Senseable – a lot to explore there! Will admit I don’t yet see the link with enterprise-architecture, other than through the value of visualisation etc, but will aim to get a better understanding once I’ve had a chance to explore.

  12. @Iyigun Cevik Iyigun – thanks also. I will admit that to me this is still mostly a metaphor, a way of breaking out of the dreaded ‘current state’/’future’ state straitjacket. As I’ve said above, I’m really doing little more here than making a very preliminary report on someone else’s work, and I don’t yet have enough detail to make reasoned arguments ‘for’ or ‘against’ any particular way to take this forward. The good news is that Robert has now said it’s spurred him to get his thinking down in writing, in more detailed form: I’ll let people know as soon as that happens, and can discuss that in more depth with him then.

    “I’s just the messenger, guv’nor – honest!” – well, that’s my excuse here, an’ I’m stickin’ to it… 🙂 (But at least it does seem a useful idea that people want to argue about, anyway, which is definitely good.)

  13. @Richard Veryard Richard – yep, to me at the moment it’s essentially a metaphor. As I understand it, to Robert it is more than a metaphor, but I’ll have to leave the detailed explanation to him.

    On Beer, Maturana, Meadows and the like, we already “agree violently”, I think? 🙂 I may put it (a lot) more clumsily than any of them, but that’s the general vector I’m aiming for, anyway.

  14. @Stuart Boardman Stuart – likewise thanks – and yes, that’s a really good point about viewing the so-called ‘future state’ as probabilistic rather than deterministic.

    To me the real point, as you suggest, is that ideas about ‘future state’ and the like provide a frame to keep people focussed on what they’re aiming to do, and also to keep them talking with each other about how to create delivery of the next concrete activity towards that goal. In my experience the great value of visioning and the like is that it creates tension towards a ‘future intent’, but without dressing up that future as a misleading ‘goal’. Once we understand that everything is an ‘intermediate step’ towards that unreachable beyond-a-goal, this allows what we might describe as ‘corrective vectors’ to realign with the desired direction. Ideas about ‘future state’ can often end up creating vectors in entirely the wrong direction, because people become focussed on what is now a ‘past state’, or a temporary staging-post, rather than the longer-term flow.

    As I said, above, to me this is still an abstract metaphor; but I understand that to Robert it’s more than that. So whilst it’s useful to continue exploring as a metaphor, we may have to leave detailed exploration at a more concrete level until Robert comes up with a more explicit description. Watch This Space, I guess?

  15. @Tom G
    @Tom

    For me the link is that modeling and planning a system (city or enterprise) is nice but not very valuable without taking the dynamics into account. The senseable city project is an example how you can visualize the dynamics by using realtime info and why those visualizations are useful for the design & planning process.
    A bit like our brain using realtime info from our senses to constantly model the world around us and make predictions about possible future states/outcomes.

  16. Sorry for those who wrote vectors are too abstract. I much appreciate the vector metaphor. Thank you!

    The item and discussions reminded me of something that I read and is even more abstract: chapter 25 ‘Who Shooves Whom Around Inside the Careenium’ of Douglas Hofstadter’s book ‘Metamagical Themas’ (his sequel of ‘Goedel, Escher, Bach’).
    There I find ‘proof’ that all of you are right at the same time.
    Citing the book (p.783): “That is the metaphor of the ‘careenium’ — a kind of enormous arena in which billions of marbles careen around, bashing into each other unconsciously, and yet which gives rise, when one stands back and look at the whole, to a vast consciousness. The title question, ‘Who shoves whom around inside the careenium?’ concerns how to look at such a system, one that has various levels of description. The central issue is whether the marbles shove the total system around, or whether the desires of the system as a whole shove the marbles around. It’s a slippery issue, and pinning down the nature of free will — referred to also as /free won’t/ in the dialogue! — is the name of the game.”

    When ‘system’ is mapped to ‘organisation’ or ‘enterprise’ and ‘marble’ is mapped to ‘person’, I see an application of Douglas’ chapter 25.

Leave a Reply

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

*