Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Part 2(assignment)-what goes into Technical Risks and what goes into Design decisions

 
Sharma Ashutosh
Bartender
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Assumptions are straight forward-one should put what all assumptions he/she has made to arrive at the solution and moreover what all deviations he/she has made from the original assignment.

But what should go into Technical Risks and what goes into Design decisions?
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34095
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Design is what were you thinking about when you created the architecture. Anything you want them to know.

Risks is what you can think of that could go wrong and cause a problem.
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To add to what Jeanne has said

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

HTH
 
Yegor Bugayenko
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Sharma Ashutosh
Bartender
Posts: 346
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic