Architecture Practice in Defence Realising the Seamless NCW Force

Transcription

1 Architecture Practice in Defence Realising the Seamless NCW Force Meredith Hue Defence Science Technology Organisation Third Avenue, Edinburgh, South Australia Tel: Fax: Abstract Australia s Network Centric Warfare (NCW) capability can be regarded as a very large System-of-Systems (SoS). The problem of engineering such a large SoS capability has thus far been intractable, defying efforts to specify for acquisition because of its considerable size and complexity, and the inherent volatility of its external environment. Architecting has risen to prominence in Defence to provide mechanisms to assist implementation of Australian NCW capability. Despite energetic endeavours, there are still many challenges facing architecting practitioners in Defence. In particular, the process continuum from architecting to systems engineering is poorly understood. Some of the more enduring challenges are thus explored, and some practical approaches proffered, with a focus on realising the promise of architecting in supporting development of Australia s NCW capability. Key Words Network Centric Warfare; Architectures; Systems of Systems; Information Capability Introduction The era since the launch of the last Defence White paper [1] in 2000 has seen profound changes in Defence capability planning, both in terms of the processes employed, and the capability outcomes sought. This has heralded a paradigm shift from the Industrial Age into the Information Age with the formal recognition of Information as an explicit Defence capability and the endorsement of Network Centric Warfare (NCW) as a critical enabling concept to underpin the ADF approach to future warfighting.[2] Architecting in Defence has risen to prominence to provide mechanisms to assist implementation of Australian NCW capability, with Australia drawing inspiration from its major allies, the US in particular, both in terms of its NCW warfighting approach and its architecting endeavours. Despite energetic endeavours, there are still many challenges facing architecting practitioners in Defence. In particular, the process continuum from architecting to systems engineering is poorly understood and difficulties can arise where responsibility for architecting and systems engineering to deliver an integrated capability is distributed across different organisations. Some more enduring challenges are thus articulated and explored, and some practical approaches proffered, with a focus on realising the promise of architecting in supporting development of Australia s seamless and integrated NCW Force. 1

2 The NCW and Information Capability Planning Challenge Network Centric Warfare is a warfighting concept, described as a means of organising the Force by using modern information technology to links sensors, decision makers and weapons systems to help people work more effectively together to achieve the Commander s intent. [3]. The notions of NCW and the seamless integrated force have demanded unprecedented coupling between previously disparate capabilities and organisations, which span whole of Defence, and can extend beyond this to other Government organisations (OGOs), and non-government organisations (NGOs). The Information Capability planning challenge is illustrated in the following diagrams of Figures 1 and 2 below, as Defence seeks to transition from a legacy aggregation of disparate independent stovepipe systems to a deliberately planned emerging structure which has a specific topology with much greater cohesion than its legacy predecessors. FROM THIS: Independent Stove-pipes RHIB Coalition Allies OGOs Industry NII Figure 1 TO THIS: Representation of Legacy Information Architecture Architectural cohesion harmonisation of: structure - topology - relationships standards New Doctrine, TTPs, SOPs New technical standards RHIB Coalition Allies OGOs Industry NII Figure 2? Representation of Notional Target Information Architecture (Example) 2

3 This has resulted in extended and overlapping spheres of influence, challenging the traditional notions of systems boundaries previously established through various management and governance mechanisms in Defence for capability planning, including those boundaries of responsibilities devolved to individual Defence acquisition projects. The scale of the NCW challenge is clearly illustrated in Figure 3, where architectural cohesion is sought across a plethora of projects in the Defence Capability Plan (DCP) [4] as identified in the NCW Roadmap [5]. Multitude of Projects - Sensors, C2, Effectors, Networking, Platforms, Information Systems Maritime Domain Land Domain Aerospace Domain ISR Domain Joint Domain Coalition Domain Ref: NCW Roadmap 2007 Figure 3 Projects in the DCP Contributing to NCW Capability [5] Implementation of Information Capability in the form of a Defence Information Environment (DIE), underpinning both the NCW warfighting capability and corporate business capability, thus presents a major challenge to capability planners, particularly where responsibility is distributed across a number of different organisations, with separate budgeting and governance arrangements. A more cohesive and systematic approach across the organisation as a whole is therefore sought. While new solutions can be successfully integrated within individual projects with welldefined system boundaries, there is currently a lack of sufficiently formalised, explicit and systemic mechanisms in Defence to provide the cross-project SoS engineering and architecting perspectives to drive the respective systems engineering processes at individual project level and facilitate force integration and organisation integration on a larger scale. Projects can therefore struggle to achieve the desired level of horizontal 3

