A new direction?

It was a good chat, that serendipitous meeting with an IT-recruiter on the crowded homebound train. We’d managed to grab one of the rare table-seats, so I was able to show her my slidedeck ‘Attracting, retaining and getting the best from your architects‘, from my Australian ‘EA Tour’. “Very useful”, she said, “it’s the first time I’ve seen something I could show my staff to explain what architects actually do.”

And we got on to the topic of enterprise-architecture, of course – the role of the enterprise-architect. “It’s dead”, she said. “I hardly get any enquiries for enterprise-architects any more.” She shrugged. “And the few we get, you’re right, they’re not really architecture-jobs at all – not like what you’ve shown me there, anyway. They’re just hyped-up titles for low-paid, low-level software jobs – probably nothing more than that.”

Kinda illustrated my fears about the whole sad mess of so-called ‘enterprise-architecture’ these days. Oh well.

“But there is this new job-title I’m seeing”, she added. “Transformation-architect. I’m seeing a lot of demand for those. And at top rates, too.”

So is that me? Is that the new label that I need for my work – Enterprise Transformation Architect? Time now to change direction?

Hmm… Maybe… I dunno…

Okay, yeah, ‘Enterprise Transformation Architect does have a nice ring to it – a certain rightness, I’d agree.

And yet…

And yet…

In some ways this whole mess around enterprise-architecture kinda reminds of the one-way traffic-system in the city of Bath, in western England. In principle, it’s supposed to keep traffic out of the centre of the city: but the road-layout is such that there’s actually only one possible exit-road, and all the other roads instead loop back into the middle of city again – keeping all the traffic stuck there, fuming in more ways than one. Daft…

But much of enterprise-architecture is like that now, too. Courtesy of Open Group et al, the ‘enterprise-architect’ title is all but meaningless now: lost within itself, a dead-end, even to recruiters. No way forward, it seems.

And yet, like the city of Bath, each time I’ve turned sideways to some seemingly-new direction, it seems it’s brought me back to the same place again. And again. And again. And again. And again

To be honest, even at this point, that would-be ‘new direction’ of ‘Enterprise Transformation Architect’ already looks like it’s heading the same way too.

It seems that whatever I do, whichever way I turn, I just can’t escape from here…

Yet, to be honest, I’m not even sure that I’d want to. Instead, in this endless turning-and-returning, there’s often a sense more like that last section of TS Eliot’s ‘Four Quartets‘:

We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time.

The reality is that, for now, enterprise-architecture is what I do – the place or profession I where I most express what I do. (The real ‘enterprise-architecture’, that is – the literal ‘the architecture of the enterprise’, as a unified whole, a ‘bold endeavour’. Not the tiny, often-near-irrelevant, IT-obsessed subset that still so often purports to be ‘enterprise-architecture’ – that disastrous term-hijack that’s crippled this discipline for decades now…)

There’s no other term that really describes it: it is, literally, the architecture of the enterprise’. Nothing else will do.

(Darn nuisance, then, that that bunch of idiots have hijacked the term to try to make it mean something completely different – a pathetic subset of the real scope of ‘the architecture of the enterprise’. Oh well.)

Yet since I can’t meaningfully use that term any more, perhaps the best option would be describe more exactly what it is that I do. Which, in the process, might also open a much broader market for what it is that I do. It’s worth a try, anyway.

— The core is that I focus on the practice of the practice of enterprise-architecture and related disciplines – helping people within organisations to develop an enterprise-architecture practice, and to lift their skills, their maturity, at the disciplines of enterprise-architecture.

(These days, I don’t do much of the detail-level practice of enterprise-architecture itself, in that I don’t set out to develop an organisation’s enterprise-architecture for them. There’s a very good reason for that: from long experience in ‘the trade’, I’m adamant that the only people competent to do an organisation’s enterprise-architecture are the people who work within that organisation – and, preferably, have themselves worked there for several years as well. In my opinion and experience, few if any external consultants have the social-networks and in-depth knowledge of an organisation that real-enterprise practice will need – and since I’ve always been a consultant, not an employee, that constraint applies to me too.)

