In the first instalment of this series, we compared drivers for enterprise architecture in defence and industry and found that there is are increasing commonalities: a growing focus on interoperability and collaboration in complex ecosystems. a blend of the physical and IT worlds, and the preference for “off-the-shelf” products over custom development. These commonalities also lead to increased usage of the same methods and standards for enterprise architecture. In this instalment, we’ll compare the architecture practices of defence and civil sectors.
-Marc Lankhorst (BiZZdesign) & Kevin Wallis (MOD ISS)
Commonalities in the architecture process
When we look at the typical architecture process, most established approaches are quite similar. They follow a cyclical process of direction setting, developing architecture alternatives, choosing an option, planning the resulting work, and governing the realization to ensure that what is built follows the architecture. Feedback from reality may require adjustments to the architecture, thereby closing the loop.
Influenced by agile approaches and the increasing speed of technological change, these iterations have become shorter and more interactive. No longer can you define a 5-year change plan and expect to follow it to the letter. Rather, you need to be able to correct your course in time, adapting to change as you go.
This iterative architecture process is captured by the TOGAF® Architecture Development Method (ADM) as the most widespread method for architecture development. Other architecture frameworks, including the NATO Architecture Framework (NAF), often use a process based on this. During the development of NAF v4, the TOGAF ADM was explored for its many attractive features, including widescale adoption. However, it was felt to be too information system-centric. NATO also uses different architecture processes to develop platform architectures such as tanks, planes, ships, and missiles. Although these increasingly provide or consume information products, they also have elements that are outside the current scope of TOGAF, which is why NAF uses a somewhat adapted version of the ADM.
Commonalities in the use of architecture artefacts
When we look at the use of architecture artefacts in defence and the civil sector, we observe another commonality. Increasingly, architectures are not only used for defining the things that need to be realised within one’s own organisation; they are also used in communication with various vendors and contractors, providing context and defining requirements. In a complex ecosystem of contractors and subcontractors, working on an even more complex world of interconnected systems and subsystems demands clarity of communication.
In the public sector, including defence, this extends to public procurement, where clear specifications are essential to ensure a common approach between partners and a level playing field among vendors. It also validates proposed solutions in context and supports quality assurance of a delivered product.
Exchanging architectures between customer and vendor organisations is, therefore, increasingly important and needs to be supported by adequate standards.
Use of reference models
A third area of commonality between defence and civil sectors is the use of reference architectures. The content of these architectures is, of course, very different, but the use of domain-specific reference models has become common practice across many domains. Examples include:
- Various government reference architectures, i.e.:
- The BIAN, ACORD, and Panorama 360 frameworks for the financial services sector
- The Frameworx set of models for the telecoms industry
- The Open Group’s IT4IT and Cloud Ecosystem reference architectures
- Reference architectures for manufacturing and supply chains such as ISA-95 and SCOR
- The APQC process framework
- The COBIT governance framework
Of course, it is very helpful if such reference architectures are themselves expressed in a standard language. This is increasingly the case. Examples include the EIRA and various government architectures, and The Open Group’s architectures mentioned above. The Open Group also collaborates with BIAN to express their model in the ArchiMate language.
The defence world extensively uses reference architectures, as well. A prime example is Federated Mission Networking, which aims “to support command and control and decision-making in future operations through improved information-sharing.” The UK Ministry of Defence is also developing the Defence as a Platform (DaaP) Services Architecture (DSA), a reference architecture to describe the information services that underpin operations. Both these reference architectures are now also being expressed as NAF v4 models using ArchiMate v3.
In the next instalment in the series, we will address the use of ArchiMate v3 in defence in more detail, explain why it fits the needs of NATO members, and how we can overcome differences in terminology between defence and the typically “civilian” terms used in the ArchiMate standard.