There are some definite benefits to being a soldier - the rush of being a part of something larger than yourself, having a well-defined role which is important and vital to the success of great enterprises, the camaraderie of fellow soldiers, and the belief that if everyone performs as well as you, victory will soon be at hand.
However, the reality of a battlefield is that not all soldiers are equal. Some troops are well trained, well equipped, disciplined, and possessed of a great deal of combat experience; others are recently thrust into battle straight from civilian work, lacking knowledge, discipline, experience, and even the will to compete against hostile enemy forces. Similarly, in the software industry, there is a great degree of difference in productivity between the best and worse performers. For the most part, raw recruits in the software industry frequently have the will and a fair degree of knowledge but need a proper environment to acquire the discipline and experience required to excel. Therefore, more experienced and disciplined developers are forced to leave their comfortable foxholes to assume the greater responsibility of leading a team of developers with diverse development experience into the greener pastures of effective software development.

Leadership Is a Necessary, Learnable Skill

It is rare that a talented developer can immediately excel when first thrust into a leadership role. Fortunately, leadership, while being a necessary part of an architect's skill set, is also a learnable skill.
Special characteristics of architectural leadership must be emphasized in order to maximize a software architect's chance for success. They are vision, integrity, and decisiveness. Vision provides a concrete goal for a development team to focus upon. Without having a vision, it will be difficult to justify the rationale for the many technical decisions which are made throughout the development life cycle. A high standard of integrity is essential for motivating team members to look beyond their own self-interest and consider the various issues from the viewpoint of what is best overall rather than easiest for them. Finally, an architect needs to be decisive, both to facilitate progress and to maintain the confidence of the team.
It is the job of the software architect to clearly articulate a compelling vision for the software project. The vision provides the motivation for the team and provides the basis for making tradeoffs in order to accomplish the overall vision. The architect's vision becomes the software project blueprint, the clear path through which the overall concept of the software is realized in an actual software product.
It is absolutely essential that the software architect is honest and has the absolutely highest standard of integrity. As the technical leader, the architect has to advocate a particular approach as the most desirable technical solution. If the architect's actions are perceived as being motivated by other than technical reasons - for example, to appease various political forces in an organization - it undermines the trust of team members who are expected to preserve the architectural vision.
Finally, the most vital attribute a software architect must have is decisiveness. When a technical issue arises which requires the architect to make a decision, more likely than not the worse decision is to avoid making any decision at all. Doing so impedes, rather than facilitates, progress, and it frustrates people who can be far more effective once the decision is made. Remember that failing to decide something is also a decision, just one that is unlikely to result in any sort of resolution and may run an increasingly high risk of magnifying the problem. Not being decisive demonstrates to others both a lack of urgency and a lack of confidence in resolving technical issues. If the architect does not exhibit a determination to have the development effort succeed in its goals, then other team members will question whether the team and their role within it are meaningful and whether the team goals are worth pursuing.

The Architect as Team Builder

The software architect leads by bringing the team together. As the most visible and technical of the management staff, the architect is in a position to turn the mindsets of the team members in a common direction. Teams want to be successful. However, where people differ is on the details of what it means to have a successful outcome. To correct the first of these issues, the architect must continually communicate the vision of what the final outcome of the development team can be. This creates a willingness in team members to give the day-to-day decisions the benefit of the doubt as long as they believe that the end goal is sufficient to satisfy their own personal criteria for project success.
Once a team is on the same page as to the overall vision and desired outcome, the common view of where the team is going serves to lessen the contention about what is the best means to achieve it. In a software project, any time the discussion can be converted into a purely technical discussion rather than one based on personality and ego management, it is a major win in moving toward the project goals.
One important lesson software architects must learn is to trust the skills and talents of other people on their team. A common mistake of new software architects is to micromanage other team members. This results in one of two predictable outcomes.
(1) The other developers may become resentful of your lack of trust and confidence in them, resulting in a significant negative impact on their productivity with regard to the team goal and overall project vision.
(2) Even worse, the developers may eagerly allow the architect to assume the bulk of the project responsibilities. This creates the illusion of working in the short term, but it breaks down quickly as the reality sinks in that the architect cannot work as effectively on his/her own as with a high-performance team of dedicated developers focused on accomplishing the same outcome. Therefore, having trust in other team members to execute tasks independently is critical for the overall success of the team. Yes, this involves undertaking risks. However, it is important that others accept and live up to their individual and team responsibilities.
A software architect is sometimes required to mediate between conflicting demands of project management and higher-level stakeholders in a development project. Often the demands on the software developers were made higher up in the management chain than the software architect without detailed knowledge of the development staff that will be responsible for delivering on whatever claims and expectations were formulated. In order to be effective, a software architect focuses first and foremost on the needs of the development staff. At some level, every project plan is a fantasy. The software architect must be aggressive in serving the needs of developers through communicating with management, overseeing the purchase of productivity-enhancing tools, ensuring proper recognition for the team, etc. After all, the ultimate value the architect adds is to ensure that the developers are efficient and effective in performing their tasks.

