- Introduction
- Responsibilities
- Exceptional Work Product
- Exceptional Written Communication
- Developing a Technical Opinion
- Getting Hands Dirty New
- Building a Network of Organizational Leaders New
This document is for individuals developing their skills around application architecture and for professionals working with or managing application architects. I intend it as a direct and practical guide. The topics distill ten years of working with, managing, and mentoring exceptional architects around the world. I’ll add a couple of sections each week as I get them out. I hope you enjoy the read.
The primary responsibility of an application architect is to make and communicate architectural decisions via architectural work product. But this is not enough to excel.
An application architect must also:
- Ensure product and team success through architectural design.
- Ensure application designs are operationally supportable.
- Ensure development teams execute architectural decisions correctly.
- Continually improve lifecycle workflows for both quality and speed to market.
- Continually develop informed technical opinions.
- Understand the problems surrounding leaders are currently solving.
- Communicate effectively both up and down the organizational chain.
- Perform research and development to create new opportunities and improvements for both the application teams and the business.
An application architect must know with clarity who his or her audience is for the work product the architect produces. The work product cannot be for “the team” or for “anyone who needs it.” For some organizations, the application architect writes foundational work product for the project manager, the tech lead, and as a reference for fellow application architects. I include fellow application architects here because they may leverage the work product for other projects or take over when the original architect is no longer available. Work product for other individuals is on an as-needed basis.
Don’t get hung up if this is different in your organization. The point is that the audience must be precise down to the individual roles. The architect must continue to adapt and improve his or her work product towards those individuals’ needs.
The work product must be simple, concise, and self-evident.
The work product must decrease the cognitive load on the development team. It is the architect’s job to take complex problems and make the solutions simple for the development team. Be warry of producing complicated work product. It is a trap that feeds the ego at the team’s expense.
Concise work product is more likely to be read and understood. Don’t write a book. Everyone is busy.
Aside from an initial walkthrough with the intended audience, the work product should speak for itself. If the tech-lead can use the work product to explain architectural decisions to the team’s newest member, then the architect hit the mark. If, on the other hand, the architect must attend every product meeting to reinterpret architectural decisions, the architect has failed to make the work product self-evident. The architect has become the smartest person in the room at great expense.
It’s worth mentioning that an interconnect diagram, a drawing of components and lines, alone is not self-evident. Real understanding comes from an architectural use case document -- concise prose describing each architectural use case. This document communicates practical knowledge to the newest member of the team.
Producing exceptional work product will help your application team be successful. It will also free you up to work on other initiatives or contribute to the team in different ways. But it doesn’t wash your hands of an application team’s failure.
An application architect should meet with team leaders on a reoccurring basis and ask probing questions.
Probing questions should be designed to detect if:
- The team continues to execute Architectural decisions as intended
- The design still fits the needs of the project, isn’t unnecessarily complicated, and is supportable
- The technologies chosen remain within the capabilities of the team
The final step in developing exceptional work product is the post-project review. This review is a brief interview by a fellow architect and includes both the work-product recipients and the architect. Questions should probe what standards worked well and what needs improvement. The fellow architect should bring findings back to the architect team. This review is not a substitute for the technical evaluation that occurs before implementation.
An application architect must excel in two types of written communication styles. The first is technical communication. The second is written communication directed towards an executive.
Application architects should be practices in writing technical communications by the time they advance to architect. These written communications are usually emails, text chats, or other forms of writting to fellow technologists. They are brief, professional, technically relevant communications that arise in the course of working on an application team.
Writing to an executive audience is materially different. Because of the target audience, these emails must follow a different pattern. The beginning of the email must be extremely brief – at most, only a few sentences.
The first sentence must establish a simple context – what is this email about? This email will be one of many hundreds of emails an executive may read in a day, and a reminder of context is critical. Next, the email should clearly and concisely state the problem that needs solving or the information that needs to be communicated. Any additional relevant information should follow this brief introduction of context and ask. The email must avoid jargon and should spell out acronyms the first time used unless the architect is confident individuals both inside and outside of technology will understand these terms.
Exceptional application architects are comfortable admitting when they do not have a technical opinion about a matter. Although an architect should have a broad range of knowledge, it is impossible to know everything. What sets an exceptional application architect apart is that the architect will recognize this and communicate the responsibility to form a technical opinion on the relevant matter quickly. Follow-up is critical here.
Forming an opinion is done by seeking relevant, first-principles information. Opinion and second-hand knowledge will not suffice if the architect is to take the lead on a technical matter. If the architect cannot educate him or herself with first-principles information and develop an informed opinion, the architect should bring an appropriate expert into the project. Bringing in an expert doesn’t absolve the architect of any bad decisions. The application architect must adequately verify the advice of a trusted third party. Verification can occur as the architect continues to educate him or herself on the topic.
If the topic is so complex that only the most specialized individuals can understand the solution, the architect should verify outcomes as a part of the development process. Special care should be given to project planning around the additional inherent risk. This planning could be in the form of a POC or a callout regarding project risk. Other actions may be warranted to decrease project risk.
An exceptional application architect will perceive and fill the need to code along with many other purely technical tasks. The team may need a POC or prototype built to show how to integrate new technology. There are times when a new algorithm needs development. There are crunch times when the team needs general help. Sometimes systems or data need to be analyzed to figure out what is going wrong.
An exceptional application architect will continue to develop a diverse network of individuals to work with. As the architect continues to grow, the architect will seek to understand the organizational leaders around him or her -- both inside and outside technology. An exceptional architect will be able to answer the following questions of an organizational leader:
- How does your organization work?
- What is your strategy and how does it fit into the executive plan?
- What problems are you solving this year?
- Who are your leaders?
An exceptional architect will begin to develop a sense of how architectures impact the leaders around him or her. At the senior architect level, the application architect should already have a leadership network in place. A senior architect will develop solutions to problems that cross many organizational boundaries, but cultivating the needed relationships begins at the architect level.
Copyright (c) 2020, Charles Kaminski