Posts

Showing posts from December, 2017

Why Decision Log is important for an Architect?

Image
As an Architect during the life cycle of Product Development, key decisions will be made for some valid reasons. Often if these reasons are not documented in a Decision Log then down the lane it will be hard for anyone to understand why certain decisions are made at that time. I personally get challenged asking these type of questions typically when people leave the project and new people take the role and they would like to understand why certain decisions have been made and rationale behind them.  Having a Decision Log and documenting the rationale will be really handy in these situations. As Simon Brown mentioned in his " Software Architecture for Developers " book keep them simple as it is mainly for technical audience.

The Death of the Architect

I just received an email with this subject line and got curious and started reading it immediately. ( https://dzone.com/articles/the-death-of-architecture?edition=347143 ) Though I agree with some of the points in the article but I don't agree the fact that Architect role is disappearing. With Cloud computing, I personally feel the responsibilities of an Architect has increased. There are far too many options and ways of addressing the problem using Cloud Solutions and that's when you need a Pragmatic Architect. I completely accept the fact that we don't need Ivory Tower Architects and we need Architects who definitely knows writing code and be part of the Development team ( https://www.infoq.com/articles/architects-should-code-bryson/ ). The Architect must know when to assist the Development Team with coding activities and when to focus on Architecture activities. Pragmatic Architect knows how to balance this quite well and they earn respect from the Development Teams.

What Pragmatic means in Software Architecture?

We are currently in the world of rapid software development using agile methodologies where fast and frequent delivery of software is paramount. This is done through 2 week sprints providing customers opportunity to view and provide feedback on the software as it gets developed. This definitely brings in the discussion around how much architecture work needs to be done before or whether it needs to be carried out during the Sprints? In my experience I would always recommend a Sprint 0 which provides ability to do enough Architecture to get the Development team understand on the technical aspects of the software to be developed and reviewing them as part of the Sprints so that what was proposed got delivered. Understanding what is really required for the Development team to get started is what I think being pragmatic. This will avoid doing too much upfront design or doing nothing. P : Promote collaborative work that involves all team members R : Reduce risks and uncertainties A

Why this (Software Architecture) blog?

Software Architect profession doesn't rely solely on technical skills. An architect must also possess soft skills (Leadership, Communication, Presentation, Negotiation, Delegation, Coaching, Mentoring, Political). I personally was a Software Developer and looked for my next career level 10 years ago. Initially I struggled to understand what it takes to move from a Software Developer to an Architect. There is no checklist as such to guide people to make the career move. The result of this is people becoming Architects without realising what's expected from the role. I started this blog to guide and share my knowledge for people aspiring to become Software Architect.