Always Insist on Excellence in Deliverables

A responsibility of the software architect is to review developers work. Inevitably, in the early stages of a new effort, it is likely that several of the work products (use cases, designs, test plans, etc.) are going to fall short of the architect's expectations. Most likely, the disconnect between the architect's expectations and the work produced is due not to malice or a lack of effort but rather to a lack of understanding of what precisely the architect's standards are. This should be done professionally and politely, however; the quality and level of effort must not be compromised. If the architect does not insist upon excellence in the early development process, it is unlikely that it will ever be achieved in future iterations.

An architect should expect some resistance the first time any experienced developer has to undergo a work review. Typically, the architect will receive arguments about the worth of producing deliverables which satisfy the standards, about whether the task description was clear enough to sufficiently describe the desired deliverables, and a thousand or so similar variants, most of which blame the standards and the architect rather than the developer. The software architect's best course of action is to be gracious and accept full blame and responsibility, but insist that the additional work required to achieve the desired deliverable is performed in a timely manner. If this is done well, the most avid detractors of the initial standards will eventually become their staunchest defenders, once their value has been demonstrated later in the development process.

The software architect must be versatile and set an example for the rest of the development team to follow. For example, if the project is at risk of being delayed because a critical design is missing, frequently the best contribution the architect can make is either to sit down with the group and jointly develop the design. In either case, the architect should adhere to the same process, in terms of documentation guidelines and reviews, that everyone else on the team adheres to. Similarly, if integration is delayed because of problems in debugging tricky parts of the source code, ideally the architect will sit with the developers and, if all goes well, assist in rapidly resolving the obstacles. Not surprisingly, this aspect of being a software architect frequently comes easily to new architects, as it was a responsibility also assumed by them as experienced developers.

However, there are a few pitfalls which must be avoided. As the software architect, you have the most visible technical role. Like it or not, you are also the technical role model for the team and your actions directly impact their actions and mentality. Therefore, if you take or suggest shortcuts and kludges to quickly resolve a development issue, like it or not, you are implicitly advocating that others use similar means to resolve issues which they find problematic. Also, rest assured that less experienced developers will encounter many more things which are problematic than will the architect, and they will be more than content with adding numerous kludges to source code rather than asking for help in resolving the problems according to the known architectural principles. Similarly, if your code lacks a unit test or is not related back to the requirements specification, you will immediately discover several developers who automatically are following your lead. Therefore, as the architect, you must conduct your efforts exactly as you expect others to conduct their own behavior. It is far easier to start off with a good example and maintain it, than it is to explain why you didn't and yet still expect others to conform to your stated standards.

Some Technicalities

At a minimum, a software architect's courage should take two forms. First, no technical question should ever be feared by the architect. The decisions of the architect should be made based on his best technical knowledge. Not every decision is popular, but they are all based on understanding of various technologies and design approaches. Any question should either be answerable by recapping the known tradeoffs or be a source of information which may require that an existing tradeoff be reevaluated. Neither case reflects badly upon the architect, since honestly considering questions and hearing new information, even from critics, is a perfectly valid technique of information acquisition! A software architect should welcome both types of questions without getting agitated, as they both provide practice in articulating the project's architectural vision and may lead to cases where the vision is further refined in light of new information. Second, the architect should never be afraid of making a concrete decision.

One constant in software development is that good software architecture never just happens. It must be planned, monitored and defended over the lifetime of the software. If, as a software architect, you are not constantly monitoring the execution of software processes to verify that the architectural principles and guidelines established at the outset of the project are adhered to and maintained, then you are failing in your role. A software architect cannot be effective without actively seeking out the real progress and direction of the project from the developers who are performing the actual work.

