Technical Architects Demystified

Who are these stern looking people, with an innate ability to make you feel stupid? Why do they seem to be the first to leave the project when things go wrong and a scapegoat is required?  This article takes a look at this least understood, yet most influential role in IT.

What do they do?

They can be thought of as the 'top techie'. However do not confuse them with some kind of Boys Own Internet enthusiast. They tend to be much graver. A fit of chortling is not their style.

Their job is a demanding one. As the final arbiter in technical decision making, they carry a heavy burden. You may have wondered why your organisation uses certain technologies. That is because they chose them.

Like an architect in the world of buildings, the technical architect is the designer of your companies IT system. Their role is highly creative and hence it is understandable that they get can suffer delusions of being Leonardo de Vinci or Christopher Wren.

At the end of the day, like 'bricks and mortar' architects they do not build things, they lay down the blueprint from which others will build. 

Why are they so important?

For the reasons mentioned. They are in effect the person who carries the technology vision. Others see a collection of middleware, applets and web pages; the technical architect sees a global web enabled trading system. Having chosen the technology components, hardware and software, their reputation is put on suspend until the system is built.

How do I impress one?

Forget it. Don't even try. Fawning deference is a much more effective tool for influencing a technical architect. There is a clear technical pecking order in IT. You are either a groomer or a threat. And threats are a high profile opportunity for the technical architect to let others know what is in store if you try and mix it with them. Try the following:

Step 1 Pick a technical architect

Step 2 Get their attention by saying you value his/her opinion

Step 3 Then pronounce that you believe that Java is rubbish / excellent (either will do). Followed by no justification for your remark

Step 4 Curl into a ball (mentally or even physically) and wait for the technical architect to exhaust themselves.

That's how technical architect's feel about unsubstantiated technology assertions.

It's a jungle out there and the technical architect is the technology lion.

Why don't they like me?

Stop making unsubstantiated technology remarks for a start. But even this doesn't guarantee friendship. Business networking to a technical architect does not go much beyond cabling and routers. Getting involved in human alliances and political maneuvers would seriously undermine the technical independence and objectivity that the technical architect needs to develop the best solution. On the other hand when you know everything where's the benefit in being a net exporter of knowledge.

Where can I find one?

The best breeding grounds are software houses, within which they would have been exposed to a variety of technologies. Not necessarily being financially driven (unless they are planning to set up a technology interoperability laboratory at home), they are happy to remain in median salary organisations (so long as the technology challenge remains).

A much sought after hybrid of the technical architect is the solutions architect. This is a client facing technical architect. So rare is the genetic combination of technology 'smarts' and 'unprompted' social skills that some clients are willing to pay £250k salary. Such high earners can be found in hardware companies that are in the process of reinventing themselves as solution providers.

Associated buzzwords

Use these terms very carefully in the proximity of a technical architect:

• N- Tier Architecture - An architecture whereby the application software is split across N platforms. For ecommerce applications N typically equals 3.
• Middleware - The software that enables the application software to communicate across multiple platforms
• Common operating environment - A nirvana like term used by organiations to define the technologies that make up their IT infrastructure. By nirvana I mean that organisations strive to adhere to a limited set of tried and trusted technologies. This usually involves migrating from a hotch potch of hardware and software, originally chosen before the company had an IT strategy and after IT became important to the business
• Component Based Development - An approach to building systems where there is a strong focus on using existing software components. Such an approach should reduce development costs and speed up the development lifecycle.

In summary

Be nice to technical architects as they have the power to make or break your company.  Don't expect them to be nice to you, their role is to make the right technology decisions not be your best buddy.