The tale of the Pied Piper refers to all of the towns' rats being led away, followed by the children after he wasn't paid. I see the same thing happening with capable IT architects - the analogy works even if you can't decide if architects behave like rats or children. While corporate IT departments are busy with other things, the real architects are slowly disappearing.
Definitions of the architectural role aside, let’s for a moment assume that an IT architect is a technical person with significant experience making a technical contribution to a project. Look around within your own organization and count how many people who are actively working as architects that are above thirty five, in their forties and their fifties – I don’t count very many. It seems strange that with IT systems being so darn hard to build successfully every time, that there is a lack of receding hairlines on our technical teams. This is not necessarily the case in other industries – most surgeons are considered to get better with age, right up until they are too shaky to hold a scalpel. My grandfather finally stopped working when he was in his seventies, spending every day on civil engineering sites – he had built virtually every major bridge and road in the city and was useful to have around.
Where the IT Architects are going
If as an architect you can coerce a multi million dollar system into existence, chances are you have a pretty broad range of skills. IT architects, in addition to technical knowledge, can project manage, lead teams, handle politics, understand business and so on – all of this in a fast-paced, highly stressful environment. It is pretty easy to handle a career change.
Some architects have moved out of IT completely – I know some who have become pretty good property developers, while telling me how great it is because building technology is fairly static. Some stay in corporate environments, even consulting, doing things such as project management – it is far easier to brand yourself as a senior project manager than an architect. Some move onto the supply side of IT, using their experience to sell products, services and resources to corporate buyers.
Most do less and less architectural work on a daily basis, lose touch with the current technological hype and feel that it is not worth the effort to re-skill again (intentional tautology).
Why the IT Architects are leaving
The reasons should really be handled by a more substantive survey, but there are some things that really annoy architects and make them throw up their hands and think "I'm going to become a project manager!" Here are some of my theories.
Fifteen years of experience overridden by technical developments in the last year
There is a perception in IT that the more you know about the latest technology, the better you are. While this may be relevant for part of the project team, much of the work that needs to be done is not latest-framework specific. Imagine an architect with fifteen years of experience focusing briefly on non-technical aspects such as quality for three years – by the time he tries to become involved on the latest project he is considered out of the loop and drops a couple of rungs in terms of technical seniority. Architecture is a lot about abstractions and as much as developers will say how radically different v3 of the framework is, the abstractions still remain the same. At some point good architects say "This is the last framework/language/methodology/platform that I am going to learn if we buy into the 'next big thing' I'm out of here!"
Seen this movie before
Do you ever get the feeling that in IT we are continuously re-solving problems that were solved a long time ago? I'm not even talking about that latest language, framework or other technologies that could arguably be evolving. I'm talking about things like handling temporal data, long running transactions, concurrency and contention and so on. Often architects find themselves mentoring, arguing or persuading others that if they choose a particular approach they will run into well known problems that may have been solved thirty years ago. Obviously this is the architects role – imparting their knowledge and experience, but sometimes they are flat-out ignored by people who think they know better because the technology has changed. In these cases I often start my counter with "I've seen this movie before and it has an ending like Titanic" – by now, people on my team know that it is a prompt to pay attention to avoid pain.
He doesn't code
Amongst architects the discussion as to whether or not an architect codes is unnecessary. The problem is that the technical members on a project feel that the architect should be coding and their reasoning is sometimes valid. A good architect is stuck in the middle – too technical to be valued for business knowledge and not a good enough coder to earn street cred from developers. Even coding architects find it difficult to keep up because they are not coding all day every day.
Salesperson Competition
Pre-sales techies are the bane of virtually every architect – energetic semi-technical salespeople that have all the latest brochures, white-papers, presentations and anything else to get business excited. Sometimes by the time the architect becomes involved, business is so sold on the particular product that the train simply cannot be stopped. Instead of inviting architects soon enough, and face it they don't get as excited and can ruin a 'fun' demo, business holds back on architectural input until they say "We have bought this product and it is a strategic fit – please get it integrated with all the other products that we have bought"
False Credentials
I was involved in a project with an awesome architecture assembled and delivered by a brilliant architect. When the final testing was going on external auditors rocked up to do an assessment – fair enough, it was a bank after all. They conducted a few days' worth of interviews and inspections and in their auditors report proudly announced that the architecture was bad (it should have been in a cube and not a relational database). How on earth would an auditor know, where are his qualifications, what is the basis for his argument, can we see the report, when can we have a meeting? Nothing… no answers… nada! "The auditors have spoken and it is so recorded, entered and agreed." Architects, without recognised qualifications and the rest of business not really understanding what they do are always at the whim of roles that traditionally have more clout and credibility.
Make him a manager
Sometimes, the best way to keep experienced architects around is to give them an office and a larger credenza. That way they can justify the cost and still have someone who knows how all their systems hang together. The problem is that then as a technical manager the architect does less and less architectural work and does administration, putting out fires and ultimately more golf. The result is an architect that is totally out of touch with what he or she really enjoys doing.
How to stop the Architectural Pied Piper
I don't consider myself one of those people-people and can't really provide input that is of a general nature – you can go and speak to your own people-people about that.
The first thing to decide is if you want the people with experience around – sometimes you may want to cut out the dead wood so that you can finally replace the token ring network. This can often be the case with architects that are simply looking backwards instead of forwards – the kind who look back fondly on SmallTalk and print out their emails.
Also you need to establish why you want to retain the experience – it could be that you need someone who knows all the history of the legacy systems so that they can be used as a reference guide for all the hacks and workarounds that have been put in over the years. That kind of person may be quite happy being a manager of a maintenance team and does not want any architectural responsibilities.
If you want to keep good, experienced architects, you need to create an environment where you can realise their benefit. A good place to start is to define the architectural role carefully – not simply employee specific roles and responsibilities. What is needed is a clear understanding of what architects do and how they fit into the IT department and it needs to be communicated more broadly. Although good architects are able to explain their functions to whoever they interface with, it would be a great help if all participants, from developers to business are clearer on the functions. Understanding functions within an organization is usually general knowledge – most people know the difference between say a sales manager and a financial controller – why should it be any different with IT.
For other ideas, look at the reasons for leaving above and find ways to counter them, such as:
- Insist that architects have relevant current knowledge of implementation issues, but don't insist that they code it up themselves or patch it into the network.
- Bounce proposed approaches off architects and ask for their input. Most good architects will be able to provide useful pointers, anecdotes and long stories of things that you have not considered yet.
- Involve your architects throughout the entire procurement process. If they rough up the sales person a little – let them. The worst that can happen is that they uncover some cracks. If the product is worthwhile and the salesperson any good they will be back for another round – hopefully having addressed some of the concerns.
- Back up your architects and present them as key participants in decision making – if they disagree, ask them to present their reasons formally, logically, concisely and clearly. Good architects revel in such an approach.
In case you were wondering, I'm not some washed-up techie who is going through a mid-life crisis. I have been in software development for about fifteen years and been doing architecture for at least eight. When I need to, I can out-code and out-deliver most developers on my team on the latest technology. I'm not leaving, although I if my current framework/platform (.NET/MS) becomes marginalised, I probably won't learn a new one in as much detail.
To the architects out there – see what you need to do to stay in the game. To business – keep your great architects so that systems can be delivered.
Simon Munro