The software architect serves as a technical mentor to other developers on a project. Often the architect is asked to help resolve technical problems or mediate a technical dispute between two parties. Rather than simply resolving the technical problem or deciding between the two alternatives, the software architect should go the extra mile. In the case of technical problem solving, the architect should walk the developer through the steps necessary to resolve the problem at a level of detail low enough that the developer can resolve similar problems in the future without additional aid. In mediating technical disputes, the architect should articulate the issues and design tradeoffs which make a particular alternative more desirable in a particular case than the competing alternative. If possible, the architect should figure out the concerns being addressed by the inferior alternative, and point out what elements are missing in the current case which, if present, would make that alternative more desirable. Ultimately, team members should feel that interacting with the architect is a learning experience. Furthermore, if the same technical issues are brought to the attention of the software architect, take the developer to task and ask why he/she doesn't feel comfortable resolving such problems without your assistance. Eliminating road blocks to applying new knowledge is an easy way to improve the efficiency of a development team. A software architect should always be willing to hold team members accountable for their lack of productivity. If a design is overdue, it is reasonable to ask for the reason for the delay and a description of where the elapsed time has been spent. Similarly, if a coding task is delayed, getting specific details about whether the delay was caused by problems in the design, debugging a tricky section of code, or unforeseen complexity in the implementation is vital. Such information can lead the architect to gain productivity increases across the board by conducting debugging tutorials or by improving design review procedures. Also, always make it clear that as soon as delays are anticipated, developers have an obligation to let the project manager know so tasks can be re-planned accordingly. Most development efforts, even ones with mature processes and an experienced team, cannot avoid some degree of chaos. Left unchecked, the unexpected technical and organizational issues could occupy just about all of the software architect's time.
However, any software architect needs to ensure that the bulk of his/her time is devoted to issues internal to the development team. An effective architect must always be available on relatively short notice to attend to the team's internal details, which may delay development if not attended to promptly. These issues include resolving disputes over interfaces between various subsystems, weighing in on problems caused by product upgrades, or providing verification that certain design approaches aren't in violation of the architect's vision of the system.

Architect's Walkthrough

An architect must give the impression that he/she is always available with the expectation that the internal demands of a development team will be greatest early in the development process through the design process, tapering off somewhat during implementation, testing, and deployment. The best way to be available is to walk around periodically and talk to people about their progress. If any significant issue comes up, set up an appointment between the two or three people most involved and discuss it at some time separate from that devoted to the walkthrough. This limits the time spent during the walkthrough and gives the people involved a chance to work things out on their own before the meeting. If the meeting continues to be necessary, everyone will be prepared to focus on a specific problem, which, if properly facilitated, can lead to a short, highly productive meeting.

Another benefit of the walkthrough is that you get a lower-level understanding of the project details than you would from just meeting with the team leaders. Restraint is required to remember that the primary objective of the architect in a walkthrough is to listen and understand the problems rather than immediately to attempt to resolve every issue. In fact, the less direct guidance given in a walkthrough, the better. Rather, think about the problem and make suggestions to the appropriate team leader. This will keep the team leader in the information loop, allowing him/her freedom in incorporating your suggestions into the overall team direction. In addition, it will provide you with greater insight into team dynamics in future walkthroughs.
The architect should avoid making too many suggestions directly to team developers, as these suggestions are frequently taken as mandates, regardless of the direction set by the team leaders.

The issue most new architects face is evaluating whether their efforts have actually made a difference on a particular software project. Fortunately, there are a few heuristics which are effective for recognizing when you are succeeding as an architect. Unfortunately, the ultimate metric, repeatably delivering high-quality software on time within the estimated constraints, typically takes several years to establish.

Heuristic 1: Arguments within a team are over increasingly trivial subject areas.
With any group of software professionals of diverse backgrounds, there will always be disagreements of some kind or another. Early in a project new to software architecture, the typical disagreements focus on whether or not XYZ is the right thing to do. Later, if the architect is successful, there is an implicit agreement on what to do, and the developer battleground shifts to arguments about how to accomplish XYZ. These arguments will be just as heated and impassioned as the previous wave of disagreements, but the debated issues are at a lower level. Later, if there is an implicit buy-in on how to accomplish XYZ, new arguments will arise, again just as heated, on what an implementation of how to accomplish XYZ looks like. While the volume levels and passion may be constant and to an outside observer the internal problems appear unchanged, it is the shift of focus which indicates vision, architectural, and design consensus. Achieving this consensus is a monumental accomplishment and eliminates a slew of problems which would arise did such a consensus not exist.

Heuristic 2: When it appears that there is no consensus initially, consensus is easy to achieve after listening to all sides.
Frequently, when establishing the overall vision and defining the architecture for a project, complete consensus is nearly impossible to achieve. For whatever reasons, there will always be a few people who will need concrete evidence of the benefits of the approach on their own personal level, before they will accept any vision save their own. Later, if a consensus is established, there will be roughly the same number of disagreements. However, most frequently, one side or the other is mainly motivated to ensure that its concerns are acknowledged and known to the team and is not actually demanding that all of its issues are addressed immediately. An architect should recognize such concerns for what they are and allow them to be presented to the team. Typically, when the minority side has been convinced that it has been heard and understood, it will not object to a more popular alternative plan which satisfies the architectural vision and project objectives.

Heuristic 3: Other developers are willing to argue the merits of the architecture.
When this occurs, it indicates team buy-in for the system architecture. Note that if the software architect considers himself the sole defender of the architecture and is always the first to rise to its defense, the architect will never realize that this architectural buy-in has occurred. Therefore, the architect should be patient and give others the opportunity to comment when architectural issues are challenged. If the architect is exceptionally successful, several meetings will pass where consensus is reached in accordance to the architectural principles of the project without the architect's saying anything. Of course, when this occurs in several consecutive meetings, the architect is obligated to bring donuts to subsequent similar meetings.

