For many years I couldn’t understand what software architects do. Early in my career, I thought they were useless. As a young developer, I felt that I could do the job of a business analyst, software architect, and developer all at the same time. Now, almost two decades into my post-college career I am one myself. I am trying to learn what it means to be a good software architect, and I hope to be one myself.
So, what changed?
About seven years ago I was hired by a startup to help build a cloud SaaS. Over time, I became responsible for platform vision, some sales presentations, thought leadership, and driving a team of developers. My working title was changed to Cloud Platform Architect. An opportunity to join ADP Innovation Lab as Chief Architect came up in the fall of 2016 and I took advantage of it. I have entered this role with seventeen years of post-college experience and a well-formed view of what thought leadership means.
In many ways, the developers are already architects. They are making decisions about software architecture routinely, as they do their jobs. Often they establish coding guidelines and styles among themselves. Good development teams are mostly self-managed, and the lead developer often acts as a Chief Architect as well.
As the project grows, however, someone needs to take ownership of the big picture. How does the project fit into the rest of the company initiatives? How does it integrate with other systems? How will customers use it? What technology should the project rely on? How will it scale? Will it perform? Will it be secure? At this stage, the role of a Chief Architect emerges.
The role of the Chief Architect
The role of a Chief Architect covers the following four areas:
- Business: the application works and meets business needs;
- Developer productivity: the developers are productive;
- Integration: the application plays well with other applications in the enterprise;
- Leadership: thought leadership and advisory;
The application under the Chief Architect’s responsibility has to work. It has to use the technologies and the architectures that are conducive to fulfilling the business requirements. The architect has to be aware of the business needs and understand the domain.
Productivity can mean many different things, but the most important is what I call “farm to table”: how quickly can a developer deliver a feature or a fix to the users? The developers applying the architecture have to be productive. Software architecture cannot exist for the sake of itself.
The Chief Architect cannot live in an ivory tower. The Architect needs to be able to roll up their sleeves and code alongside the developers.
The application has to work well with the other applications in the enterprise and with the outside world. It should use the same identity management, so the users are not required to create new credentials. It should use the same identifiers and speak the same language.
The Chief Architect has to be able to interact with the CFO, CIO, and CEO all the way down to the lowest level coder. They have to be comfortable sitting down with the board of directors and with rolling up their sleeves and coding alongside the developers.
To be an active leader the architect needs to “socialize” the architecture within the developer and architect community. They have to volunteer to speak at outside conferences and meetups and to offer guidance internally within the company.
Some last thoughts
A large enterprise may have many Chief Architects, sometimes multiple across projects. Some Chief Architects may have an org structure beneath them, while others are individual contributors. At a startup, depending on size, there could be one, and they may be referred to as the Chief Technology Officer. The role of a Chief Architect is a natural career progression for a life-long technologist who is not necessarily what they call “management material.” It is a role I am in today, and I love every moment of my job.