Software Architect & Big Picture

In this post I am going to cover an important responsibility of a software architect. A software architect should know and own the big picture. The big picture is a collection of important decisions, if broken has a system wide impact. Often software teams come up with the following arguments for not having an architect

  • Architects don’t code. They are costly resource.
  • We need the architects at the start of the project then we don’t need them.
  • Architect just write power points and don’t understand the details.

But in reality a software architect is not a role with all the details. This role works with all the abstraction of abstractions. A software architect is responsible for ensuring that all the quality attributes are achieved. For a simple small project a software architect may not be needed. But the moment project becomes huge and complex the team needs someone to take up the role of software architect. To do this a software architect needs to know and own the big picture. The component teams often make lot of local design decisions. A software architect should be able to identify decisions that might have an impact on the big picture. And if a local decision will break this big picture then it’s the architect’s job to communicate and do a course correction. Ok enough of abstract talk. Let me give a real world example.

I used to visit one of my friends who run a cell phone repair shop. One day a customer came to the shop with lot of anger. He mentioned that the helper broke his mobile and the camera is not working any more. My friend inspected the phone and found the memory card was filled up. There is no space left for storing a new picture. He explained this to the customer. But the customer mentioned that the camera was working until he gave the phone for servicing. Now my friend enquired the helper regarding the service he performed. The helper mentioned that as a part of service the customer asked for some songs to be loaded to the phone. The helper filled up the memory card with songs. Now my friend said to the helper that the memory card is a shared resource. At least 30% of it should be left empty. This is a basic rule of servicing. The helper freed up this space, learned the lesson and gave the mobile back to the customer. Customer mentioned “I normally don’t give my phone to your helpers directly. Next time I will give my phone for servicing only during your presence”.

In this story the helper was focusing on one aspect “Loading the music to the phone”. He decided to fill the entire memory card with music to delight the customer. But he was not aware of the implication it might have on the other subsystem (camera operations). And he broke the rule of leaving 30% space free. In real life software projects each of the component team is thinking about its component and makes such local design decisions without knowing its implications on the other subsystems. And they may break an architectural decision. Here my friend is like the software architect and the helper is like the component designer. A software architect needs to communicate with his fellow designers on a regular basis and ensure that the architectural decisions are not broken. But during the course of software architecture and design lot of such mistakes are bound to happen. During all these times a software architect should patiently course correct his fellow designers and ensure that his big picture remains valid.

The customer in the end mentioned that he wants someone to own the big picture in a subtle way. In real life software projects too we need someone to know and own the big picture throughout the project.