
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>What EAs need to know about Risk Management and Open FAIR – A Conversation with Jim Hietala</title>
<link>https://www.globalaea.org/members/blog_view.asp?id=1331934&amp;rss=47w1eFLz</link>
<description><![CDATA[
How would you define Risk Management in terms of how it affects Enterprise Architecture?
There are two notions of risk that play in when you’re talking about Enterprise Architecture. One is—and the way that it’s described currently in TOGAF® 9.1—is that there are sections on risk that are really related to project risk—projects that start and don’t finish, things like that. That’s a pretty narrow subset of Risk Management. The larger context has to do with things like security risk and other risks that broadly fall into Enterprise Risk as a discipline.


]]></description>
<lastBuildDate>Mon, 20 Jul 2026 13:47:28 GMT</lastBuildDate>
<pubDate>Mon, 18 Jan 2016 15:51:11 GMT</pubDate>
<copyright>Copyright &#xA9; 2016 Association of Enterprise Architects</copyright>
<atom:link href="https://www.globalaea.org/members/blog_rss.asp?id=1331934&amp;rss=47w1eFLz" rel="self" type="application/rss+xml"></atom:link>
<item>
<title>What EAs need to know about Risk Management and Open FAIR – A Conversation with Jim Hietala</title>
<link>https://www.globalaea.org/members/blog_view.asp?id=1331934&amp;post=236738</link>
<guid>https://www.globalaea.org/members/blog_view.asp?id=1331934&amp;post=236738</guid>
<description><![CDATA[




<!--[if gte mso 9]><xml>
 <o:DocumentProperties>
  <o:Template>Normal.dotm</o:Template>
  <o:Revision>0</o:Revision>
  <o:TotalTime>0</o:TotalTime>
  <o:Pages>1</o:Pages>
  <o:Words>1225</o:Words>
  <o:Characters>6988</o:Characters>
  <o:Company>The Open Group</o:Company>
  <o:Lines>58</o:Lines>
  <o:Paragraphs>13</o:Paragraphs>
  <o:CharactersWithSpaces>8581</o:CharactersWithSpaces>
  <o:Version>12.0</o:Version>
 </o:DocumentProperties>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:TrackMoves>false</w:TrackMoves>
  <w:TrackFormatting/>
  <w:PunctuationKerning/>
  <w:DrawingGridHorizontalSpacing>18 pt</w:DrawingGridHorizontalSpacing>
  <w:DrawingGridVerticalSpacing>18 pt</w:DrawingGridVerticalSpacing>
  <w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery>
  <w:DisplayVerticalDrawingGridEvery>0</w:DisplayVerticalDrawingGridEvery>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:DontGrowAutofit/>
   <w:DontAutofitConstrainedTables/>
   <w:DontVertAlignInTxbx/>
   <w:UseFELayout/>
  </w:Compatibility>
 </w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" LatentStyleCount="276">
 </w:LatentStyles>
</xml><![endif]-->

<!--[if gte mso 10]>
<style>
 /* Style Definitions */
table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-ascii-font-family:Cambria;
	mso-ascii-theme-font:minor-latin;
	mso-hansi-font-family:Cambria;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;}
</style>
<![endif]-->



<!--StartFragment-->

<p class="MsoNormal"><span style="font-weight: bold; text-decoration: underline;">What EAs need to
know about Risk Management and Open FAIR – A Conversation with Jim Hietala<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-weight: bold;">By AEA Staff</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">How would you define
Risk Management in terms of how it affects Enterprise Architecture?<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">There are two notions
of risk that play in when you’re talking about Enterprise Architecture. One
is—and the way that it’s described currently in TOGAF&reg; 9.1—is that there are
sections on risk that are really related to project risk—projects that start
and don’t finish, things like that. That’s a pretty narrow subset of Risk
Management. The larger context has to do with things like security risk and
other risks that broadly fall into Enterprise Risk as a discipline.</span></p>

<p class="MsoNormal"><span style="font-style: italic;">In the architecture
world, we’re working to make sure that future versions of TOGAF better
represent the bigger picture and not just project risk, which is important but
it’s just a small piece.</span><span style="font-style: italic;">&nbsp;</span></p>

<p class="MsoNormal"><span style="font-style: italic;">For me, the big thing
is that the tools that we use and things like TOGAF have to represent the idea
that there are risks that need to be considered with new IT developments and
the risks to IT infrastructures that are up and operating. We need to have the
right set of tools to be able to measure what those risks are, which is where
things like Open FAIR come in.</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">Why do Enterprise Architects
(EAs) need to be aware of risk and risk management issues?<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">In terms of the ‘why’
it’s because as they’re doing things to re-architect the business or re-architect
IT systems, bring new things to the business to improve operations, they don’t
want to bring things that have fundamental security issues or risks that will
maybe be taken advantage of by cyber attackers or whoever it is. Getting risk
and security wrong as you’re doing architecture can result in being in the
headlines for the wrong reasons. I think that’s the basic reason to do this is
that you’re trying to increase the business’s agility or cost or revenue
capture but at the same time you don’t want to introduce things that cause
financial harm to the company. That means really understanding what risks are
present in a new architecture that you’re building and then doing things to
mitigate those risks.</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">Lots of people tend
to think about risk in terms of security and cyber threats—are there other
aspects of risk that EAs also need to be aware of?<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">There are a number of
other risks to consider. These include financial, economic, geopolitical,
operational, supply chain, environmental, safety, regulatory compliance and
cyber security. EAs should consider these to the extent that they are involved
and affected by Enterprise Architecture within an organization.</span><span style="font-weight: bold;">&nbsp;</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">What can EAs do to
better inform themselves about risk and risk management in order to help their
organizations?<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">I think one place
where we see gaps sometimes is getting risk and security people involved in Enterprise
Architecture projects earlier rather than later so that they’re not blindsided
by someone from Information Security or a Risk Management group popping up and
saying ‘No, you can’t do that’ or ‘Have you thought about this risk or that
risk?’ So I think it’s mostly about making connections to the people who do
security architecture or risk management work and making sure that they’re
engaged in Enterprise Architecture development activities early on.</span></p>

<p class="MsoNormal"><span style="font-style: italic;">In TOGAF, it should be
in the preliminary phases when you’re considering things like that. Ideally,
security and risk should be considered as soon as possible in the system
engineering development lifecycle and at each phase of the development
lifecycle as appropriate. This can vary from high-level advice and guidance in
the early phase up to a detailed security check in the final phase. In the
operational phase, security aspects should be monitored, assessed and reported.
Although the operational phase does not begin until the first iteration of the
TOGAF ADM is complete, we are currently working on designing and incorporating
risk and security capabilities during other phases of TOGAF to provide greater
guidance for Enterprise Risk Management and Information Security Management
scenarios within TOGAF.</span></p>

<p class="MsoNormal"><span style="font-style: italic;">(Note that a whitepaper
from The Open Group on the topic of "Integrating Risk and Security within a
TOGAF&reg; Enterprise Architecture”<a name="_GoBack"></a> will be published and
available by February 1, 2016 here:
http://www.opengroup.org/open-group-publications.)</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">Last year, The Open
Group published a Risk Management Survey that showed a lot of Risk Management
work within organizations was not necessarily being done by Risk Analysts per
se. If there aren’t people in your organization doing risk analyses, as an EA
what else can you do to better inform yourself if there aren’t analysts that
you can bring into your projects?<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">In TOGAF, this should
be done in the preliminary phase during the Business Impact Analysis, which
looks at the parts of the business and the potential damages. The idea is that
if you do a Business Impact Analysis for a given architecture you can look at
what are the potential parts of the business that might be impacted. That’s a
good place to start in understanding where you’re going to have risks pop up in
a given project or architecture. &nbsp;</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">What is Open FAIR? <o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">Open FAIR is a
framework and methodology for allowing organizations to communicate about risk
and do a better job of measuring risk.</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">What can EAs get out
of Open FAIR and how will it benefit their organizations?<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">It can be useful in
evaluating how much risk is present in given risk scenarios. Let’s say you’re
an organization looking at implementing a new web ordering system for your
customers, where customers can order things through an e-commerce type website.
There are things that you can do to architect that, but you also want to
understand, depending on how you build it, how much risk will there be of
people compromising credit card details? Open FAIR gives you the methodology to
say ‘We’re concerned about attackers from Eastern Europe breaking in, capturing
credit card numbers and selling them on the black market.’ Open FAIR gives you
the tools to take a risk scenario like that and determine how much risk there
is and also to understand the relative value in terms of risk reduction of
various security controls you might plug into the architecture. You might say, ‘If
we put in a web application firewall to alert us to people trying to hack in,
that will cost this much and the risk reduction will be 20 percent on a $1 million
risk that we think might happen once every three years?’ Open FAIR gives you
the tools to quantify how much risk reduction you get out of alternative A or
alternative B in terms of the solution architecture that you plan to use to plug
those security holes.</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">Open FAIR also
contains a certification component – what does that entail and how can people
become certified if they are interested? <o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">It entails gaining an
understanding of the two standards that underpin Open FAIR. There’s O-RT, the
Risk Taxonomy Standard, and O-RA, the Risk Analysis Standard. People who want
to be certified have to understand those well enough to pass a multiple choice
exam. They can take the exams at testing centers throughout the world and get
the knowledge necessary to pass the exam either through self-study—there’s a
pocket guide and study guide that can be bought from The Open Group website—or
you can take a course from an accredited trainer.</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">In many
organizations, risk is left to risk analysts – do you see a growing need for
EAs to be better versed in risk management and risk issues moving forward? <o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">Yes, when I do
presentations on risk and security and Enterprise Architecture the point that I
like to make is that if you look at all the big breaches and big brands that
have had very public breaches, their failings tend to boil down three things.
Either they got their security architecture wrong or they didn’t really
understand the risks so they didn’t really understand what to go fix or they
just a lousy job operationally at security. In some of these cases, their
security systems were throwing off alerts left and right and they had so many
alerts that they just didn’t catch it. But it tends to be one of those three
things that they’re getting wrong. For the first two, security architecture and
understanding the risks, Enterprise Architects have a role to play. They need
to understand how you actually assess the risk in the architectures they’re
creating. The operational piece not as much, but for the first two, they need
to know. <o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-style: italic;">&nbsp;</span></p><h2 style="color: rgb(0, 0, 0); font-family: ArialMT;"><span style="font-size: 12pt;">Jim Hietala, Vice President, Business Development and Security,&nbsp;<br>The Open Group</span></h2><div class="field field-name-body field-type-text-with-summary field-label-hidden" style="font-family: ArialMT;"><div class="field-items"><div class="field-item even"><p class="p1">Jim Hietala, Open FAIR, CISSP, GSEC, is Vice President, Business Development and Security for The Open Group, where he manages the business team, as well as Security and Risk Management programs and standards activities,&nbsp; He has participated in the development of several industry standards including O-ISM3, O-ESA, O-RT (Risk Taxonomy Standard), O-RA (Risk Analysis Standard), and O-ACEML. He also led the development of compliance and audit guidance for the Cloud Security Alliance v2 publication.</p><p class="p2">Jim is a frequent speaker at industry conferences. He has participated in the SANS Analyst/Expert program, having written several research white papers and participated in several webcasts for SANS. He has also published numerous articles on information security, risk management, and compliance topics in publications including CSO, The ISSA Journal, Bank Accounting &amp; Finance, Risk Factor, SC Magazine, and others.</p><p class="p2">An IT security industry veteran, he has held leadership roles at several IT security vendors.</p><p class="p3">Jim holds a B.S. in Marketing from Southern Illinois University.</p><div><br></div><div><br></div></div></div></div>

<p class="MsoNormal"><span style="font-style: italic;">&nbsp;</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">&nbsp;</span></p>

<p class="MsoNormal"><span style="font-weight: bold;">&nbsp;</span></p>

<p class="MsoNormal"><o:p>&nbsp;</o:p></p>

<p class="MsoNormal"><o:p>&nbsp;</o:p></p>

<p class="MsoNormal"><o:p>&nbsp;</o:p></p>

<!--EndFragment-->  ]]></description>
<pubDate>Mon, 18 Jan 2016 16:51:11 GMT</pubDate>
</item>
</channel>
</rss>