— To do this, I develop tools and techniques for sensemaking and whole-of-enterprise architecture. I’m a maker of tools for change – such as SCAN, SCORE, Five Elements and Enterprise Canvas. Most of these are now described in books, ebooks and slidedecks. Later this year, they’ll also start to be described on video – and, if current plans come off, implemented in sensemaking-apps as well.

— And I do training, to help people make the best use of those tools and techniques. I already have a fair amount of training-materials and training-courses ready to go – and will be doing a lot more of that over the coming year).

— As a set of disciplines, enterprise-architecture is still a complete shambles. It’s easy to identify why it’s such a shambles, but pointing fingers doesn’t actually solve anything. Instead, on this blog and elsewhere, I also develop detailed critiques of what doesn’t work, why it doesn’t work, and what to do about it, to make it work properly. (Okay, a fair few people do complain that my posts on this can be kinda long – but unfortunately it does need that level of detail if we’re to have any chance of disentangling some of the more egregious messes that have been made in these disciplines…)

— Like others, I also do in-person consultancy, on enterprise-architecture, strategy and more. Over on LinkedIn, Grant Charles Adams summarised well one key aspect of this kind of consultancy:

What am I good for? You’d have to confirm with clients, but I feel it is my ability to “think differently”. Too often I find my clients locked-in to a way of thinking, or a client-owned method that focuses on the ‘how’ and the ‘who’, but rarely the ‘why’. Considering my successful engagements, because we’ve all had unsuccessful ones too, I am certain they were successful because I understood the ‘why’ and found a way to bring “big-picture thinking” to the work.

— That’s also about creating clarity, about building capability to enact a continual, collective process of sensemaking / decision-making to support action, on purpose. And not imposing a prepackaged ‘solution’, but helping architecture-teams and others find their own solutions from their own context – and own those solutions, too.

So far, so sort-of-same, it might seem. But what’s different, even unique, is that these tools and techniques work together as a unified set, and are fully fractal – in other words, they work together, consistently, always in the same way:

  • for every type of content – things, information, relations and more
  • with every type of activity – people, machines, IT, whatever
  • across every type of context – commercial, social, government, non-profit and more
  • at every level – from strategy to tactics to implementation to operation and back again
  • at every scale – from a single line of code to an entire planet

(In case you’re interested, the technical term for this is metatools, metaframeworks or metatheory – tools and techniques that apply to and reflect upon themselves, recursively. Sounds complex at first, but in practice makes sensemaking and the like a heck of a lot simpler, for everyone.)

All of those tools have strong crosslinks to proven techniques for futures and strategic-foresight – hence Tetradian’s longstanding tagline of ‘The Futures of Business’. That’s not unique as such in enterprise-architecture, but there aren’t many other EA-folks as yet who’d have such tools readily available in their toolkit.

And also almost-unique in enterprise-architecture, my work has a strong focus on enterprise as a human activity, with a strong emphasis on people and the people-issues in the architecture – in contrast to the excessive over-emphasis on IT alone that you’re likely to find elsewhere.

That’s me – sort-of a new direction, though still in much the same space as the old one. So if you need:

  • tools and techniques to make sense of the enterprise, and where it’s going or needs to go – whatever type of enterprise it might be
  • new approaches to ‘the architecture of the enterprise’ – ones that actually work in the real-world
  • enterprise-architectures with a human face – yet still also include the IT and everything else, of course

…you now know who to call for this. 🙂

So do get in touch! – let’s talk about what you’ll need, to build better futures, for your own enterprise and beyond.

Tagged with: , , ,

