Find my posts on IT strategy, enterprise architecture, and digital transformation at ArchitectElevator.com.
Defining what a software or IT architect is or does is no less challenging than defining software architecture itself. The SEI maintains a list of software architecture definitions, yet I have not seen a corresponding list for software architects. One could try to skirt the issue by declaring that software architects are the people who make software architecture. However, I think that this approach would be missing some important aspects of being an architect.
When I am asked to characterize the seniority of an architect, I resort to a simple framework that I believe applies to most high-end professions. A successful architect has to stand on 3 "legs":
This classification maps well to other professional fields such as medicine: after studying and acquiring skill, doctors practice and treat patients before they go to publish in medical journals and pass their learnings to the next generation of doctors.
While the model is rather simple, just as a stool cannot stand on two legs it's important to appreciate the balance between all three aspects. Skill without impact is where new architects start out as students or apprentices. But soon it is time to get out into the world and make an impact. Architects that do not make an impact do not have a place in a for-profit business.
Impact without leadership is a great place for a solution architect who is engrained in projects. However, without leadership this architect will hit a glass ceiling and won't become a thought leader in the field. Many companies don't put enough emphasis on nurturing or pushing their architects to this level as they fear any distraction from the projects reduces impact and thus will cost them money. As a result, architects in these companies plateau at an intermediate level and typically won't lead the company to innovative or transformative solutions, which can be a much higher cost. Some companies like IBM formalize this aspect of leadership under the category "give back": distinguished engineers and fellows are expected to "give back" to the community inside and outside the company.
Likewise, leadership without (prior) impact lacks foundation and may be a warning signal for so-called ivory tower architects, which lack any relation to reality. This undesirable effect can also happen when the impact stage of an architect lies many years or even decades back: the architect may preach methods or insights that are no longer applicable to current technologies. While some insights are timeless, others age with technology: putting as much logic as possible into the database as stored procedures because it speeds up processing is no longer a wise approach as the database turns out to be the bottleneck in most modern web-scale architectures. Even more dramatic is the misalignment of nightly batch cycles with modern 24/7 real-time processing requirements.
The circle closes when a senior architect mentors junior architects. Because feedback cycles in (software) architecture are inherently slow, this process can save new architects many years of learning by doing and making mistakes. In the end 10 well-mentored junior architects can have much more impact than one senior architect, so this aspect is critical to scale the architect skill. As I am continuously trying to recruit architects and sense that many other large enterprises are in a similar need of architects, scaling the skill set is as important as ever.
Mentoring not only benefits the mentee, but also the mentor. The old saying that to really understand something you need to teach it to someone else is most true for architecture. Likewise, giving a talk or writing a paper requires you to sharpen your thoughts, which often leads to renewed insight.
Experienced architects will correctly interpret the 80ies reference to mean that an architect does not complete the virtuous cycle just once. This is partly driven by ever changing technologies and architectural styles. While a person may be a thought leader in relational databases, the same person may acquire skill in NoSQL databases. The second time around building skill is likely significantly faster because we can build on what we already learned. After a sufficient number of cycles we may in fact experience what the curmudgeons always knew: that there is really not much new in software architecture and we've seen it all before.
Another reason to repeat the cycle is that the second time around our understanding may be at a much deeper level. The first time around we may have learned how to do things, but the second time we may understand why. For example, it is likely no misrepresentation that writing Enterprise Integration Patterns is a form of thought leadership. Still, some of the elements such as the pattern icons or the decision trees and tables in the chapter introductions were more accidental than based on deep insight. Only now in hindsight we can we understand them as instances of a visual pattern language or pattern-aided decision approaches. Thus it's often worth to make another cycle.