Code Architect
What it means to lead the building of a virtual structure
An architect is someone who constructs the design of an object. In the context of physical objects like buildings, cars, or bridges the design of the object and the implementation itself are completely separate. The act of designing the car and the act of physically constructing it are in no way similar. Designing consists of rendering pictures either through computers or pen and paper or both. The design consists of images and written text. It is an idea. The physical implementation is none of these things. It is an object that exists in the physical world and either fulfills its purpose and gives you a new capability, or it doesn’t and is considered a failure. The design is an idea of ink and data, the implementation is an object of wood, plastic, and metal.
It is somewhat rare that the designer and implementer are the same person in the world of physical products. Often the scale of the object is such that you could never have the architect actually implement the entire design themselves. This is a concept we are all familiar with, and we carry it with us into virtual systems.
In the virtual world however, I believe this intuition ceases to aid us. In fact, I would argue that it is an incredibly effective saboteur. In the world of software, the difference between the design and the implementation is much more blurry. The design is still a series of visual renderings and written text, but now the implementation is also a series of visual renderings and text. The limitations of scale that exist in the physical world are no longer relevant in the virtual. It would take a team of people in a construction crew to build a building that could house a thousand people, but a single programmer can write an app that serves millions of people. The reasoning for why the architect and the implementer are different individuals dwindles to nothing.
My advice, beware the non-implementing architect. In my experience, they don’t exist in the world of software. A software architect is only actually as good an architect as they are an implementer. This is because there is really no difference in the act of each. In software, to implement is to architect and to architect is to implement. The difference between implemented code and pseudo-code is the writers grasp of programming syntax. And if they have a weak grasp of syntax, I would be highly suspicious of the efficacy of anything they design.
So what should you expect of someone who calls themselves an architect? What should their minimum deliverable be? In the context of a building, you would expect a blueprint of the floor plan and a 3d rendering of any of the more complex elements of their design. For software, people typically expect some box-and-line-diagrams and maybe some swagger docs. Honestly sometimes all they ask for is a written description of the system. I urge you to substantially raise the bar. The reality is that in the programming world, throwing together some diagrams isn’t difficult to do at all. It’s also not particularly useful if that’s all you’ve done.
In order for someone to consider themselves and architect, I would require them to be able to generate a functioning end-to-end proof of concept. In the same way a building architect might construct a not-to-scale model out of styrofoam, I expect architects to create demonstrations of their system. The only difference is that the software architects version should actually be usable. A user should be able to interact with their POC and use it in a way that demonstrates the functionality of the architecture. Deployed and working code is the only reasonable form of a blueprint.
To make things concrete (get it?), the following are what I consider the minimum viable deliverables for anyone who calls themselves a software architect:
A system diagram: your typical boxes-and-arrows diagram that shows networking constructs/servers/3rd party services, and sequence diagrams that show all network calls for all major paths through the system for core functionality
Documentation of all major technical decisions: a list of all major libraries, languages, and frameworks selected to implement each piece of functionality required by the system delineated in the system diagram. For each selected component, viable alternatives to that component should be listed along with reasoning for the ultimate selection.
A functioning proof of concept: a deployed implementation of at least one major pathway through the system that includes integration with every single library, language, and framework specified in the documentation. This should have initialization and invocation of each library in a way that demonstrates the baseline capability of that library to fulfill the needs of the system in the domain it is specified to solve in the documentation.
Synthesis of the previous three deliverables into the same wholistic deliverable: documentation should include code snippets from the POC, the system diagram should include named component choices from the documentation, the POC should implement the network boundaries outlined in the system diagram.
This is now an acceptable blueprint. A team of less experienced developers can take the output of this architect and actually build a full-featured implementation of the system. Anything less than this, and the implementation team will need to have on it architects of the same or better caliber as the original “architect” in order to construct a system at all. In the world of software, being an architect means rolling up your sleeves and building the thing yourself. There is no such thing as a non-coding architect. The only way to earn the privilege of getting to design is to help build. #realarchitectscode