4 integration across projects and organisations as they do not have sufficient visibility of peer system and organisational requirements. Communications and Information Systems (CIS) (incorporating associated Information Communications Technology (ICT) capability) are particularly challenging, as project boundaries may be determined by considerations other than logical partitioning of the respective CIS systems supporting NCW-related functionality, where NCW-related functionality may be distributed across multiple systems, platforms, and organisations, with dependencies contingent on other system and platform characteristics and interactions as shown in Figure 4. Furthermore, both information and infrastructure may be shared between warfighting and non-warfighting systems and organisations, which are subject to different acquisition, management and governance processes. NCW Warfighting Capability Platform/System components acquired thru mix of different project procurement in DCP -SE and DAF documentation for individual projects - no requirement for SoS perspective Other* Sensor Networks Corporate Business C2 Effector Some ICT components acquired thru separate DIE governance mechanism - no requirement for SE or DAF documentation - SoS perspective for some aspects of DIE Platform/System DIE CIS (ICT) components Other*: e.g. Command Support/Logistics/Navigation System Components Figure 4 Procurement Challenge of Overlapping Responsibilities Individual project status is normally accorded for a major platform acquisition. Platformrelated CIS requirements supporting NCW functionality are therefore typically included in the respective platform functional and performance specifications along with the myriad of other platform specific requirements. From an engineering perspective, there are currently no mechanisms for specifying NCW and CIS requirements in the systems engineering context independently of the individual projects, to provide a cross-project perspective as design guidance for platform-specific implementation. To help ameliorate this problem, an enterprise architectural approach using the Defence Architecture Framework (DAF) [6] has been mandated for major capital acquisition projects listed in the DCP that are acquiring information-related capability seen as 4

5 underpinning NCW. However, despite the various governance arrangements that have been put in place at the enterprise level, the problem of engineering such a large SoS capability (described as a seamless integrated force) has remained intractable. The inherent volatility of the external environment, giving rise to changing requirements has also exacerbated problems of managing and coordinating delivery of an integrated capability that provides the aggregate functionality and performance intended. It is clear that further consideration is needed in order to redress these more enduring challenges. Current Systems Engineering Practice in Defence Defence has a maturing system engineering process that accords with ISO/IEC [7], as described in the Defence Capability Development Manual [8], for managing capability over the entire capability life cycle spanning cradle to grave, with specific phases encompassing needs, requirements, acquisition, in-service and disposal. The DCP is the key planning document guiding the acquisition of new Defence capability. It provides a rolling 10-year window to provide oversight of major capital equipment proposals for consideration for approval over the period of the plan. Individual projects in the DCP have responsibility for undertaking system engineering activity within the confines of their respective project boundaries. Detailed analysis with specific system focus is undertaken at project level during the requirements phase, with individual project documentation being generated to support the acquisition phase leading to the introduction into service of individual new capability supporting the notion of the seamless integrated force. Thus a suite of individual system-level specifications is generated bounded by the scope of the respective projects in the DCP. System boundaries are therefore established within the context of individual projects, rather than on a functional basis. The projects therefore have distributed responsibility for ensuring horizontal integration is achieved. DIE Capability Planning in Defence Cohesion between Defence capability planning and DIE planning is currently being managed through the application of a number of different governance mechanisms throughout different parts of Defence. The DIE is conceptually the single entity underpinning Information Capability, and was formed to help rationalise ICT investment in Defence and align Defence capability and information systems development [9]. The DIE encompasses both the information used by Defence, and the means by which it is created, managed, manipulated, stored, disseminated and protected, across both corporate business capability and NCW-related warfighting capability. It thus encompasses the enabling information systems and infrastructure underpinning the combat capability for information users delivering combat effects in operations, being acquired through the DCP as shown in Figure 5. 5

