Architecture as Leadership

I have the privilege of working with some really smart folks here in MSIT. One of those folks is Gabriel Morgan. Like Gabriel, I’m passionate about Architecture and what it means to be an Architect (well at least as I think of it, anyway). In my time here at The Big Show Gabriel and I have had many conversations about the role of the Architect.

In these conversations one of the ideas that Gabriel and I fervently agree upon (like true Architects we don’t agree on everything ;-) is the concept of Architecture as Leadership.

For those poor souls who have had the distinct misfortune of working with me this idea is nothing new – it is something I’ve espoused for years. At the risk of boring these readers, I want to publish some thoughts on this subject today.

NOTE – While I’m using the specific example of the Software Architect here, I would argue that the ideas are readily transferable to Solution, Enterprise, or any other kind of Architects as well.

Some History, and Hype, of the Software Architect

If one was to take a very simplistic view of the subject leadership (which I obviously am for the purposes of this post ;-), one could make an argument that leadership takes two primary forms – leadership via influence and leadership via authority. In gross terms the former type of leadership is epitomized in the concept of Sales (can I convince/influence you do to something), while the latter type of leadership is epitomized in the concept of Management (you have to do what I say because I’m your boss). The corporate world has traditionally seen Management as the route to leadership within organizations. In terms of software, this tradition has manifested as Developers having to choose between hitting a promotional glass ceiling as Individual Contributors (ICs) or going into management.

Those of us who’ve been in the industry for a while (more than a decade) readily acknowledge that this situation was suboptimal. Arguably, the development of senior level IC roles like Software Architect were an inevitable outgrowth of the realization that potentially brilliant technical leaders (e.g., super-talented Developers) were not necessarily going to be brilliant managerial leaders (e.g., folks that excel at the care and feeding of the peeps, deflecting political BS, managing budgets, etc), and that both roles were needed if a technical organization was to be successful.

OK, I would postulate that like so many things in the software/IT industry the rise of senior IC roles like Architect follow a lifecycle typified by the Gartner Hype Cycle. To my mind, the Hype Cycle explains why we’ve seen an explosion in the number of folks in the industry with some sort of Architect title (“They’ve got their super geeks, so I’ve gotta have mine!”) and it further explains the proliferation of Architect-related titles (“If I have a BI Architect build my Enterprise Data Warehouse it would have to be, by definition, better than an EDW built by a Sr. Systems Analyst!”).

Using the Hype Cycle as a conceptual framework I would argue that the industry is still closer to the “Trough of Disillusionment” than it is to the “Slope of Enlightenment” in terms of Software Architects. I would offer the following as proof of this argument (based on personal experience and anecdotes I’ve heard from folks I trust):

• The number of Software Architects that are still perceived as being “Ivory Tower” and offering nothing of practical value
• The number of Developers in the trenches that still perceive Software Architects as nothing more than roadblocks to building quality software
• The number of articles, blogs, forum posts, etc that question the intent, duties, and value of the Architect role

To be honest, even as an Architect I still identify with the first two bullet points above. As both as a Developer and as an Architect I’ve had the misfortune of working with other Architects that fit the mold described by these two bullet points. I also must confess that at one point in time (a long time ago, mind you) I was an Architect that fit the second bullet point’s mold – although I’ve since been reformed (honestly, I really have).

To again use the Hype Cycle as a framework, if the industry is going to climb the Slope of Enlightenment and reach the Plateau of Productivity then we as software architecture practitioners are going to have to start doing some things differently – namely focusing back on the basics.

At the risk of being painfully obvious, I’m going to offer that we as Software Architects need to focus on our most basic responsibility – to provide technical leadership to the teams we work with. As described above, the rise of the Software Architect role was a response to the need of having dedicated expertise in technical leadership. I won’t bother going into the myriad of contributing factors (e.g., feature explosion, increased architectural complexity, globalization of development, the Internet, etc) driving this need for dedicated technical leadership – those of us in the industry know it all to well.

What I propose is a deceptively simple concept. I have a hard time imagining a dedicated Software Architect saying, “No, Dave. I’m not a leader at all. I enjoy getting paid to make life miserable for the Developers, it’s what I do.” However, I would argue that by saying that a Software Architect is first and foremost a technical leader that there are a number of subtle, but profound, ramifications to this view of the Software Architect role.

The Software Architect as a Technical Leader

One of the first ramifications of this view is the framing of the primary responsibilities of the Software Architect as a technical leader. What I’m about to propose is common in some organizations, but is foreign in many others. However, my experience has been that the following four responsibilities are required to enable Software Architects to lift teams out of the Trough of Disillusionment and move them towards the Plateau of Productivity:

