Software/Enterprise/System/X Architect all seem to be pretty much interchangeable titles these days – the trouble is for most people it’s hard to exactly pin down what a X Architect is and what they are expected to do on a day to day basis.
Well you are in luck, this article will shed some light on these titles and what they often mean in practise and what they shouldn’t mean.
This is fairly ‘generic’ Architect title in the field of computing systems, pretty much everything is software in some form or another. In my experience its usually a junior architect, who might not have had any formal training in architecture principals; it’s sort of a step up or across from an Engineer. It can mean they are domain expert in particular piece of software or a software language. They will often not have the final say in how something is constructed, they are there to advise and inform other architects in their decision making.
This is an architect, surprise, surprise, whose remit covers the whole of the business systems wise – although you may find in an organisation multiple Enterprise architects all looking after their particular piece of the puzzle.
Now this is the confusion with the Enterprise Architect role, they are either so high level that their feet don’t touch the ground OR they are responsible for a well defined sub section of the whole Enterprise business – in which case they are actually System or Software Architects… Also if they are truly responsible for everything, shouldn’t they be Chief Architects?
This is another HR Xmas stocking filler as far as I’m concerned – they are only truly senior to other architects if other architects report into them. Which is unlikely in any organisation that follows the matrix model, in that Architects are ’embedded’ into the teams responsible for products – so at best this can be a dotted line.
If a business has a traditional hierarchical reporting structure, and they do have direct reports that are also Architects. Then its likely you have come across an Architect ‘Tiger Team’ – i.e. a very senior set of engineers and architects who trouble shoot across the organisation, and it would have to be a very large organisation indeed to justify such an investment. You can treat this as a good sign.
Now we are getting somewhere – this person has Go/No go responsibility (or at least unavoidable Red flag raising ability against core standards and requirements). They work closely with other Architects and Senior engineers to ensure core qualities and objectives are met whilst minimising technical risks. They often interact with the C level and the board. They also need to keep a handle on technical debt. They are architecture ‘standard carriers’ other Architects look to. You may find a dotted line of architects reporting into them, so the quality can be enforced top down and disputes cleared down quickly and effectively (architects do argue from time to time).
Whoever is in this role needs to be highly experienced, respected, an effective communicator and able to wear multiple hats – so they can understand the different viewpoints and the resultant impacts on the system designs and drivers.
Now just ‘Architect’ on its own is an extremely rare thing these days, and if you do come across it in the wilds – treat it as a good sign. It often indicates that title has been ‘earned’ the hard way – they probably came up with a formal background in system design and tactics analysis, or via the Ops route. It’s likely they are focussed on one or two systems, but those systems are critical to the business.
Basically they should know their stuff and are respected for it, sometimes their word makes or breaks a project (think of Ford on WestWorld and you wouldn’t be far off).
Why the Architect title explosion?
I think HR departments and ill informed managers are responsible for this, it’s a nice cheap ‘catch all’ for someone they cannot fit anywhere else, the give away sign is if they are without Go/No Go authority – then its often a pure vanity title. The other give away is that they write code the majority of the time, then they are really a Senior Programmer in disguise…
The other give away is no meaningful formal training in systems design, tactics, risk analysis, etc combined with no evidence of authoring such documentation or being an authority – nice diagrams are a small part of the Architecture role – a lot has to do with understanding the four W’s (what, why, whom and when) and the real drivers in play; this then leads to well considered design backed up by documented decision making.
The other problem with the title explosion is that anyone who is actually an Architect looking to work for a company will have a look around on sites like LinkedIN – they will then find that people are being given Architect titles which their background does not support. End result being they won’t work there. So such title explosion actually re-enforces the problem and stops a business getting experienced people!
Conversely, if an employee in said company tries to get a job at another company with proper job skill requirements, they will either fail the interviews or not be able to do their job – so nobody wins out of this.
Myself I think we need make better use of Developer and Programmer postfixes and not be so afraid to give people job titles that better match what they really do. If someone is a Senior Systems Developer call them that. If someone is an Software Toolsmith, call them that. If someone is a Technology Researcher – again call them that. Remember a title is that just that a title, and you want people to have titles which actually reflect what they do and the experience they bring to the role. Plus it makes CV’s a lot more clear and indicates directly the breadth of experience someone has when they have been in multiple roles over many years.
Hopefully the above quick breakdown on the Architect titles in play will help you and if you have any more questions, please feel free to get in touch.