Been re-reading Len Fehskens’ presentation “Re-thinking architecture” [may require login] at the last TOGAF enterprise architecture practitioners conference in Munich. His intro [public] indicates at last a fundamental shift in thinking about enterprise architecture, away from the inane IT-centric world towards a real architecture of the enterprise:
Most thinking about IT architecture as a discipline has been shaped by the ideas of the software architecture community, which in turn grew out of the software engineering and structured programming initiatives of the late ’60s and early ’70s. Increasingly, though, IT architecture is less about programs and more about solutions and enterprises, of which software is only a part. Does this shift in the focus of IT architecture require a corresponding shift in the way we think about architecture? Many practicing solution and enterprise architects believe it does, and this session will re-examine the role of architecture from this perspective.
Gratifyingly, or perhaps worryingly, there were several slides which were all but identical in mood, if not content, to my own presentations at TOGAF Paris, eighteen months ago (“Unpacking TOGAF’s Phase B: business transformation, business architecture and business buy-in” – just discovered it’s not up on the Tetradian site, an oversight which I must remedy Real Soon Now 🙂 ) and at TOGAF Glasgow earlier this year (“Enterprise architecture and the service oriented enterprise” [PDF] – and that one is up on the Tetradian site!). He even included one slide which used exactly the same New Yorker cover to illustrate the limitations of an IT-centric perspective.
(Likewise Business Architecture lead Dave van Gelder’s intro to the session, and Open Group Fellow Walter Stahlecker’s presentation “The quest to apply architecture holistically” (summary and PDF [may require login]) often seemed to be echoing what I’d presented at those conferences and discussed with them in person: “…the implications of addressing architecture of an entire enterprise … possible adaptations of TOGAF for use with the whole enterprise…” and so on, with again some of the text and diagrams that could easily be said to be drawn from my previous presentations. Gratifying in one sense, yes, and all of them nice guys, earnest and honest and genuinely committed to what they do; yet it’s still a trifle galling that I didn’t get any acknowledgement for it at all. A passing reference to “builds on work by … the TOGAF Business Architecture Working Group”, perhaps, but that was it – a ‘working group’ which they’d offically excluded me from last year, and asked me to join this year, but then in effect asked me to pay them several thousand pounds to be ‘allowed’ to correct the disastrous mistakes in TOGAF’s design, and hadn’t bothered to contact me since. So yeah, I will admit I’m more than a bit miffed about it all: be nice to get some acknowledgement for all the work I’ve done, and even – though I’ll accept I ain’t holdin’ my breath for this – ‘twould be nice to actually be paid for some of it too… 🙁 Hey ho…)
But there was one slide in Len Fehskens’ presentation, ‘Architecture vs Design’, which to me was new, and which gives a very useful tabular comparison of the differences between architecture and solution-design. A handful of examples:
- Architecture: about the entire entity in its environmental context; Design: about components and subsystems of the entity
- Architecture: a different architecture implies a different mission; Design: different designs may address the same mission
- Architecture: defines a class of acceptable solutions; Design: defines a single specific solution
- Architecture: role of the architect is mostly to make correct inferences; Design: role of the designer is mostly to make correct decisions
The last item triggered a fair bit of discussion: Len was trying to show that architecture and design are fundamentally different, but wasn’t quite getting his point over – especially to some of the non-English speakers, for whom ‘inference’ and ‘decision’ seemed essentially to be the same. It was only later that I realised that the critical difference there is around a linkage between two other themes that Len had mentioned, about ‘values’ versus ‘business-value’, and architecture as ‘upstream’ requirements versus design as implementation of ‘downstream’ requirement. So here’s my suggested addition to that list:
- Architecture: explores the values of the business to derive its structure and logic; Design: uses the structure and logic of the business to derive business-value
Design operates within a logic; architecture creates that logic. By definition, logic cannot assess the validity of its own premises; it needs an alogical process outside of itself to do so, and that’s the real service (or one of the key services, at least) that architecture provides. To many people in business, and perhaps even more in IT, architecture often seems vague and blurry and indefinite – but that’s what an alogical assessment of values will need, from which to derive the business logic which the designers can use.
Something to think about, anyway.
And yeah, for the reference to the Open Group folks in general: please note that you did see it here first? Oh well… the joys of the Outsider again, I guess…