Search Results for: archimate

In this blog post, Marc Lankhorst discussed  the value of EA in managing risk, compliance and security in the enterprise. He suggested a number of next steps. Two next steps are discussed in more detail in this blog:

• Capture and visualize risk and security aspects of your organization. Visualize hazards, risks and mitigation measures in relation to the overall architecture and business strategy.
• Measure and visualize the impact of risks and use these insights for decision making. Visualize data from e.g. penetration tests and use this to decide at the business level about necessary IT measures.

 

Enterprise Risk Management approach overview

The two steps from above are incorporated in an Enterprise Risk Management approach, visualized in Figure 1. This approach helps in understanding the consequences of risk & security policies, because the definition of risks and control measures on strategic level are step by step detailed into operational control measures.

 

Figure 1: Enterprise Risk Management approach

 

This is a model driven and cyclic approach which can be started on multiple points in the cycle, depending whether you are using a more top-down approach or a more bottom-up approach. Each phase will be explained briefly below:

1. Assess risks. In this step, the risks that the enterprise has to cope with are identified and documented. This covers multiple risk types: these can be IT related (like cyber-attacks) risks, but also business related risks. Furthermore, risks can be based on identified threats (see step 6).
2. Specify required control measures. For each risk is identified which control measures are required. Some risks may require extensive control measures (because of the high impact of the risk), as others may require less control measures. The combination of risks and control measures can be modelled with elements of the ArchiMate motivation extension (Assessment, Goal and Requirement) which makes the relation between these aspects clear. Furthermore, it can be incorporated in your existing EA models by linking risks and control measures to ArchiMate core elements. More details on this approach will be presented in a follow up blog.
3. Implement control measures. The required control measures needs to be implemented. This is the step where the shift from design to implementation is made. Control measures can be implemented in several ways: some may be IT control measures like firewalls or authentication mechanisms. Others can be business focused control measures like the four-eyes principle.
4. Execute & monitor. The implemented control measures needs to be executed. Furthermore, monitoring on operational level is necessary to get statistics of the performance and effectiveness of implemented controls. An example is to use pentesting on the technical infrastructure. With pentesting you look with a systematic and automated approach for weak spots in the infrastructure. Results of pentests are used to analyze vulnerabilities in the infrastructure and define new control measures.
5. Analyze vulnerabilities. From executing & monitoring you obtained the necessary insights about performance and effectiveness of implemented controls for example via pentesting). In this step this data is analyzed to determine which vulnerabilities there are and how dangerous these are. The link is made between vulnerabilities and identified risks from step 2, by using the existing EA models. This gives insights in how well the risks are managed or that new or improved control measures are needed.
6. Identify threats. In this step threats from the external or internal environment are identified. Threats from the internal environment can be based on the results of the previous step (analyze vulnerabilities). The identification of new threats can lead to new or changed risk assessments in step 1.

 

Top down vs bottom up

The approach described above can be applied top down or bottom up. In a top down approach will be started with the identification of threats and assessment of risks, which serve as a basis for design and implementation of control measures. A bottom up approach would typically start at the monitor & execute step: investigating the current implementation with pentests or other mechanisms and use this information to determine vulnerabilities in the current landscape.
Which approach fits best in your organization, depends on a number of aspects. In general, organizations with a more mature EA approach can follow more easily a top down approach.

Benefits of this approach

This approach includes the following benefits:

• Systematic analysis of threats and vulnerabilities
• Integrated design of control measures
• EA models support business impact analysis of technical risks / vulnerabilities
• Translate business risk & security decisions into effective enterprise changes. This requires a strong cooperation between business and IT.

These benefits help to embed security more in the business layer of your organization and will help to make well informed decisions based on operational risk impact and costs. 

Learn more about Security Architecture in our webinar, September 18th. Or Join our Security Architecture training course in the Netherlands, October 2nd. 

In my previous blog post I wrote about value-driven enterprise architecture and its relations to different disciplines within the enterprise. In this blog, I want to focus on the added value of using reference architectures.

What are reference architectures?

Reference architectures are standardized architectures that provide a frame of reference for a particular domain, sector or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution architectures, i.e., they are not implemented directly. Rather, they are used as a constraint for more concrete architectures. Typically, a reference architecture includes common architecture principles, patterns, building blocks and standards.

Many domains have defined their own reference architectures. Well-known examples include:

• the BIAN service landscape for the banking industry;

• the ACORD Framework for the insurance industry;

• the eTOM business process framework for the telecommunications industry from the TMforum;

• various government reference architectures, for example the Dutch NORA and her ‘daughters’, the US FEAF or the Australian AGA;

• the defense architecture frameworks such as NAF, DODAF and MoDAF;

• reference architectures for manufacturing and supply chains such as ISA-95 and SCOR.

Most of these architectures include the common business functions/capabilities and business processes in a domain. Next to that, they may include for example common data models, communication standards and exchange formats, and sometimes even common software building blocks and other reusable assets.

eTOM framework in ArchiMate

Why use reference architectures?

So what is the value of using such reference architectures, and why and when should you employ them?

First of all, reference architectures provide a frame of reference that helps you to get an overview of a particular domain and they provide a starting point for your own enterprise architecture effort. They provide you with basic structures so you do not have to reinvent the wheel (which often turns out to be square anyway). Reference architectures are most valuable for those aspects and elements of your organization on which you do not compete with others.

For example, the business functions of a typical insurance company are largely similar to those of its competitors, as are many of its business processes. Competitive differences will most likely be in its products, pricing, customer segments, and customer relationships. Reusing industry best practices provided by reference architectures ensures that you are not behind the curve on these non-competitive aspects. We also see this in the implementation of many IT systems, where vendors such as SAP provide reference processes for large parts of an organization. Your accounting process, for example, is seldom a competitive advantage.

A second reason for using reference architectures is interoperability. In our increasingly networked world, organizations need to connect and cooperate with all manner of other parties. The standards and building blocks provided by reference architectures facilitate these connections. A related benefit is that using standards improves flexibility, because it is easier to exchange building blocks that connect via standardized interfaces; vice versa, it is much easier to develop standards if the building blocks themselves are standardized. LEGO is a perfect example, as my colleague Bas van Gils described in his blog recently.

This then brings us to a third reason for using reference architectures: mergers & acquisitions and outsourcing. If two parties speak the same language, use the same standards, and recognize the same boundaries between functions, processes and/or systems, it will be much easier to recombine their elements in new ways.

A fourth reason for using reference architectures is to facilitate benchmarking within your industry. Often, the differences between companies are not in the design of e.g. their business processes, but in their execution. Using reference designs makes it much easier to compare those execution results.

Benchmarking leads us to a fifth reason why reference architectures are important: regulatory compliance. Often, reference architectures are prescribed (or at least strongly recommended) by regulators. Accounting principles, practices and processes, for example, are evermore standardized and mandated. This leads to business reporting standards, even down to the level of exchange standards such as XBRL.

Another example is given by the Wijffels committee on the structure of Dutch banks, installed by the Ministry of Finance and the Dutch National Bank at the request of the Dutch Parliament. They have published a report which explicitly recommends banks to use industry standards such as BIAN. The context of this report is the need for decommissioning and breaking up banks in case of financial disaster (the so-called ‘living wills’). Structuring a bank along the lines of a reference architecture such as BIAN’s may certainly help in such a case. These issues are also addressed by the Dodd-Frank Act in the US and the new ECB Resolution Mechanism in the EU, so we may expect similar guidance from those sources.

How to use reference architectures?

Before you decide to use a reference architecture, some conditions should be fulfilled. First of all, a reference architecture should be community-based. Users, not vendors, should decide on best practices, and the architecture should be actively maintained by the user community. The world changes, and so should your reference architectures.

Such an active and open community process is ideally complemented by the use of open standards in describing the architectures. For example, the descriptions of the Dutch government reference architectures are largely based on the ArchiMate standard. BiZZdesign can provide many such reference architecture models out-of-the box.

The use of a reference architecture in an organization also requires governance: the organization should really commit to its use and this should be ‘enforced’ in some way. Reference architectures are only of value if people are really using them as intended and actually follow their guidance, otherwise the whole idea of reusing industry best practices breaks down.

Finally, your reference architecture of choice should provide true, actionable guidance. General architecture principles are not enough. Actual structure, for example in terms of business functions or processes, building blocks and standards, is needed to provide you with a useful backbone for your own architecture efforts.

Using reference architectures does not imply that you lose all your design freedom. Rather, you focus that freedom on those aspects of your enterprise where you make a real difference. That is where you as an architect can add the most value!