13 Comments on “A new direction?

  1. I’m glad to hear you say this: “I’m adamant that the only people competent to do an organisation’s enterprise-architecture are the people who work within that organisation – and, preferably, have themselves worked there for several years as well.” (I didn’t actually hear that, except in my head, but, you know … 🙂

    • Yes – to me it’s crucially important. Unfortunately, many of the big-consultancies who sell purported ‘enterprise-architecture services’ do not want people to hear this… 😐

  2. Oh, sorry, I also meant to comment on the transformation bit. There was a period during my IBM years that we embarked on defining the Business Transformation Architect (BTA) role. I was never very happy with that, for several reasons.

    The word I’ve been using (without, as yet, turning it into a role label) is coherence. The way I think about this, it cuts across all the specialties, and all the projects, and all the ‘solutions’, and all the transformation efforts. Maybe a useful label would be Chief Coherence Officer (since people all seem to want to be chief officers of some kind or other?)

    • On ‘coherence’ in relation to enterprise-architecture, do take a look at the work of John Götze and the others in that general group around Copenhagen’s IT University and the like. Perhaps particularly the anthology he edited with Pallab Saha, Gary Doucet and Scott Bernard, ‘Coherency Management: Architecting the enterprise for alignment, agility and assurance’ (AuthorHouse / International Enterprise Architecture Institute, 2009).

  3. Re the phrase ‘the architecture of the enterprise’.

    Does any Enterprise Architect really work on ‘the architecture of the enterprise’?

    I have never seen any enterprise architecture methodology/framework/approach, etc etc that has organisational structure in scope.

    I would have thought that the way the people are organised and managed is an integral part of ‘the architecture of the enterprise’.

    Or have I missed something?

    • Yes, you’ve missed something. Probably, anyway.

      All of my work, for the past near-decade, has been about ‘the architecture of the enterprise’. At present I’m perhaps the leading proponent of that approach, but I’m by no means the only one – see the work of Chris Potts on enterprise-investment, for example, or Kevin Smith on ‘pragmatic EA’.

      Re organisational-structure, my Enterprise Canvas model-suite explicitly has organisational structure in scope, as it describes management in terms of services that themselves can be modelled via Enterprise Canvas. Doug McDavid takes a similar approach with his emphasis on organisation-as-services; and in his Enterprise Evolver toolset, Syed Suhail Ahmad includes some aspects of the interplay between organisational-structure and capabilities. Even TOGAF 9 has some thin indications that organisational-structure might be at least somewhat relevant in EA. So yeah, it’s there – if we remember to look for it

      Sure, the IT-folks make lots of noise about what they mistakenly describe as ‘enterprise’-architecture – but what they’re doing is merely enterprise-IT-architecture, not enterprise-architecture as such (or, to be more precise, they’re only doing a tiny subset of EA but pretending that it’s the whole). I’ll admit it’s kinda hard sometimes to see us in midst of the mess that the IT-folks are making of ‘the trade’, but yeah, we are here. Don’t miss us, please! 🙂

      • Tom,

        I delved a bit into your Enterprise Canvas model-suite and came across this:

        “a service-oriented architecture models everything as services”

        FYI, I trained as an electronics engineer, and have post graduate qualifications in control engineering and a PhD in computer modelling, so I claim to have some expertise in this area.

        My concern with modelling an enterprise in terms of services is that it makes non-functional requirements difficult to manage and deal with. It also makes emergent characteristics such as performance and whole of system optimisation almost impossible to define and achieve.

        IMHO, SOA is a perfectly acceptable modelling technique but should not be the only approach when dealing with complex, multi-variable, non-linear, dynamic systems.

        • @Bernard: “FYI, I trained as an electronics engineer, and have post graduate qualifications in control engineering and a PhD in computer modelling, so I claim to have some expertise in this area.”

          I didn’t, I don’t have, and in many ways I don’t. I ain’t nothing special: it’s probable that my only claim to competence is that I’ve been doing this for rather more than forty years in a couple of dozen different industries in perhaps a dozen different countries, and that I look at things with a professional generalist’s eye.

          (I’ll freely admit that for software-engineering etc I’m largely self-taught – or, rather, trained at ‘The School of Hard Knocks’, such as whilst developing a significant chunk of the desktop-publishing industry and its software from scratch, back in the late 70s to mid 80s. FWIW, I trained as a graphic designer, followed up with a masters degree literally in ‘General Studies’ from London’s Royal College of Art – I covered such a huge range, from medical education to media design to psychology to print-production to publishing-industry to marketing to retail to workflow design to systems-engineering and much, much more, that they gave me a department of my own… 🙂 )

          @Bernard: “My concern with modelling an enterprise in terms of services is that it makes non-functional requirements difficult to manage and deal with.”

          That’s a really important point – and yes, it’s a huge problem/risk if we develop services in the classical engineering-oriented way, as a purely technical system. However, Enterprise Canvas assumes that we approach it as a socio-technical system, in which people are inherent elements (not least because they’re the system-elements for whom the respective services most often actually exist). To give a simple engineering example, the output of a steam-engine is classically controlled by a regulator-valve – but it needs a human as part of the overall socio-technical system to calibrate the regulator according to so-called ‘non-functional’ requirements. See the post ‘Services and Enterprise Canvas review – 3C: Validation‘ for more on this.

          @Bernard: “It also makes emergent characteristics such as performance and whole of system optimisation almost impossible to define and achieve.”

          Again, a good point – though other than services, what metaphor or guiding-concept would you use for this? In Enterprise Canvas – again, with an emphasis on socio-technical system rather than purely technical-system – I’ve taken a three-fold approach to that:
          — fractality (a service is always in context of a larger-scope service – hence emergent-effects should become visible at larger scope, even within the same overall service-frame);
          — the ‘Validation’ service-relationships, as above (expanded VSM ‘system-3*’);
          — and some aspects of the ‘Coordination’ service-relations (expanded VSM ‘system-2’).

          For more on the latter, see, for example, the post ‘Services and Enterprise Canvas review – 3B: Coordination‘.

          @Bernard: “IMHO, SOA is a perfectly acceptable modelling technique but should not be the only approach when dealing with complex, multi-variable, non-linear, dynamic systems.”

          Of course – strongly agreed. IMHO, as an enterprise-architect, no technique should ever be ‘the only approach’ to anything. 🙂 We always need cross-checks from other approaches; and when one approach ceases to be useful, we need to let go of it – keeping only the learnings that came from it – and move on.

  4. One of the problems I have with many of today’s supposed EAs (and I’m not talking about you, Tom, you are as much a lateral thinker as I believe I am, but from a different starting point) is that they believe they are doing something new and different.

    In 1950, Norbert Weiner wrote a book “The Human Use of Human Beings”, which I read in 1969.

    In the copy I have, there is an afterword, written by Walter A. Rosenblith in 1967, in which he says:

    “Learning involves feedback, according to Wiener. This crucial concept, which is taken over from the control theory of the engineer, consists of modifying the behaviour of a system by reinserting the results of actual (and not just expected) past performance.”

    Question: How many enterprise architecture approaches embody feedback in the development process or in the systems being developed? Any approach that tries to define a “target state” almost certainly doesn’t.

    On this page

    are these quotes from John A. Zachman, 19 November 2015:

    “If you really want to engineer an Enterprise, a lot of good work has already been done. You don’t have to know everything… you just have to do some research.”

    “… most of the problems we have today have already been solved and extensively documented but nobody is taking the time to read what has been written.”

    IMHO, the big danger is people stumbling into EA from a technology background, thinking they are trailblazers and trying to re-invent the wheel.

    The result? EA is one of the few disciplines that seem to be going backwards and the people responsible are totally unaware of why.

    • @Bernard: “One of the problems I have with many of today’s supposed EAs … is that they believe they are doing something new and different.”

      Regrettably true. Many of them have so little grasp of either history or context that they think that EA started with John Zachman in 198whatever… (If we bother to look, there are clear examples and antecedents all the way back to Lao Tsu and the ‘Tao Te Ching’ c.500BCE, and probably much earlier than that in other cultures. Bah…)

      @Bernard, quoting John Zachman: “If you really want to engineer an Enterprise…”

      As a metaphor, ‘Engineering the enterprise’ is somewhere between dangerously-misleading and flat-out wrong. I wrote about this somewhen last year, in the blog-post ‘John Zachman and the curate’s egg‘.

      @Bernard: “The result? EA is one of the few disciplines that seem to be going backwards and the people responsible are totally unaware of why.”

      Yep. 😐

      Hence why I’ve been working nigh-on flat-out for the past decade and more on finding ways to sidestep the mess, and develop tools for ‘an architecture of the enterprise’ that actually work. As you’ll see on this blog and elsewhere. (Yet since there’s always vast amounts of money available for hype and wishful-thinking and propping-up-delusions, but not much if anything for things that actually work, it’s been more than a bit of a struggle keeping going in that. Oh well. But that’s another story, of course…)

  5. From the blog-post ‘John Zachman and the curate’s egg‘.

    “the Zachman Framework is a ‘curate’s-egg’: it looks good on the surface, but is deeply-flawed, in many different ways – flaws that have been embedded in the framework right from the start, and yet have not been properly addressed at all in the three decades or so since then. Useful though it is in enterprise-architectures, the framework can be dangerously misleading if not used with care, capable of causing very real damage to the respective organisations – and we ignore its flaws at our peril.”

    Totally agree, which is why I wrote “Beyond the Zachman framework: Problem-oriented system architecture” which was published in the IBM Journal of Research and Development. Volume 56, Issue 5, September/October 2012.
    This is a copy of the paper
    http://www.drbrd.com/docs/Problem-orientedSystemArchitecture.pdf

    In your blog you quote Zachman ‘– (on use of frameworks) “Please explain to me the business-problem you’re trying to solve, and how you plan to solve it.”’.

    If you read Zachman’s original paper he says the role of the architect is to ask the business person what the solution is and the architect writes down the “requirements”.

    All the frameworks I have seen centre on “requirements”, which are a description of a solution. From my perspective, this is the most serious flaw of Zachman and all the other framework approaches.

    BTW, I was around doing system architecture when Zachman published his paper. I worked with people from IBM who knew him. I was told that Zachman was part of a team of IBMers who developed the approach and that Zachman was the one who wrote it up. The story was that Zachman was the communicator and had little to do with the development of the approach. The fact that there are so many flaws in the approach and that he has done nothing to address them seems to bear that out.

  6. Tom

    There seems to me to be some merit in the thinking behind “transformation architect”, but the thinking I am referencing would lead in a different direction.

    It has seemed to me that one of the problems facing EA is that it is a tool, so there is the risk that it becomes a solution looking for a problem, and that it also treats everything as a “nail” (as per the hammer story).

    It is incumbent on us as EAs to apply our own discipline to our discipline. That requires us to understand stakeholders, concerns, enterprises, environment, outcomes, etc. In particular, a common technique in considering services is to identify the customer lifecycle towards which these services are directed.

    What is the customer lifecycle for EA? It is the enterprise development lifecycle – how an enterprise goes from recognising the need to develop (mature / change) through to realising its new state of development (maturity). Oftentimes, this is expressed as a business transformation strategy, roadmap and program – hence, the genesis of the transformation architect.

    Of course, the role name is more problematic, because there are so many involved in shaping enterprise development strategies and programs. In a fully mature enterprise, the vast majority of EA tasks would be attended to by people with non-EA titles.

    It seems to me that in these situations, the EA is called upon to be an “enterprise development assurance officer” – but I don’t expect that title to take off!!

Leave a Reply

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

*