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.

In a perfect world, the strategic and tactical planners operate in lockstep with different focus.  The strategic planners establish the goals and vision and the tactical planners translate those goals and vision into an execution plan.  But collaborating at different levels of granularity is an extremely hard problem to solve.  Most commonly, such as in the case of militaries or sports teams, the communication is simplified by giving absolute control to the strategic planner.  If the coach or the commander tells you to do a somersault, you simply do it without thought or hesitation, tactically executing the maneuver as crisply as possible.  This is at the heart of the command and control division of labor, and each level of the hierarchy becomes more strategic and less tactical.

In spite of repeated attempts by the industry to the contrary, however, this model tends to go poorly when it comes to knowledge work.  Asking software developers to operate in a purely tactical mode without understanding of or concern for the bigger picture produces profoundly bad results.  Massive graveyards of heavily templated, code-generated legacy applications speak to this.  Instead, software development goes more smoothly when architects communicate their strategic visions to the developers and the developers provide feedback based on tactical realities.

To give this a bit more concreteness, let’s say that I’m an architect and I have a vision for building some functionality with as little in-house code as possible to save on maintenance staff and costs.  Part of my strategic vision is, “Let’s use a 3rd party web service to locate stores near the GPS coordinates supplied by our users.”  The developers involved then set about making this happen, but discover that the third party API is actually extremely unreliable and subject to frequent outages.  But let’s say that, as they’re discovering this by perusing Q&A sites like stack overflow, they happen upon an elegant solution to do it locally with almost no code.  This is the point where communication has to be able to flow the other way as well.  Knowledge workers at all levels need to be trusted to participate in strategy, when it makes sense.

The question thus becomes, “How should communication between architects and developers occur?”  With two different areas of focus, how can each keep the other in the loop?  Well, here are a few critical pieces that can go a long way.

• Automate.  Architects in many organizations lay out coding standards and architectural guidelines to be followed.  Automate enforcement of these via the build so that out of band effort isn’t required to check that things aren’t drifting.  If a guideline becomes a serious point of friction, it’s time to surface it to the architect.
• Post strategic goals for all to see.  Goals like “keep in-house code to a minimum” shouldn’t be known only to a few.  Trust the people in charge of tactical work to understand the strategic backdrop and to execute it when they encounter ambiguity.
• Make the architecture visible.  It’s one thing to hear an architect ranting and raving about dependencies or global variables or whatever.  It’s quite another when everyone can see the architecture degenerating into a big ball of mud, one haphazard dependency at a time.
• Architects pair in from time to time.  Have the architects sit with the developers from time to time for a few hours here and there.  Write code together so that the the architects get a dose of the tactical friction every now and then to inform their strategic approach.

The suggestions I’ve listed here are by no means exhaustive, but they might help to bridge the communication gap between developers and architects.  Whatever the breakdown of work between developers and architects in your organization, there is no downside to having them collaborate as closely and efficiently as possible.  The more you can use tools at your disposal to facilitate that, the better.