Many enterprise architecture groups suffer from the perception that the work they do is ‘Ivory Tower’ stuff. In a recent post, Mike Kavis gave some good advice on how to combat this perception. However I disagree with one point he made and I think it’s worth a post to explain why.
In his post Mike said:
It is critical that the EA group stays focused to the cause and does not get distracted with non strategic initiatives. In other words, they cannot get sucked into the machine!
Mike probably means that the EA group’s job is to see the bigger picture and concentrate on strategic direction. If you get bogged down in tactical initiatives you can quickly lose perspective and eventually you won’t be able to “see the forest for the trees”. I agree. However, concentrating on strategic rather than tactical issues if only ONE aspect of an architect’s job. An equally important one is leadership.
I think the best way to show leadership is to occasionally jump in the trenches and get your hands dirty. I’m sure every architect knows that it is really easy for project teams to find reasons NOT to follow the EA group’s lead. Project managers and sponsors can list endless reasons as to why they’re special and have go their own way. These reasons are usually difficult to counter and what’s more, the EA group rarely has the political clout (or friends in high places) to mandate compliance. So you need to give teams reasons to follow the EA group’s lead voluntarily and the best way to do that is to actually work with them. In other words – get “sucked into the machine” (at least occasionally).
This approach has a number of benefits (below I use the term ‘developers’ because that’s who I normally deal with, but it applies to all ‘implementers’):
- Impersonal feedback from project teams to the EA group (e.g. emails) is good but it’s no substitute for seeing things first hand with your own eyes. And you’ll be amazed what useful information comes out when you join a project team for a ‘team lunch’ away from the office.
- It lets you see how the architecture works in the real world. When things like resourcing, deadlines and politics come into play there is often a difference between the ‘ideal’ and the ‘actual’ architecture. No point being pig-headed about it – a good architecture that is followed is better than a great one that isn’t. By getting in the trenches you see what works in practice and what doesn’t, and you can adjust accordingly.
- When deadlines loom, two things happen: developers start cutting corners and the ‘not invented here’ mentality kicks into overdrive. If there’s something in the architecture they don’t understand or if something isn’t quite working as described you’re on hand to help out – immediately – and they have no reason to go their own way.
- It shows developers that you’re human! There is a perception amongst developers that architects think they’re ‘above’ everyone else. Some architects think that way. The best ones don’t. Mix with developers, earn some trust, build some ‘street cred’. It will prevent a ‘us vs. them’ mentality.
- It allows you to explain what you actually do and the share the challenges and problems you face in doing your job. If developers see that your job is not as easy as it looks they will generally try and help out.
Obviously you can’t join every project – you need to pick the ones where leadership is needed most. Dive into projects with the greatest risk or ones that will deliver the greatest business benefits or ones staffed by your greatest critics. In the short term this will mean many long days as you try and get your own work done! But in the long term your job will become increasingly easier as the working relationship between the EA group and various project teams improves.
Getting your hands dirty shows everyone (executives, developers, project managers etc ) that EA is practical, applicable and outcome focussed. It’s about delivering quality solutions and not about diagrams, models and theoretical concepts.
Please note! This advice only applies to architects with technical skills – those that have ‘been there done that’. You need to have some ‘street cred’ with the developers. Take it from me – if you’re a “Powerpoint and Visio” architect then embedding yourself in a project team will harm both the project and the credibility of the EA group.