Lessons learned while working as an architect — Part II

Photo by Med Badr Chemmaoui on Unsplash

Few years back I wrote about lessons learned while working as an architect, you can read them here. Since then my role changed from an architect who works on implementation projects for a single customer to an architect who consults teams from multiple customers spanning different industries. Here are some new lessons I learned external consultant/architect.

Accept the fact that efforts realization will be low

While working on a single project, all you care about is details, and make it work. It’s a fulfilling job with a high realization of efforts, the outcome benefits end users, sometimes you need course correction, but you learn as part of that process which is also fulfilling. Consulting on the other hand is very different, you are always on the move, switching context, effort realization is very low, you spend time on things like POC, RFP, and RFI which may get scrapped suddenly. This impacts your motivation, and you may feel out of action. By accepting the nature of consulting business you will be able to cope with low realization.

Use/suggest patterns/styles/practices without naming them

Using loaded terms like Microservices to explain proposed design invites unproductive debates. The discussion moves to advantages vs disadvantages of said practice, everyone starts throwing buzzwords, and it derails the focus from the actual problem. What I learned is to just use the underlying idea, for example instead of saying “Microservice Architecture”, I say “Modular services holding their own data, using asynchronous channels and crisp messages for communication”. This removes unnecessary resistance and bias. This advice looks contrary to practice of naming patterns to ease the communication, but I found it very effective.

Connect with real decision maker(s) and end users

As an external consultant, it takes time to get access to real decision makers within the customer organization. Sometimes the org structure does not reflect real flow of decision making and influence. Finding the key decision makers, opening a communication channel with them, and establishing trust is key for success. There is no formula for this, you have to observe, listen, and follow the memos (like follow the money). On the other hand, finding end users is easy, but getting access to them is very difficult for external consultants. Organization policies, politics, and culture builds multiple barriers between you and the end users. Connecting with end users, and understanding their needs helps you to distill the problem statement. It helps you to ensure that you are building the right thing for the right people, and deliver it incrementally.

Understand and pick your battles

As an architect providing appropriate technology solutions to a business problem is your primary battle. Defining the problem is also a battle, navigating a complex org structure for information is another one, and so is selling your solution. Each battle requires different skills, you can’t master them all. You have to pick your battles, work with your team to augment skills which you don’t have and support them for remaining battles.

Thanks for reading.




Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Case Study: Design Development of an App for Saving

Design Systems Meetup @ F-Secure

Green Diet — Midterm app project

Six Lessons From 15 days of Replicating UIs

Matchly: a college side project.

10 steps to be a better ally

A protest sign on a climate march. The sign says: “Fight today for a better tomorrow”

FigMagic — The new magical way to start new projects in Figma in 2022

EdTech Battle Lines: Specs vs. UX

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ajay Bhosale

Ajay Bhosale

More from Medium

Resource Oriented Architecture and Design

Produce different kinds of results dynamically from the same processing procedure by leveraging a…

Learnings from a Microservices Migration journey

Enterprise Application Architect- Part 1