aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Top 3 technical risk and mitigation - Meaning? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Top 3 technical risk and mitigation - Meaning?" Watch "Top 3 technical risk and mitigation - Meaning?" New topic
Author

Top 3 technical risk and mitigation - Meaning?

Arpit Kumar Jain
Ranch Hand

Joined: Jun 05, 2010
Posts: 41
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


SCJP, SCWCD, SCEA
Teja Saab
Rancher

Joined: Mar 08, 2010
Posts: 152

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...


    SCEA 5, SCJD,SCWCD,SCJP,PMP,IBM-SOA Solution designer,IBM-XML
    Arpit Kumar Jain
    Ranch Hand

    Joined: Jun 05, 2010
    Posts: 41
    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
    Rancher

    Joined: Mar 08, 2010
    Posts: 152
    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
    Ranch Hand

    Joined: Jan 09, 2008
    Posts: 525
    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 ... ...


    BEE MBA PMP SCJP-6
    Arpit Kumar Jain
    Ranch Hand

    Joined: Jun 05, 2010
    Posts: 41
    Thank you, Jim and Teja for detailed clarification.

    Regards
    Arpit Jain
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
     
    subject: Top 3 technical risk and mitigation - Meaning?