Quite a lot, as it happens – though we might need to take a detour or two to get there, of course.

One point is that it’s not quite as simple as ‘thesis, antithesis, synthesis’. In the classic formulation, the antithesis is simply the negation of the thesis: it doesn’t really add anything, and the so-called ‘synthesis’ is then little more than ‘the thesis after we’ve gotten the antithesis to shut up’, which doesn’t add anything much either. All a bit pointless, really.

So to make sense – to get some real value out of it – we need, as usual, to go back closer to the source. And as the Wikipedia page on Dialectic puts it:

Hegel did use a three-valued logical model that is very similar to the antithesis model, but Hegel’s most usual terms were: Abstract-Negative-Concrete. Sometimes Hegel would use the terms, Immediate-Mediated-Concrete.

The formula, Thesis-Antithesis-Synthesis, does not explain why the Thesis requires an Antithesis. However, the formula, Abstract-Negative-Concrete, suggests a flaw in any initial thesis—it is too abstract and lacks the negative of trial, error and experience. The same applies to the formula, Immediate-Mediated-Concrete. For Hegel, the Concrete, the Synthesis, the Absolute, must always pass through the phase of the Negative, that is, Mediation. This is the actual essence of what is popularly called Hegelian Dialectics.

In other words, the antithesis is not a negation of the thesis, but a challenge to the assumptions on which the thesis is based – which then leads to a synthesis that makes real practical sense. And that starts to look a lot more like enterprise-architecture.

Or, more precisely, in the business context, the three distinct roles of business-analyst, business-anarchist, and enterprise-architect.

Which might need a bit more explanation.

The business-analyst role is well-understood, I think. That’s the ‘thesis’ part of the triad, the Abstract, the Immediate. As the name suggests, it’s all about analysis, often about what can be seen in ‘the Now’, about order, certainty, honing the algorithms, defining the ‘best-practice’ methods for making decisions. It’s very good at enhancing efficiency through careful calculation; very good at doing things right.

The catch is that the real world is not just about efficiency, nor only about doing things right: it’s also about doing the right things, about bringing it all together to enhance overall effectiveness. And with analysis alone, it’s all too easy to create something that is extremely efficient at going off at full-tilt but in the wrong direction – which, in terms of its effectiveness (or lack of it), can easily be worse than doing nothing at all.

Oops…

Which is why analysis alone is not enough.

Which is why we need those other two roles: the anarchist, and the architect.

The business-anarchist role is perhaps the least-understood of the three – certainly the least-popular, anyway. It’s the ‘antithesis’ part of the triad, the Negative, but also the Mediated. One of the key problems for analysis is that it’s entirely dependent on its assumptions: everything within that frame of assumptions would be valid enough if the assumptions are correct, yet analysis has no means within itself to test those assumptions, and make sure that they do indeed align with the real world of “trial, error and experience”. If no-one is willing to question the assumptions – or even admit that they are just assumptions - things can get kinda risky, or worse, very quickly indeed…

That’s a really crucial problem there, right at the core of all analysis; yet unfortunately it’s one that’s evaded all too often in a business context. And that’s especially true where the drive for ‘efficiency’ is allowed to override everything else. So if we’re going to get things to work well in the real world, we need some definite means to face those often rather unpalatable facts. And that’s where the business-anarchist role comes into the picture.

It’s an extremely important role, and also an extremely responsible one, too: namely, challenge every assumption. It’s not about ‘order’, but about ‘unorder‘ (to use Cynthia Kurtz‘s valuable term). It’s about challenging, but it’s not negative, not merely challenging for the sake of challenging: it’s about creating space for mediation, for sensemaking in a deeper, more directed sense. It’s not just about doing things right, but also about being sure that we’re doing the right things, too, making sure that every assumption has a solid basis, so that the analysts can do their job well.

And the architect role is about bringing it all together again. It’s the ‘synthesis’ part of the triad; but it’s also about the Concrete, about making things real, being effective – about doing the right things right in a concrete, practical way. It’s about bringing things together such that everything workswell  together, responsive to change as required, and as a unified whole. Where the analyst takes things apart, and the anarchist takes apart the thinking that takes things apart, the architect brings everything together again, by resolving the fragmentation in new, more effective ways.

Some people seem to think that the architect role is rather abstract. But it’s not abstract at all, because the architect is responsible for bringing everything in scope to real, usable, useful completion in the real world. It’s not abstract: in many ways it’s perhaps the most concrete that anything can get.

And yes, it does indeed all start from the abstract. Sort-of.

Yet the point here is that this is also a triad: thesis, antithesis, synthesis; analyst, anarchist, architect. None of these roles stands alone: each depends on each of the others, always in dynamic tension with each other, dynamic balance: “the Concrete, the Synthesis, the Absolute, must always pass through the phase of the Negative, that is, Mediation”. And yet they’re also distinct and often very different roles. Tricky, that…

One way to resolve the architecture of that architecture is to have just one person doing all of those roles – after all, they’re different roles, not necessarily different people. But that can sometimes be quite a ‘big ask’, because each of the roles does demand different skillsets, different paradigms, even different worldviews – again, somewhat tricky. (It’s true, though, that the real ‘business analysts’ of the 60s, 70s and 80s used to do all of that, and many advocates of ‘design-thinking’ and the like would do much the same now. Most advocates of ‘real enterprise-architecture’, too.) But there are many different ways to do it, of course: “whatever works” is probably the best guideline here.