6 Shared infrastructure across corporate, business and NCWrelated warfighting Information Capability Other Defence Information Environments Corporate Business Other Defence Information Environments DIE Maritime Corporate Business Maritime Warfighting Info Env Aerospace Warfighting Info Env Aerospace Corporate Business Joint Warfighting Info Env Coalition Allies OGOs Industry NII Land Warfighting Info Env Land Corporate Business Capability boundaries are blurred Other Defence Information Environments Whole of Defence Figure 5 Big Picture Perspective Information Capability The primary vehicle for managing the DIE is the DIE Strategic Planning Framework.[10] The DIE is described as comprising two parts, viz, the Defence Information Domain (DID), which describes the business information requirements, and the Defence Information Infrastructure (DII), which is the technology base of the DIE, as shown in Figure 6. Defence Information Environment Defence Information Domains (DID) Defence Information Infrastructure (DII) Infrastructure Management Information Management Management Operations Policy and Doctrine Processes and Procedures Organisation and Structures People and Training Data User Applications Common Services User Devices System Hardware Networks/Datalinks Bearers Fixed Deployed Information Interoperability Sensors Weapons Coalition Allies OGOs Industry NII Figure 6 Defence Information Environment Representation [10] 6

7 The DID comprises the information management elements of Defence business processes, and provides the fundamental inputs to Information Capability of policy and doctrine, processes and procedures, organisation and structures, and people and training. The DII comprises the infrastructure that supports the electronic creation, collation, processing, protection and dissemination of Defence information. Management of the DII is achieved through the DII Plan [9]. In real terms, this means that the sensors, people and weapons encapsulated within the NCW warfighting paradigm are linked together via the CIS infrastructure within the DII, which is providing the required connectivity to support the information flows between the respective force entities in support of the notion of the seamless integrated force. The DII therefore enables Defence to conduct its business operations, but also supports the generation of combat power through its C4ISREW (Command, Control, Communications, Computing, Intelligence, Surveillance, Reconnaissance, and Electronic Warfare) capabilities. However, neither the DIE Strategic Planning Framework nor the DII Plan explicitly incorporate the concept of architectures or architecture frameworks in their deliberations, although they are the primary management tools used for coordinating the strategic management of the DIE. Although individual illustrations in DIE documentation may use presentation templates from the DAF, the DAF is not explicitly used to assist in the articulation and development of information capabilities, nor to manage the interface boundaries with other networks including those supporting the NCW-related warfighting activity in the DIE documentation. While the DII Plan reflects an enterprise-oriented approach in a number of instances, referring to notions such as enterprise process owners, enterprise licence arrangements, enterprise data, and enterprise application integration, there is no explicit guidance provided in any of the planning guidance to an enterprise-wide architecture; the only reference to the DAF being in the context of a proposed architecture repository. Conversely, from the DAF perspective, the DIE is seen to be managed using the enterprise architecture methodology, where the enterprise architecture is described as comprising the collection of specific architecture descriptions prepared by projects whilst preparing their respective systems engineering documentation.[11] Thus the same NCW-related warfighting capability may be simultaneously subject to quite disparate governance mechanisms associated with the respective planning and strategy frameworks. While an enterprise-level architectural approach may be inferred for the development and management of the DII as a whole and therefore by inference, the larger DIE, this is clearly not the case. Accordingly, the current governance processes do not readily support a comprehensive, consistent, coordinated and integrated architectural approach to Information Capability acquisition and its development to underpin the NCW warfighting capability sought. Understanding Enterprise Architecture Frameworks How can architecting help? Are there different types of architectural approaches? The increasing importance, prominence and complexity of the information environment require new tools and techniques to explicitly manage the promulgation of information as a Defence capability. The usefulness of a logical construct or architecture for defining and 7

