11 Types of Architect Jobs (Only 3 Are Actual Architect Roles) Which You May Not Have Known

In technology companies, there is role of architect(s). There is a huge demand for competent architects.  Some are groomed within the organization. Some others are hired from outside. All the time there is huge demand with big pay packet.

Surprisingly(or not so surprisingly), I have seen lot of frustration for the architect herself and also for the stakeholders around.

The biggest issues are

• Mismatch in understanding of job description
• Additional dynamic implicit expectations to ‘fill in’
• Not much thought is put into defining architect role. (For good job description I have a check-list in “this article“).

Within no time, all stakeholders go out of sync. To save the frustration, it is essential to understand the various technical tasks requiring a senior technical member. Lot of times, all the roles are called as architects.

Now let us closely look at what the roles with keyword ‘architect’ look like –

1. System Architect

Architect who defines the architecture of system (which probably involves hardware, software, mechanical etc. ). It could also be all-software system. The idea is that the architect analyses at the system-level, breaks it down into sub systems. The system architect defines the boundary of what the system would have and what is outside it.

2. Software Architect

Given the boundaries of the system, the task is to define the internal architecture of the software. Depending the size and complexity, this could be a team of architects or a single architect.

I do not want to write about the known part. I would rather settle for this wiki link. Further, there are enough references online.

3. Solution Architect

This is a predominant role if you are in consulting business. You understand the domain. you understand the ‘building block’ products. Using these, you would define a solution, customization needs and quote a overall project.
So far so good. Looks pretty architectural.

4. Low-level Designer

There are many times, architects are hired for product maintenance. Instead of working at the level of architecture, the expectation is to own up small changes. Making these small changes would not be very challenging. But management wants to buy comfort by assigning ‘senior resources’.

5. Code Reviewer / Debugger

Sometimes, the architect needs to become a full time developer. There are critical parts of software which needs lot of background to do flawless implementation. Also major escalations from largest customer would readily demand the architect to become the coder, debugger which could have been handled otherwise. This falls into grey area. Lot of times any software modifications/development can be done by junior folks. But the junior members are in training mode and probably not equipped enough to

6. Reverse Engineering Role (Mainly, Design Documentation)

There are lot of times a good product is built in record time which becomes a market success. However due to complexities, maintaining it becomes too difficult to handle. Understanding and documenting it becomes a very high value task. Since documentation is considered not the ‘core work’, organizations end up hiring someone from outside to learn and do it.

So, this also could have the title of architect.

7. Domain Expert / Subject Matter Expert

Many high end applications involve specialized domains. Like – image processing, IT security related domains, deep learning, networking, product design standards specific to domains (like oil & gas, automotive etc.). The architecture tasks are not much. But the system/domain/standards overview is very critical.

Since they need to be paid adequately, they need to figure in right level. Many times, for the lack of title, such a candidate may be called ‘architect’. Though it does not sound attractive, it may still be good to build your network and “quickly prove”.

8. Technical Manager

All managers in any industry need to understand the work contents of the team members. However, in R&D environments, most managers do not understand the work content. One of the main reasons is it becomes too specialized to understand. Secondly, once someone is a manager, there is steady stream of operational work coming along from all directions.

This is why some organizations bring in technical person who can do and understand technical work, track it and bring things to closure. This role need not be concerned with organization dynamics and so on. Quite a role for technical people.

9. Developer

Mostly developer job is considered as straight forward. But it is not so, when associated systems are complex. the developer needs to have clarity of system implications. For example – if you are telecom developer you might work on network processor’s co-processors. There could be specific development environment for co-processor alone. For the developer, What happens outside this world is as crucial as what happens inside.

And the developers who code for control loops of large engineering systems. Or those who write steering control in automotive sector.

These are coding job. But it is lot more than coding.

10. Project Manager-Architect or Architect-with-People-Responsibilities

The “HR theory” in most organizations talk about distinct technical and managerial paths. However many high performing organizations have these roles merged together. If you are technically sound, it wont be enough. There is good expectation to be organization savvy and people friendly.

11. Product Manager

There many different names for the role. Ranging from product owner, manager, product head etc. The expectation is to be everything for product – features, delivery, customer facing and many more.

Too many different expectations on architects! It is hard.

True. To make it worse, the expectations may not be specified early. Most of management have no clarity on what to expect from senior technical members. It could be anything from the above list. In any combination. Under any title. If you are in system architect mindset and expectation is to do debugging, it just may not work.In the eyes of people around, you will be a theoretical person and a failure.

Dangerous! What are the safety checks for accepting architect role ?

1. Talk about the roles explained above. Find out the specific role and the combination of expectations from the above list.

2. Understand the industry,if it is new industry. Across companies in same industry, the roles are similar. If you are switching industry, check about the product / project life cycle, project contents etc.

From this you can deduce the work content. Do not go by the bullet points in formal Job Description. Do a self check here

3. Understand the org structure/roles around this role. Depend upon other roles, your role may expand / shrink. Also find out the profile of the people in those roles. You can also gauge the level of people dynamics.

This understanding will give you the kind of ‘fill in’ / ‘jump in’ you need to do. With this, you are likely to have a safe landing in the new job. Good luck!