Thinking of Enterprise Architecture as Vectors
Tom Graves and Robert Phipps propose a vector metaphor for enterprise architecture (EA), specifically viewing the enterprise to be composed of vectors rather than entities. This distinction brings out the inherent dynamics in the formulation of an enterprise architecture which is essentially a result of complex interactions of various change vectors rather than frozen states in time.
Tom Graves in his blog entry on "Enterprise-architecture as vectors" describes the interesting analogy between particle-wave duality and enterprise-architecture:
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.
Stuart Boardman describes another salient feature of the wave analogy to establish an approach to EA:
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.
While Robert Phipps is working on a detailed approach to be described on his blog soon, his tweets reflect his thought process to take this analogy beyond being just a metaphor:
@pbmobi @leodesousa @nickmalik vectors are defined on spaces which are constructed from orthogonal dimensions representing characteristics.
@pbmobi @leodesousa @nickmalik basic theory comes from gardenfors conceptual spaces - 'the geometry of thought' but using dimensions from EA
@pbmobi @leodesousa @nickmalik gardenfors shows conceptual space of interlocking dimensions. Both system state& vectors can be defined there
@pbmobi @leodesousa @nickmalik by constructing a space like gardenfors speaks of but using #org and #entarch characteristics as dimensions.
Conceptual Spaces in a very broad sense is an attempt to represent concepts using a geometrical structure with multiple quality dimensions. This approach from the field of cognitive science is applied in the development of artificial systems capable of solving cognitive tasks.
Richard Veryard agrees to the metaphorical comparisons and dwells into the need for representing the dynamics:
And EA needs to understand the complex interaction between many different changes. 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 enterprise-as-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.)
David Sprott was quick to agree and added that the CBDI-SAE reflects this spirit through the concept of continuous evolution. He specifically focuses on the modernization effort in various organizations and the need to view it as a multi-dimensional activity rather than a linear transformation from one state to another:
But I suggest we need to go further; to view modernization as a more holistic and multidimensional activity which plans and delivers a progressive transformation of the As-Is business through a series of maturity states on a number of (yes OK) vectors. The vectors may include:- Architecture: Business, Service, Information, Social Network, Implementation, Technology, Deployment- Portfolio: progressive componentization and transition engineering- Service architecture: progressive delivery of the service based business- Cloud: progressive unbundling- Standardization and Differentiation: adopting commodity services where it makes sense and delivering strategic differentiation where it is a business imperative. Naturally using cloud as a key enabler of both- Organization: transformation of IT organization ownership to a core business activity- Process: transformation to continuous evolution- and there are many more. Note CBDI-SAE practitioners, we might label these Streams.
Critics were concerned about the abstractness of the analogy and the possibility of losing information in translation:
Way too abstract, a company is about people not vectors or particles…
Analogies are very useful for inspiration but not 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.
What are your thoughts and reactions to this metaphorical vector approach to EA?
Thanks for the comments on the 'Vectors' article
You don't seem to have included a link to the original post, though. So in case anyone needs it, here it is: 'Enterprise-architecture as vectors'.
This is why architects MUST code...