Architecture evaluation attititude

When faced with a task of architectural evaluation of an existing system a software architect may make an assumption that something must be wrong with the architecture. Of course if someone asks you to perform such task your first question is to understand what is implied by “evaluating the software architecture of an existing system.” Before any work of technical nature commences the business purpose of the evaluation task needs to be established.

The goal of an evaluation is not to determine what is right or what is wrong. The goal of an evaluation is to gain an understanding of how a system is constructed. It’s always healthy to be skeptical – we advocate this strongly as it’s the mantra of the Firebrand Architect® blog – but also give a “benefit of the doubt” and try to understand why a solution was architected one way or another. Remember that the system was designed and implemented under constraints that may no longer be true today.

As a public service announcement, please do your colleagues a favor and methodically document your solutions, and most importantly the thinking process behind your decisions. If someone has to conduct architectural reconstruction on a system you've architected (instead of architectural evaluation based on existing documentation), then you've done this discipline a disfavor. Thank you in advance for being considerate.

Constantin K.
Firebrand Architect®
SoftwareArchitectures.com

Comments

Popular posts from this blog

Why we do agile

Quality Attribute Refinement