8 controlling the interfaces and integration of system components systematically across an entire organisation or enterprise was recognised as early as the mid-1980s, when Zachman released his seminal paper on a framework for information systems architecture, now known as the Zachman Enterprise Architecture Framework, or more commonly called the Zachman Framework (ZF) as shown in Figure 7 [12]. Figure 7 Zachman Architecture Framework Representation [12] Enterprise Architecture Frameworks (EAF) are used to organise enterprise architectures into different views that are meaningful to different stakeholders, where EAF may specify process, method and/or format of architecture activities and products. Although the notion of an EAF is quite broad, it characteristically takes a whole of organisation perspective. An EAF can then be regarded as a logical structure developed using an agreed taxonomy and ontology, for providing descriptive representations or models of the organisation at the enterprise level that are important for the management of the organisation and the development of the systems that comprise them. It can provide not only a means of defining how to organise the structure, but can also define the views associated with an Enterprise Architecture. The taxonomy provides a means of classifying the basic elements in the architecture, and can include the principles underlying the classification. The ontology is a formal representation of the set of concepts within a particular domain and the relationships between those concepts, providing a form of knowledge representation 8

9 about that particular domain. It typically encompasses individual elements, classes of elements, attributes and relations, and provides a means to reason about the properties of each domain. Thus, in an organisation, the Enterprise Architecture can be regarded as the organising logic relating business processes and Information Technology (IT) infrastructure, reflecting the integration and standardisation requirements of the organisation s operating model. Considerations typically span domains of business, applications, information and technology. A key benefit purported from using an EAF is the ability to support decision making in changing businesses, responding to changing external environments, providing traceability from the business strategy down to the underlying technology infrastructure. Because they bring together business models (e.g. process models, organisational structures) and technical models (e.g. system architectures, data models, state diagrams), it should be possible to trace the impact of organisational change on the systems, and also the business impact of changes to the systems [12]. Thus, as an EAF, the DAF might be expected to be taking a whole of enterprise approach, and provide a logical structure for providing descriptive representations of the organisation at the enterprise level. This would then allow for some form of traceability from business strategy to the underlying technology infrastructure so as to be able to evaluate the impact of organisational change on systems, and the impact of system changes on business outcomes, which is the key benefit sought from such an architectural approach. However, the current instantiation of the DIE does not invoke any relationship with the DAF. Understanding Architecting Methodology Given an architecture framework, architecting methodology involves the preparation of a series of architectural representations providing a temporal perspective, for example, from the current architecture ( as is ), to planned or possible intermediate forms ( to be ), to various notions of future possible target architectures ( to be ), or to an idealised and unconstrained notion of a strategic target architecture ( should be ) [13]. Real world tradeoffs are needed based on cost-benefit analyses, shaped by organisational imperatives such as policy considerations, budget, required time lines, and other real-world constraints. This allows business decisions to be made as to where to invest resources to re-shape the current architecture towards the planned future state, where to re-align organisation goals, and what policies and procedures will support core missions or business functions. In this regard, clearly articulated decision criteria, decision processes, and metrics (e.g. Measures of Performance (MOP) and Measures of Effectiveness (MOE)) are crucially important to provide the underpinning rigour to decisions being made which can ostensibly have a significant impact on the organisation s future ability to achieve its organisational objectives. The presentation artefacts produced as a result of the various analyses reveal the underlying rigour supporting the decision-making processes to progress the evolution of the architecture towards the planned future state, revealing the relevant detailed structure within the organisation relating to the respective domains such as business, applications, information and technology, as in the case of a ZF. The taxonomy and ontology within the framework should allow clear articulation of what processes a business performs, and provide detailed information about how those processes are executed and how well they are executed across the organisation. The presentation artefacts should provide the necessary 9

10 detail to reveal what and how an organisation operates and what resources are required. Thus an architectural approach can provide insight to basic questions such as: Is the current architecture providing adequate support towards achieving the organisation s short-term business goals and objectives? How might the architecture be modified so that it is better adapted to support achieving the organisation s short-term business goals and objectives? Based on what is known about future aspirations of the organisation, how well does the current architecture support those notions and how might it need to change? Governance plays a crucial role in the evolution of architectures as it is a key process to keep organisational changes on track for meeting articulated goals and strategies defining the future state of the organisation or enterprise.[13] Architectures Origins in Defence The notion of using architectures to assist in shaping military information capability acquisition was first mooted by the US Department of Defense (DoD) with the launch of the C4ISR Architecture Framework (C4ISR AF) in the late 1990 s [14]. The framework was introduced to address a number of challenges relating to increasing uncertainty of requirements, rapidly evolving technology, and structural change in DoD, together with an increasing need for interoperability with the Services, across whole of DoD, and across national and international agencies. The C4ISR AF was a major initiative underpinning US DoDs transformation efforts as they sought to embrace the new network-centric (netcentric) warfighting paradigm. Initial architecting efforts were directed towards breaking down information stovepipes and, at the system level, focussing on developing the information environment known as the US Global Information Grid (GIG) which is the key information capability underpinning US DoD s net-centric warfighting capability. To be able to mix and match organisations with composite capabilities to suit a particular situation as demanded in a net-centric environment requires an unprecedented level of interoperability in information systems. To achieve this flexibility to plug and play, the US DoD looked to developing information architectures to assist them that could provide current or future descriptions of a domain composed of components and their interconnections, together with descriptions of the actions or activities performed by those components, and the rules or constraints with that domain. The term architecture, used in this context, is referring to the structure of the domain comprising the related components, and the system is the domain [14]. Importantly these system architectures, while they will change over time, were expected to change much slower than the actual systems they represent. Because of their stability, they were seen to provide important guides to acquisition decisions as well as defining operational concepts. The goal therefore was to describe architectures using multiple views that answered questions regarding the operational capability provided by the systems if they were built conformant to the architecture. Another goal was to support the acquisition community in its efforts to acquire interoperable systems, providing a seamless process from knowledge elicitation to architecture design to evaluation. The US DoD adopted a commonly used definition of architecture in the C4ISR AF derived from IEEE Standard [15] where the architecture is described as the structure of components, their relationships, and the principles and guidelines governing their design 10

11 and evolution over time. Architecture descriptions therefore provide the representations of a defined domain, as of a current or future point in time, in terms of its component parts, how those parts function, the rules and constraints under which those parts function, and how those parts relate to each other and the environment. The architecture framework provides the guidance and rules for structuring, classifying and organising the architectures. Architectures were seen to provide a common approach to ensure system-wide characteristics (such as interoperability) were achieved across the evolution or deployment phases of the systems that were built in conformance with the architecture. These systems could be related by time-evolution, by differing deployment options, or both. Timeevolution in this context is where individual systems that are interconnected in a large distributed system are upgraded over time. Systems may also differ over deployment schemes, as in the case of military task forces, which consist of a large number of component types, with specific deployments having varying mixes and numbers of components. Notably, the C4ISR AF had a strong systems focus rather than an enterprise focus, and was designed primarily in conjunction with structured analysis concepts, placing strong emphasis on interface design of the plug and play components within the domains, and interface design between domains, informing the both the component design process and the system design process. It thus fitted seamlessly into extant systems engineering practices of the day. However, the C4ISR AF did not seek to constrain the notion of the system in any particular way, and had an enterprise focus at its core at the outset, as its applicability notionally spanned whole of US DoD, with the GIG as its focal point. The C4ISR AF was subsequently updated during the early 2000s and renamed as the Department of Defense Architecture Framework (DoDAF) to incorporate broader organisational business perspectives, reflecting more of an enterprise approach than a systems approach to architecting to comply with a US Federal Government mandate. The DoDAF is intended to ensure architecture descriptions can be related across programs, mission areas, and ultimately the enterprise, thus establishing the foundation for analyses that support the decision making processes throughout whole of US DoD. The DoDAF therefore provides the US DoD a structured and repeatable method for evaluating investments in net-centric related capability and investment alternatives as well as the ability to effectively implement organisational change, create new systems, and deploy new technologies [16]. A key feature of the DoDAF (and its predecessor the C4ISR AF) as shown in Figure 8, is the representation of the architecture in terms of a set of prescribed perspectives, from an operational viewpoint, from a systems viewpoint, and from a technical viewpoint. A list of views or architectural products is prescribed to provide a common representation of prescribed information for consistency across the entire organisation. Prescribed taxonomies (e.g. Universal Joint Task Lists) and ontology (e.g. the CADM or Core Architecture Data Model) are underpinning key features of the DoDAF. The DoDAF thus consists of two layers; the presentation layer and the data layer. The architecture data elements and their defining attributes and relationships are within the data layer. The presentation products and views are within the presentation layer. These provide a visual 11

