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

Is a $20 Re-usable Notebook worth it? (5 Month Rocketbook Update)

A Black girl with Black hair, smiling and holding up blue Rocketbook Wave notebooks

Customer Story: Billing Transparency Between a GC, Owner, and Subcontractor

UX Case Study: Use Empathy to Rise the App Rating from 2,8 to 4,7 in Six Months

Designing UIs for climate change

Idea Generation Part 1

What different Henna colors are available?

In-Depth Look at Developing a Standardized Usability Test for Your Product or Website

محاورے ۔ ضرب المثل — Reflections.

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

Hexagonal Architecture- Ports and Adapters

When Should You Apply CQRS Software Architecture Pattern?

We Are Not Doing Domain-Driven Design — Part Two — CQS

Technical Debt: How to Identify, Plan and Deliver Debt Changes