Heuristic 4: There is an implicit willingness to delegate development issues to teams.
As the subjects of many meetings degrade in quality, fewer of the team members will care about how many of the development issues (configuration management trees, coding conventions, utility modules, etc.) are resolved. In such cases, it is beneficial to everyone to delegate an issue to a group of two or three people. This group can meet independently, come to an agreement on the issue, and present the agreed-upon solution to the development team at a later date. In fairness, it is important that everyone agree to accept whatever solution is agreed upon by the smaller group. Otherwise, interested parties will not join the group in hopes of overriding the group's decision later, thereby wasting the efforts expended by the developers who possessed the initiative to join the smaller group.

Heuristic 5: The software architecture becomes less obvious.
you know when you are not succeeding as a software architect when the opposite of these heuristics are true—for example, if various fundamental aspects of the architectural vision are questioned throughout the development life cycle, or achieving a consensus on meaningful issues is increasingly more difficult to obtain. If a consensus is developing against the architectural vision, then it is necessary to understand the opposing arguments and discover why they are so compelling to the developers on the team. Sometimes, gaining insight into the compelling nature of the opposing arguments may result in modifying the architectural vision to one which can achieve buy-in from the development team. At other times, the software architect needs to present a better case as to why the proposed architecture is better than the available alternatives. Frequently, this may require educating the team on technologies and industry trends which they may not otherwise be aware of.

It is important to differentiate between architectural leadership and management.
The most obvious difference is that the software architect is responsible for creating and articulating the technical vision of the development effort. Frequently, the architectural vision is not limited to a single effort but provides a blueprint of what the organization can accomplish in the long run. The success of the current project validates the architectural vision and provides greater confidence that the long-term architectural vision is achievable through similar methods.
Management, on the other hand, is focused on the success of a short-term project with limited, well-defined objectives. For example, an architectural vision could be a component-based enterprise framework which may be used to produce scalable applications in several domains. A manager's goal is to produce a workflow management system for logistics in nine months with a team of twelve developers. Similarly, a manager has to ensure that a specific set of agreements are satisfied and often has to interact with external stakeholders to verify that what is being produced matches their expectations. Any changes in direction, such as new requirements or procedures, are communicated from external stakeholders to project management, whose responsibility is to communicate the changes to the team.
The architect, however, is focused more internally and communicates why the work is meaningful and the purpose of doing things in the prescribed manner. It is not uncommon to have the software architect advocate taking more risk and adopting radical changes if he is expected to produce a technically superior product without involving too many additional resources.
Management, on the other hand, tends to be more cautious and more willing to repeat technical approaches which have been successful in the past rather than gamble on state-of-the-art techniques. All but the most routine of software development efforts require both a software architect and a project manager.

Seven Habits of Highly Successful Software Architects

Keep it simple. When communicating to team members various architectural concepts or software mechanisms, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group. Instead, say enough to communicate the idea at a high level, just low enough to be understood in principle, and let individuals do their own homework or meet with you individually to address their specific concerns.
Let others defend the architecture. It is always preferable to have someone else respond to a technical concern rather than have the software architect appear to be the sole source of knowledge. It reinforces teamwork, provides the architect insights from people who agree as well as disagree, is a key aspect in mentoring others, etc.
Act, don't argue. Arguing technical points in a meeting wastes time, hurts feelings, and seldom if ever fully resolves any technical issues.
When such an argument starts, act--either assign people to get or verify the relevant information, set up a meeting specifically for resolving the debated topic, or, if time requires an immediate course of action, lay down the law explaining why the time constraints force an end to the matter.
Keep an eye on the prize. Always be aware of the end goal. It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to one form of tunnel vision or the other. However, it is vital that the architect is always focused on the overall vision of the system and can relate every task or technology to how it contributes to the end goal.
Be willing to change, but never too much at once. After the initial bootstrapping of a software development effort, be wary of implementing too many process improvements all at once, as there is a risk of compromising the effective parts of the process.
Learn where to stop. Resist the temptation to go into too many details and to micromanage design decisions. For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be reused throughout the application.
However, detailing the specific caching algorithm used or writing the caching pseudo-code is probably overkill. Learn to trust other team members to provide design and implementation details and let them come to you in case of difficulties.
Know how to follow. If there is a lead architect you report to, or even if you delegate the responsibility for an issue to someone else, avoid publicly confronting others on major design issues. This is accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions.
This is a key aspect to developing a focused, high-performance team.

---

• Run Away Back to Mama
• Basic Level
• Drill Sergeant
• Navy SEAL
• Special Advisor
• Commander-in-Chief
• Secret Agent
• I Spy

---