12 means to communicate and understand the purpose of the architecture, what it describes, and the various analyses performed. Recent upgrades of the DoDAF have served to strengthen the focus on architecture data rather than the products, with the CADM incorporated as an integral component of the DoDAF. Figure 8 Linkages Between DoDAF Views [16] Importantly, the DoDAF has also expanded on the need for development of integrated and federated architectures to support the net-centric warfighting concepts as shown in Figure 9, where an integrated architecture has all architecture data elements uniquely identified and consistently used across all products and views within the architecture. By being integrated, the architecture is referring to those common points of reference within the architecture description that link the operations view, systems and services view, and technical standards view. This means that architectural objects common to more than one view should be identical or be linked via an underlying relationship, and all objects that have relationships across all views are linked by underlying data relationships. In this manner, architectures clarify roles, boundaries, and interfaces between components and systems within large SoS, and as act a key tool for enterprise-level systems integration. 12

13 Figure 9 Notions of Integrated and Federated Architectures Supporting the Netcentric Warfighting Concept [16] As described in the DoDAF, the notion of a federated architecture provides a framework for enterprise architecture development, maintenance, and use that aligns, locates and links disparate architectures via information exchange standards. A federated architecture is a distributed strategic information asset base which defines the mission, the information and technologies to perform the mission, and the transitional processes for implementing new technologies in response to the changing need. Federation is facilitated by having a core set of meta-data for all architectures that enables discovery of information, and semantically aligns disparate architectures to support understanding and interoperability across stakeholder communities. Thus integrated architectures enable a broader perspective of the mission by architecture data elements through multiple views. Federated architectures support decision-making at program, DoD, component, mission and enterprise levels by linking architectures across the enterprise, providing an holistic enterprise view that allows for assessment of interoperability, identification of duplications and gaps, and determines re-usability. Both integrated and federated architectural approaches are seen to support netcentricity by enabling the semantic and structural alignment of data across disparate architectures in a useful manner for the improved reliability and efficiency of decisions, thus resulting in improved mission outcomes. Notably, allied nations such as the US, UK and Canada have all adopted architectural approaches to assist the development of interoperable C4ISR architectures to support integrated warfighting ability across the boundaries of individual environments. Architectural approaches such as the US DoDAF, the UK MODAF and the French AGATE Architecture Frameworks are all underpinned by a standard meta-model which defines the critical architectural data elements and the dependencies between them. 13

14 Analytical tools based on these models can then query the underlying architectural information in support of the various analyses. An Examination of Current Architecture Practice in Defence Australia has similarly drawn on experience from the US DoDAF, and has taken an enterprise architectural approach for the implementation of the DAF. A representation of the DAF is provided in Figure 10.[17] The use of the DAF has been mandated for major capability development projects listed in the DCP to provide cross-project architectural cohesion for information-related capability acquisition delivering into the DIE. Architectural descriptions are included in the relevant systems engineering documentation. Once endorsed, the descriptions provide major input into the systems engineering process shaping the subsequent acquisition of the project specific capability. Such documentation thus bounds the fidelity of the information being provided to the system developer for subsequent implementation. Defence Architecture Framework Governance, Compliance and Co-ordination Operational and Business Context Security Enterprise Architecture Business Standards Defines Information Influences Systems Determines Infrastructure Presented by Common View Specific Architecture Descriptions Operational View Systems View Technical View Data View Populated by Defence Enterprise Architecture Library Defence Architecture Supported by Information Model Repository Tools Fundamental Inputs to Capability Research and Technology Influences Figure 10 Defence Architecture Framework [17] Current architecture practice in Defence is view-based, in that the emphasis is placed on the production of a consistent set of illustrations to provide consistency in presentation of architecturally relevant information. It prescribes a set of products representing operational views, systems views and technical views, in a similar manner as described in the DoDAF for use in project documentation prepared in support of the acquisition process. Templates are made available for use by the respective projects in their systems engineering documentation to ensure presentation of information is consistent, the same views are produced, and the same type of information is made available by each project delivering a component of Information Capability into the DIE. In this way, it is possible to provide 14

