Now that ArchiMate 2.0 has been published it’s time to deliver on a promise I made a while back. I have been pretty silent on this blog. I have lots of material but I have been working on an iBook instead. That goes slowly (as I have real work to do as an architect…), so if I don’t publish this on the blog, it will be take too long before I can deliver on my promise.
Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF) for more information.
The promise was to mention in this post two colleagues who have contributed to the result I am going to show you below: Jos Knoops and Roy Krout. Roy is a colleague who has collaborated with Jos to create the initial solution for the way we model risk in ArchiMate, a solution which then morphed with some changes into the solution I am presenting here. Jos, incidentally, has been an important sparring partner for me over the last year or two when we were creating these ‘ArchiMate patterns’ we now use. Jos also is the manager of our company’s Current-State model, almost 8000 objects and over 17000 relations as I am writing this.
The reason I mentioned ArchiMate 2.0 at the start is that we use ArchiMate 2.0’s Motivation Extension to model risk in our Enterprise Architecture. Which in a way is kind of funny, because personally I am pretty skeptical about hidden assumptions under much of such modeling in the real world. For instance, Architecture for me has not much to do with Principles (available as an ArchiMate 2.0 concept), Policies and Guidelines. Those, for me, are emerging patterns more than anything else. They are not prescriptive but descriptive rules, and therefore won’t help you much, looking forward. I am also deeply skeptical about how useful ‘digitizing’ the world of complex and non-discrete human motivations is. If anything, research shows we — and thus our enterprises — are highly non-discrete and there is pretty little we can do with discrete-rule-like approaches — like symbolic modeling — in our human world. Uncle Ludwig explained that pretty thoroughly, long before there were computers.
Luckily, Uncle Ludwig also taught us that the meaning of something lies hidden in its use. So, if we have a proper use for things (be it concepts, words or anything else) we give them meaning. In ArchiMate 2.0’s Motivation Extension, we have found a nice way to use concepts to model risk.
Thinking about risks, a way to look at them is in a three-way division (I am simplifying):
- The risk itself. This is about the situation you do not want. We use ArchiMate 2.0’s Concern for that;
- The control objective. This is about the situation you want instead. We use ArchiMate 2.0’s Goal for that;
- The countermeasure. This is what you need to do to get closer to 2 from 1. We use ArchiMate 2.0’s Requirement for that.
We associate Risks with Control Objectives and we let Control Measures contribute to Control Objectives. Control Measures are realized by behavioral objects in our landscape (Business Process/Function, Application Function or Infrastructure Function). Furthermore, we associate the Control Objectives with the Processes/Functions they apply to. Strictly spoken, this association is redundant (as all the countermeasures are a way to get to the processes/functions involved), but it does much to simplify reporting and analysis on our model.
Now, setting up and maintaining Risk Management itself is more than these dependencies. I’ll return to that question below.
So, here is a large view that displays 5 patterns we use when we talk about risks:
The green grouping contains the heart of the matter: a primary Business Process (one that belongs to the core of your business, that produces business services that are part of the raison d’être of your organization) that is a composite of several sub-processes. The grey groupings show 5 ways a risk can be mitigated. The 5 patterns are:
- There is a separate business process addressing the risk. An example would be a process that inspects another process, e.g. auditing.
- The process itself is changed to address the risk. For instance, we could have an additional step in our process to do some checking. In the view, this is Sub 1.b. This subprocess is an essential part of the main process, e.g. if you do not do it, there will be no flow from Sub 1.a to Sub 1.c. However, we also made it part of an Aggregation: the processes that are needed to realize the “Counter Measure 2” that contributes to “Control Objective 2”. Note that this view does not show the roles executing the subprocesses. It might of course be that Sub 1.b (the countermeasure-related subprocess) is also executed by a separate ‘control’ role, e.g. a role that is assigned to “Execute Countermeasure 2”. But that is not required in this pattern.
- The process uses control information that is produced by another process to address the risk. This is slightly different from the first option in that while our main process can happily go ahead when “Execute Control Measure 1” is not available (there is no real dependency on the auditor’s availablity), in this case there is a real dependency. There are two subtypes here, depending on the role the control data is used:
- From the world of Asset Management, a typical example would be that the Investment Control function produces a list with allowed counter parties, countries, currencies to trade with/in. This list needs to be used in the trading processes.
- Another example would be that the Business Control function sets rules for the way processes are executed. For instance, certain transactions are required to follow a “4-eye” principle. Or some parts of a process require a separation of duties: certain roles may not be executed by the same actor. Such a description is not directly used in the main process, it is used to design the process. As such, the rules are part of (here: an Aggregation) the process description.
- The control measures are realized by the application or infrastructure layer instead of the business layer. I have modeled these here to be realized by the Application Function or the Infrastructure Function (new in ArchiMate 2.0).
The processes (or functions) at the business level and the functions at the application and infrastructure levels possibly realize two different (concurrently) things in this pattern: a service or a countermeasure.
Now, as I mentioned before, there is more to Risk Management than these dependencies, however useful they already are (imagine what we can do in reporting to our overseers if we can show them the ultimate relations between risks and our EA landscape). Because, what the view above does not show is a lot of other stuff that goes into Risk Management. Think about the officers setting up control frameworks, distributing them, checking them, etc.
I am tempted to point you to my first post on this blog and then write (as I used to read a long time ago in my university text books): “the rest is left as an exercise for the reader”. In those days and with certain text books (Quantum Mechanics by Gasiorowicz springs to mind), statements as “a little algebra shows” or “slightly more complex algebra shows” led to some brave and brilliant students (not me) working for up to three days straight to get the derivation from one formula to the next.
Anyway, this is not as difficult as that was, but it is still friendly to do a bit more than leave it to you. Recall from that previous post that if someone mentions an actor, or better, a role like ‘owner’ and wants to relate ‘owner’ to the application, the proper ArchiMate question to ask is: “if you are talking about a role, like owner, what process is he or she assigned to?”. In other words: What does the ‘owner’ do? So, we have a Risk Management function, a department that is assigned to the Risk Manager role and that role is assigned to the (internal) processes of that function. In other words: everything that surrounds the Risk assessments and what you do about them is a Business Process like everything else in your company. That they effect other processes does not change that. ArchiMate is powerful enough to model these relations, without you having to fall back to Association to link anything to anything. Just like in the other post, where we were talking about primary, secondary and tertiary architecture (all of which can be modeled with ArchiMate), you might talk about primary and secondary business activities. Modeling clearly what Goals (e.g. Control Objectives) they contribute to might even make them more accepted in the business at large.
Finally, what about ‘Security Architecture’? Some EA frameworks talk about it as something that almost has an independent existence. I disagree with that approach, in part because it promotes the (in my view mistaken) idea that architecture is not design, but more ‘design guidance’ (in the form of principles and guidelines and such). As the meaning of a book generally does not follow much from rules of grammar or rules of logic, nor does the meaning of enterprise architecture follow much from principles and guidelines. I’m aware that in Enterprise Architecture land mine is a minority view, but I am quite satisfied with the way it keeps our Enterprise Architecture ‘grounded’ and meaningful.
(As an aside: in a recent discussion one of the architects in my environment strongly advocated the use of principles, policies, guidelines, etc.. He added to that that it was very difficult to do that right, but that only meant one had to do ones’ best even more to get it right. My personal take on that is that it is reminiscent of the arguments for AI in the 1970’s, which assumed that there was nothing wrong with the AI ideas in principle, only in practice. It was Hubert Dreyfus who, I think, very convincingly showed (the Wikipedia page linked to here still does not give him enough credit) how mistaken they were and how their assumptions were deeply rooted in our culture. I think these EA ideas based on principles and such are not just difficult, they are fundamentally mistaken and they can be blamed for how ineffective EA often turns out to be.)
For me, therefore, a separate ‘Security Architecture’ makes little sense. It is in my view more productive to look at security as a special case of risk. There are risks that we can collect under the name ‘security’ (like ‘threats’ and what they can do to us) and we can take countermeasures to counter the threats. The countermeasures you take in security are just requirements to your enterprise architecture from a security (risk) perspective and the things you do (processes and functions) are the way you meet those requirements. The result is part of your integrated EA landscape. There is no ‘security architecture’, there is only one integrated enterprise architecture (maybe categorized in primary, secondary, etc.) with many, many requirements of which countermeasures for risk are only one.
We’re not also creating an HR-architecture that applies to how departments have to handle their people, are we? Or an energy efficiency architecture? Or a legal architecture? That way, we’ll end up with a chaotic aggregation of difficult to relate architectures instead of a good integrated enterprise architecture with lots of (sometimes contradictory) requirements.
R&A IT Strategy & Architecture 
1 comment