System Architecture Role

 Having been a systems architect for last four years, I feel I can talk about being an architects better now, than I could 4 years back. Before being an architect, I admired the documents, the artifacts and  the diagrams they created, honestly I was intimidated by it. Now after 4+ years, I feel that is the easiest thing to do as an architect. I have put some of my thought together, and these are somethings that have worked for me.

Architect I feel is just a liaison between the business team and the technology team, well, the statement seems too simple, it does get complicated as you dive deeper. For someone to be a good architect, most important thing is to understand the business requirement and also be technically competent.  If you are in sync with the product owner or the analyst, 90% of the battle is won. The product owner wants to build an application, they have a release date, the product goal, and the budget. Now the architect has to make it happen based on it.  Architect needs to know the technical solution or hunt down someone who can help on technical solution.

Architect are also selfish folks, they always wants to use the newest technology and make it sound cool, that is where the architects understanding of the business goal comes into play, the design has to be based on it and the design also has to be in agreement with where your organization is, where it is heading towards and its appetite for risk tolerance. 

Once the architect is in sync with the product owner, then you next thing to do form you alliance with the technology team, these might take months to accomplish, that should be the goal. Nothing goes ever smoothly, I haven't seen it yet. There is always Forming, Storming, Norming, and Preforming. That never goes away. I have been part of a major scrum for last 2 years plus and every few months we have a new big feature that needs to be implemented. I have to go thru same thing again, there is no escape, it is back into the hole again, some times deeper, some time not so much. You got to work your way up every time.

Architect are expected to know the product well, are pulled in more regularly then the business analyst. BA's keep moving from one project to another and I don't know how that happens, but architect are the first go to person, where there are question on why the system behaves in certain way or why certain decision was taken. If the original architect was not done by me, I might have to dig in to find the answer, but even if I have done it, there are so many things the architect work on, it is easy to forget and that's where the documentation comes into help.

Architect don't needs to have answer for every question all the time and I think that works into our favor too, it makes the product owner or the client feel good as they feel, there question or the need was really complex and architect themselves need time. I have realized my creditability has never gone down, because I didn't provide the answer immediately. It is always best to brain storm with someone if the situation demands it, there is always another perspective. I have gone to another architect, another developer, or the tech manager to ask for help or I do a brain storming session with the team.

I should do another blog sometime about teamwork, and why is it so crucial to architecture.