1. Any implicit/explicit assumptions you make while defining the architecture is a decision. Sun wants you to document such decisions under the 'assumptions' section and
explain the impact of such decisions(how did these decisions sway your architecture?).
2. A technical risk is a 'potential problem', What are the potential issues that can arise in such a problem statement. The part which sun is interested in is 'How valid are your problems - do they really have a impact and are you able to identify the major ones correctly?' . The next part which sun wants you to answer is 'How does your architecture mitigate these problems?'
Together, they help you defend your decisions and your architecture
OCMJEA/SCEA, SCDJWS, SCBCD 1.3, SCJP 1.4
My SCEA experience:http://javalogue.blogspot.com/
Let me disagree a bit with Rahul. Risk is something that may happen after the SuD is implemented according to your architecture. If the SuD mitigates the risks - they are not risks any more. They are your technical decisions.
SCEA, PMP, OCUP
Lead Architect of fazend.com - Free Hosted Continuous Integration Platform
Joined: Apr 06, 2001
Copying the text from Mark Cade and Humphrey Sheil's book Sun Certified Enterprise Architect for Java EE Study Guide - 2nd edition:
"A technical risk is something that is unknown, unproven, or untested. Risks are usually associated with the service-level requirements and can occasionally be associated with a business requirement. Regardless of the type of risk, it is easier to address the risks early in the project while creating architecture, than to wait until the construction phase of the project, when you have a large developer base that could potentially be waiting while you are solving risks."
So i can deduce that technical risk is like- let's say SuD has some interface with external system-what if that external system is down or responding slowly? - it might impact the NFR of the SuD. So for me this is a technical risk and the proactive solution to take care of that risk is a mitigation.