On learning enterprise-architecture

A few days ago Pradeep (I don’t know his surname, unfortunately) wrote a comment to one of my previous posts, asking for advice on learning enterprise-architecture:

I aspire to become a enterprise architect. Not sure if you have written on a topic how someone can become a enterprise architect.

What it takes(Capabilities) and how to work on developing those(Roadmap)for someone who wants to pursue this career path. Please point me to post if you have already written on this. If not would you be kind of enough to share your thoughts on this?

I pointed Pradeep to some of my books – particularly Everyday Enterprise-Architecture – and also two of my previous posts that I thought might help here:

Creating a career in enterprise-architecture– on the mindset and thinking-processes that an enterprise-architect will need
Two roles for enterprise-architects– comparing the roles of internal and external enterprise-architects

Pradeep came back with some further questions, around two distinct themes here: the specialist-generalist, and mentoring. All of which needs answering in some depth.

As you’ll see, there’s a lot in there, so yes, apologies, folks, but this is going to be another long post… but hope it’s useful, anyway.

Enterprise-architect as specialist generalist

This was the first part of Pradeep’s questions:

Enterprise architect is a generalist… One who can connect the dots… someone who can see/paint the full picture… someone who has broader knowledge.
So here are my questions:
How someone can become a consummate generalist without getting insane as there is lot out there to learn because EA is the architecture of the enterprise? How do someone bring focus(Focus to not to focus on particular thing)? How do I create a specialist in me who is generalist?

Let’s just start off by saying that the relationship between specialist and generalist is rarely an easy one… but if you want to be involved in enterprise-architecture – or any form of architecture, really – then it’s a relationship that you’re going to need to resolve. And, perhaps most of all, resolve it within yourself…

Perhaps a thousand years ago, it was not all that unusual for an individual to become a ‘complete generalist’: someone with deep skill in everything – or at least, everything that was known at the time. Even though overall knowledge grows exponentially, for a few rare people in some places it was still just-about possible to do the ‘complete generalist’ three or even two hundred years ago. But these days, the blunt reality is that no-one could do this: the vast scope of information, knowledge and skills that could apply in our overall world are such that any one person would need many, many, many lifetimes to learn them all. And yet somehow we have to able to get things done right here, right now. In short, a seemingly impossible conundrum.

Think of this as two axes: horizontal, for breadth of knowledge, and vertical, for depth of knowledge. The usual solution is ‘go deep’: to specialise, and then perhaps to superspecialise, in ever-narrower domains of knowledge and practice – because going deep into the detail is what gets things done. The danger of over-specialism, though, is that we risk losing the ability to ‘connect the dots’: we get better and better at ‘doing things right’, but we lose the ability to know if we’re ‘doing the right things’. So we need some means to link all those specialists together: and that’s where the generalist comes into the picture. Enterprise-architects are specialists at being generalists.

I’ll talk more about the detail of that in a moment, but first, one very big catch: in most current cultures, specialism is still prized far more than generalism. One of the reasons is that specialists visibly do things, whereas generalists don’t seem to do much at all – connections between things are kind of difficult to describe or to value. To quote the Tao Te Ching:

…therefore profit comes from what is there;
usefulness from what is not there.

No matter how useful the generalism of enterprise-architecture may be, the visible ‘profit‘ will usually seems to come only from the specialists – and hence that’s what gets paid… So as a would-be enterprise-architect, you’re going to need to maintain a visible and valued professional specialism, if only to pay the bills. (In my own case, my fallback-specialism is information-architecture and data-architecture: it’s not the work I prefer, or do best compared to others, but it’s easier for people to see direct value from that.)

And also – and often infuriatingly – as a generalist, you’ll usually seem to come off second-best whenever you’re compared to a depth-specialist in any domain. This is a direct side-effect of that matrix of breadth versus depth: no matter how hard you work, no matter how hard you study, there’s only so much time and focus that you can give – so the more breadth you cover, the less time you’ll have to develop depth in any domain. Back in the days when I still did regular IT-type contract-work, I can’t count the number of times that I was turned down for a gig because I was ‘not enough of a specialist’: yet there were also a fair number of times they came back to me later and asked me to do exactly that gig, because the person they’d picked for the role was too specialist to be much use… You’ll also have to put up with the fact that at first you’ll often be offered lower contract rates for the same gig, because they mistakenly assume that you’re less experienced: all I can suggest there is that you practice your skills in renegotiation, to get a better rate once you have demonstrated that you can indeed do the job – and do it better than the specialist, too.

Next point: many people might deride a generalist as a dilettante, ‘a jack of all trades and master of none’. Given this, it’s really important to recognise that specialist generalists are depth-specialists – they specialise in the skills required for broad-scope generalism. The focus is not so much on content – as a domain-specialist would – but on how different disciplines link together. Some of the skills-challenges here include:

thinking in multiple domain-‘languages’ at the same time, and translating between them as required
thinking and designing in terms of interdependent systems rather than single independent domains (hence design-thinking, hybrid-thinking and suchlike)
thinking in and working with multiple time-perspectives, in some cases ranging from sub-microseconds to millennia or more
identifying, and rapidly learning, the key principles and practices of new domains, and requirements for and implications of linking between them
clarifying and communicating contexts, constraints, designs and design-issues
searching for simplicity (in contrast to specialists, who often love to all but drown in the detail…)
mastering the ‘soft-skills’ needed for negotiation and suchlike, in what will always be a challenging and highly ‘political’ domain of work

Probably the most visible challenge will be around learning all those myriad of different domains: ‘just enough detail‘ to be useful, yet no more than that – because you simply won’t have time to do any more than that. For every domain that your work will touch, you’ll need to learn enough about it not only to be able to converse credibly with any of the specialists in that area, but do so in ways that will enable you to make connections between all of those domains – connections that the specialists probably won’t even know could exist.

There are some huge personal challenges, too: such as the embarrassment of having to admit to others that “I don’t know”, for example, or the endless struggles with self-doubt that, in reality, are usually a sign that we are doing the work properly – even though it certainly won’t feel like it at the time…

Especially in the earlier stages of study, you’ll need to be a voracious reader. Books I would recommend here include:

— Matthew Frederick, 101 Things I Learned In Architecture School – very useful as a book to keep on-hand in your bag or on your desk, to remind you of core themes you’ll need to remember at every moment. On the surface, the book is mainly about building-architecture, but most of the principles described there will apply to all forms of architecture. And his emphasis on the importance of learning to draw likewise applies just as much to enterprise-architecture and the like – as do the crucial skills of story-telling and, even more, of story-listening.

— Simon Brown, Software Architecture For Developers – aimed primarily at software-developers, as the title suggests, but written by someone who ‘gets’ enterprise-architecture far better than many (most?) nominal ‘enterprise-architects’. His slidedecks, too, are especially helpful on how to do sketching for architecture-design – again, applicable directly to enterprise-architecture.

— WIB Beveridge, The Art of Scientific Investigation – probably the classic text on how scientists actually work. Both a practical guide and a real-eye-opener for anyone who thinks that science is solely about logic, the book includes chapters on the role of chance, the use of intuition, the hazards and limitations of reason, the processes of strategy and tactics, and dealing with the personal challenges of doing the work. The examples are mainly from Beveridge’s own field of biochemistry, but are applicable to any kind of research – including enterprise-architecture.

— Christopher Alexander, A Pattern Language – another real classic, and as important to architects as, say, Donald Knuth’s Fundamental Algorithms is to software designers. This is again nominally about building-architecture, but is applicable to all forms of architecture – not least because it introduces and explains the idea and practice of pattern-languages in a very accessible way.

Even more, perhaps, you’ll need to learn to ‘read’ people, or ‘read’ a context – again, very fast, and right to the essence of whatever’s going on. Although some books do give helpful advice on this, in reality there’s no short-cut to developing these skills: the only way that works is first-hand experience, and lots of it – which does indeed take years, whether we like it or not. The trick – such as it is – is to set yourself up and ready to learn something new at any time, from anything and anyone, anywhere. One useful tactic from Pixar’s ‘rules for storytelling‘ (see also the fun Lego version of some of the ‘rules’) is to deliberately do things or go to places with which you’d usually be uncomfortable: study fashion-design, for example, or the complexities of a restaurant-kitchen, or the (to me) horrors of a sports-bar on a Saturday night. Be interested in everything, and in everyone – because that’s how you’d learn to make sense of practical themes such as user-journeys in service-design, for example, or anti-client risks for a business-architecture.

And yes, I know that doing all of that might at first seem crazy-making – a guaranteed recipe for instant-insanity. But if you’re from India, or from a fair few parts of the US or Europe, you’ll have already made a strong start on one of the key challenges here: thinking in different disciplines and ‘translating’ between different domains, because it’s actually no different from thinking, speaking and writing in multiple languages – which you’ll do already if you live in such places. In conventional enterprise-architecture your first task is to learn how to think in and translate between the very different worldviews of IT and ‘the business’; over time you’ll discover that ‘the business’ itself has many ‘languages’, and IT too, for that matter. But once you’ve gotten used to that process of real-time ‘translation’, adding another ‘language’ is actually no big deal. In a strict technical sense, holding conflicting, contradictory ideas and assumptions in your head is a kind of ‘insanity’: but it’s an ‘insanity’ that you do already know how to deal with – so don’t worry about it! 🙂

