Think about the arrows

When doing architecture reviews. I'll often point at one of the arrows on the architecture diagram and ask "what is this?". Depressingly I often get an answer similar to " Well, component A talks to component B". Rarely do I get an answer will actually explains:

• Why the components need to communicate
  
• What information is communicated
  
• What the arrow indicates (e.g. flow of information)
  
• What component initiates the communication
  
• How the information is represented
  
• What protocols are used
  
• What is physically used to transmit the information

In designing an software architecture I've always found it useful to think about what the arrowed lines actually mean as this often provides insights into how the design will actually behave. I was therefore happy to see that at least somebody else also thinks the same way and have submitted a software axiom ("Architects focus is on the boundaries and interfaces" by Einar Landre) to Richard Monson-Haefel's 97 Things. If you haven't come across this before, 97 Things is a set of "axioms for software architects by software architects" and should be published by O'Reilly next year.