A Week in the Life of a 27Global Architect

For many developers, including myself, their career aspirations apex at the title of “Architect”. It’s an impressive title, especially in the technical world, but many don’t fully understand what an Architect does, or what the role entails. 

Wikipedia defines a software architect as: 

To expand on this definition somewhat, a Software Architect is someone who evaluates project requirements, researches and keeps up-to-date with the latest technologies and technical standards, and attempts to marry the two into the perfect solution for any implementation. They’re the person who formulates and understands the overall design of the project, identifies the technologies utilized, and guides the implementation team towards the overall objective.

That’s the sunshine and rainbows definition at least! In reality, the role of an Architect is much much more nuanced. 

An Architect, or aspiring Architect, will likely have been a full-time developer for years, if not decades. They will have built up a significant base of expertise solving problems, formulating solutions, and implementing applications using a broad suite of disparate technologies. They may have specialized in a particular domain, like data or API development, or they might have diversified into a “full stack developer” who has had his/her hands in all facets of modern software development. The most important qualifiers are that an Architect has extensive experience in their field, a deep level of knowledge in their chosen domain, and most importantly, can formulate novel implementable solutions that solve unique, non-trivial problems.

With that said, what is life like as an Architect? The short answer is that it’s challenging, dynamic, and can be rather frenetic and stressful at times. The slightly longer answer is this: be prepared to toggle between many different roles, including but not limited to: architect, manager, project lead, documentarian, QA, DevOps, consultant, and developer – sometimes all on the same day. In my role, at least, I’m asked to take on nearly all of the following responsibilities, frequently concurrently, throughout the course of a project: 

• Thoroughly digest technical specifications, and then formulate a coherent and technically achievable solution, typically on very aggressive timelines.
• At times, assist in the translation of client or business needs into functional requirements
• Build easily understandable Architecture diagrams and flowcharts to help management/clients, developers, internal project team, etc understand the overall design and the end goal.
• After DevOps has provided the foundational infrastructure, be prepared and potentially accountable for configuring and validating any new environments. This could involve tasks like establishing secrets, configuring databases, managing user pools, setting up Docker containers, optimizing build pipelines, and more.
• Scaffold and potentially build out “Proof Of Concept” versions of proposed implementations.
• Be responsible for diagnosing infrastructure issues and either resolving or identifying the people that can.
• Review the daily work product of the development team, identifying coding and/or logic errors, anti-patterns, code “smells”, etc, and sharing your findings with the team.
• Answer technical or architectural questions posed by the development and or project management teams, help resolve blockers, and generally act as the steward of the project.
• Act as both a project and client technical fiduciary
• Is there a problem with the application? Take the initiative and identify the root cause, and likely resolve as well. 
• Act as the SME (subject matter expert) during Sprint planning and grooming sessions. Be able to provide context, feasibility, and LOE estimates when necessary.
• Be willing and able to jump in and code features or enhancements if there is insufficient developer bandwidth available, or the client needs something completed ASAP.
• Be prepared to communicate the status and details of any technical implementation to project stakeholders, both proactively and when asked.
• Write comprehensive documentation for all facets of the project, including READMEs to assist future developers in standing up local development versions of the application, write wikis to assist the business in understanding how the application works, clarifying the architecture, outlining how deployments and the CI/CD processes function, describing the branching strategy and development workflow for future developers, etc.
• Contribute to your company's architecture community, e.g. peer reviews of other projects, acting as a sounding board for fellow Architects, mentoring junior talent, etc.

What should be patently obvious by now is that a Software Architect is, to use a factory analogy, expected to take on the roles of owner, facility manager, foreman, line manager, accountant, inventory manager, factory worker, 3rd shift seasonal help, and quality control interchangeably throughout the lifecycle of a particular project. You must be able to comfortably wear all of the hats, at any time.

At the end of the day, the success or failure of a particular project depends on the active and vigilant oversight of the Architect assigned to the task. The Architect can not assume that the developers, or even the project managers, understand the what, or the how, on any given task.  The Architect must take full responsibility and ownership of any project for which they have been assigned.

For example, in just the past week, I have been engaged in the following tasks:

1. Stand up and build out robust online developer and managerial documentation
2. Experiment and determine root cause of behavioral anomalies between browsers
3. Diagnose and resolve issues with database configurations in a Production environment
4. Diagnose and resolve issues related to container definitions and environment variables
5. Diagnose and resolve API inconsistencies between environments
6. Diagnose and resolve issues related to an API Gateway configuration
7. Make a number of requested UI updates in preparation for a client demonstration
8. Build out user stories and clarify objectives in upcoming Sprint(s)
9. Read and digest API specifications for new 3rd party service, determine the level of effort required to integrate with this new service
10. Refine and optimize CI/CD pipelines to maximize reusability and minimize human engagement (approvals, monitoring, etc)
11. Revise and review internal documentation, Architecture diagrams
12. Consult with team members on their projects, provide input and direction
13. Review Pull Requests, provide guidance and feedback to the development team
14. Answer questions from both the development and project management teams
15. Meetings. Many many meetings.

This list is not exhaustive, but communicates my point - an Architect is not only the person who designs a solution, but also the go-to when something goes wrong, a question needs answering, or if a project needs additional development support. 

The role of Technical Architect is demanding. It’s dynamic. The responsibilities change almost daily. To use yet another analogy, you are the captain of the ship and you must be prepared to not only command, but to also man the rudder, and be willing to take on the role of any other crew member on board. I, personally, enjoy the challenge. Every single day is different. It’s impossible to get into a routine because each day brings new and different demands. It keeps me sharp because this role consistently forces me out of my comfort zone, and as a result, I’m constantly having to learn new things and solve new problems. 

I find the role, and the resulting challenges, exciting.

Onward and upward.