Mentoring in EA

Anyway, on to the second part of Pradeep’s questions:

Also do you mentor budding Enterprise architect(Apart from sharing your knowledge/thoughts through Blog/Books etc) something like involving in your work(there could be legal implication?) or may be some other way. I am aware of the organizations who provides certification/training so specially looking something from you. If this is something you do or intent to do or if not let me ask what would make you do it 🙂

I don’t do this explicitly as yet – but you’re right, I ought to do so in some form or other. The next question, of course, is ‘How?’… and, for that matter, ‘Where?’, ‘With whom?’ ‘In what format?’, and so on.

I’ll split this into three parts: formal mentoring, structured training, and contextual training.

On formal mentoring, I’d have to admit that my current work really doesn’t fit well with doing that – not in the form that works best, anyway, which is regular and preferably day-to-day contact over several years. The practical problem for me is that I don’t do any conventional long-term project-work these days: I do tend to work in blocks, but it’s mostly spot-work on strategy and the like, typically two or three days with the client or their enterprise-architecture team, and then move on straight away to somewhere else. It can also be literally anywhere in the world, which brings real complications in terms of bringing someone else along with me – including legal implications such as visas and so on, as you say. The only work I’m doing at present that’s sort-of mentor-like is with a group of colleagues in Central America – and that’s more of a peer-relationship rather than a mentor one, anyway.

I’m probably better set up to do structured training. For example, I’m formally accredited to do training in PEAF (Pragmatic EA Framework), which is aimed at the early stages of setting up and running an enterprise-architecture capability and – unlike so many so-called ‘enterprise’-architecture frameworks – is not centred solely around IT. That’s usually run as a two-day course, for which the first half- or one-day section is suitable for time-poor executives.

I’m also in process of restructuring all of my own material into various training-type formats such as a two-day strategy workshop and a five-day ‘EA bootcamp’. These would be a better fit for a somewhat more experienced team that wants to lift their EA-maturity level, or expand outward from old-style IT-centric ‘EA’.

That said, I won’t be doing any kind of certification on this – because, bluntly, I regard many of those current certification-schemes as little better than money-making scams. I do see real value in base-level certifications such as the TOGAF Foundation and Archimate Foundation, because they ensure that people share a common language; but beyond that first-level, far too many of the schemes I’ve seen – and no, I won’t name names here – guarantee only that the person has enough knowledge to get a project into serious trouble, without any certainty of being able to get out of it again. In that sense, certification can easily be worse than useless.

Whilst certification may be all but meaningless, training is not: the catch is that an awful lot depends on the skills and experience of the trainer. For example, TOGAF always needs to be customised to the context of the actual business: so unless the trainer can lead you through how to do that, you almost might as well not do the training. One trainer I know who does a brilliant job of showing how to use TOGAF in (US) federal government agencies is John Polgreen at Architecting The Enterprise: but his name probably wouldn’t appear on the certificate, so a potential employer wouldn’t know that you’d have trained with ‘the best of the best’. Which kind of defeats the object of the exercise. So it’s all a bit of mess, to be honest… Oh well.

In short, I’ll happily do training-courses for you, depending on your needs, but I won’t play along with the ‘certification’ game. If that’s okay with you, let’s talk?

Finally, contextual training – by which I mean some kind of seminar or workshop customised on the spot to match the specific needs of that client at the time. In duration, these typically range somewhere between a day and week, usually dependent on budget and people-availability and suchlike.

I’ll admit that that’s the type of ‘training’-work I most prefer to do – especially as I always learn a lot in doing it. The catch is that I can’t say beforehand exactly what you’re going to get, or what in detail the training (or education, rather) would cover, precisely because it’s adapted to fit the needs of the business-context. Instead, before we start, we’d typically identify some known themes and a rough idea of schedule, and then adapt everything on the fly, to fit the time-constraints and suchlike, drawing on the shared experience of all of the participants – in other words, an Agile-style development. It’s not like a TOGAF or ITIL or Scrum training, where everything’s defined in advance; but I do have a large body of published work available, in this weblog, the books and the slidedecks and so on, so it should still be clear what kind of scope I cover and how in general I would present it to a course – so there’s a fair degree of certainty there even for the most worried training-buyer. 🙂

One possibly-significant point is that unfortunately I can only present in English: I can just-about survive in French, Portuguese or Spanish, but it’s not up to presentation-standard, and those may not be languages that apply for you – so if you need another language, you’ll need to set up appropriate translation for speech and/or text. Obviously there are other practical matters too, such as logistics, visas and legal, and, of course, fees – my apologies, but I do still have to make a living somehow! – but it’s all easy enough to sort out. Whatever you need, really.

If you’re interested in any of this, perhaps let me know?

Over to you, anyway.