NATO Architecture Framework & ArchiMate: How ArchiMate Addresses Defence Needs
Jul 2, 2018
In the previous two instalments in this series, on drivers for architecture in defence and industry and on comparing NATO Architecture Framework practice with the civil sector, we described the common drivers for architecture in defence and industry. We also discussed the commonalities between the architecture practice in defence and civil sectors. We noted that collaboration and interoperability in networks of organizations is an increasingly important driver for architecture, and we highlighted the growing use of commercial “off-the-shelf” products in both defence and civil organizations. Where architecture practice is concerned, we also explained how processes are largely similar (as captured, for example, by TOGAF’s Architecture Development Method), that architecture artefacts play an increasingly important role in public procurement and other arenas, and that both worlds are increasingly using reference models to capture commonalities and share knowledge.
– Kevin Wallis (MOD ISS) & Marc Lankhorst (BiZZdesign)
In this third instalment, we want to go into more detail about choosing the ArchiMate language as a standard for expressing architectures in the NATO Architecture Framework v4. We will also discuss how this addresses the needs of the defence sector, specifically the UK Ministry of Defence.
When we look back at the history of the ArchiMate language, it has gradually grown over the years to encompass more aspects of the work of enterprise architects. The first version of the language focused only on the ‘core,’ describing the construction and operation of an enterprise in the common three layers of Business, Application, and Technology. This was a good start, but not yet enough to capture all concerns of an architect.
Version 2 of the language, published in 2012, added concepts for capturing the motivation behind an architecture in terms of stakeholders, goals, requirements, etc. On the other hand, it also added concepts for the realization process of an architecture, describing it in terms of stages (plateaus), deliverables, and the work to be done. In the past, we have made a comparison of this 2nd version and the concepts in the MODAF framework. At that time, the conclusion was that ArchiMate covered perhaps 80% of what was needed, but still lacked a number of important concepts.
Version 3, published in 2016, augmented ArchiMate with precisely the concepts that were still missing. Important additions included the Capability concept, which is crucial to architecture thinking in defence; its use in other domains can even be traced back to this defence notion. Another important addition is the Course of Action concept, which can be used to model the strategic development of an enterprise; an equally important concept in defence. This version also changed the location concept from a physical location to a more generalised grouping, thereby fulfilling the defence concept of an Operational Node (somewhere an activity is undertaken). Now, an Operational Node can be a generic “operations room” or more specific locations depending upon the architecture’s needs.
Finally, this 3rd version added concepts for modelling the physical world in terms of equipment, facilities, and material. Previously, the language focused on information technology only, but obviously physical technology (and its interplay with IT) is even more important in defence, where you will want to model weapons systems, logistics, and other aspects of the physical world.
Below, you see a number of views for a Search-And-Rescue example, ArchiSAR. The first is a C1 Capability view, the second an L2 Operational Node view, and the third an LP4 view of the relationships between a Mission Thread (a business process in ArchiMate terms) and the physical world of SAR helicopters.
Finally, the ArchiMate Exchange Format was established as part of the standard. As we described in our previous instalment, there is a growing need for defence to exchange architecture information with industry (i.e. public procurement) and to reuse information captured in reference models. This file format greatly facilitates this exchange, not only within defence but also with the outside world. This opens up a world of possibilities for reusing and sharing architecture information and it also prevents organizations from being locked into vendor-specific solutions.
ArchiMate was originally not developed with defence as a focus, but rather the typical large information factories in government and finance. This has had its effect on the use of terminology, which may not always match terms used in defence. That requires a mapping of terms between the different worlds. For example, a defence term like “Mission” may map to ArchiMate’s Course of Action concept, and “Thread” maps to the Business Process concept. Other terms like Artefact are used differently in both worlds. But this is in no way a blocking issue. The main task is to come up with a suitable mapping between terms, so people can translate between these two worlds. Much of this work has already been done and the NATO architecture community, with the NATO Architecture Framework, has started work on a common set of mappings.
More importantly, though, is the practical use of ArchiMate concepts to express relevant architecture views, such as those described by the ‘periodic table’ of viewpoints in NAF v4, or the viewpoints of TOGAF. In the final instalment of this blog, we will discuss in more detail how to express NAF viewpoints in ArchiMate, and go into MOD ISS’s approach based on predefined templates and patterns. Moreover, we also explain why ArchiMate alone will not suffice; it has to be connected to other standards in the defence domain, such as the OMG’s UAF, which is also mentioned in the NAF specification. Stay tuned!
