When computers were small and programs short, writing programs for them was pretty much a solo enterprise. But as computers became more powerful, and importantly, interconnected, you started to see software development in teams, and with teams came the most unfortunate of byproducts, management.
In a modern software development project, there are in fact a lot of contributors who have nothing to do with actually generating code. You have a product owner, determining exactly what functions the software should enable. You may have user experience designers, who are turning those requirements into a cohesive and logical look and feel. You have UI designers, creating graphical assets and fleshing out the U/X designers. There are strictly overhead roles such as managers of different flavors (including scrum-masters, who are really just a specific breed of manager). There are the developers themselves, who may include team leads. And then there are the folks with the mysterious title of Architect. But just what do they do?
In my depressingly long career as a software engineer (the career isn’t depressing; the length of it is), I have seen no title as subject to variable interpretation as Architect. I’ve seen architects that were essentially the MVPs of the project, and I’ve seen ones that are speed-bumps on the road of life. Why they are placed onto projects, and how they are used, can drastically influence the overall happiness and productivity of a team.
Let’s begin our look at the role of architects with the most negative example. There exists a class of companies that have architects Because They’re Supposed To. In this kind of environment, architects can gum up the works in a number of ways. First, these tend to be the people who Read Things in Magazines (or online). They tend to be in love with concepts like elegance and abstraction (which are good in moderation), and to some extent try to justify their existence by making things more complex. They rarely code.
Let’s call this subspecies of architect the Formalists. You can tell them by the fact that they have more books on UML and Patterns on their bookshelves than on languages and operating systems. The Formalists believe in form over function. As an example of the kind of poison they can spread in a project, I once had an architect explaining to me that my clean, compact and well-tested Java code was unacceptable, because I did not implement a single Pattern in it. I added a Singleton (which neither helped nor hurt the code), and he became happy.
The Formalist frequently kills the enthusiasm of the developers with mandates that drastically increase the workload of the developer for little to no benefit. Formalists are the polar opposites of the agile process, because they will insist on building in levels of complexity far in advance of a proven need for the extensibility provided. If you have a simple application laden with Enterprise Service Buses and Factories, a Formalist probably had their hand in the design.
Let me be clear, when used correctly, architects are awesome. Let’s label the group of good architects the Pragmatists. The primary phenotype of a good architect is that they know how to code, and code well. Beyond that, a good architect serves a crucial role in the definition of the product requirements, not just drawing boxes at 30,000 feet.
To understand this role, you have to look at the lifecycle of a successful product. After the basic product requirements have been laid out, but before developers start to implement, there’s an important step that many teams miss. Someone, and by someone I mean a good architect, needs to flesh out the requirements into a sufficiently detailed set of high-level tasks. It is in vogue these days to do this during the “grooming” portion of the scrum process, but it really needs to happen much earlier, and by someone looking at the entire product and how this particular task fits into the overall picture. The architect needs to answer questions such as:
- Do the U/X, UI, and development requirements really cover the end user requirements (i.e., gap analysis)?
- Is this task being designed and developed in a consistent fashion to the remainder of the application (and, where appropriate, the way software is developed at the company in general)?
- Is the design flexible enough to allow future enhancements?
- Does the application implement appropriate levels of security and meet required performance standards?
The end work product of this step should be a thorough description of the required work (which developers can turn into stories and tasks) and an overview of what needs to be tested (that QA engineers can turn into test cases). Pragmatic architects translate the user-centric product requirements into sufficient technical detail to actually implement and test the product.
When you don’t have an architect in this role, it’s easy to see. You get a lot of “I forgot to mention” moments, when the implementation is complete to the specifications, but not to the actual end-user requirements. You get three REST endpoints that share a common business object, but transfer it using three different representations. You see values hardwired into the code, and developers having to design their own authentication and authorization solutions on the fly.
The big problem with the Architect title is that it has so many different meanings. Frankly, I’d like to see the position metamorphose completely, into something with a more clearly defined set of responsibilities. It’s really a role, not a job. Lead developers sometimes take on the responsibilities of an architect, and I know lots of architects who bemoan not being allowed to code anymore. The important thing isn’t whether or not you have an architect position; it’s whether or not there is architectural supervision.