Editorial Note: I originally wrote this post for the NDepend blog. Go check out the original here, at their site. While you’re there, have a look around at the other posts and at NDepend itself.
If you want to set off a ceaseless, spirited discussion, ask a roomful of people what makes some music good and other music bad. The opinions are likely to be as spirited as they are diverse, with, perhaps, good points to be had. But consensus is unlikely.
If you want to see a similar dynamic in the software development world, ask a roomful of software developers what a software architect is. What makes a person an architect? Does the architect write code? What kinds of decisions should an architect make? What is the relationship between architects and developers? Do developers report to the architect, or is it a “dotted line” reporting relationship? Maybe they’re peers? Do architects need to have a lot of domain knowledge? Do architects need to be the best programmers (or at least have been at some point)? You get the idea.
Go out and observe enough software shops in action, and you will see every different imaginable answer to these questions in every possible combination. This fact alone lays seeds for myriad communication complexities between developers and architects. In any shop, a developer is more or less a developer. But the architect role varies widely and, as developers move from company to company, this creates confusion.
Before going further down that path, let’s consider some things that are often true of a software architect. And, I say “often true” because, as I just pointed out, the definition is fluid enough that it’s hard to pin things down definitively the way we might say, “software developers write computer programs.”
- Architects tend to be the ones to make “big picture decisions” (which language/database/framework will we use?)
- Architects tend to have more tenure at companies and more industry experience.
- Architect tends to be a leadership role, meaning they supply either thought leadership, org chart leadership, technical leadership, or some combination.
- Architects tend to have more face time with “the business” than developers.
What do all of these tendencies mean? Well, simply put, they mean that architects have somewhat of a different area of focus than software developers. Developers concern themselves primarily with the tactical, and architects concern themselves mainly with the strategic. The concept of tactics versus strategy can be (perhaps over-) simplified to the idea that strategy is the “what” and tactics are the “how.” If it comes to your personal finance, “diversification” may be the strategy and “spend X amount on stocks, Y on bonds, and Z on real estate” may be your tactics.