Architectural design for integrated support of complex engineering projects

2.1Department of Defence Architectural Framework (DoDAF)

The US DoDAF is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of US Department of Defense (DoD) managers to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries [6]. DoDAF serves as one of the principal means supporting the DoD under the Clinger-Cohen Act for the development and maintenance of information architectures. The Chief Information Officer described DoDAF as providing extensive guidance on the development of architectures supporting the adoption and execution of Net-centric services within the US Department of Defence [7]. The term “information architecture” was broadly taken as an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency’s strategic goals and information resources management goals. DoDAF is supported by a range of viewpoints including:

The initial literature review identified that the US Department of Defense Architecture Framework (DoDAF) was popular, with some work further into Human Views [8] to complement Operational, System and Service Views. There are papers on specific uses of DoDAF to solve problems such as Information Security [9] and System Integration [10], but little available as examples of service-system integration.

2.2Australian Defence Architecture Framework (AUSDAF)

Zhu et al. [11] applied the Australian Defence Architecture Framework, a variant of DoDAF to software system architecture. Architecture Evaluation is an approach for assessing whether a software architecture will be complete and consistent in terms of the system needs, especially the non-functional requirements (also known as quality requirements). Architecture Evaluation can be used at different stages of a project, and is an effective way of ensuring design quality early in the lifecycle to reduce overall project cost and to manage risks.

2.3United Kingdom Ministry of Defence Architectural Framework (MoDAF)

The UK Ministry of Defence Architectural Framework [12] contains seven viewpoints: (1) All Views; (2) Strategic Views; (3) Operational Views; (4) System Views; (5) Service Oriented Views; (6) Acquisition Views; (7) Technical Standards Views. Key to this framework is the support for service information systems needed to support the operational system. The usefulness of these evolved frameworks may be limited as many of the adaptations have been incorporated into later versions of DoDAF.

2.4The Open Group Architecture Framework (TOGAF)

The Open Group [13] produced the original version of TOGAF in 1995, based on the Technical Architecture Framework for Information Management (TAFIM), developed by the US Department of Defense. In TOGAF, an entire enterprise can encompass all of its information and technology services, as well as processes and infrastructure.

The Open Group also defined the TOGAF Architecture Development Method (ADM), which was most frequently used as a process capable of modelling enterprise architecture along with the TOGAF Standards Information Base (SIB) for defining methodology and also for business-IT alignment. Other elements used include governance, the ADM’s business architecture, information systems architecture, and technology architecture. However, TOGAF did not include any specific reference to logistic support, other than transition to operation.

2.5Building Information Modelling (BIM)

Eastman et al. [14] provided a guide to Building Information Modelling (BIM) developed by AutoDesk. BIM uses an intelligent model to facilitate coordination, analysis, simulation, project management, asset management, maintenance and operation for the building and infrastructure industry. Aspects of BIM are applicable to support engineering in the form of facilities and asset management. As such BIM could function as part of the overall architectural approach for facilities design, information and services. There is opportunity to apply a similar concept to the defence industry to work on non-defence projects which are similar in scale such as buildings, processing plants, ships and oil rigs.

2.6Architectural needs for support enterprises

The literature review indicates that current architecture frameworks contain, to certain extent, architectural elements for support enterprises. However, their primary focus is on system development and hence there is little or no practice found in literature that current enterprise architecture have been used to model support systems in the same way as the system development cycle.

In US, DoDAF has been included in some large defnece projects such as JSF. In the UK, the Logistic Coherence Information Framework (LCIA) works in line with MoDAF and provides a common set of processes and work products across both Government and Defence Industry, and hence can be regarded as extending to support architecture. In Australia, there does not appear to be any equivalent policy to either UK or US that would either mandate the use of architecture or provide the means of transfer of architectural information between the Government and the Defence Industry suppliers.

4.1Stakeholder analysis

Experience from recent bidding activities shows continued observations that the Support Team and Systems engineering teams work in isolation and information transfer takes place too late in the tender cycle. Consideration of the support solution is included but due to lack of understanding of the implications of performance based contracting, many contracts were made with a lot of risks [19]. Hence, the External Stakeholder analysis was performed as a documentation analysis activity rather than through direct access to these stakeholders. This limitation was mainly because of resource and time limitations on this project (Fig. 1).

