So, you want to be an architect?

Architects are typically revered throughout the organization and are often astute, technologically capable, and often must "walk and chew gum simultaneously”! Are you interested in exploring a career in technical architecture? In this episode of Armchair Architects, Eric Charran and Uli Homann (both highly revered architects within Microsoft) delve into the traits, behaviors, and proclivities of this rare breed.

How do you know when you’re an architect? One factor is determined by how you think about technologies, components, services and how they’ll be used.  Here are a few good indicators:

• If you think in terms of components and their interactions, then you’re thinking like an architect.
• If you’re done coding up a microservice and are concerned about how it’s going to be used and consumed
• If you care about the functional and nonfunctional aspects of a solution.

You need to be able to think beyond just technology and technical implementation, expose yourself to understanding business needs.  Architecture must support the needs of the business through technology design, planning and implementation. Architects will likely be required ‘sell’ architecture approaches to solving organizational requirements and challenges by explaining your rationale for certain choices, inclusive of the tradeoffs and alternatives. Architects must master soft skills which include convincing others and inviting diverse perspectives that create common understanding.

It’s one thing to have an architect’s mindset, but does the title matter? Well, yes and no. According to Eric, the title helps others to identify the types of things that architects can help with.  This helps the way in which architects can be included in strategic and tactical conversations and challenges within an organization.

Architecture can often be thought of in two dimensions.  There’s architecture in the small and architecture in the large. Architecture in the small is the notion when you significant or deep domain expertise for a component, workload, or functional area.  Architecture in the large is when you have a more holistic perspective about designing and building a solution.  This includes understanding how constituent components tie together and work as a whole system to satisfy end-to-end requirements.  Architects must develop the discipline of deciding between a vast variety of component options offered by a cloud provider while balancing cost, reliability, security, performance, and operational excellence.

Good architects can go both deep in various domains, as well as broad to solve for a particular solution. They can learn about how things fit together and then convince management about a chosen approach while also exploring alternatives and their benefits/drawbacks.  Architects must be able to utilize their experience and expertise to go “deep in minutes” in a specific domain and understand and advise within that domain, but also be broad enough to keep the whole solution in their sphere of consideration.

Another key trait is to convince and influence others without direct organizational authority. Many good architects can persuade engineers, leadership, or other architects, even though they may not own that responsibility or function.  The goal for an architect is to leverage influence, foster collaboration and converge and guide peers and leadership to a common understanding and goal.

So, if you can go deep and broad, you should also be able to balance between functional and non-functional considerations in a solution.

According to Uli, good architects also know when to be pragmatic and when to shoot for the stars. There’s a time and place for both, and experienced architects should be able to recognize the moment. For instance, when you’re about to migrate an app, it’s usually much better to be pragmatic and not shoot for the latest and greatest components. Balance is another word for pragmatism here, and great architects know how to balance.

As mentioned above, architects know how to ask good questions. How do you define what a good question is? Typically, good questions from an architecture perspective usually focus on gathering information about the immediate to longer term future state of a solution, before considerations and challenges arise.  Utilizing questions to anticipate changing business needs, drive leadership to consider possible outcomes and to accommodate for them before they arise help to build extensible, scalable and manageable solutions.  According to Eric, a good architect will always ask, “what’s next, or “how do we support that new code or capabilities,” or “who will manage this solution after its deployed,” or “after we go to production, then what?” According to Uli, it’s even simpler: just ask the question “why” until the core rationale uncovers itself.

Another key trait is empathy. That would be empathy for your engineers, users, decision makers, and/or clients. It’s especially important to empathize with business decision makers or organizational leadership.  In many cases, they have the responsibility to achieve transformative outcomes, on time, under budget and to do more with less.  Additionally, architects must simplify complex explanations, present viable outcomes, and recommend the best path.  This is a lot harder than it sounds!

For one, the decision makers may not understand the problem well enough or may not be technical enough to describe their requirements. As an architect, it is up to you to understand these non-technical requirements and propose a technical solution in a non-technical manner. A good architect will mask the complexity and layer on technical translation into business speak for decision makers to make the right choice.

Uli considers empathy for the users of a solution as another really important trait. His example centered around a large ISV in the ERP space who used to spend a lot of time talking about performance and reliability but not much about the user experience. This turned out to be a miss, as the users found the user interface was clunky and difficult to use. It was far from intuitive.

DevOps has helped alleviate this myopia, but there are still plenty of examples of architects turning a blind eye – and experiencing poor results.

For more details and examples of how great architects think and work, watch the video where David, Uli and Eric get into distinguishing traits and behaviors.