Let’s start with a small exchange, experienced by almost all of us; developers at some point in their life.
Rookie Dev 1: What is that architecture diagram and the document?
Dev 2: Nothing bro, just that architect and BA had fun for 4 weeks on-site and gave us this 1 document and now expect us to design and develop the application in 8 weeks!
The evil architect
Being a software architect is thought to be a natural progression from a coder or technical leader to architect… but it is a different beast which needs a different thinking, different way of looking at things, a different view of the problems and taking into account business as well as the software life cycle and beyond.
As a developer, you are usually given a module or a class or a functionality to implement by your module or technical lead.
The lead, in turn would have been assigned some portion of the overall application, which they needed to design (application design).
The overall application/software design is based on the “big picture” architecture provided by the Software Architect.
A software architect may need to define the software or application architecture, within the definition of the System Architecture.
A system architecture may need to define itself within the strategies defined with the Enterprise Architecture.
Now as you can see, we have some distinct categories where we can put overall application from start to finish.
We do get some overlap between these layers, where Architecture will overlap with design and design will overlap with implementation. But categorically we have distinct phases.
The architecture, will abstractly define the structure or skeleton of your application BUT hide the implementation details. It would define different sub-systems and their interaction and communication between them.
Take for example, you NEED an architect for the entire house, but you DO NOT need him/her just for the kitchen remodeling. You need an interiors designer.
Design would go a step further and start to define different module level details like which library to use to send emails or build your own, use which ORM or have your own classes. Which classes and interfaces need to be developed and how they will interact with each other etc. etc. and how they will be implemented.
If someone wants to understand how a software or an application works, architecture documents and models, should be the first place for them to go.
A software architect should bring order and organization to the chaos of software design and development. Now, you could be an architect sitting in the ivory tower, handing down the documents and models down the chain OR ideally you should be involved and participate and collaborate with the team.
Should architects code?
Next question I have usually heard from many a team members is, should architects code also and NOT just provide documentation and models and diagrams?
I, personally agree that an architect should be hands on. It keeps you relevant in the market and you have a better understanding of what developers are facing due to your architecture. It goes a long way in avoid the issues of ivory tower architecture.
As an architect, you should be the master builder. You should have in-depth skills on technology and knowledge along with the broad knowledge of designs, patterns, non-functional requirements, alternative technologies and methodologies and various options and trade-offs available.
Up-front or just-enough?
Traditionally, all the software architecture was done up-front. All the requirement capturing, analysis and design should be completed before any coding starts.
But the new and the latest way, have a living architecture, where your architecture evolves according to the design and code, throughout the software cycle. This DOES NOT MEAN that you start reorganizing the whole architecture in middle of a release cycle.
“just enough” makes sense in today’s fast paced, agile environments but still as it deals with the real life environments, it is impacted by the constraints forced up by the operating environments.
With “just enough” architecture, you still need to identify and understand how all the key elements fit and work together. You should identify the key risks and the mitigation strategy and provide a firm foundation and vision for the software to move forward.
So as an architect, what you should do?