Fig.1

Stakeholder Engagement Analysis (Source: created by authors).

Stakeholders that can be identified through this analysis include:

Two other groups of stakeholders are not listed in the analysis but should not be ignored in the architecture:

4.2Project lessons analysis

Project lessons learnt are a set of repositories of Learning-From-Experience (LFE) documents stored on the company central database. These are documented as both “positives” or best practices as well as “negatives” or things to avoid. The intention of these documents is to inform future bids/projects as well as provide input into improvement mechanisms. The following were extracted from the LFE documents:

For complex engineering projects, new product development continues as does the need to support legacy systems. New defence projects either replace existing systems or undergo modification to achieve new capabilities or reduce life cycle cost. Traditionally, Acquisition and Support projects are separated, with the Logistic Support Analysis Report (LSAR) being the key artefact linking the two projects. Where both Acquisition and Support was performed by the same organisation, inadequacies of logistic support data could be remedied by the same organisation. Where they are separated, data deficiencies are exposed and may not be supported by Intellectual Property agreements.

For the purpose of analysis the projects have been categorised into four types to test the adequacy of Systems Engineering and Support engineering capability. Table 2 identifies these four types of projects and their relationships with different types of systems.

4.2.1Developmental mission and support system

Figure 2 depicts a “greenfield” situation where neither the Mission System nor Support Systems exist and are therefore created specifically to meet the capability requirements. In this case there is opportunity to co-develop the Mission System/Support System then establish Support services through-life. An example of this is the F-35 Weapon System sustained through the Autonomic Logistic Information System (ALIS) [20]. For BAE Systems this project type is supported through the application of the complete set of Engineering Life Cycle processes.

Fig.2

Developmental Mission and Support System (Source: created by authors).

4.2.2Off the shelf systems

In the case where there are already systems developed and in service, either as Commercial off the Shelf (COTS) or Military Off the Shelf (MOTS), the entire Mission System and Support Systems are acquired and transitioned into service. This presents capability validation questions as the purpose and use of the existing system may not be exactly the same as the systems were envisaged. This may be simply due to extended supply chains reaching to Australia or differences in the way a system is operated or maintained. In some cases the COTS/MOTS systems require adaptation to the intended environment [21]. Figure 3 depicts an Off-The-Shelf Mission System which has established support systems that were developed as an integral part of the initiating project.

Fig.3

Off-The-Shelf Systems (Source: created by authors).

When such systems are procured by the Australian Government, often through Foreign Military Sales programs these are supported by the bespoke Support System, which is now subjected to the extended supply chain reaching to Australia. While the support solution may be low risk in that it is fully established and operating, use of the service may be mandated as a condition of contract and leave little opportunity for the ADF to apply innovative support solutions. Long supply chains and the fluctuating Australian Dollar may increase rather than reduce support risk over the life of the system. Another difficulty is the continued alignment of future Mission System Upgrades with national capability requirements. Upgrades to systems require access to Intellectual Property (IP), skills and facilities not available in Australia requiring long-term reach-back to host nation Engineering Support. Where the support contract is contracted to the in-country branch of the Prime Contractor, there is an opportunity to transition to Performance Based Contracting.

4.2.3Modified off the shelf systems

Where Design Adaptation requires changes to the baseline design of the mission system, the COTS/MOTS system is modified to meet the capability requirement. Figure 4 presents unique challenges as each system has its own bespoke support system and services.

Fig.4

Modified Off The Shelf Systems (Source: created by authors).

While the integration of the Mission System may be straightforward and relatively low technical risk, integration of philosophically different support concepts presents significant challenges [22]. Where there is segmentation of mission system aligned with support system segmentation this is less challenging such as in the case of an aircraft maintained organically while the engines are subjected to performance based contracts. The more integrated the bespoke support system is with host country support services, the more difficult the challenge of forming a new “integrated support solution” from the constituent support segments. In this situation it is proposed that the existing Mission and Support Systems be “reverse engineered” to the extent required to develop an integrated support solution architecture.

