Tom Graves / Tetradian

This one started a couple days ago, with a straightforward Tweet-query from Dave Gray:

• davegray: “Strategy is design.” Agree or disagree? Why?

What followed was, for me, one of the best back-and-forth Twitter-conversations in recent weeks:

• nickmalik: @davegray design is a method.  Strategy is a result.  Fair to say good strategy may result from design, or luck, or intuition
• tetradian: @nickmalik @davegray would say that strategy tends to (or should?) come before design – or that they interweave with each other
• oscarberg: Strategy (what & why) primarily requires knowledge, tactics (how, when) primarily requires skill.
• davegray: @tetradian @nickmalik IMO a strategy is not a result. Profits, growth, revenue, etc. are results. A strategy is an approach. // hard for me to see how good strategy can be the result of luck. To me, it can’t be a strategy if it’s not intentional.
• mikerollings: @davegray @nickmalik @tetradian strategy must influence and be influenced by execution – you must be open to learning from happy accidents
• tetradian: @mikerollings @davegray @nickmalik “strategy must influence / be influenced by exec”n – open to learn from happy accidents” >strong agree
• davegray: @mikerollings 100% agree. @nickmalik @tetradian
• nickmalik: @davegray each step in a process produces a result.  The strategic dev step produces strategy as a result.  That step may use design, or not
• davegray: @nickmalik sure, strategy is a result of a strategic dev process, like a plan is the result of a planning process. cc @tetradian
• davegray: @tetradian @nickmalik it seems to me that design and strategy are both methods or approaches, ie, means to an end, with significant overlap.
• davegray: @tetradian @mikerollings @nickmalik 140-character limit constraining. Will write a post & try to make my point more coherently
• tetradian: @davegray @nickmalik in my exp., strategy sets out the intent, design is more about realising the intent (but also feeds back into strategy)
• ruthmalan: @tetradian @davegray @nickmalik Agreed Tom — you’ve better phrased my (playful) reply to Dave yesterday. Also consider: emergence vs intent
• davegray: @ruthmalan @tetradian @nickmalik I think this may be one of those times when words get in the way of meaning
• ruthmalan: @davegray [ @tetradian @nickmalik ]    or the lack of words? Can strategy, like meaning, be emergent? Or is it strictly intentional?
• davegray: @ruthmalan @tetradian @nickmalik strategy can intentionally create opportunities 4 emergence. Also unintentionally, but that’s not strategy // IMO a good strategy in uncertain environment preserves optionality & is ready to pivot quickly
• nickmalik: @tetradian two places where “design thinking” is used: developing strategy and implementing it. Which are we discussing?
• tetradian: @nickmalik design-thinking is used in both strategy and implementation; most of design-doing happens only in execution
• johnt: @davegray @tetradian From strategic planning to purpose and resilience http://bit.ly/vfJxaj >strong agree #entarch
• ArtBourbon: @davegray  @ruthmalan @tetradian @nickmalik looks like I missed a good discussion (strategy, intent, emergence etc)
• davegray: @mikerollings @tetradian I forget who said this: luck is when opportunity meets preparedness
• tetradian: @davegray @mikerollings “who said: luck is when opportunity meets preparedness” – Pasteur: see ch.3 and appdx in ‘The Art of Scientific Investigation’ http://bit.ly/7U1vgy
• mikerollings: @davegray @tetradian #nickmalik “Luck, Serendipity, and the Contextual Strategist” #entarch http://bit.ly/utJWnT >strong agree
• davegray: @mikerollings @tetradian I think context is part of it. Also important is a set of values/principles that guide decisions within the context
• tetradian: RT @davegray: @mikerollings “Also important is a set of values/principles that guide decisions within the context” >v.strong agree #entarch
• ruthmalan: @tetradian – thanks for ptr to The Art of Scientific Investigation – glad you shared it with Dave/Mike and we who follow y’all
• tetradian: @ruthmalan – glad you liked ‘Art of Scientific Investigation’ – one of my all-time favorite books! (eg. see end-summary chap. on Reason)
• ruthmalan: @tetradian There I was enjoying the Serendipity of the chapter on Chance Indeed, that end-chp summary on Reason is wonderful! Thx again!
• mikerollings: @davegray @tetradian values & principles are part of context, and there is no notion of the context setters & the consumer. We all do it.
• davegray: @mikerollings now you have lost me. Is there anything that isn’t part of the context? @tetradian
• mikerollings: @davegray Context=shared undrstndng within which we co-create. So there is context & doing. Some doing creates context w/ others @tetradian
• davegray: @mikerollings so our decisions & actions should be guided by shared understanding. Am I missing something important? @tetradian

As can be seen from the links above, the conversation triggered at least two excellent additional posts:

• John Tropea, ‘From strategic planning to purpose and resilience’ (mostly a long quote from Dave Pollard, but also a long list of pointers to other related articles)
• Mike Rollings, ‘Luck, Serendipity and the Contextual Strategist‘

My own view? I’d say they’re somewhat different: closely related, but somewhat orthogonal to each other. Strategy ‘is’ design in the sense of design-as-intent, but not in the more common sense of design-for-implementation. In that latter sense, strategy is an input into the design-process. Yet in a way strategy can also be in part an output from the design-process – especially when eliciting strategy for detail-layer changes. So yeah, it’s kinda complicated…

