If Architecture Review matters

Hey, how often are your Architecture Review sessions setup?

If teams are senior, there is a lure to run those review sessions not so often. And things are going well, since  senior developers are using proper patterns and communicate together nicely.

The risk triggers when new teams appear and level of seniority is not proven yet. If system design reviews sessions are conducted once or couple of times only, there unpleasant surprises might pop up. Usually issues are experienced once components of those poorly designed systems are integrated. Velocity of new features development is struggling also.

 Leverage the power of conversation, let people discuss the common approach in a structured manner. Do not let it go in uncontrolled manner.

Are Requirements Required

It's difficult to agree with one argument I hear quite often from peers. The wording usually varies like

- What are the requirements?

- We did not receive requirements of proper details.

- Cannot proceed further without requirements.

As per experience, such questions are signals of low team engagement into the product or process. In real life, definitions in Project Charter are quite good baseline to go ahead with development without dependency on additional requirements. 

Statements in Project Charter is enough to get vision on product features of greater impact

- Infrastructure (either terminals, or server side)

- Industry (automotive, financial, publishing, insurance, medical, ...)

- Functionality (either reporting, or data input, or extract and its modifications, ...)

System properly designed should easily accommodate usual request of changing screen flow, adding attributes and modifying entity relationships. This is the only real requirement.