An architect’s journal — Skills.

Technology and software development methodologies changed rapidly during the last two decades. Nevertheless, the importance of a software architect got increased. Architects play a vital role inside autonomous teams even in today’s agile culture.

In my previous post, I explained my motivation to become an architect. Also, I tried to explain the role of an architect in the age of agility to a great extent. This post is about the characteristics of an architect and the skills required to develop. Of course, many additional skills might need to be a successful architect, but I’m highlighting a few from my priority list.

Simplification: Most of the architecture diagrams and specifications are complicated by design. Architects do purposely by thinking the complexity demonstrates their ability. However, it is the other way round — complex architectures do not help software development. Architecture has to build step by step for someone new to the problem space can easily understand.

I use a technic called levels, starting with level 0 and gradually building the system. In most cases, the L0 is a box diagram, L1 is a solutions diagram, and L2 is with the technologies and vendor products. This approach helps to explain complex problems and break them down into modules. The person who reads or listens does understand because the architecture build level after another.

Visual thinking: Architects are visual, therefore the best way to communicate and share ideas is to use graphical models. To do that, the architects have to be visual thinkers. For example, they use whiteboards, notepads, and, worse case, a napkin whenever architects gather. Visual thinking has to map and deliver using architecture-friendly notations ranging from the block, flow chart, sequence, UML to nonstandard.

I started drawing cartoons when I was a teen, and my favorite character was Fido dido. I used to take short notes using visuals to memorize lessons during my college life. Once I moved to the industry as a software professional, I started drawing doodles to communicate my ideas. blog.infodoodler.com is the platform I created to share my findings and educate the community.

Technical drawing: to represent visual thinking, architects have to draw — not arts but technical diagrams. Therefore the architects have to master technical drawing. Technical drawing skills help architects draw geometric diagrams, utilize spacing, and increase readability. In addition, creating a media kit that includes color schemes and an icon library is essential for consistency and authenticity.

I learned technical drawing in high school as part of the subject metalwork — many models to make various items modeled using technical (hand) drawing. Then, as a software architect, I mastered technical drawing to present architecture diagrams. Based on the quality of my diagrams, many colleagues asked me what is the tool I was using. (It wasn’t the tool; it’s the thinking pattern). I’m using OmniGraffle for more than a decade now, and I love Omni as a technical drawing tool.

Systems thinking: Architecture involves solving complex problems; therefore, architects must master systems thinking. Moreover, architects should have a holistic view of the system to design and achieve the results and objectives. Systems thinking is the foundation for this. Architects have to look at the whole picture while looking at the details on each component that assembles a system.

I look at how the system architect helps improve human life, which allows me to look at the holistic view and start applying systems thinking. Treating enterprise as a complex adaptive system (CAS) helps me look at the architecture beyond technology. As a result, I partnered with a friend (Gautham) and discussed business architecture in a blog named Transformity.info.

Market outlook: Architects have to keep an eye on what is happening in the industry — technology advancements, patterns, and practices introduced. That way, they can apply the same and build the most accurate architecture blueprints that can immediately generate value and future proof.

Keeping up to date with the rapid enhancements in the tech industry is challenging, but a successful architect cannot avoid it. I use multiple channels using a pub/sub approach. I follow most of the thought leaders in Twitter and LinkedIn, subscribe to good newsletters, am active in tech forums, attend tech events and watch on-demand videos, read books and articles as much as possible. Last but not least, try to teach by picking subjects in my domain.

Communication: An architect connects business and technology groups and speaks with technical folks — the architect is a curator. Gregor Hohpe explains this as an architect rides the elevator of an organization and connects the penthouse and engine room. An architect should simplify complex systems and explain them to others. Communication includes verbal, written, and visual channels.

Mastering communication drove me to become a Technology Evangelist after spending nearly two decades in core architecture roles. Activities such as mentoring and teaching others, being involved in various marketing activities, and working on external-facing technical roles such as solutions architecture and analyst relations helped me develop the communication skills required.

Implementation: We spoke about communication in the above topic, and some architects only pay attention to that. As a result, they become theoretical or PowerPoint architects. Therefore paying attention to implementation details and working on the same help overcome that situation. Agile development and autonomous teams have provided an excellent framework for architects to get involved with developers and contribute to software development. Architects have to get their hands dirty by coding and working on various configurations with supportive technologies.

In my previous post, I explained how I realized the importance of coding for an architect — in contrast, having the title of an architect, I was involved in many coding activities. First MMS application for Ericsson, mobile payments, automating ATMs with core banking systems, eventing for a modular middleware platform, and business communication protocols such as FIX and HL7 are a few examples. However, after moving to external-facing technical roles, I didn’t give up coding; I contributed by adding more product examples, extension points, and use cases required for demos. I’ve booked an hour in the evening for coding (hour of code) that I use to hack these coding tasks and at the same time teach my kids to code.

I assume the information shared is helpful for the architects and folks who are on the path to becoming an architect. So, I will continue my journal and discuss the simplicity of architecture in my next post. You will find more information on level 0 to level n diagrams!