4.3Issues related to systems and support engineering

In addition, the following key issues were identified while analyzing the above architectural features:

Furthermore, the following key issues were identified to be outside of System or Support Engineering:

5.1Architecting the architecture

Large US based programs such as the Joint Strike Fighter (JSF) are mandated to use DoDAF. As previously discussed, since DoDAF is inherently deficient in service system integration, it is difficult to maintain coordination between the development of the product solution and support solution during the tender activity. Hence, existing Architectural Design, which is a supported BMS process, is not well supported with tools/methodology and training, particularly in Support Engineering.

In addition, the customer of BAE Systems Australia is primarily the Australian Department of Defence with most projects contracted through the Capability Acquisition and Sustainment Group (CASG) using tailored versions of the ASDEFCON, which stipulated the content of external deliverables in the form of contract data. CASG produces Operational Concept Documents (OCDs). However this approach focuses on the Mission System Capability rather than Support System or sustainment services. The Core/WSAF Model is not made available to Defence Contractors and “reverse engineering” to expose model relationships is incomplete.

The fundamental principle for changes in commercial environment is to maximize the effectiveness of the outcome while minimizing the impact to the changes. Since DoDAF is a well understood architecture in the company, and has shown effectiveness in the design and development phases of the systems engineering lifecycle, this study extends the DoDAF architectural elements to the proposed Architecture Design framework with consideration of a whole of life concept rather than a phase within the engineering development activity.

The Project Life Cycle may range from full development projects through various combinations of new (greenfield) and existing product and or services (brownfield). It may therefore not be possible to prescribe a single approach to architecture. Not all DoDAF elements are required to extend to the full lifecycle. Table 3 indicates the progression of the architectural elements that are required to be considered across the project life cycle. In this way Architecture can be seen as a continuous activity rather than a front end design activity.

5.2Engineering lifecycle

Projects are expected to tailor the organisational common processes to suit their needs. This is expected to be through the approval of engineering plans. The Systems Engineering processes are defined around the V-Model Engineering Lifecycle. While these may be suitable for “greenfield” development projects they do not meet the needs of “brownfield” projects where segments of both mission and support systems may already exist and require integration and transition to sustainment.

The Commonwealth provided Statement of Work explicitly defines the required engineering phases and mandated reviews. For “brownfield” type projects the use of development oriented phases and reviews requires tailoring for recognition of previously developed product and service.

For service projects performing Engineering Support on developed and fielded systems projects extensive tailoring of process is required. The Engineering Support Process adequately address the range of Engineering process required to perform Engineering as a service.

With change of project types from predominantly new development projects to a mix of new and existing system integrations and service projects, the approach to selection and deployment of Engineering lifecycle should reflect this change through de-emphasising the V-Model approach and forming new project templates based on project characteristic. Alternative engineering life cycles such as the spiral or incremental model should be supported by process, tools and training.

To facilitate the transition to servitisation, the project characterisation should allow for the response to be by the selection of services from the service process library. If product development is required this could be accommodated through the use of a “product development service”. In this way the distinction between a product and service can be applied at the appropriate level of the Work Breakdown Structure.

5.3Support enterprise architecture

The business should establish and maintain an overarching Entrerprise Architecture such as shown in Fig. 5.

Fig.5

Proposed Architectural Approach (Source: created by authors).

The architectural element of this framework considers architecture to be a whole of life concept rather than a phase within the engineering development activity. It is noted that the architecture could be modified and maintained for different priorities at different times in the product lifecycle. The key elements in this architecture are described in the following sections.

5.4Processes design

It is necessary to analyse the processes in order to develop a new architecture that has new processes. Table 4 analyses the relationship between the Systems Engineering and Support Engineering. While these relationships are not explicitly in the definition of the processes, the author has made a logical link to identify the nature if integration required.

To ensure smooth transition, Table 5 is intended to show the alignment of BMS and ASDEFCON organised by ISO15288:2015 Process Area to show the similarities and differences. Gaps in the table indicate areas where the author was unable to align from the literature reviewed.