In a small organisation, or a country that has only a small pool of specialist staff, we might not have much choice, because there simply aren’t enough people around to do all the roles required – that was certainly my own experience in Australia over the past decade or so. By contrast, in a large organisations, we might well have the luxury to have separate jobs for separate roles. But whichever way we do it, we have to make sure that all three roles are adequately covered, are adequately supported, and that they do indeed work together in a unified way.

Analyst, anarchist, architect; thesis, antithesis, synthesis. What part(s) do you play in that triad, within your own work? And what happens if any part of it is missing, or out of balance, within your overall enterprise?

Over to you for comments and suggestions, perhaps?

[Many thanks to Anthony Draffin for the initial Tweet that triggered the idea for this article. ]

One possible way to sort out this tangle is to deconstruct a single-sentence description:

• “Enterprise architecture is a business-capability that manages a body of knowledge about enterprise structure and purpose.”

It manages a body of knowledge: it’s a decision-support system, not a decision system. Decisions are the role of strategy, and in a smaller organisation the EA may do that too, but it’s not actually the core of the role.

• If it doesn’t manage an explicit body of knowledge used in organisation-wide decision-support, it’s probably not enterprise architecture

The core business role is to advise: “if you change the strategy, these are the implications on structure, this is the structure we will need; if you change the structure, these are the implications on strategy, these are the kinds of strategy this structure can support”, etc etc.

• If it doesn’t provide executive-level advice, it’s probably not enterprise architecture

It’s about the overall enterprise – the ecosystem in which the organisation operates, not just the organisation itself (which is the preserve of business-architecture). A scope any less than the whole enterprise (business-architecture, applications architecture, technology architecture), it’s domain-architecture.

• If it doesn’t have a whole-of-enterprise scope, it’s probably not enterprise architecture

It’s a body of knowledge about structure and purpose, and especially the intersections between them. If it’s only about structure, it’s primarily an operational issue, or a straightforward structural issue such as software-architecture; if it’s only about purpose, it’s strategy, without any actual attachment to the enterprise or organisation reality. In a small organisation an EA may well also cover some aspects of strategy (e.g. IT-strategy) and will often cover aspects of operational structure (especially e.g. IT-structures), but the real role is about purpose and structure.

• If it doesn’t deal with the intersection of structure and purpose, it’s probably not enterprise architecture

Hope this helps, anyway.

The conventional wisdom is rapidly becoming that Enterprise Architecture is more than Enterprise IT Architecture.

• There’s a lot more to an enterprise than its IT; IT budgets represent about 2% of revenues.

• An increasing number of enterprise architects believe that the rest of the enterprise, often generically referred to as “the business”, should be architected as well.

To address the architectures of things outside the domain of IT, we need a concept of architecture that is not technological, and that is expressed in nontechnical language.

(Full link to Len’s talk Re-Thinking Architecture is here, but may require login.)

Considering how much so many people in ‘the trade’ (though not Len himself, I’ll hasten to add) have put me down, mocked me and a whole lot worse, for saying such things over the past few years, I’ll admit it is perhaps a little galling to see this now described as “the conventional wisdom”… But hey, the message is getting through. At last. At last.

So can now we actually get down to doing this, as a profession? Can we at last get the tool-vendors to give us some tools that will actually work for this purpose? And perhaps can those of us who’ve been stuck out there on ‘the bleeding edge’ for so damn long now get some help and support in doing so? – and perhaps, just perhaps, even some respect for the work we’ve had to do to get this profession to break out of its utterly inane IT-centric rut? :bleakwrygrin:

A slightly wary sigh of relief: hey ho. But yeah, good news. Worth the trip for that alone.

The ‘someone’ in this case is Nigel Green and Carl Bate at CapGemini, and the acronym stands for the following:

• Values
• Policies
• Events
• Content
• Trust

They use it as a checklist for a review-process that happens before the usual “let’s rush off and build an architecture solution”. As they put it, “ask ‘What?’ before ‘How?’” (with ‘What’ meaning more ‘what do we want to do?’ – in other words closer to a Zachman ‘Why’). The aim is to create a proper translation between business and IT – hence the title of their book, Lost In Translation [on Amazon.co.uk], which describes the checklist and how to use it in practice.

In essence, this is the Zachman columns ‘Why’ (Policies), ‘When’ (Events) and ‘What’ (Content), with their Values being the equivalent to my extra ‘row-Zero’ on Zachman. (I note, though, that they’re right to point out that Values permeates every layer, not just at the highest level: this suggests that it really is another dimension relative to the Zachman frame, and that my simplification of it to a ‘row-0′ may be just that bit too much of a convenience… hmm…)

The ‘-’ before the ‘-T’ is there for a reason. (It’s not just that ‘trust’ doesn’t sit anywhere in the Zachman frame. Which it doesn’t – which could be a useful topic for another post?) The key issue in all of this ‘translation’ is trust – or, more to the point, the lack of it. And the aim is to create that trust. Because if the trust doesn’t exist, we don’t have a usable architecture. Or, eventually, an enterprise, for that matter. :wrygrin:

More details in the book, or on their website www.LIThandbook.com, which includes a free download of the introductory chapter. Perhaps still a bit too IT-centric for my taste, but hey, that’s where the big problems are, yes?

Had a really good conversation with Nigel Green on all of this last week, and look forward to hearing more.

All in all, very strongly recommended.