Aggregated enterprise architecture wisdom
When it comes to frameworks supporting business planning, software development, or other activities – I’m a fan. I like organization. I regularly use GTD with Omnifocus on three devices to keep my personal chaos in order. I’m a proponent of developing explicitly work breakdown structures (WBS) for any enterprise architecture (EA) work I’m about to […]
What naming do we need, when we’re doing architectures for every part of the enterprise? Yeah, I know this is another one that I go on and on about, but it’s just too bad: we need to resolve this one –…
Back in England after my ‘EA Masterclass’ series in Australia, seems it might be useful to reflect a bit on where this ‘whole-of-enterprise’ approach to enterprise-architecture is going. So let’s reiterate a bit, because yes, it’s different from what we might…
Until quite recently, IT security was the exclusive domain of security specialists. However, in the last couple of years, organizations have started to realize that IT-related risks cannot be seen in isolation, and should be considered as an integral part of Enterprise Risk and Security Management (ERSM). ERSM includes methods and techniques used by organizations to manage all types of risks related to the achievements of their objectives.
It is only natural to place ERSM in the context of Enterprise Architecture (EA), which provides a holistic view on the structure and design of the organization. Therefore, it is not surprising that EA methods such as TOGAF include chapters on risk and security (although the integration of these topics in the overall approach is still open for improvement), and a security framework such as SABSA shows a remarkable similarity to the Zachman framework for EA. And as a corollary, it also makes perfect sense to use the ArchiMate language to model risk and security aspects.
The previous blog post in this series outlined a method for EA-based ERSM with ArchiMate. This article proposes an initial mapping of risk and security concepts to ArchiMate concepts, and illustrates how these concepts can be used as a basis for performing an organization-wide risk assessment.
Most of the concepts used in ERSM standards and frameworks can easily be mapped to existing ArchiMate concepts. And since ERSM is concerned with risks related to the achievement of business objectives, these are primarily concepts from the motivation extension.
Any core element represented in the architecture can be an asset, i.e., something of value susceptible to loss that the organization wants to protect. These assets may have vulnerabilities, which may make them the target of attack or accidental loss.
A threat may result in threat events, targeting the vulnerabilities of assets, and may have an associated threat agent, i.e., an actor or component that (intentionally or unintentionally) causes the threat. Depending on the threat capability and vulnerability, the occurrence of a threat event may or may not lead to a loss event.
Risk is a (qualitative or quantitative) assessment of probable loss, in terms of the loss event frequency and the probable loss magnitude (informally, ‘likelihood times impact’).
Based on the outcome of a risk assessment, we may decide to either accept the risk, or set control objectives (i.e., high-level security requirements) to mitigate the risk, leading to requirements for control measures. The selection of control measures may be guided by predefined security principles. These control measures are realized by any set of core elements, such as business process (e.g., a risk management process), application services (e.g., an authentication service) or nodes (e.g., a firewall).
ArchiMate mapping of risk concepts
Using one of the extension mechanisms as described in the ArchiMate standard, risk-related attributes can be assigned to these concepts. The Factor Analysis of Information Risk (FAIR) taxonomy, adopted by The Open Group, provides a good starting point for this.
If sufficiently accurate estimates of the input values are available, quantitative risk analysis provides the most reliable basis for risk-based decision making. However, in practice, these estimates are often difficult to obtain. Therefore, FAIR proposes a risk assessment based on qualitative (ordinal) measures, e.g., threat capability ranging from ‘very low’ to ‘very high’, and risk ranging from ‘low’ to ‘critical’. The following picture shows how these values can be linked to elements in an ArchiMate model, and how they can be visualized in ‘heat maps’:
The level of vulnerability (Vuln) depends on the threat capability (TCap) and the control strength (CS). Applying control measures with a high control strength reduces the vulnerability level.
The loss event frequency (LEF) depends on both the threat event frequency (TEF) and the level of vulnerability. A higher vulnerability increases the probability that a threat event will trigger a loss event.
The level of risk is determined by the loss event frequency and the probable loss magnitude (PLM).
Qualitative risk assessment
The example below shows a simple application of such an assessment. A vulnerability scan of the payment system of an insurance company has shown that the encryption level of transmitted payment data is low (e.g., due to an outdated version of the used encryption protocol). This enables a man-in-the-middle attack, in which an attacker may modify the data to make unauthorized payments, e.g., by changing the receiving bank account. For a hacker with medium skills (medium threat capability) and no additional control measures, this leads to a very high vulnerability (according to the vulnerability matrix above). Assuming a low threat event frequency (e.g., on average one attempted attack per month), according to the loss event frequency matrix, the expected loss event frequency is also low. Finally, assuming a high probable loss magnitude, the resulting level of risk is high. As a preventive measure, a stronger encryption protocol may be applied. By modifying the parameters, it can be shown that increasing the control strength to ‘high’ or ‘very high’, the residual risk can be reduced to medium. Further reduction of this risk would require other measures, e.g., measures to limit the probable loss magnitude.
Risk analysis example
By linking risk-related properties to ArchiMate concepts, risk analysis can be automated with the help of a modeling tool. In this way, it becomes easy to analyze the impact of changes in these values throughout the organization, as well as the effect of potential control measures to mitigate the risks. For example, the business impact of risks caused by vulnerabilities in IT systems or infrastructure can be visualized in a way that optimally supports security decisions made by managers.
There are so many reference models and open-source material available for enterprise architects – so it isn’t surprising that some of this material is less well known. One useful specialized resource is free-use the open-source Security Architecture development and management method and framework – SABSA. SABSA stands for ‘Sherwood Applied Business Security Architecture’. This summary…
A few days ago I had posted some thoughts about relationship between an Architect role and an Engineer role. I had referred to the Zachman Framework to explain the trade-off and dependencies in these two important role profiles. The…
A few days ago I had posted some thoughts about relationship between an Architect role and an Engineer role. I had referred to the Zachman Framework to explain the trade-off and dependencies in these two important role profiles. The…
Enterprise Architecture (EA) has changed exponentially over the years with transforming from an IT-driven initiative to a business strategy necessity. EA as a field formally took shape in 1987 with the publication of John Zachman’s article “A Framework For Information Systems Architecture”. The paper described both the need for and the challenges of managing increasingly scattered systems:
“The cost involved and the success of the business depending increasingly on its information systems require a disciplined approach to the management of those systems.”
In today’s world we are seeing dramatic changes in how reaching this information system nirvana plays out. Why? Because we live in a world where digital access and apps are available for everything and anything. With digital and technological disruptors firmly rooted in our world there is a massive mind shift at play in how we interact with technology as well as how we expect to get things done.
Naturally, that has significant impact on EA, an IT-rooted discipline that both drives and manages change across the technology landscape.
Consumers are now accustomed to doing things themselves, and those expectations carry over into the business environment. Thanks to our “there’s-an-app-for-that” world, the IT department isn’t the only one who interacts with technology. We live in a world where everyone wants to be hands-on to leverage IT solutions and information.
What does this mean for EA?
These shifts open up a world of opportunity, or better yet a major necessity, for a function that can connect the enterprise dots to achieve a greater business outcome. EA is in the best position to step into that role. Critical business decisions require seeing the big picture in any situation. The big picture is gained through insights that answer the businesses most important questions. Successful EA should empower and inform stakeholders to answer these questions and make sound decisions using combined enterprise knowledge.
Today’s Version of EA: Beyond the IT Function
In December 2013 Gartner published Predicts 2014: Enterprise Architect Role Headed for Dramatic Change, highlighting the future version of EA which crosses business functions and often lives outside of IT altogether.
At Troux, we call this new era of EA enterprise intelligence. Enterprise intelligence gives the C-suite and their decision-making counterparts a heightened level of transparency by establishing a line-of-site that spans the enterprise as a whole without weighing down IT resources to make it happen.
The Way Forward
If you are reading this thinking, we are so behind the curve, go easy on yourself. The new era is in the early stages. Gartner estimates that market penetration of business architecture is at 20 percent. There is a lot of ground to be covered. Just be sure your business and IT worlds are interacting and integrating – that is what the people want, after all.
Make Strategic Business and IT Decisions: Download the Troux Answers Guide to gauge your ability to make strategic business and IT decisions. The guide takes you through questions like:
 |
