Just over 3 years ago I was appointed to a position in my organisation called Enterprise Architect. Naturally I researched the job before I interviewed for it, read the 50-page job description (I kid you not), bought a couple of books and read a metric shedload of internet articles and (since we were a client at that time) Gartner documentation.
I got a vague impression from all this that Enterprise Architecture was something that bridged the divide between business and technical people, that it was involved heavily with strategy, that there were a number of different competing frameworks involved, and that there was a high level of debate amongst practitioners with some people claiming to be the only ones in possession of the One True Way of doing things.
In other words, par for the course. I had graduated through relentless discussions about what was really free software and what wasn’t, and I think I could cope with a few internet trolls. And surely as the discipline moved forward we would sort some of these issues out?
Seemingly not. And three years on from those heady days, the “enterprise architecture” team that I spent so long helping to try to form and drive forward along lines roughly similar to others in the industry and – most crucially – in a way that actually added value to my employer, is being de-scoped and effectively disbanded.
Initially this news was devastating to me, as I felt we were just about starting to get somewhere. But now I’ve just about settled with it and I’m starting to learn some lessons. Well, just one lesson really: and it’s one that I’m sure every enterprise architect, enterprise IT architect, technical architect or indeed anyone with an analytical nature who wants to succeed might do well to take on board: it doesn’t matter how clever you are.
We started strongly and soon had a very elegant programme for exploiting the organisation’s resources to drive higher productivity, better outcomes and lower costs. But no-one was interested. I now believe this wasn’t because people disagreed with it, it was because people didn’t understand it. And I think that has more to do with demographics than anything: there are still a large number of people at or near the tops of big organisations that have a blind spot when it comes to anything new: they can’t cope with big paradigm shifts and clever methods changing the way business is done.
So here are my four tips to anyone who calls themselves an Enterprise Architect:
1) By all means do the clever stuff. Analyse the current and future states of your organisation in its environment as well as you can. Use an expensive modelling tool or proprietary architecture framework if you must. But under no circumstances should anyone find out about it. Keep it under your hat. This work is just to ensure you have a good understanding of what the organisation has and what it’s trying to do so you don’t suggest anything stupid.
2) Break up the programme for reaching the future state into small chunks. And then break it up again. Projects that cost less than £100K at the very biggest. Less than £10k is ideal. Mainly though, they must be simple in concept and non-threatening in appearance. You aren’t re-engineering your financial payment processes: you are simply linking the website to your payments system. Because it makes common sense.
3) Build a business case for each project separately and gain business sponsorship, then get them through. Sugar-coat each project with all the benefits you can find. Invest time and resources, if you have them, in ensuring they deliver what they say they will. Do the small stuff. Help people on the ground to implement and don’t compromise on quality.
4) Be clear about the services you provide. This is about how you work with people and the channels you use for delivering value: consulting on projects, providing and customising models, participating in governance and assurance, educating people about new developments, and doing research.
As for me, whatever role I find myself in in future, I think I’ll always be an enterprise architect. Even if I stay in IT I’ll still use these models and think this way.
Even if no-one I work with ever gets to hear about it.
WTF? our posts are being deleted, no one told me (LOL)
Seriously though, I couldn’t agree more, I personally feel like once you start thinking like an Enterprise Architect, you always think like an Enterprise Architect.
Carl
Great blog. As Enterprise Architects, we spend too much time trying to explain to others what it is we do and too little time actually doing anything. We must find ways to add value. And your statement that we must do it in little chunks is exactly right. The reason is that little chunks are all we really know how to do.
I don’t know if you have seen it, but I recently did a white paper that puts a theoretical basis under your recommendation. It is called The Mathematics of IT Simplification. It is the theory of HOW to break up big systems into little chunks so the little chunks are as independent as possible. If interested, it is at http://objectwatch.com/white_papers.htm#Math.
Hi Martin
I agree with your comments but not the Architecture solution in which you were working in.
In my mind Architects (technical / solution / design / etc…) only have a place as a ROLE within projects – whether that be internal project or as a supplier delivering to clients. Even in this instance I believe that they should be line manging the technical delivery staff and working as a translator to the project manager.
I believe (and I’m sure many others won’t) that operational line managers within IT should deliver the architecture they are responsible for – For me the tips you make above are PERFECT for that role. If the manager isn’t technical enough or ‘doesn’t get it’ then frankly they are not good enough for the position they hold and should be moved on.
I hope you find a role managing the delivery of IT services because the insights you have gained through your journey would seriously improve the quality received by your customers.
Alex
Hi Alex
thanks for your comments. It’s interesting how you see the split between architecture and delivery working out. Your views differ from those of many in the field that see architecture as the link between organisational strategy and execution: in this case enterprise architects are not “on projects” at all but define programmes instead.
It would be good to catch up! It’s been a while.
Martin
I wonder how it happend in the first place that your EA is gone when you know the major famous tricks?! When I think about it, we could actually start naming those trick. Here;s the first attempt, as you list them:
1) “No Framework policy” – never mention this or similar doomed word to anybody or you’re screwed. Should you use it in discussion with C-level or similar “mind-oriented” manager – I warn you – you’re in the box labeled “academic-good-for-nothing-detached-from-reality-stuff” for good.
2) “Salami method” – everything – really evertyhing! – can be cut to small pieces so that it slips unnoticed or without very much fuzz around it. If it does not work, cut it again. Most of you folks now what’s recursion, right (damned me, I’ve broken the rule number one already!)
3) “Benefits amplification miracle” – it does not matter how many times your promise the same benefit sover and over again. Really. When it works with revenue, TCO and co. why should not it work with business cases. And they are not read anyway, so save the time and just praise what you do over and over again.
4) “Real work doesn’t hurt” – this one really sounds like a lot of work which makes me dizzy, I’m not gonna comment that one.
One could add many more, I personally like this one:
5) “Cooking a frog” – you might know that you can cook a frog alive when you put it into a cold water, because as the temperature raises, the threshold is never so big that it would make the frog to jump out. Though from the hot water it jumps out immediately. Use this fact with your counterparts wisely and often.
6) … I am too tired for another one… let me just wish you all the best in your new career path!
cheers
Hi Ondrej, thanks for your comment. A nice list!
to answer your first question, that’s really only 50% about us but also about our environment. We are in Local Government in the UK and services that aren’t on the “front line” (teachers, social workers, people out fixing the roads) are subjected to major budget cuts . Strategically-focused teams are always the worst hit in such circumstances. I think politics also played its part.
Thanks for your good wishes, I’m sure I’ll be ok