Top 3 technical risk and mitigation - Meaning?

[Arpit Kumar Jain]

Hi,
I have a question on SCEA Part II assignment. Assignment states -
"List the top three technical risks you have identified in the project and identify
a mitigation strategy for each risk.".

My question is - what is the meaning of risk?
Are these the risks already addressed in our architecture or the ones which are limitations of our architecture and need attention in the future, which may require to be addressed by making changes into the architecture/implementation.

Thanks

[Teja Saab]

My question is - what is the meaning of risk?

I think the intent here is to ascertain if the SCEA candidate has an appreciation for the high level picture of the system. The ability to have an appreciation for the high level picture of the System under Development (SuD) is one of the key skills that separates a senior developer from an architect. Part of having this architecture vision entails the identification of risks that might manifest themselves either now or in the future. The architect is expected to have the ability to identify risks and create mitigation strategies for those.

In the context of any SuD, risks can be of two major types.

Risks that can be addressed and mitigated through your architecture (for eg. data validation to prevent data poisoning)

Risks that cannot be addressed completely but can be handled to some extent through a mitigation plan (for eg. an outage experienced by your ISP (Internet Service Provider) that results in lost network connectivity with a business partner

Are these the risks already addressed in our architecture or the ones which are limitations of our architecture and need attention in the future, which may require to be addressed by making changes into the architecture/implementation.

Not all of the risks can be addressed by making changes to your architecture. To quote the example mentioned earlier, an outage experienced by your ISP resulting in lost network connectivity with your business partner's IT systems cannot be addressed by making changes to your architecture. In such a situation, you will have to have a mitigation plan (for eg. a backup ISP to be used in case of an outage experienced by the primary ISP).

Just my thoughts though...

[Arpit Kumar Jain]

Thank You, Teja for your detailed reply.

I have one more question -
If any risk is already mitigated, then do those risks need to be part of risk mitigation plan and if "yes" then why?

Thanks Once again.

Regards
Arpit

[Teja Saab]

Arpit Kumar Jain wrote:If any risk is already mitigated, then do those risks need to be part of risk mitigation plan and if "yes" then why?

If the mitigated risk is significant, then it certainly can be mentioned in the risks and mitigations section of your part 2 deliverable. The key here is to convince the part 2 evaluator that you have thought through the risks and have addressed them appropriately by making changes to your architecture and/or by having a mitigation plan in place. So even if a risk is already mitigated and it happens to be a significant risk, you can mention it in the deliverable.

In most situations, the mitigation plan will involve two aspects. One aspect that is within your control and another one that isn't. For example, in order to cope up with an unexpected surge in web traffic, you might have to make certain changes to your architecture to handle the increased load. However, your transaction might involve interaction with a business partner's IT systems. You cannot control the business partner's IT systems. In this case, you might want to enter into appropriate SLAs (Service Level Agreements) with the partner to ensure the desired level of performance during the time of increased work load. So your mitigation plan involves two aspects making change to your own architecture (in your control) and entering into appropriate SLAs to ensure proper working of a partner's systems (not in your control directly).

Just my opinion...

[Jim Hoglund]

If by mitigated you mean eliminated, then it is no longer a risk but simply
an accomplished task. Management is all about identifying and assessing
ongoing risks and actions that limit negative impact, or enhance positive
impact. (Though focus is usually on the bad stuff.) Try to plan for them
all, ranked by probability of occurrence and impact severity. Good luck.

Jim ... ...

[Arpit Kumar Jain]

Thank you, Jim and Teja for detailed clarification.

Regards
Arpit Jain