3 things I’ve learnt as an Architect
Having worked in architecture for a number of years, from analysing the technical detail to driving platform strategy, there are a few things, good and bad, that I’ve picked up along the way. From learning when to fight for your cause to when to collaborate with team members who have more specialised knowledge than you, every day as an architect brings something new. Here, I’ve outlined the three main things I’ve learned in my time while working as an Architect on digital transformation projects.
Don’t feel like you need to know everything
There’s a growing trend that architects are expected to have a broad knowledge base and it often feels like it’s simply not enough to know your own area of expertise. This could partly be due to all the new products and services being introduced by big organisations (Apache, AWS, GCP etc.) that cover a vast number of areas from security, event streaming, logging, data processing, data storage; the list goes on. This often means that you run the risk of becoming too broad as opposed to specialised.
While I have a passion for learning, it’s important to not reach the point where I know a little of everything but not a lot in detail about specific topics. Staying in touch with new tech and new offerings, while remaining focussed on my primary sphere of expertise, is the best way I’ve found to combat this.
As an architect, our role is to design the system end-to-end and be responsible for the final result. I’m always acutely aware that there are others who know a lot more than I do in certain areas of IT. But I’ve learned to use this to the team’s advantage. Working with some of the fantastic resources on the team, we can come up with a better overall architecture together than if I worked solely on every aspect.
This doesn’t mean you should become oblivious to all other areas; for example, an architect can’t ignore security if their interests lie in data storage. In this scenario, the architect would still need to understand concepts such as data at rest, how to overcome common problems, and how the different storage capabilities may help with this.
Fight for your cause, but be pragmatic
I’m always keen to find the best solution to achieve a client’s requirements; taking the time to assess different technology options or slicker processes. However, at times it is too easy to go off on a tangent – looking at new technologies for technology’s sake. I’m a fan of playing with new tech, but it’s often not what we need to get the job done.
Architects should provide solutions that achieve client’s ambitions and take into account project constraints (e.g. estimated effort, costs, timescales and required resources). In some cases, this may require cutting corners for a tactical solution, or to achieve a cut-down MVP that will realise business benefits sooner. However, if you fundamentally disagree with this approach for a particular project and think a more strategic design is immediately worthwhile, it’s important to fight for what you think is the right decision. As we all know, it is never a good idea to only build tactical fixes and add to technical debt. I’ve found that a great architect will provide the client with a range of options to work towards their desired outcome.
Find the right level of engagement
Some architects will be at the highest level, surveying the project they’re here to help. While others will be in the weeds daily, looking at every pull request, being notified of every bug and designing the technical detail. How far should you go? For example, if you’re in a project which adheres to some form of Agile methodology, should you join every standup, attend every ceremony and even set your architecture work up in sprints?
When it comes to these kinds of questions, do what feels right – right for the client and right for you. It’s essential to adapt for what the client and role demands. As part of my current role, I’ve had to adjust and operate at a higher level that I did in my previous role, which was more technical architecture. While I love learning about new technology and looking under the cover of how things will work for specific requirements, given the number of services in the current platform I’m designing, I have to focus on strategy before I approach the detail.
This is a fantastic experience; a new way of looking at what needs to be done by focussing on what the organisation’s business objectives are, the business processes in place and the future business landscape. I do still provide input in finding the right technical solutions, but it does mean that my level of engagement is of a different nature to what it used to be with the technical teams. While this could give rise to issues, discussing with the technical lead at the start of the project what we expect of each other means we now have a level of engagement that we are both happy with. If at any time this doesn’t feel right, we reassess and adapt. Whatever your approach, I’ve learned it is essential to set expectations to enable your team to get projects delivered.
Ultimately, it’s all about striking a balance. Adapting to the needs of the project and client, as well as to your own interests, can result in a more balanced view of architecture, and architects can become more involved with delivery teams to achieve the client’s goals.
