5 ms·

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

• jaimebuelta 11y ago
  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"
• Fr3dd1 11y ago
  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.
• ChuckMcM 11y ago
  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?
• imechura 11y ago
  I would be glad to discuss it with you over email. My address is in my profile.
  • antoaravinth 11y ago
    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.
• matt_s 11y ago
  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 11y ago
    Thanks for your response. So its all about designing the system and reduce the riskness involved in system interactions?
    • matt_s 11y ago
      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 11y ago
  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 11y ago
    Thanks for your response. Interesting to see how a tool knowledge is mandate for an architect!
• ilaksh 11y ago
  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.
• dpeck 11y ago
  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/eeles/ http://www.ibm.com/developerworks/rational/library/mar06/eel...
• wintry757 11y ago
  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.