|
Architect and Engineer Perspectives – in Zachman Framework All Copyrights with Zachman International |
TOGAF though defines Architect roles well; it probably does not clearly differentiate between an Architect and an Engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, Business Architecture View, Data Architecture View, Software Engineering View, System Engineering View and so on. In my opinion that works well too as with these views an organisation can then map roles, responsibilities of Architects and Engineers onto its operating model.
While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best do Architects work with Engineers? Or vice versa! In some organisation they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, Architect role may still be part of the retained IT staff and Engineers (or Engineering Services) may be procured from suppliers. I suppose, individual organisational operating model will dictate the specifics on these.
|
| Architect and Engineer Perspectives – in Zachman Framework All Copyrights with Zachman International |
TOGAF though defines Architect roles well; it probably does not clearly differentiate between an Architect and an Engineer at a role profile level. But it does offer a good methodical (as you can expect from TOGAF) and well defined classification of view; namely, Business Architecture View, Data Architecture View, Software Engineering View, System Engineering View and so on. In my opinion that works well too as with these views an organisation can then map roles, responsibilities of Architects and Engineers onto its operating model.
While many readers of this blog may or may not agree with precise definitions, I think this is still a good enough framework for us to start building operating model constructs around how best do Architects work with Engineers? Or vice versa! In some organisation they may be played by single role profile, in large environments it may be spread across say two or three role profiles. In an outsourced environment, Architect role may still be part of the retained IT staff and Engineers (or Engineering Services) may be procured from suppliers. I suppose, individual organisational operating model will dictate the specifics on these.
What’s the current state of mainstream enterprise-architecture? Where is it headed? I’ve just spent the past few days in and around the Open Group’s Amsterdam ‘summit’. (I say ‘in and around’ because I was there officially for just one of…
Often we, the Enterprise Architects make life difficult for ourselves (legacy of complex system thinking?) Example? We label one of the most beautiful constructs in Enterprise Architecture with a dry, “medical sounding” term Taxonomy. This is probably …