• The Software Architect is responsible, along with others (e.g., Project Manager), for the overall success of software delivery within the Architect’s defined scope of responsibility (e.g., system, component, feature, etc)
• The Software Architect is empowered as the final arbiter of architectural decisions within the Architect’s defined scope of responsibility – Developers are bound by the Architect’s decisions
• The Software Architect is responsible for making as few solo judgments (aka “Architect Decrees”) as possible
• The Software Architect is responsible for continually obviating the team’s need for the Software Architect

I think it is worthy of note that none of the primary responsibilities listed above include something like, “The Software Architect is responsible to know more about everything than anyone else on the team”. I tend to think of this as the second ramification of looking at a Software Architect as a technical leader – technical virtuosity is a necessary, but not sufficient, condition for being a Software Architect.

Technical virtuosity is obviously required, otherwise the Software Architect could never deliver on the second and third responsibilities in an informed and efficient manner. However, the scope of modern software delivery has gotten so complex that I would argue that it is unreasonable to expect the Software Architect to be an expert in all technical subject areas on every single project.

Therefore, the Software Architect needs skills in interpersonal communication and consensus building – classic leadership skills.

That last point didn’t really hit me until 4-5 years go – and once it did I started to have greater success as an Architect.

Since that time I’ve been constantly amazed at how many of the lessons of the “business world” with respect to leadership are germane to the work of the Software Architect. Take, for example, the concept of leadership as leverage.

Out in the corporate world there exists a school of thought that leadership is a point of leverage (for some interesting ideas on the subject, check out “Certain to Win“or “Good to Great”). In essence, an argument can be made that one hallmark of great leadership is the ability for an individual to align the thoughts, motivations, and actions of a group of people towards a common purpose – human leverage. I subscribe to this point of view. If one considers some of the classic examples of leadership (e.g., Alexander the Great, JFK, Winston Churchill) then the concept of leadership as leverage is pretty apparent. I’m convinced that great leaders employ, at a minimum, the following ideas when building leverage:

• Management – Great leaders leverage the concept of decision authority as means of legitimacy for their ideas/message
• Sales – Great leaders capitalize on their Management legitimacy to reinforce their ability to convince/influence others with respect to their ideas/message
• Service – Great leaders feed their egos through the success of the group (however that may be defined – company, project team, direct managerial reports, etc)

Oddly enough, these ideas for building leverage map very closely to the four responsibilities of successful Software Architects outlined above:

• Management – As an empowered arbiter of architectural decisions, successful Software Architects use this responsibility as a means of legitimacy, not as a stick to beat Developers with
• Sales – Successful Software Architects rely on their ability to compromise and build consensus with the team to minimize the number of “Architect Decrees”
• Service – The best Software Architect feed their ego through successful delivery of software and the continual up-leveling of the team’s knowledge/skills

This line of thinking has lead me to the third ramification of looking at a Software Architect as a technical leader – Software Architects lead best when they are a point of leverage for the team.

Software Architects Should Focus on Leverage

I once worked with a MS CRM Architect that described the role of an Architect as a “force-multiplier” for the team. I was immediately taken with the term for two reasons:

1. I played bookshelf games when I was kid (dating myself a bit with this, aren’t I?)
2. This concept of “force multiplication” is quite a bit more intuitive than saying that a Software Architect is a point of leverage – even though they express the same concept.

Using this new term, the best Software Architects are obsessed with the amount of their force multiplication. In fact, in an ideal world this force multiplier could be calculated and Software Architects would be compensated based on this number (right now I imagine a legion of Developers clapping furiously in response to this idea ;-).

While all this high fa-lootin’ theory is intellectually satisfying (being an Architect, I do love the high fa-lootin’ ;-), I’m a delivery guy at heart.

As such, here’s a non-exhaustive list of practical ways for Software Architects to raise their force multiplier. I can personally attest that they all work, and Developers will end up respecting you – I swear!

