There are a few different path’s I’ve seen people take to grow into architecture roles, and many people will grow into an architect role from more senior technical SME roles (senior developer, development leader, infrastructure leader, etc). It’s not always a straightforward journey because the competencies asked of architects are different than the competences expected of senior technical people. A developer who is solely focused on increasing their technical knowledge will become a better senior developer, but will remain ill-prepared to take on an architecture role unless they focus on and demonstrate the competencies of an architect.
This article will walk through some key fundamentals that people can start to work through and introduce into their own work in order to better prepare themselves to move into architecture roles within their organization or outside of their organization.
Just doing your current job well may not be enough to propel you forward. It’s possible that your boss may recognize skills in you in addition to your expertise as a senior developer and may want to take a chance on moving you into an architecture role, but it’s not a good strategy. If you want something, you have to be pro-active. You have to “step up” (a wise person told me this once). You have to make things happen.
If there isn’t an ‘Architecture Practice’ in your organization, create one.
If your organization doesn’t have an architecture practice, there may be an opportunity to create it. You can become a pioneer at your organization by creating a (informal) team of highly skilled technical people focused on ‘architecture’ and use this to help push the organization to mature their architecture practices. If you don’t have SA’s or EA’s then you don’t have an existing architecture practice.
Here’s how you can push forward with new architecture ‘practices’ in both a formal or informal way. It may only require a few hours a month at first which will have a negligible impact on your day to day activities while opening the door to growing your architecture skills and the architecture maturity of the organization.
- Start new “architecture groups” and “architecture practices” within your organization. Invite technical people into the groups and facilitate discussions around creating an informal architecture practice. In the group, have regular meetings (bi-weekly or monthly to start) with brainstorming sessions and action items designed to move the architecture practice forward.
- Look to re-use components, identify standard patterns, and create technical reference architecture as a start. This could create a foundation on which to build out an architecture practice from the ground up, and who better to lead that practice than the ones who founded it at the ground floor and worked to build it out. Don’t worry about getting it perfect on the first pass; this is an iterative process.
- If the organization already has an existing practice, I wouldn’t recommend starting your own ‘architecture practices’ unless you also include some of the organizations existing architecture expertise. In this regard, you might want to focus on practices that are specific to your technical discipline that interest with the architecture practices of the organization.
- Personal Anecdote: I’ve found success in creating and participating in “architecture teams” within a large global organization that didn’t have an established architecture practice.
Express Your Desire to Move into an Architect Role
- Discuss this with your peers, with architects, and with your manager.
- Ask for feedback and be explicit about asking for more opportunity in the discipline as an architect.
- You are likely going to get positive and constructive feedback.
- Personal Anecdote: A long time ago, I did exactly this. From my perspective, I was already doing all of the things an architect should be doing. It turns out I was doing a lot of the things an architect should do, but not everything. My manager was frank with me and said “You are doing a great job, but when I look at architects in the enterprises I worked with in the past, they drive change to move the business forward.” Over time, I also went on to learn more about the strategic value of solution architects as it relates to expanding business value.
Amp Up Your Skills
- Negotiation, conflict resolution, emotional intelligence, and decision making are required. Practice this daily.
- Deepen your technical knowledge. Dive deeper into designing fault tolerant, high performance, high scale, geo-replicated, secure solutions.
- Increase your expertise about everything that intersects with technology and successful solution delivery, including, integration technology, DevOps, agile methodologies, CI/CD, etc
Certification Isn’t as Important as you Might Think It Is
- You don’t need TOGAF; I’d prefer to see people spend their time getting technical carts in their domain over TOGAF. Of all of the architects I’ve worked with, I have not noticed anything at an aggregate level that distinguishes a TOGAF certified architect from a non-TOGAF certified architect in terms of effectiveness in their role as an architect.
- You don’t need technical certs, but they can be useful to demonstrate particular expertise in a given technical domain. This expertise can also be demonstrated in other ways, including a portfolio of successful implementations given a particular technology, subject matter expert level of expertise demonstrated via mentoring, knowledge sharing, presenting, and being an evangelist for the technology, etc.
- Certs might help increase your technical knowledge which is great for development and very important for architecture, but remember these roles have a dependency on knowledge and not on certs.
- Think about the tens of thousands of people who hold coveted certifications in particular technology domains, but have little to zero practical experience in them.
- The phrase “if only I just had more certs” is a fallacy. Don’t fall for it.
Find a Mentor
- Look for architects in your organization that could mentor you in a formal or informal way, but make sure to find the right kind of mentor.
- Look for architects who are doing a great job overall and have garnered respect from their colleagues and peers and who are open to sharing their ideas and methods with you. Often these are the same people who are already completely transparent with their methodology and are already looking for ways to multiply the output of the people around them.
- Don’t just chose anyone to be your mentor; if you can’t find the right architect to mentor you, look outside of your organization instead. Ask people you know who might know a good fit within your extended network, and consider if you are following anyone on LinkedIn who may be a good fit as a mentor – and ask them.
- Personal Anecdote: Early on in my career, I remember working with an architect who was pretty closed. They didn’t like developers asking questions about their methods, and they didn’t want any transparency into their work (One of their responses might be: “You’re a developer, you shouldn’t be asking about or being involved in these conversations.”). Terrible attitude and needless to say, these are not the mentors you are looking for and likely won’t have the career progression that is worth emulating. I simply moved on and found other people to emulate and who worked well with other people.
Start Thinking Like an Architect
- Consider the architecture perspective of every technical challenge or piece of technical work presented to you.
- As you aren’t actually an architect yet, you won’t have the title or the accountability. The issues with that is that it is others that will hold accountability; this may be your manager, another architect, or someone else in a more senior position than you. Because of this, it’s important that those who hold the accountability know what’s going on – over time they may (and should) empower you to make bigger decisions, but you’ll still need to align and work closely with them.
- Developers like doing ‘fun things’ and sometimes that can lead to development for development’s sake (aka building out things which are fun for the developer, yet don’t always yield the highest business value given the effort and other priorities even though it keeps the developer busy). Try to avoid this kind of trap, and always focus only on building what delivers business value and be transparent about it.
- Instead of rushing to build something – see what else exists.
- Personal Anecdote: Before I became an architect, I was asked to build out a .NET based training application for one of the global divisions the company I worked for at the time had (develop the code, basically). At that time, and unbeknownst to that division, there was a company wide PeopleSoft training module that was just provisioned at the head office with the possibility of having other divisions using it. I was aware of it and helped get other divisions already on-board with it. I brought this to the attention of the IT manager of the division, and he was on-board with it and we moved forward with that PeopleSoft solution instead of building something net new.
- This saved at least 3 months of work and allowed the division to on-board quickly.
- They had no idea about this other initiative. This is a core tenant of what architecture does — find effective ways to meet the business need, don’t duplicate; re-use technology where appropriate. Drive change and drive the business forward.
- If you think about it, how many developers would have taken on the initial development work and just did as they were asked? They might be the greatest developers at the company, and they’ll happily slave their days away for 3 months building the best darn training app known to exist because that’s what was asked of them. However, there is a huge hidden benefit that would not have been brought to the table by the developers who’d have happily slaved away building a new and amazing training app.
- If you want to be an architect you need to think like an architect thinks, and you need to be pro-active in driving change. Focus on the right things rather than succumbing to tunnel vision that prevents you from seeing beyond what you are presented with.
Good luck on your journey to becoming an architect. Additionally, take a look at a recent article I wrote Evaluating Solution Architect Competence – 10 Indicators which delves into the core competencies of Solution Architects. I also wrote Six Key Traits of Successful Solution Architect Consultants.