15 visualisation of the Information Capability as manifested from the specific perspective of each individual project. In the absence of a DAF-provided taxonomy or ontology, each project is free to choose its own taxonomy and ontology to support localised architecting efforts within the project boundaries. From a broader SoS perspective, current architecture practice has a number of implications: Resources for architecting effort are focussed on delivering the mandated set of architectural products for inclusion in the documentation for specific project phases rather than looking forward to the acquisition phase and supporting the larger systems engineering process; Since particular views are produced primarily for inclusion in documentation for specific project phases, there is no consideration of adequacy or utility for re-use, either in support of project specific detailed design activity, or in support of other projects, thus constraining their utility; There is no architecture meta-model or set of reference models to promote consistency of architecture information across project boundaries; There is no process to correlate sets of views, or the information contained within them, to relate different capabilities operating together; Analyses are performed in the context of individual project phases, and may not provide a whole of project perspective, or enterprise perspective; There is no indication as to the types of analyses being undertaken supporting the production of the views, to give a known level of assurance of the information content in terms of accuracy, consistency, or coherency from a SoS perspective across multiple projects; Static representations do not provide adequate insight into the dynamic behaviour and performance, neither at an individual systems level nor the SoS level; There is insufficient guidance provided on the concept of interoperability for projects to use as a common basis for analysis, despite being a primary focus area for architectures; and There is no guidance as to what metrics are to be used in support of architecture assessment to promote cross-project consistency of analyses. Key challenges facing Defence are thus summarised as follows: Governance Process: Governance processes and hence architecting processes for overseeing the management and evolution of the collective Information Capability are not harmonised across Defence; additionally there appears to be significant differentiation between that underpinning corporate activity and warfighting capability, despite common imperatives and blurred boundaries. Architecture Scope: There is no representation or common notion of a concept or entity that is the Defence Enterprise Architecture, which can then be related to the DIE, which is the instantiation of Information Capability in Defence. Since there is no notion of a SoS representation of Information Capability in Defence with the current project-centric architecting methodology, there is no notion of architecture at the SoS level, so there is no overall representation of a Defence-wide architecture. This means there is no: o vehicle to provide holistic perspectives of the current architecture underpinning Information Capability, 15

16 o aspirational architecture, or o series of intermediate states which may be dependent on individual project outcomes, that would otherwise permit examination of cross-project interfaces, and promote consistency in adoption of specific standards across respective technical architectures. This is seen as a significant impediment to the outcomes sought. DAF Implementation: The current view-based implementation of the DAF, and its project-phase specific application, fundamentally constrains the value of architecting activity in Defence and contraindicates the outcomes sought. Future Directions A key question one can ask therefore, is what can be achieved by architecting endeavours beyond that which is already being supported within the current systems engineering and other management processes. Architecture practice has significant unrealised potential in its capacity to assist in achieving better outcomes for delivery of NCW-related capability into Defence. However, some significant challenges are faced. The following notions are suggested as ways of improving support to the acquisition of future NCW-related capabilities: Acknowledgement of the pervasiveness of the NCW concept across whole of Defence (including the business processes) rather than constraining the notion to the future warfighting concept; Acknowledgement of the DIE as a formal construct spanning the entire Information Capability underpinning NCW, rather than constraining the scope of the DIE based on particular organisational responsibilities or technical scope; Formalisation of the concept of a Defence-wide Enterprise Architecture (DEA) which accords with the Defence Information Environment (so as to support a unified approach to Information Capability development) with consistent governance arrangements across the warfighting and non-warfighting functions, including application of the DAF across the entire DIE. (A high-level requirements document along the same lines as the Capstone Requirement Document for the US GIG could be useful to facilitate improved systems engineering process integration across the respective organisations); Formalisation and dissemination of the concept of the DAF beyond the current model so that the guidance and rules for structuring, classifying, development and use of architectures for Defence are clearly articulated and widely accessible by the broader architecting community; Formalisation of a standard architecture meta-model within the DAF to enable critical elements and their dependencies to be identified. This would promote better consistency in the architectural information across project boundaries, and provide for improved reconciliation across overlapping spheres of influence. It would also allow consistent application of analytical tools based on these models to query the underlying architectural information in support of the various analyses towards the development of integrated and federated architectures; Formalisation of technical reference models with the DAF to provide for consistent taxonomies in architectural representations across project boundaries; 16