• Mitigating Project Risk – A natural point of leverage for the Software Architect is to work with the Project Manager and the appropriate stakeholders in crafting the SDLC appropriate for the project. I can’t stress this point enough – There is no one silver bullet way of working that will always guarantee success in delivering software. The optimal way of working to build software can be affected by any number of factors, including the technologies involved, the location of team members, the skills profiles of the team members, and the nature of the software features. The best Software Architects bring their years of experience, and extensive knowledge of SDLC practices, to bear in an effort to increase the likelihood of success across the entire project team.
• Understanding the Problem – Another potential point of leverage for the Software Architect is gaining a deep understanding of the problem to be solved by the software. In particular, the Software Architect should gain this deep understanding from an “all-up” perspective. This type of understanding is often crucial for the Software Architect to make informed decisions in real-time as issues/problem crop up during coding. One of the most important ways that Software Architects bring leverage to software development is by implementing consistent, rigorous decisions across the whole code base that adhere to common architectural principles. Often these principles cannot be formed with out a deep, all-up understanding of the problem.
• Crafting a Software Architecture – This would seem like a no brainer for a Software Architect, but I’ve deliberately listed this item third to illustrate the point that the best Software Architects concentrate on the highest points of leverage first, and that isn’t always the obvious. The best Software Architects view the software architecture as the collective “big decisions” of how the software will be structured, what frameworks/technologies will be employed, what design patterns will be leveraged, how important cross-cutting concerns will be handled (e.g., logging and exception handling), and how architecturally-relevant requirements (both functional and non-functional) will be fulfilled. Generally speaking, what I propose here is more detailed than XP’s concept of the Metaphor, but is not Department of Defense-level specification either. The idea is that the software architecture is defined to the level, and in the way, required to get the maximum amount of leverage based on the realities of the project at hand (BTW – I will be writing a series of posts on Agile Software Architecture with UML shortly, stay tuned). 
• Federate Architectural Stewardship – For large teams/projects, the Software Architect should attempt to federate architectural stewardship as much as is possible. On large and/or technically complicated projects the Software Architect can become a bottleneck if every design/code review must involve the Software Architect. Instead, the Software Architect concentrates on activities that build leverage to allow multiple members of the team (e.g., Dev Leads) to participate in architectural stewardship practices. To make this a reality, the Software Architect often needs to create a software architecture (see bullet above) that guides design reviews and the Software Architect often needs to mentor reviewers (see bullet below) on architectural concepts.
• Facilitate High-Bandwidth Communication – Apparently “high-bandwidth communication” is a commonly used term here at The Big Show, so I’ve copped it for my own use here :-). As software development has grown more complex and abstract, it has gotten harder and harder to facilitate productive communication about software concepts – especially across large teams. As such, the Software Architect is constantly on the look out for the mechanisms to make communications about the software to be as succinct and unambiguous as possible. In terms of a specific project, this facilitation of high-bandwidth communication is often born of the software architecture. For example, the statement “I’ll update the Controller to add error handling and add a new error object to the Response message for that edge case” has high bandwidth meaning for a team with a software architecture employing very specific design patterns. Facilitating high-bandwidth communication also entails finding the best means for creating written documentation and/or specifications. This might necessitate the use of modeling technologies like UML or a Domain Specific Language (DSL). In many cases, the Software Architect will be required to mentor members of the team in the knowledge necessary to participate in the project’s high-bandwidth communications (see bullet below).
• Up-leveling the Leveragability of the Team – As referenced in the bullets above, the Software Architect may spend time mentoring members of the team on the knowledge/skills needed to allow for increased leverage. This mentoring may take many forms, including teaching team members UML, design patterns, a new DSL, or how to use a framework (e.g., NHibernate) in a manner consistent with the software architecture. Hopefully I can’t state this in a more ham-handed way – mentoring the team can sometimes be the most valuable use of the Software Architect’s time.
• Investing in Skills, Knowledge, and Technology to Increase Leverage – As the best Software Architects understand they are a point of leverage for the team, they are constantly investing in new skills, knowledge, and technologies that allow for increases in the Software Architect’s leverage. This point often has non-intuitive implications. For example, it might be more important for a particular Software Architect to be well-versed in Model-View Controller (MVC) from studying Fowler than it is for the Software Architect to invest in learning the ASP.NET MVC Framework. To continue the example, this may be true because the Software Architect works in a heterogeneous environment using multiple technologies. In this case an argument can be made that understanding the architectural impacts and trade-offs of MVC in general allows more leverage than knowing a single MVC framework. This being said, the best Software Architects do not spend all of their time studying theory. In the end it’s all about delivering quality software, therefore the best Software Architects keep their coding and hands-on delivery skills sharp.
• Listen to Developers – Hopefully this goes without saying. The best Software Architects respect the fact that Developers will, in some cases, know more about the nuts and bolts of writing code than the Software Architect. This tends to be increasingly true the more specialized the development is. The net result of this is that a Software Architect never knows when a Developer might present a better way of doing something or offer up a nugget of useful knowledge. As such, the best Software Architects listen carefully to Developers since listening is always in the best interest of the Software Architect. As a Software Architect don’t be afraid of statements like (this example is drawn from my own career), “Troy talked to me about using CI on the project. I think it is a great idea so we’re going to be using some tools he suggested called CC.NET and NAnt.” OK, this concept applies more broadly than to just Developers – steal every good idea that you can wherever you find them!

Whoa!

That’s quite a bit of pontification. I would be highly interested in the thoughts of other Developers and Architects…