What is the role of the Architect when it comes to handling unspecified scenarios?

[Darryl A. J. Staflund]

Hi there,
What stance should an Architect take when detailing unspecified alternative scenarios in their documentation? It's a question that has been on my mind for some time. I think the question stems from my uncertaintly of how to balance the needs of detailing customer requirements vs. the need of leaving to other what appear to be implementation and design details. I tend to view use cases as detailing the contractual behaviour of the system and as such I think many of the important alternative scenarios should be explicitly outlined in order to obtain customer buy-in, in order to create test scripts, etc. Yet on the other hand, I am not sure in my sequence diagrams whether to code these implement scenarios explicitly or simply make note of it and let the designers deal with it. For instance, if a customer has no credit cards on file, should I explicitly depict the steps that should be taken to handle this alternative scenario? Or if seats need to be held after being selected by a customer or before being paid for, do I need to deplict this scenario as well? I think the credit card scenario is obvious enough that it doesn't need to be depicted. Yet the seating scenario I think ought to be depicted because it's an important architectural consideration. And yet I can't decide either definitely because I am not sure what criteria to base my decision on.

[Al Newman]

 

For instance, if a customer has no credit cards on file, should I explicitly depict the steps that should be taken to handle this alternative scenario? Or if seats need to be held after being selected by a customer or before being paid for, do I need to deplict this scenario as well?

I think both scenarios ought to be sketched out at a high level. The specifics ought to be left to the designers.

[Bill Morrison]

Darryl,
I.M.H.O.!!
The architect should take the stance that would provide the deliverables that are required. Typically, architecture deliverables do not require detailed alternatives. Rather, the architect should propose a design that can be rationalized based on both an understanding and an evaluation of the issues that arise from possible scenarios.
The architect must recognize the risks and difficulties of building the system and then provide the developers an effective and efficient way to build the system and its subsystems. This can be tantamount to providing a rigorous system structure that incorporates one or more frameworks for subsystems. The framework might be incarnations of various design patterns that address the problem space of a particular subsystem. The developers chore is to adapt to the rigorous system structure and to design and build components that based on the framework patterns available within each subsystem.
Regards,
Bill