How Learning the Software's Architecture can help a Business Analyst?

We all have super heroes in our lives. This can be your father, mother, teacher or even a marvel character. For Software companies also there is a one.

Who? Well in my experience across past work places more than anyone it's the software architect.

How is this person that cool? I call the software architect the Tony Stark of the company, not because of any fancy character worship, but for the enormous knowledge he's having.

What does he knows? The architect has a vast knowledge about coding, the domain, systems existing and being developed in the company, critical logics, knowledge on latest tech trends, updated on all the best standards and technologies, most importantly bright in-depth knowledge about all the roles with years of experience to back. Finally my favorite, good processor with super processing speed planted inside his brain ;)

So how inside his brain looks?

How he explains it?

That's a Software Architect for you.

Let's come to the topic....

why did I start this article in such a way? there is a reason. Some BA's when said that they need to know the architecture, they think about doing software architects work. It's a straight forward No. You do not need to go into the complex brain of an architect to know the architecture of the software. What BAs should do is to understand the explainable version which can be drawn on a canvas. The version that everyone can understand where you draw it with the help of architect and Tech leads prior to finalizing the design. In a descriptive but simple and understandable way as the below example.

Why you should know your software's architecture is because it gives you a good understanding about your product. Some BA's try to learn about coding to understand the details. One main reason to this is, when they are at a meeting with technical people they simply feels like an alien. So advice is not to think about learning in-depth coding (BTW it is handy if you can) but to learn the architecture.

By understanding the architecture you will understand where the APIs/ Services are, how components will talk with each other, what data goes through and to where, what are the security implemented. This is what you need to know and will learn by understanding the architecture. So you will be able to understand technical discussions with the team in the efforts to be a comb shape player in the Agile environment.

At the beginning of a project to understand the solution as a BA, you can create prototypes, the process diagrams and then the architecture diagrams. This will give you a good overall understanding about the software. To learn architecture of your product there are few diagrams you can draw,

1. Application architecture - Application and component wise diagram with the connectivity. You put the environment of the software and inside add the components as symbols (example - cogwheel for services, cylinder for DB). Arrows depicts the connectivity and arrow heads the direction of communication.
2. Data architecture - Here onwards it is an update to the Application architecture where you identify data stored and communicated.
3. Technology architecture - This diagram updates the application architecture with technology of each application including backend, front end, services and DB.
4. Security architecture - Diagram update with encryption and security implementations in the system architecture.

You can check out in Google for more information about Software Architecture diagrams to expand your knowledge. Above 4 are some we practice at my current workplace.

Coming to my career, there's also a story to tell behind my curiosity about Software Architecture. It happens when I started my first job, where I directly worked with a Software Architect. At the office it was sudden calls to a meeting, where me as the BA and the UX designer attends with our Architect. Intention is to design the project proposals. The Architect explains the solution to us, which is a well thought solution, without any gaps, and a solution which other teams will take weeks and many meetings to come up on their own. He explains this using the whiteboard from the architecture diagrams to wireframes well drawn and detailed. So after the meeting UX designer will give life to the diagrams drawn on the white board, where I include them in the proposal and articulate the story to a document.

It was so effective even at that stage, because when the project is accepted, then as the BA I had a good understanding about the architecture and about the solution. This is even at a stage where project is not yet started. So after my first job I continued my BA path in other work places. The next place I worked didn't had a Software Architect, but because I wanted to learn the system, I kept asking from Tech leads. What I learned from the industry is that most of the Tech leads are not able to draw and give you an architecture diagram. So your responsibility will be for the learning purposes try to understand by asking from them. Ask what are the components, environments and the communications between these components. Then check diagrams in google and draw using 'draw.io' or any other available tool. I had even heard from some TL's that it is not necessary for a BA to know the software architecture. That is completely wrong. Dear young ones in your future interviews you will be asked about the architecture of the software's you had worked in. I had experienced this personally. So you should be ready on this regard.

Anyway at my current work place we are having an Architecture document to create before finalizing the solution. So BA with the help of the Security Architect and Tech lead will create the document and pitch it to the regional bodies for approval. In between the process, learning the essentials and becoming an all round player.

Even if it's not in your company process, by doing so you can take a step to become an all-round comb shape BA to your scrum team. Which assist you to set your path of someday becoming the Superman BA we all aspire ;)

So try learning and keep expanding your product knowledge. I believe personally as a BA that it's this thirst to learn is the key factor that can companion you for a long journey and set you on a great career path. Saying that I will be putting a full stop to today's edition on the belief to companion you on another week with a similar edition of my news letter.