Ask HN: How to plan your career for an Architect role?

Architect is a not-standard role in tech. Sometimes mean a thing, others a different one.

That said, normally it's referred to people dealing with architecture problems, not so involved with the specifics on a single system, but on the interaction of different ones.

- If you want to plan to career to be architect, either ask for it if your company has this role or keep an eye on openings in other companies.

- It's a work which involves a lot of communication. Create good design docs, convince people of your design and solve their doubts, get requirements of different parties to have a design that covers everything...

- Learn about different languages and systems. Be able to see common structures (e.g. design patterns) and when to apply and when not...

- Learn about "the support parts" of software. Logging, HA, scalability, deployment... Everything that makes a production system truly "production"

I think you should just start to act like one. The following are things you could do for example:

- Try to look at the bigger picture during your work

- Engage in discussions about the whole system

- Document the bigger thing

- Maybe build some test solution with important designs that are being used in your project so that new devs can learn with it.

I am not a big fan of measurements because in my opinion measurements are never really objective.

I'd echo some of the other answers here, what do you think "architect" means? And then ask what could you do as an architect that you can't do as a developer?

There are places like IBM and Oracle where they have specific job functions defined for the architect role (and training to get you there) so if their idea meets your idea you would do well to just work for a company that trains for that role.

There are also people who have a lot of experience who are sometimes called "architect" but that is a function of how much experience they have, which really you can't push faster than the passage of time. You spend all your days working on the technology and encounter many different situations and then 10 to 15 years later people start thinking of you as an expert/architect.

There are developers who have better design sense. I don't know if that is a talent thing or just that they pay attention to not only what their code is doing but the structure of it and the underlying problems it solves. People will experience their code not only solving the problem but anticipating future problems and either handling them or having a clear evolutionary path to handle them. They start being called architects at some point in their career.

So why do you want to be an architect?

I would be glad to discuss it with you over email. My address is in my profile.

There are defined Architect roles when you work at large companies where the division of labor requires more specific roles.

Like others have said, the focus should be on the bigger picture of the overall system(s) and how they inter-relate.

As you move around in your career, look for roles where you have more say in how the system is designed in the beginning. Take on more responsibility in how different modules/components interact.

Also read up on design patterns - including the book Patterns of Enterprise Application Architecture by Martin Fowler (and read his blog/site too).

Much of architecture is focusing on the parts of the system that have high risk and making them less risky, usually these are the parts where the systems interact with each other.

The fastest way is to be mentored by other architects. To me, these are the tools architects should know.

UML

1) Sequence diagrams

2) Domain diagrams

3) Sitemap diagrams

Other 1) Ability to do domain to data model conversions

2) Ability to create diagrams defining data flows

3) Ability to define interfaces and data exchanges in between systems.

If you have any qs, also feel free to pm me.

So far I have not come across an architect role that made any sense. You just can't effectively design a dynamic technical system from a high horse looking down without being involved in the implementation.

The reasons for this: you need tight feedback loops in engineering. If you accomplish that then you are iterating and constantly refining requirements, design, tests, implementation, even platform selection for various parts of the system. All of the feedback loops need to be observed and responded to in detail. Someone who is not doing coding is just not going to be able to contribute positively. They will not be able to see what is going on in terms of requirements changes, implementation challenges, technology changes, etc.

So a company with anything like a traditional software architect role is suspect of not understanding software engineering.

I'm new to it myself, in my first role with the title "Architect" after a decade of being individual contributor and lead for R&D teams. So take these from someone very early in the position, but I think the important things are:

Know your shit and be able to have high level conversations about nearly anything technical. You don't have to know the inner workings of everything, but you should have a good idea and high level understanding of it. For instance, you don't have to know every message queue system on the market, but you should know a few, their relative strengths and weaknesses, how specific ones are often used and how message queues play a role in overall system design.

Learn a new language every year or two and keep an eye on the horizon for new technologies that can make you and your teams faster and more efficient.

Live and breathe failure. Understand the conditions that the systems you build and work in break down and learn to compensate for that and explain that to others.

Be able to talk to others, on their terms, whether thats your top flight engineer or the guys on the business side.

Its a bit corporate and soft, but I found the IBM article on it fairly insightful http://www.ibm.com/developerworks/rational/library/mar06/eel...

I've recently done a survey of job listings, titles, and the skills and experience levels associated with the term “architect” for the North America corporate IT marketplace. I drew the general definition of an IT architect’s roles and responsibilities partly from major Enterprise Architecture frameworks (e.g., TOGAF, FEAF, and DODAF) and partly from the survey of architect job postings on popular employment websites (e.g., Monster, Dice).

This material is “enterprise”-y and may not describe some of the more advanced IT businesses out there, like Google or Facebook. But before I did the research and write-up, I was quite ignorant about some of the wider uses of the term, and I did not have much clarity on what separated an architect from (say) a project manager or product representative.

Seeing hundreds of job descriptions and trying to map out what companies and recruiters were looking for was quite eye-opening. These descriptions may contribute some useful knowledge or terminology to others in their career planning or job hunting. I would like to think they represent current IT best practices, organized, simplified, and given consistent terminology and definitions. But the title “architect” in IT is not yet usefully standardized, and there’s lots of room for alternative viewpoints.

IT architect roles, skills, and experience

The title of “architect” identifies someone with extensive experience in one or more IT knowledge and practice domains (as I define them below). The most junior architect role builds on at least ten years of progressive, non-management design and delivery experience in a basic IT domain. A more senior architect shows similar progressive experience but more of it, and in more than one IT domain.

Note: Title inflation may be weakening the concepts of seniority and specialization we used to associate with the IT architect role. Just as a startup with a few dozen employees may end up with numerous staff titled “Vice President”, some smaller IT environments give the title “architect” to several of the IT team without necessarily requiring lengthy experience or depth of knowledge. For example, in many job listings the title “Solution Architect” describes a (junior, three-year) technical sales-support role, not a senior IT architect role as it might be generally understood.

The IT domains

For our purposes, there are five core domains of enterprise IT practice and knowledge. Each domain has an equivalent architect role:

1. Business. A business can be described as processes and groups of processes. Business architects analyze and document these processes and relationships to help optimize them for flexibility, efficiency, and performance.

2. Data. The data architect deals with the stable, long-term structure of data of interest to the enterprise, and with the technologies that deliver value in data storage and retrieval.

3. Technology. Applications and data reside on a complex and evolving technical infrastructure, which the technology architects design and implement.

4. Application. Application architects are the senior representatives of the programming trade, experienced enough to support successful application design, development, integration, and delivery.

5. Security. A newer entry to enterprise architecture, the security architect designs and oversees the implementation of corporate information security.

Apprenticeship roles

Every domain has one or more apprenticeship roles for individuals likely to become architects. For example:

1. Business: business analyst --> business architect 2. Data: database administrator --> data analyst --> data architect 3. Technology: system admin --> infrastructure analyst --> technology architect 4. Application: software developer --> developer-analyst --> application architect 5. Security: network security analyst --> security architect

There are many more paths than these, and some of these may become uncommon or obso...