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.