Your SlideShare is downloading. ×
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Technical Architect Role
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Technical Architect Role


Published on

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. The Role of a Technical Architect
    • Ian Maurer
    • [email_address]
  • 2. The Role of a Technical Architect
    • A Technical Architect is like…
  • 3. a “Firefighter”.
    • Technical Architects can be used to solve the toughest problems
    • This is a highly reactive, and thus poor, way of utilizing a Technical Architect’s talents and skills.
    • Instead…
    • 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.
    • Technical Architects should be developing and enforcing best practices (i.e., Fire Codes) for design, development and testing.
  • 4. an “Oracle”.
    • 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.
    • Instead…
    • Technical Architects should instead be “ Curators ” of knowledge.
    • TAs need to lead team members in the creation of documentation ensuring the quality and completeness of the information gathered.
    • TAs must also ensure that people utilize the documentation rather than repeatedly answering the same questions.
  • 5. a “Jack of all Trades”.
    • 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.
    • Instead…
    • 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.
    • 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.
  • 6. a “Coach”.
    • 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.
    • Instead…
    • 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.
    • The Senior Developer should be leading the individual tasks.
    • Also, to be a good coach, a TA must provide both warranted praise and constructive criticism.
  • 7. an “Expert”.
    • Technical Architects need to be experts in their domain in order to instill confidence with the client.
    • 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.
    • But being an expert is not enough…
    • Technical Architects must be curious people, constantly learning and improving their craft.
    • Because of this, TAs should always consider themselves a “ Student ” as well.
  • 8. an “Architect”.
    • Both types of architects can create plans that look wonderful on paper.
    • 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.
    • Until then, a Technical Architect must be…
      • A Storyteller
      • A Salesman
      • A Mountain Guide
  • 9. a “Storyteller”.
    • For a software project to be successful, the developers must have a shared understanding of the software design.
    • 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.
    • 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.
  • 10. a “Salesman”.
    • The greatest plans don’t mean much if you cannot convince others of their worth.
    • Technical Architects must be able to sell designs and solutions to problems to both the client and more importantly their team members and superiors.
    • Technical Architects must be able to sell themselves as experts in their field through publishing, speaking, etc.
  • 11. a “Mountain Guide”.
    • A more experienced and skillful team member who teaches others how to fend for themselves.
    • The guide understands and communicates the value and risks associated with the different paths ahead.
    • They are there when things get especially tricky.
    • 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.
  • 12. References
    • The “Mountain Guide” analogy was borrowed from this article…
    • mags/so/&toc =comp/mags/so/2003/05/s5toc.xml&DOI=10.1109/MS.2003.1231144