Technical Architect Role


Published on

Published in: Technology, Design
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Technical Architect Role

  1. 1. The Role of a Technical Architect <ul><li>Ian Maurer </li></ul><ul><li> </li></ul><ul><li>[email_address] </li></ul>
  2. 2. The Role of a Technical Architect <ul><li>A Technical Architect is like… </li></ul>
  3. 3. a “Firefighter”. <ul><li>Technical Architects can be used to solve the toughest problems </li></ul><ul><li>This is a highly reactive, and thus poor, way of utilizing a Technical Architect’s talents and skills. </li></ul><ul><li>Instead… </li></ul><ul><li>Technical Architects should instead be utilized as “ Fire Marshals ” that learn from the fires and use this experience to create and cultivate an environment that decreases the number of fires that need to be fought. </li></ul><ul><li>Technical Architects should be developing and enforcing best practices (i.e., Fire Codes) for design, development and testing. </li></ul>
  4. 4. an “Oracle”. <ul><li>A Technical Architect is frequently used as the sole resource of knowledge. People journey to the Technical Architect and wait for them to answer to their questions. </li></ul><ul><li>Instead… </li></ul><ul><li>Technical Architects should instead be “ Curators ” of knowledge. </li></ul><ul><li>TAs need to lead team members in the creation of documentation ensuring the quality and completeness of the information gathered. </li></ul><ul><li>TAs must also ensure that people utilize the documentation rather than repeatedly answering the same questions. </li></ul>
  5. 5. a “Jack of all Trades”. <ul><li>As strong technical resources, Technical Architects can execute on a wide variety of technical tasks. This again is not a productive use of a TA’s time. </li></ul><ul><li>Instead… </li></ul><ul><li>TAs should be a “ Match Maker ” using their ability to diagnose technical problems and evaluate technical skills (sometimes via proxy skills) to match a task to a person. </li></ul><ul><li>TAs should also understand what makes each technical resource tick… what kind of problems make them excited to come to work. This way a TA can also match the person TO THE task. </li></ul>
  6. 6. a “Coach”. <ul><li>A Technical Architect can lead and grow the developers working on the individual tasks of a project. This model, however, doesn’t appropriately leverage the Technical Architect. </li></ul><ul><li>Instead… </li></ul><ul><li>The Technical Architect must be a “ Head Coach ”. As in the NFL, they need to be leveraging their assistants (Senior Developers) and growing them into future TAs. </li></ul><ul><li>The Senior Developer should be leading the individual tasks. </li></ul><ul><li>Also, to be a good coach, a TA must provide both warranted praise and constructive criticism. </li></ul>
  7. 7. an “Expert”. <ul><li>Technical Architects need to be experts in their domain in order to instill confidence with the client. </li></ul><ul><li>They must also be perceived to have technical capability with their team (i.e. “geek cred”) in order to keep the team confident in their abilities to lead. </li></ul><ul><li>But being an expert is not enough… </li></ul><ul><li>Technical Architects must be curious people, constantly learning and improving their craft. </li></ul><ul><li>Because of this, TAs should always consider themselves a “ Student ” as well. </li></ul>
  8. 8. an “Architect”. <ul><li>Both types of architects can create plans that look wonderful on paper. </li></ul><ul><li>Once we can figure out how to make the construction of a software applications as predictable and process-driven as the construction of a building, then this analogy will likely work better. </li></ul><ul><li>Until then, a Technical Architect must be… </li></ul><ul><ul><li>A Storyteller </li></ul></ul><ul><ul><li>A Salesman </li></ul></ul><ul><ul><li>A Mountain Guide </li></ul></ul>
  9. 9. a “Storyteller”. <ul><li>For a software project to be successful, the developers must have a shared understanding of the software design. </li></ul><ul><li>Through storytelling (the communication of abstractions and analogies) the technical architect is able to keep everyone on the same page and going in the same direction. </li></ul><ul><li>Storytelling can be used at all levels of the architecture. From the highest level of an enterprise system to the construction of the individual units of code. </li></ul>
  10. 10. a “Salesman”. <ul><li>The greatest plans don’t mean much if you cannot convince others of their worth. </li></ul><ul><li>Technical Architects must be able to sell designs and solutions to problems to both the client and more importantly their team members and superiors. </li></ul><ul><li>Technical Architects must be able to sell themselves as experts in their field through publishing, speaking, etc. </li></ul>
  11. 11. a “Mountain Guide”. <ul><li>A more experienced and skillful team member who teaches others how to fend for themselves. </li></ul><ul><li>The guide understands and communicates the value and risks associated with the different paths ahead. </li></ul><ul><li>They are there when things get especially tricky. </li></ul><ul><li>The guide makes everyone (both the team and the client) feel comfortable that they are on the right path and that no insurmountable problem will arise. </li></ul>
  12. 12. References <ul><li>The “Mountain Guide” analogy was borrowed from this article… </li></ul><ul><li> mags/so/&toc =comp/mags/so/2003/05/s5toc.xml&DOI=10.1109/MS.2003.1231144 </li></ul>