Hi everyone! In the last blog, we explored who a Software Architect was! This may seem simple but as we explored we got to understand the different types of Architects and how an Architect fits into the organizational chart!
Today we dive a bit further into understanding the mindset needed to be an Architect. Whether you are a team lead or a system analyst or simply someone who wants to step into the shoes of an Architect, this piece might just be the thing you need to know!
So how does an Architect think? Read on to know more
Know the business
The biggest change that needs to be there in the mindset is to understand the business that your employer is in.
This sounds trivial, like every employee of an organisation must know the kind of business that they are in. But, in reality, this is not the case.
E.g Amazon’s consumer side business may seem only that of the Amazon store selling items from books to electronics and so on. But in reality, it is a huge amalgamation of seller networks, affiliate marketing, inventory partnerships, storage and shipping etc.
As an Architect, we must have a deep understanding of the organization’s business.
Make yourself familiar with the company/organization’s:
- Weaknesses
- Strengths
- Competition
- Growth Strategy
One of the mistakes that architects make is that they view systems that they are working on as a stand-alone system, isolated from the rest of the organization.
But it isn’t the case! Every organization is a living organism with a lot of moving parts and an Architect must know how the system integrates into this living organism.
So an architect must first look at the business, before walking through the architecture of a system.
System’s goals
Here we don’t mean what a “System should do”. These are not goals, these are requirements and we must know how to differentiate one from the other.
Here we are talking about the effect the system will have on the organization.
Goals describe the Effect on the Organization. We must look at the bigger picture of how a goal will fit in an organization’s business.
We must know the environment the system is going to operate in and what obstacles it must tackle.
Usually, The client will describe the System goals, but this is not always the case.
Some examples of goals can be as follows:
Your Client’s Clients
One of the most important aspects of an Architect is to identify who the client is.
Architects are a part of the IT ecosystem but their decisions affect the end users. As an Architect, we must ponder and introspect what will be the effect of every decision on the end users.
The comfort of Client’s client is prioritized over the comfort of our own employer (client).
Sometimes the Client might not consider the end users as Client’s client. In such case try to convert them as at the end, users will definitely appreciate the willingness of any system to prioritize their ease of use and comfort.
Watch your language
One of the Architect’s roles is to talk to different people in the organization.
Always keep in mind what is the thing that really matters to the person you are talking to
An example could be that a tester might not be interested in how a solution for a feature was developed but simply on whether or not it meets the acceptance criteria for that feature. So an Architect must be able to provide contextual information across teams on the same.
E.g.:
So that is it for part 2! In part 3 we shall explore more about the architecture process of Software!
Discover more in the next blog!!
I keep on coding something cool, visit ankush.tech to see what all I am doing!
If you wish to read about my work, here is a book that I published recently – “CSS Bullets, a comprehensive guide to all the CSS you need!“
Interested in React? Learn react from scratch with my book, “REACT Bullets“.
Not subscribed to the newsletter? Subscribe now!!!
Thanks for sticking around!
Till next time, keep howling, hustling, and learning!
Leave a Reply