17 Formalisation of a common definition for interoperability and metrics to promote better consistency in analyses supporting interoperability assessment; and, Formalisation of a set of metrics to provide consistency in analyses in support of Information Capability development. Notions of the DIE and architecture methodology in Defence have been continuously evolving since 2000 and there is an emerging awareness of the importance of architecture practice in supporting development of whole of Defence Information Capability. While efforts have recently been increased in the Australian Department of Defence, architecture practice, particularly as it relates to net-centric operations, is still underdeveloped. Importantly, the above notions offer significant potential to progress the maturity of architecture practice in Defence in developing the DIE, and delivering future informationage warfighting capability. Acknowledgement This paper was prepared under the auspices of the Network Centric Warfare Science and Technology Initiative, DSTO, with the support of Command, Control, Communications and Intelligence Division, and Land Operations Division, DSTO. The author would like to thank Dr Terry Moon for his inspiration and guidance during the preparation of this paper. Bibliography [1] White Paper - Defence 2000: Our Future Defence Force, Defence Publishing Service, Department of Defence, Canberra, ACT, URL: [2] Head Strategic Policy, Enabling Future Warfighting Network Centric Warfare, ADDP- D.3.1, Defence Publishing Service, Department of Defence, Canberra ACT, URL: [3] Director General Capability and Plans, Explaining NCW, Defence Publishing Service, Department of Defence, Canberra ACT, URL: 21feb06.pdf [4] Defence Capability Plan Public Version, Industry Division, Defence Materiel Organisation, Defence Publishing Service, Department of Defence, Canberra, ACT, URL: [5] Director General Capability and Plans, NCW Roadmap 2007, Defence Publishing Service, Department of Defence, Canberra, ACT, URL: [6] Brochure No. 1, Introduction to Enterprise Architecture, Information Architecture and Management Branch, Chief Information Officer Group, Department of Defence, Canberra, ACT, January,

18 [7] ISO/IEC Standard 15288:2004, Systems and Software Engineering System life cycle processes. URL: 4 [8] Director, Capability and Plans Defence Capability Development Manual 2006, Defence Publishing Service, Department of Defence, Canberra, ACT, URL: [9] Defence Information Infrastructure (DII) Plan Financial Year , Chief Information Officer Group, Defence Publishing Service, Department of Defence, Canberra, ACT, URL: [10] Director Information Communications Technology Futures, Defence Information Environment Strategic Planning Framework, Information Strategy & Futures Branch, Department of Defence, Canberra, ACT, March, [11] Brochure No. 3, Architecture as the Change Driver for the Defence Information Environment, Information Architecture and Management Branch, Chief Information Officer Group, Department of Defence, Canberra, ACT, January, [12] Zachman, J.A., A framework for information systems architectures, IBM Systems Journal, Vol 26 No. 3, , [13] C4ISR Architectures Working Group, C4ISR Architecture Framework, Version 2.0, December, URL: [14] Levis, A.H. and Wagenhals, L.W., C4ISR Architectures: I. Developing a Process for C4ISR Architecture Design, Systems Engineering Vol 3 No 4, , [15] IEEE Standard , IEEE Standard Glossary of Software Engineering Terminology Description, URL: [16] DoD Architecture Framework, v1.5, Volume I: Definitions and Guidelines, US Department of Defense, April, URL: [17] Brochure No. 2, The Defence Architecture Framework - A Methodology for Enterprise Architecture, Information Architecture and Management Branch, Chief Information Officer Group, Department of Defence, Canberra, ACT, January,