Software Architecture Review

Software Architecture Review  - in my opinion happens at two levels

1.  Macro Level 
2.  Micro Level 

To review an existing system for any recommendations or trouble shooting - is not a one man job especially for complex Enterprise systems. This is simply not feasible. This is a team effort -at least a team of 3 to 4 - you need strong developers, architects, designers, database architects, domain architects etc.
But for simple to medium complex applications - one person can do the review - provided he networks and seeks help in areas which he is not hands-on.

Coming to the review part, first and foremost - the reviewer (or the review team) should understand from the stakeholders: 
Why this review is being conducted? 
What are the existing concerns?
What measures have they taken already to address the issues? What have they learned till now?
Or is it a pro-active measure by the management?

These questions would set the right direction for the reviewer. He should exercise his personal judgment and be unbiased.

At Macro Level - the focus should be on the 

• Big picture
• What problem is being solved?
• Looking at Architectural layers, Domain objects, their dependencies
• Metrics (Size of the system, violations, outliers)
• How are the NFRs addressed?
• History, timeline of the project execution 
• Bug database - if one exists 
• What kind of tools the team uses?
• Continuous Integration (i.e. are nightly builds happening)
• Process, guidelines, standards followed
• Team Dynamics

At the Micro level - it gets interesting because at the Macro level things can be misleading - the code would give the true picture. The reviewer should start digging into the code. 

• Code review using many opensource or commercial tools i.e. static analysis of the code
• Class Design
• Build file - How is the build done?
• Does the team has Source Control? Look at the commit history? What is the trend?
• Are there unit testcases?
• Coding standards and guidelines
• Peer review process

At the end of this exercise the review team should produce a diagnostic report highlighting recommendations and best practices.

Bob Martin on Software Craftmanship

After listening to this marvelous session, if any body related to Software development, who writes production code, does not write a unit test (i.e. automated test) for that production code, then he is not a software "professional" --> period.

Everything falls in place, like good design, good architecture when we have a set of test suite. It adds immense confidence to keep improving the software without any "fear" of breaking it. Good test suite == good software.

Craftsmanship is nothing but professional commitment of an individual to deliver "best" software to their client or the employer.

No finger-pointing, no blame-game, no wasting time how this mess got created - just get your hands dirty and start fixing.

Thanks Bob for the lesson.