
Ask HN: How to plan your career for an Architect role? - antoaravinth
Hi HN,<p>I work in a company, where I do Javascript and Java dev works. The work is challenging and I&#x27;m loving it. Its been almost 3 years, I have been in dev role.<p>I want to became an Software Architect; thats my ultimate goal. But I&#x27;m not sure, what all consideration, I need to keep in mind, while I work as dev role so that I can became an efficient software architect in the future.<p>Currently, what ever technical problems that occur in my work, I could able to debug and solve most of them. I do read every year atleast an technical book.<p>With all these in mind, I want to ask few question to HN:
1. How should I plan my career path from dev to architect?
2. Should I measure myself, say every year, how I have grown in my knowledge? If so how?
3. What all best qualities an dev should have to became to an good architect?
4. Other plans if any, kindly let me know.<p>Thanks HN.
======
ChuckMcM
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?

------
Fr3dd1
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.

------
jaimebuelta
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"

------
dpeck
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...](http://www.ibm.com/developerworks/rational/library/mar06/eeles/)

------
ilaksh
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.

------
matt_s
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.

~~~
antoaravinth
Thanks for your response. So its all about designing the system and reduce the
riskness involved in system interactions?

~~~
matt_s
System interactions tend to be where there are mis-communications or bugs in
API and cause issues during development. Especially if you are building on
another companies service.

That isn't it though, there are the non-functional aspects of the system that
the design will need to take into account. Things like scalability,
performance, etc.

For example, think of a SaaS application that handles taxes. How would you
design the interactions with government systems & banks, how would security
work and how would you handle performance? That's what I meant by risky areas
- risk to the project success, areas that may not be well known in the
solution yet and may be "moving targets". Writing out the software that
implements the tax law is probably a daunting task but should be very well
known (probably a giant if/else tree with basic math).

------
palidanx
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.

~~~
antoaravinth
Thanks for your response. Interesting to see how a tool knowledge is mandate
for an architect!

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

~~~
antoaravinth
Thanks for your response. I couldn't able to see your email id in your
profile. Anyways this is my email id anto.aravinth.cse@gmail.com.Just give a
ping, have several questions for you.

------
wintry757
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
obsolete as the roles continue to evolve. Future architects often follow paths
in two or more domains, for example, both the data and the application domains
for n-tier client-server developers, or application and technology domains for
web developers.

 _Senior architect roles_

The most senior architects are not tied to specific IT domains. For their work
to be valuable, they must have a strong knowledge of all IT domains, and
extensive, progressive working experience in two or more domains. The most
common titles for these roles are:

 _A. Solution Architect:_ expert in two or more domains, and senior to single-
domain architects

 _B. Enterprise Architect:_ senior to all other IT architects in the
enterprise

Note that the terminology for architects at this level of seniority is not
very consistent at present in the industry. In particular, “solution
architect” is a synonym for “application architect” in some markets. As well,
the term “enterprise architect” is sometimes applied to any IT designer above
a certain level of seniority, even if their experience has been in a single
domain and they have no claim to senior-level knowledge or skills across the
full collection of enterprise IT domains.

 _Nature of IT architecture practice_

We don’t use “architecture” in the world of information technology as we do in
the design and construction of buildings or other structures, where the term
originated. In building physical structures, architecture is the initial step
that elicits user (owner) requirements and attempts to meet them with one or
more initial designs. A design will contain enough information to support
project risk analysis, costing, and local zoning or equivalent review. When
the design has been accepted, the architect is generally finished and other
professions or trades come to the forefront of project decision-making.

IT systems and technology architecture works with extremely malleable but less
predictable materials, processes, and staff roles. As a result, IT architects
have far more freedom in design, but less certainty in the costs and risks of
the resulting product.

As a result, the IT architect tends to be involved in a greater number of
decisions for an IT project, may have made important decisions even before the
project started (e.g., regarding corporate IT standards, development
methodology, infrastructure technologies, etc.), and may influence IT
development or delivery processes as well as detailed product and service
design. The IT architect’s role is broader in scope and longer in duration
than common for the architect role in construction.

In general, IT architects work with corporate business requirements and major
project requirements as input, producing general enterprise IT standards and
custom IT designs as output. Good architects are familiar with multiple means
of achieving IT goals, including multiple basic computing platforms, multiple
development methodologies, multiple product delivery architectures, IT design
patterns, design and delivery tools, academic resources, and other
contributors to flexible, intelligent decision-making and design.

Rather than producing architectural models and sketches to be implemented and
then walking away to leave development and project handover to a subsequent
team of engineers, IT architects define the overall IT delivery environment,
do initial designs, select or define technical standards, and may even take
lead engineer roles in one or phases of a delivery project. In short, the IT
architect role overlaps with detailed systems engineering. This attention to
both concept and detail helps overcome the problems of working with an
insubstantial construction material like software, keeping the experienced
designers in touch with a project and its technologies until all significant
technical risks have been recognized and overcome.

 _Differences from other IT roles_

The IT architect roles do not imply supervision or management
responsibilities. Like the corporate lawyers or financial investment team, the
architects are valued for their knowledge and resulting contributions to
corporate goals. They typically do not take supervisory or management roles,
as these do not require the specialized technical knowledge and skills for
which the architects are retained.

Within IT departments, therefore, there exists a line of seniority for
management that is separate from the line containing architects. Staff
development for IT management generally follows a path from team lead on
technical projects, to project management, to portfolio management (overseeing
multiple projects, each with its own project manager) for a business unit or
other organizational group.

IT managers generally keep up with the broad march of progress in the
technology domains for which they are responsible, but do not remain active
practitioners once they reach middle or senior management. IT architects, by
contrast, remain active practitioners to develop and maintain the deep
knowledge and skills associated with the title of “architect”.

I hope I haven't muddied the water too much with these thoughts. I don't claim
any special insight here, and I think there is space (which is actively under
exploration and colonization) for much deeper thought and more rigorous
conclusions about the IT architect role, title, and qualifications. I'd be
particularly interested to hear the current state of the art in Europe and
Asia, if anyone has knowledge from these areas.

