Analysis of dependencies between information systems, business processes, and strategic goals is an important part of the discipline of Enterprise Architecture (EA). However, EA models typically provide only visual and qualitative decision support. This paper shows how EA frameworks for dependency analysis can be extended into the realm of quantitative methods by the use of techniques from Fault Tree Analysis (FTA). Using MODAF, the UK Ministry of Defence Architecture Framework as an example, we give a list of criteria for the extraction of a metamodel for FTA use, and provide such a metamodel for MODAF. Furthermore, we use this MODAF FTA metamodel to perform dependency analysis on a sample MODAF model.
During the last decade, Enterprise Architecture (EA) has grown into an
established approach for management of information systems in organizations. EA is
model-based and does not only increase the general understanding of an
organization’s business and information system landscape, but also aids in decision
making. Formal analysis approaches for EA [
MODAF, the Ministry of Defence Architecture Framework, is designed to
support the creation of an enterprise architecture for the British Ministry of
Defence. Dependency analysis, i.e. the connection of high level concepts such
as strategic capabilities (airlift, search and rescue, etc.) with the detailed and
precise concepts that constitute low level technical systems (particular vehicles,
radars, IT systems, etc.) has been identified as a key use of MODAF [
The present paper proposes an improvement and formalization of EA
dependency analysis by methods from Fault Tree Analysis (FTA). FTA is a
combinatorial model of systems dependability, widely used for safety and reliability
evaluations [
The remainder of this paper is structured as follows. Section 2 contrasts the present paper with some related work. Section 3 is the locus of the main contribution, describing how to map MODAF models into fault trees. Section 4 gives a practical example of the method. Section 5 discusses the contribution and concludes the paper. 2
Related work
Model based generation of fault trees has been previously addressed. [
A metamodel for the use of FTA in MODAF In this section, the possibility of mappings between MODAF models and fault trees is discussed. Criteria for the use of FTA in MODAF are listed, and a metamodel based on these criteria is then presented. 3.1
Selection criteria While FTA is a formal, mathematically precise method, MODAF models span wider fields (viz. all activities of the UK Ministry of Defence) and are as a consequence less clear-cut. We therefore define a list of selection criteria for identifying MODAF Meta Model (M3) objects appropriate for use in FTA. Criterion 1 (Causal chain). M3 objects relevant to FTA must be part of a causal chain connecting technical systems to higher level concepts on the way to the strategic enterprise goals from the MODAF Strategic view.
Criterion 2 (Proper abstraction). M3 objects relevant to FTA must not make the overall architecture unnecessarily detailed.
Criterion 3 (Relevance to failures). M3 objects relevant to FTA must have at least one of the following properties (i) be the subject of failure (prospective fault tree events) or (ii) be able to transfer failures (prospective fault tree arcs). Criterion 4 (Concreteness). M3 objects relevant to FTA must be on the level of concretion normal to FTA.
Criterion 5 (Binary fault states). M3 objects relevant to FTA must, when instantiated as fault tree events, have the binary fault states non-failed and failed. 3.2
Creating the metamodel Using the M3 objects (entities and relations) thus selected, we build a metamodel for the use of FTA in MODAF. This entails a final delimitation: Criterion 6 (Connectedness). M3 objects relevant to FTA must not be solitaire with respect to the whole set of such M3 objects. For event objects, this means that at least one arc object has to point to it. For arc objects, this means that it has to connect two event objects (not necessarily distinct).
The metamodel created by application of criteria 1 through 6 is illustrated in Fig. 1. Objects removed by criterion 6 are listed to the left in the figure.
ActivityMapsToCapability StandardOperationalActivity
m eCapability t sPhysical y
itcgaeEGEnnotdaeulrrpinrigse CapabilityDeCpeanpdaebncilyity trTask SlitraaenoMLBANFMolerooiacgshdwhtsiaceeiiovatHreilnioaaculsturre ESOEIInnpnxpefetcoeerchgrrrimafaayictFncaiaotgltioitoneoiwona*n,n*l, NoCdaepCAaTbocyitlpmiutLyeFopaFlgoloeiwcrtNa*elondcee*IEnOlefpomerraCmetPonioarntontsvaiuoildmNneoesdse,LifeNLCCoinooLDennoeffAOniipgggcluuryetgrreraauUadttaii,nsoolennisdAacttuRioaelnlOatrigoannsihsiaption p
LogicalFlow* ActualPost PDlaatftoarEmlemeRnetCsCoomuornmcteraoUnlssd*asg*e* ReCsCoomuornmcteraoUnlssd*asg*e* ResourceUsage
Physical ResourceUsage* ConAtroslsset Controls*
ResourceUsage ResourceUsage*
RUessoaugrece IRnteesroauctricoen
ands ResoCuorncterUolssa*ge*
OperationaAlctivity
Events Starting from an existing MODAF model, identify the entities that are instantiations of entities found in the FTA metamodel (Fig. 1). We now have an event set.
Arcs Similarly, identify the relations that are instantiations of relations found in the FTA metamodel (Fig. 1). We now have an arc set.
Gates For each relation connecting two entities, take the causally descendant entity and consider together the whole set of arcs connecting it to antecedent entities. Partition this set into OR or AND gates. The degenerate partitioning of the whole set into one single gate is allowed, as is partitionings including singletons, i.e. gates corresponding to the identity relation. The procedure is iterated until all arcs in the arc set have been mapped to gates.
Of course, this procedure cannot do away with the requirement of expertise and acquaintance with the system modeled. It does, however, provide a template and a coherent process for the generation of fault trees from MODAF models. 4
Dependency analysis of Search and Rescue capability
This section presents a practical example of how FTA formalism can be employed
for dependency analysis of an existing MODAF model. We use a Search and
Rescue (SAR) example created by the VEGA Group under contract to the UK
Ministry of Defence [
Now, we employ the FTA usage method from the previous section. Figure 2
illustrates the process of going from the initial MODAF model (1. in the figure),
viz. a top to bottom dependency diagram from [
The Maritime SAR capability is described by Search, Assistance, and Rescue sub-capabilities, connected to the top event, i.e. failure of the maritime SAR capability, through an OR gate. OR gates are used for faults acting independently of each others, AND gates are used for failures acting in concert. For brevity, we have left the Assistance and Rescue capabilities undeveloped further down the tree. Instead developing the Search capability into sub-events, we proceed down through the Operations and System views until we reach basic events.
This example illustrates the process described in the previous section. The fault tree generated, as depicted in Fig. 2, enables not only qualitative dependency analysis, as does standard MODAF models, but also quantitative analysis. If the fault distributions of the components whose failures constitute the basic events are known, the impact of these distributions on the maritime SAR capability can be calculated. Decisions on procurement and maintenance of low level technical systems can thus be optimized with regard to the actual capability they are to support, rather than an intermediate proxy. Not the least, this allows rational prioritization when it comes to trade-offs between different systems. has sub-capability
Top to Bot om Dependencies This diagram shows an example of tracing dependencies from capability down to system port interconnections <<Capability>>
UK SAR Capability has sub-capability <<OperationalActivity>>
Find victim undertakes <<OperationalActivity>> Generate distress signal contributes to
<<Capability>>
Distress Signal Monitoring undertakes <<CapabilityConfiguration>>
NIMROD MRA realises <<Node>> Search node needline distress signal <<Node>> Person in distress realises <<CapabilityConfiguration>>
Person in distress 1. Initial MODAF model
Process Signals <<Function>>
<<Function>>
Emit distress transmission has sub-system provides provides
hosts <<CapabilityConfiguration>> trTask
S
Yacht has part <<PhysicalAsset>>
Yacht <<System>> ESM System of ers <<SystemPort>> Frequency Scanner system connection distress signal <<SystemPort>> Transmit er of ers <<System>>
Distress beacon 3. Created fault tree has sub-capability <<Capability>>
SAR <<Capability>>
Search has part <<Physical Asset>> NIMROD Airframe hosts <<System>> Sensor Suite c i g e t a r t S l a n o i t a r e p O m e t s y S <<Op. Activity>>
<<Cap. Config.>>
<<Capability>>
OR <<Capability>>
OR <<Op. Activity>>
fails <<Op. Activity>>
<<Op. Activity>>
<<Op. Activity>>
<<Op. Activity>>
fails <<Op. Activity>>
<<Op. Activity>>
fails <<Op. Activity>>
signal fails <<Op. Activity>>
operation fails <<Op. Activity>>
assets to operation <<Op. Activity>>
assets OR <<Cap. Config>>
fails
Discussion and conclusions MODAF was developed to support the modeling needs of the UK Ministry of Defence, while Fault Tree Analysis is a well-defined mathematical hazard analysis technique. The present contribution attempts to bridge this gap in several ways.
First, there is a gap of abstraction: the MODAF Meta Model is a metamodel, whereas FTA is generally performed on concrete instances – models – of technical systems. This is bridged by the creation of a smaller metamodel aimed specifically at FTA usage. Second, there is a gap of expressive power: FTA is much less expressive as a language than is MODAF. This is bridged by the algorithmic procedure for creating a fault tree out of an existing MODAF model.
The contribution of the present paper is three-fold: (i) The feasibility of expanding Fault Tree Analysis to strategic level enterprise architecture objects, usually considered too abstract for FTA, has been demonstrated. (ii) A metamodel for FTA use in MODAF has been proposed. (iii) A method for generation of fault trees, starting from the FTA metamodel in conjunction with an existing MODAF model, has been provided, thus allowing MODAF users to perform dependency analysis using the FTA technique.