The following summary contains my notes from an architecture workshop I attended by Mark Richards (http://www.wmrichards.com) at the O’Reilly Software Architecture Conference in New York in 2016.

This post is in continuation of my first post which summarizes O’Reilly Software Architecture Conference ’16.

Continuous learning is inherent part of an Architect’s professional journey and there are many ways most architects attempt to achieve this. Some options are listed below (options listed are not exhaustive by any means)

  • Online resources
    • Email newsletters
    • Following people on social media
    • Articles
    • Forums
  • Attending Software Conferences
  • Meetups
  • Technical discussions with peers

While there are many avenues for learning about trending technologies or tools to keep their technical knowledge updated, how could one approach prioritizing and learning them?

In limited time available for an Architect to devote for improving their technical knowledge, it is recommended to have a structured approach for prioritizing things to focus on.

Knowledge of an architect could be grouped into following three categories

  • Things you don’t know
  • Things you know that you don’t know
  • Expertise in something

Unknown stuff

There is overwhelming amount of information about various technologies out there. Knowing everything is impossible, there is no denying to this point. But that should not stop an architect from trying to learn new things.

Trigger for learning new things could come from virtually anywhere, it could be from a new business requirement or reading/discussing about some new technology. This trigger would push the new topic to learn that was previously in the ‘Things you don’t know’ category to ‘Things you know that you don’t know’ category.

Architect Continous Learning

Things you know that you don’t know

This is “the” important category of information that an architect should thrive to build. This category indicates the scope of technology awareness one has. Architect should have introduction to the things in this category but deep understanding is not required. This is the category of information Architect would rely on when evaluating solutions for business problems.

If further information is required on some topic of interest from this category, Architect can plan for building expertise in that area. Level of expertise required should be assessed based on how hands-on the architect needs to be in the implementation of solution.

Once the Architect has some level of expertise in the chosen topic of interest, it moves into the ‘Expertise in something’ category.

Expertise in something

This category houses knowledge about various technologies and related tools, processes or concepts that Architect has some expertise at various levels.

Maintaining expertise in any technology over a period of time can put tax on Architect’s time and availability for other tasks.

Architects should prioritize the technologies or areas where one would like to maintain their expertise. This category should have minimal things so that it is easily maintainable.

Closing comments

This approach of prioritization has worked out pretty well for me in deciding some of the new stuff I am planning to learn in coming days. Please update the comments area with any other interesting approaches that you adopt for keeping your technical knowledge upto date.