Leveraging Enterprise Architecture in Enterprise Risk Management

Print Friendly

Enterprise risk management (ERM) is one area that I believe EAs could positively contribute to. Several years back, a manager in charge of ERM approached me enquiring how EA could benefit his department. He knew what EA was and was keen to see if he could benefit from it. His primary challenge was assessing impact of risk across the enterprise; his team was handicapped, as they did not have traceability capability. In this article, I explain how EA helped him achieve his objectives.

Organizations deal with different types of risks that, if not attended to, could have adverse impact on organization performance and outcomes. Generally speaking, “risk” is the potential of undesirable outcome resulting from a given action or omission (foreseen or unforeseen). On a different note, “risk management” (RM) is the identification, assessment, and prioritization of risks followed by appropriate actions to minimize, monitor, and control the risk impact. The intention of this blog is not to explore risk management as such but rather explain how enterprise architecture (EA) could benefit risk management. Those of you seeking more details about risk management can explore other external sources.

While I do not dispute that RM is not unique to EA, it is important we appreciate that EA has great potential to contribute to GRC (governance, risk and compliance) by feeding into the enterprise risks management (ERM) process. The problem with traditional RM efforts like program and project (risk management) that are usually independent, narrowly focused and functionally driven is that they work in silo and fail to integrate at enterprise level leading to fragmented view of risks each with its own classification, criteria, and measure. Ultimately, most critical risks with major business impact never make it at the enterprise level though the resulting consequences do.

So what is the rationale behind leveraging EA in ERM? As we all know, EA involves blueprinting an enterprise by connecting the business, information, application, and technology layers. Usually, we achieve this iteratively through an architecture development method like TOGAF. Whenever we create (or update) and link each of these architectural layers, we get the opportunity to assess impact of change on subsequent layers. The presence of this unique traceability creates a window of opportunity for ERM. If we extend the concept further, it could help organizations identify and assess impact of risk on these architectural layers (I like to view this as enterprise assets).

Why do I say so? One of the toughest challenge in ERM is modeling risk and its impact on enterprise assets. Techniques like fault tree and event tree analysis have been used to model risks before but unfortunately, they are ineffective when dealing with ERM. Likewise, newly introduced ERM frameworks like COSO have a limitation too in that they too do not provide vertical traceability between the architectural layers (business, information, application and technology). Moreover, although newly introduced GRC tools establish horizontal integration between governance, risks and compliance, these too fail to provide vertical traceability between these architectural layers. Instead, such frameworks independently focus on financial, IT and legal risks and controls.

So how can we leverage EA in ERM space? EAs are aware that vertical integration between architectural layers helps to establish necessary traceability required for effective enterprise impact analysis. While considering both top-down and bottom-up traceability between architectural layers, whenever an organization identifies a risk that maps to any one of the architectural layers, it is possible to easily identify the resulting impact on other subsequent layers. This traceability helps to assess the impact of that risk at the enterprise level.

As an example, if an organization identifies revenue leakage to be a risk originating from a poorly designed financial business process (business layer), it could easily identify the subsequent impact in other layers (information, application and technology layers) that either enable or automate the process. In effect, when mitigating such a risk (say at the business layer level), the organization would also be in a position to assess the necessary effort required in other subsequent layers too. Traditionally, unless we know the traceability between the layers in advance, most often than not, such a risk is only mitigated in one layer leaving the residual impact intact in other layers. Obviously, this does not entirely rid the risk but instead realize its negative impact elsewhere.

Does your EA practice contribute to ERM? If so, how do you achieve this? Likewise, have you encountered obstacles or challenges in your efforts? It would be nice to hear your opinions. Until next time, I pen off here…

Author: Fahmy Al-Amoody

Share This Post On

Submit a Comment