People-skills – the forgotten EA skillset?
There’s been a long-running thread on LinkedIn about the purpose of enterprise-architecture. Started by Kevin Smith of Pragmatic EA fame, the aim was to provide the shortest-possible summary of the business-purpose for EA. For a long while most of the responses conformed to Kevin’s request to limit the summary to no more than 160 characters – a good challenge, even if most of the answers were still hopelessly IT-centric – but the thread has now moved to a more considered analysis.
One contributor there I greatly respect is South African Roderick Lim Banda. His work on knowledge / architecture / systems / engineering approach is one of the most comprehensive in the field, and draws on the classical Vituvian notions of venustas, utilitas, firmitas (aesthetics, function, structure) as the core for an architecture of the enterprise. On skillsets for architecture, he wrote:
I think a good EA has a combination of all types – theorist/philosopher, academic, architect. The Vitruvian definition of an Architect still applies:
1. Should have an imagination
2. An understanding of the theoretical and practical aspects of construction
3. Should be versed in: Letters, Drawings, Geometrical Instruments, Optics, Arithmetic, History, Philosophy, Music, Medicine, Law, Astronomy
Agreed. But there’s one further skill-set missing from that list, that trumps all the others: people-skills.
EA is hugely political. If we use the IEEE-1471 definition, an ‘enterprise’ ispeople, collaborating and sharing resources towards shared aims and goals. EA isn’t ‘engineering’, it’s about relationships, between things, machines, ideas, information and much else besides, but above all between people.
To quote Gerry Weinberg, “no matter what the problem looks like, no matter how technical it may be, in the end it’s always a people-problem”. Creating links between people is probably the core skill in enterprise-architecture.
These days, as a consultant in business-architecture and enterprise-architecture, fact is that I do very little detail-level design. I do almost no direct implementation. It’s true that I do create a lot of models and write a lot of documentation – I can’t escape that part of the EA’s role. 🙂 But my real task is to foster conversations and to help resolve conflicts, so that the people of the enterprise can create their architecture of their own enterprise.
And it’s in those people – far more than in ‘the architect’ – that each of Roderick’s items above will need to come into play: imagination, knowledge of structure, and awareness and experience of the interplay and interdependencies of all the different disciplines within the enterprise. So a key part of my work is to remind those people that they already have each of those, and/or help them fill in any gaps in imagination, knowledge, awareness or experience.
Hence I don’t (and shouldn’t) design the architecture: the clients do. Ultimately the architecture is, and must be, their responsibility: it will only work, only happen, when they know that they own it, that everything in it is their choice, their commitment to each other and to the workings of the enterprise as a whole.
Sounds overly idealistic? Not at all: it’s the exact same principle as in Agile software-development, where the client is an actively-engaged member of the development-team. Sure, EA is often on a much larger scale, and there’s often a lot more emphasis on the ‘people-stuff’ than on that easy (?) unchallenging (?!?) controllable (?!?!?) world of code, but that’s the only difference – honest! 🙂 🙂