Several people, including Nigel Green, Doug Newdick and Kris Meukens, picked up on my comments about architecture versus design in my earlier post ‘Great conversations on enterprise-architecture‘. Nigel kindly wrote a follow-up post on his Posterous blog, and Kris pointed to an earlier blog-post of his own, whilst Doug also added useful comments to both of those blog-posts. As a result, I really ought to clarify my thinking on this a bit…

To me, there’s no fundamental difference between architecture and design: in essence they’re facets or views or emphases or whatever into what is actually the same overall activity, that we might call ‘design-thinking / design-practice’ or ‘hybrid-thinking / implementation’ or a whole variety of other related terms.

In the simplest possible sense, we could say that ‘architecture-design-whatever’ is the way in which we bridge the gap between what we want to happen, what we’re doing towards achieving what we want to happen, and what we’ve actually done towards achieving that aim. Think of it, perhaps, as a tension between future and past, between desired-ends and realised-ends:

Everything that we might ultimately implement via the architecture/design activity can be viewed as some kind of service at some level of granularity, in that it serves the overall aim that we derive from the ‘infinite future’ of the enterprise-vision. The service delivers value to the enterprise – and towards its aims – by acting on one or more of the value-flows that move around the enterprise:

So architecture/design is primarily about change – about creating a new or modified means to deliver in the real world something that contributes towards the desired ends of the enterprise.

The simplest split between architecture and design, as I said in the previous post, is that architecture focusses more on the ‘why’, whereas design and, especially, implementation, will focus more on the ‘how’. But remember that that’s just a semantic choice: they’re always the same overall activity.

Architecture-design is needed throughout all of that spectrum of change from infinite-future to near-future to now to past. At the very ‘top’ – the infinite-future of the vision – we could say that there is no architecture-work that we could do, because the vision is the architecture, the ultimate ‘why’ for everything in the enterprise. Right down at the ‘bottom’ – the unchangeable past – we could equally say that there’s no design, because there’s nothing to change. Between those two extremes, though, both architecture and design will always occur. Which way we view this activity – in other words, whether we say we’re doing ‘architecture’ or ‘design’ – depends on which way we face at any given time, and at any given point on that spectrum.

For example, let’s take the extended-Zachman that I’ve used in a lot of my books and elsewhere:

In effect, it’s a spectrum of layers of abstraction. And if we take just the standard Zachman layers – rows 1-5 – we should be able to see that what’s called ‘design’ at one layer will look very much like ‘architecture’ for the layer below; and likewise what’s called ‘architecture’ at that layer will be viewed as ‘design’ from the layer above. (What we call ‘implementation’ has much the same ‘downward’ relationship with design – which is what’s always been implied by Zachman’s framework, of course.) In other words, they’re all different views into the same activity, depending on which way we face .

Yet it’s still useful to maintain some kind of distinction between ‘architecture’ and ‘design’, to describe the emphasis within the respective set of activities. (Likewise the distinction between ‘design’ and ‘implementation’ – which to my mind is actually the same distinction at the next layer downward towards realisation.) Some suggestions for such ‘useful distinctions’ would include the following:

Design focusses on the ‘how’; architecture on the ‘why’. We’ve already seen that distinction summarised above – though in some ways we could also describe it as the difference between ‘what’ or ‘with what’ (as design), versus the ‘who’, the human needs and desires in the context (as architecture).

Design focusses on use; architecture on re-use. Or, to put it another way, design focusses on making things concrete, explicit, the implementable specialisation of an abstract idea or pattern; architecture aims to identify the generalisations and abstractions that enable the same design-principles to be applied in different ways. Hence, in turn, Zachman’s distinctions between ‘composites’ (design) versus ‘primitives’ (architecture), or TOGAF’s distinctions between SBBs or ‘Solution Building Blocks’ (design) versus ABBs or ‘Architectural Building Blocks’ (architecture).

Design focusses on content; architecture on context. This in effect combines those two points about ‘how/what’ versus ‘why/who’, and concrete versus abstract.

Design focusses on ‘functional requirements’; architecture on ‘non-functional requirements’. In terms of the practice of design or architecture, this is perhaps the most important distinction of all – and also illustrates why the term ‘non-functional requirement’ is so dangerously misleading. To take the example of a bridge, there is no functional difference between between a plank placed across a stream, and an eight-lane highway across an estuary: they both provide the same function (though you might perhaps describe it as the capability or service) of enabling the passage of some kind of land-based traffic across a body of water. Yet evidently there are huge differences between those two implementations of that same function – and those differences all arise from the ‘non-functional requirements’ that describe the qualitative needs implied by the enterprise-vision.

In the same way, an IT-based service that handles only small volumes of simple traffic with low variability and low criticality will end up looking radically different from one that must handle vast yet highly-variable volumes of complex traffic with high criticality and high levels of guaranteed uptime. The function is essentially the same, yet the ‘non-functional requirements’ dictate a very different architecture for each, and hence very different designs and implementations. (Hence the reason why architecture is essential for agile-design – and yet is so often forgotten because of the over-emphasis on function over everything else…)

The qualitative requirements in effect describe the constraints implied by ‘why’ and ‘who’; architecture adapts those constraints into something that makes sense as a ‘high-level design’; design adapts those constraints into something that is implementable; and so on down through the decision-trees and real-world constraints towards real-world implementation, deployment and use.

That’s my take on this for now, anyway – make of it what you will?

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Read more…