I was thinking about the system architects problem and it seems that the main problem is that their work is directly passed to the implementation team. From point of view of static testing, their work has to be evaluated via review. At least as a walkthrough.
That way their poor work quality will be noticable earlier, than relying on the outcome analysis - dynamic testing.
At that level it becomes a collaborative effort. Usually you will have an architect, designer, product person and a senior dev or two doing the initial design. Product person defines requirements, architect defines the overarching system (backend, frontend, any middleware, etc), designers will work on the frontend design and those senior devs are working with the architect to make sure the architecture is feasable.
So when you're at that level, it's less about "I report to X", and more of "we need to build a consensus between X, Y and Z stakeholders"
I think it can help if the architect is part of the team developing the product and not part of a different entity that is responsible only for "architecting". If the architect is part-time developing then both the feedback loop is much shorter and he'll have to eat what he cooked, so he'll try to do his job as good as he can.
It would be the project owner's or coordinator's responsibility to organize a review for the architecture or specification. The process wouldn't differ much, whether an inhouse senior developer designed the architecture or a contracted one did it.
As for the process itself, it could either be a walkthrough or more formally a technical review. The organisator would call together a temporary team of reviewers (they could be anyone with a useful input - developers, software analysts, end user representative etc) and have the reviewers independently check the architecture design for comments or flaws. If any are found, the design is sent back to the author for improvements.
As a developer if you notice consistent poor design documents, best you could do is have a talk with higher ups about possibility of improving the process by intruducing a review phase for design documents.
Great read, thanks!
I was thinking about the system architects problem and it seems that the main problem is that their work is directly passed to the implementation team. From point of view of static testing, their work has to be evaluated via review. At least as a walkthrough.
That way their poor work quality will be noticable earlier, than relying on the outcome analysis - dynamic testing.
Just curious who is responsible for reviewing the architects work? Senior most devs in the company?
Say what if the Architect is on contract basis?
🤔
At that level it becomes a collaborative effort. Usually you will have an architect, designer, product person and a senior dev or two doing the initial design. Product person defines requirements, architect defines the overarching system (backend, frontend, any middleware, etc), designers will work on the frontend design and those senior devs are working with the architect to make sure the architecture is feasable.
So when you're at that level, it's less about "I report to X", and more of "we need to build a consensus between X, Y and Z stakeholders"
I think it can help if the architect is part of the team developing the product and not part of a different entity that is responsible only for "architecting". If the architect is part-time developing then both the feedback loop is much shorter and he'll have to eat what he cooked, so he'll try to do his job as good as he can.
It would be the project owner's or coordinator's responsibility to organize a review for the architecture or specification. The process wouldn't differ much, whether an inhouse senior developer designed the architecture or a contracted one did it.
As for the process itself, it could either be a walkthrough or more formally a technical review. The organisator would call together a temporary team of reviewers (they could be anyone with a useful input - developers, software analysts, end user representative etc) and have the reviewers independently check the architecture design for comments or flaws. If any are found, the design is sent back to the author for improvements.
As a developer if you notice consistent poor design documents, best you could do is have a talk with higher ups about possibility of improving the process by intruducing a review phase for design documents.
For more information and reference: astqb.org/resources/