You are viewing a javascript disabled version of the site. Please enable Javascript for this site to function properly.
Go to headerGo to navigationGo to searchGo to contentsGo to footer
In content section. Select this link to jump to navigation

Architectural design for integrated support of complex engineering projects

Abstract

Defence Projects world-wide are undergoing a gradual transition from development projects to those involving integration of Commercial-Off-The-Shelf (COTS) and Military-Off-The-Shelf (MOTS) Systems. At the same time Requests for Tender (RFT) demands innovative support solutions to reduce Life Cycle Cost (LCC) over thirty years of operation. Increasingly the Defence seeks ‘Value for Money’. While there are defined processes to support both Systems Engineering and Support Engineering, these are hierarchical by engineering discipline and do not provide the means of architecting and trading off system design and support objectives concurrently. This study analyses suitability of existing Systems Engineering and Support Engineering processes with respect to the transformation of a Defence industry enterprise from predominantly engineering development projects to service projects. This transformation is in response to changes in the Defence industry context, where Defence has transitioned from bespoke system acquisition to the integration of COTS and MOTS systems coupled with support for up to 30 years. The study builds a model of the current state process set and artefact relationship and compares these with the international standards against the goals of reduced Life Cycle Cost (LCC). This study identifies the transitional needs and proposes changes to the Enterprise Business Management System processes, tools and work product templates to achieve concurrent system and service solution engineering.

1Introduction

Australian Defence Force Projects are undergoing a gradual transition from procurement of products and services to sustainable solution development aiming at reducing life cycle cost (LCC) over the service life, typically over thirty or more years of operation [1]. While there are defined processes to support both systems engineering and support engineering, these are hierarchical by engineering discipline and do not provide an efficient means of isolated and trading off system design and support objectives concurrently. Often shortfalls of acquisition funding limit the adequacy of the support solution to sustain the system. Robinson et al. [2] discussed 12 problems that the Australian Department of Defence had in the transition from document centric capability development to the application of Defence Architecture Framework. These problems could be consolidated as lack of understanding of how the models in the framework are linked to the defence system lifecycle development.

Current government thinking is to enter into performance based contracts that engage a prime contractor to be fully responsible for managing all relationships with suppliers and sub-contractors [3]. This process requires defence tenderers to submit a set of Operational Concept Documents which is restricted by a defined structure and format. The idea is to focus on producing a coordinated set of information which becomes part of the contract baseline. However, some key information such as support organisation is missing. The effect is that the potential tenderer has to scan and import content into their own system modelling tools in order to propose a viable solution.

Furthermore, research has shown that effectiveness of this type of contracts depends on the relationship and system compatibility between customer and suppliers. For example, due to changes in the government’s procurement process, a large defence company has to transition their enterprise structure to suit [4]. Likewise, the Hobart Class Air Warfare Destroyer (AWD) requires a well-defined support architecture for through life support system due in part to the complexity of the ship and partly due to the large number of stakeholders that need to interact to create an effective support solution for the systems [5]. The enterprise design process aims to mitigate the risk of violating availability and loss of capability of the system being support over the service life of the defence asset. However, there is no dedicated enterprise model for support and sustainment.

This paper discusses an enterprise integration approach to adapting commercial organization internal systems to manage defence related projects in such a volatile environment is a complex and time consuming exercise as it involves multiple stakeholders, an understanding of the processes, determination of the requirements of the organisation and knowledge of available system models for supporting military asset’s 30 years of service life.

2Review of current enterprise models

Enterprise models require an architecture framework to provide the foundation structure and constructs to build. The following literature review focuses on some of the common architectures used in industry and government agencies.

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:

  • Capability

  • Data and information

  • Operational

  • Project

  • Standards

  • Services

  • Systems

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.

3Review of Australain Standards for Defence Contracting

The Australian Standard for Defence Contracting information is published by the Capability and Sustainment Group (CASG) (formerly Defence Materiel Organisation) [15]. The contractual mechanism for defence projects is ASDEFCON. The ASDEFCON suite of projects is organised into a tailored set of templates known as “work products”, each provided with its own guidance for use [16]. These template sets are summarised in Table 1.

Table 1

ASDEFCON Suites of Work Products (Source: Department of Defence [16])

ASDEFCON SuiteDescriptionRelevance to Project
Strategic MaterielHigh risk, software intensive systems with complex integration relating to major platforms or highly developmental systemsMost complex template for large acquisition projects
Complex MaterielProcurements with medium technical risk involving design, development and integration which do not justify the use of ASDEFCON (Strategic Materiel)Reduced set of templates for Acquisition and Support
Support 2.0In-service support services for Defence materiel capabilitiesRelevant to performance based contracting for services
Support ShortProcurement of support services for Defence materiel and equipment where the assessed level of complexity and risk is low to mediumShortened version of ASDEFCON Support
ServicesEngage consultants, professional service providers and other contractors to provide services to DefenceSpecifically for the contracting of professional services – not suited for logistics services
Support Version 3.0 Exposure DraftVersion 3.0 contains significant changes, notably it integrates a full Productivity and Performance-Based Contracting (PPBC)Highly relevant to servitisation Key PPBC concepts Performance and efficiency linked to Award Terms

The objectives of ASDEFCON templates are:

  • a) To engender professionalism of Defence staff by providing tools and guidance for the ongoing development of procurement skills;

  • b) To support the reprioritising of Defence contracting activities by facilitating RFT and contract development and management;

  • c) To standardise and benchmark Defence’s business practices and procedures;

  • d) To improve relationships with industry through the engagement of industry in the development and enhancement of the tendering and contracting templates; and

  • e) To lead contracting reform in Defence by taking into account the use of contracting options and strategies that reward performance.

In response to a tender, the tenderer is responsible for finding the best template for the project proposal. Very often, the processes requested in these templates do not align with the tenderer’s business model. Significant effort is required to adapt to the tender requirements.

There are numerous methods of defining and representing process [17]. The common features of these representations are that they in some way describe activities to varying extents. Unfortunately, ASDEFCON does not define processes. It is up to individual tenderers to interpret and respond. Interestingly, ASDEFCON requests tenderers to provide a list of Data Item Descriptions (DIDs), which contain a range of information covering:

  • Policies,

  • Standards,

  • Dependencies,

  • Tasks,

  • Formats,

  • Checklists.

In this research, the methodology selected to compare processes was the Supplier Input Process Output Customer (SIPOC) method [18]. The extent to which processes are integrated involved the categorisation of the maturity of integration using Integration Readiness Levels (IRLs) by considering the process structure as a system and linkages between processes as interfaces. A SIPOC analysis was performed to identify relationships of ASDEFCON with BAE Systems processes. This is needed as the ASDEFCON templates form the basis of the Contract Data Requirements List (CDRL) on a contract.

Since ASDECON was the customer’s template, it was not feasible to directly relate to the BAE Systems Process. The SIPOC process representation was used to create “process equivalence”. The analysis was performed on a small number of items to determine the extent of linkage between data items. The literature review did not discover any overall architectural framework under which ASDEFCON is defined. This does not mean it is non-existent, but further work may be needed in conjunction with the Department of Defence to establish whether such an architecture exists and whether it is maintained.

4Analysis of support architecture requirements

The Business Management System (BMS) in BAE Systems Australia is based on a combination of Life Cycle Management (LCM) a BAE Systems Project Phase/Gate Methodology, the Australian Standard for Defence Contracting (ASDEFCON) and the System Engineering Life Cycle Model (V-Model) organized by the ISO 15288 Process Areas. This approach considers the primary processes to be those required to produce a Mission System as well as those to develop the Support System. It should be noted that the BAE Systems definition of Product does not differentiate System and Service and it intends that the defined processes support both product and service tenders.

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).

Stakeholder Engagement Analysis (Source: created by authors).

Stakeholders that can be identified through this analysis include:

  • The Warfighter – The user of the defence products is collectively termed the “warfighter” as the front line operator/maintainer/supplier of the product or service system. The warfighters opinions of fitness for purpose may be represented through official defence, political or media channels.

  • Capability Acquisition and Sustainment Group – The Defence Materiel Organisation was the contracting organisation of the Australian Government and managed the contractors such as BAE Systems for all Australian Defence project portfolio.

  • System Project Office – The System Project Office is set up by the Department of Defence to oversee operation and support of a particular type of system, which may have multiple units. Changes of any nature will be initiated by the System Project Office as projects involving commercial contractors.

  • Prime Contractor – The Mission and Support System and its subsystems are acquired by a contract given to the Prime Contractor. The Prime Contractor then subcontract to other contractors to provide allocated subsystems. BAE Systems may perform in the role of either a Prime Contractor or Subcontractor depending on the scope of the project.

  • Original Equipment Manufacturer – The Original Equipment Manufacturer (OEM) is the primary supplier and design authority of the engineering system being acquired. In an acquisition, there may be several engineering systems integrated into a Mission and Support system. The OEM is responsible for the part they supply.

  • Service Providers – Service providers may be engaged as part of the Support Project or already exist as part of an ongoing support arrangement. These service providers require the skills to operate support processes as well as a means of improving their quality etc.

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

  • The General Public – While the general public is not identified as a process stakeholder, the general public and its special interest groups have impact on the operations and support of defence products and services.

  • Internal Stakeholders – Unlike external stakeholders, the internal stakeholders have roles and responsibilities within the organization. These relationships may jeopardize their views on lessons learnt.

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.

Table 2

Analysis of Project Types (Source: created by authors)

CaseMisson systemSupport systemSupport serviceOpportunities
Developmental Mission and Support SystemNew Development Mission SystemNew Development Support SystemNew Support ServiceArchitecture Driven Performance Based
Unmodified MOTSUnmodified Mission SystemUnmodified Support SystemUnmodified Support ServiceLimited by Legacy Arrangements
Modified COTS/MOTSModified COTS/MOTSAdapted Support SystemAdapted Support ServicesReduce Life Cycle cost
Sustainment OnlyExistingExistingInnovative Support SolutionsReduce Support Cost

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).

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).

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

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).

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.2.4Sustainment only projects

There is a class of project where both the Mission and Support Systems are already established and there is a changeover of support contractor. This occurs when the Commonwealth either transitions from Interim Support arrangement to a Through-Life Contract or periodic retendering. In this case the opportunity is to review the existing support system and services and propose innovative solutions to reduce support cost. This is supported by high reliability systems principles for improvements to the Engineering Change Proposals [23].

4.3Issues related to systems and support engineering

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

  • The transition from “Greenfield “project to “Brownfield” projects

  • Transitioning to Model Based System Engineering (MBSE)

  • Transitioning from Functional Methods to Object Oriented Methods

  • Tailoring of Systems Engineering on Projects

  • Cost of developing and maintaining architectural and system models

  • Time constraints on Requests for Tender limiting the ability to perform modelling

  • Lack of architectural approach to support solution

  • Functional and physical architecture slow to evolve – driving late development of the support solution

  • Difficulties in performing logistic analysis for existing systems where data may not be available

  • Reluctance of System Engineers to perform reliability/availability analysis

  • Conflicting support goals and objectives – traditional approach mandated yet innovative solutions expected

  • Consideration of innovative support solutions too late in the tender process to affect product selection decisions

  • Product Breakdown Structures generated during the early bid activities do not adequately cover support solution components

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

  • No overarching Business wide Enterprise Architecture

  • Difficulties performing cross-functional work during bids

  • Lack of a companywide metrics capability

  • Alignment of Work Breakdown Structure (WBS) with Processes

  • Cross functional involvement in Life Cycle Cost Modelling (LCCM)

5Proposed architectural approach

The theoretical frameworks reviewed so far are required to be matched with existing engineering system processes for transitioning. The following section describes the proposed architectural approach managing the implementation.

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.

Table 3

Architecture Lifecycle (Source: created by authors)

Purpose of ArchitectureStrategySolutionTransitionSupport
Manage CapabilityEstablish Capability ArchitectureObtain Capability ArchitectureVerify Capability ArchitectureValidate Capability Architecture
Manage Mission System (Operation)Model Mission SystemModel Mission SystemVerify Mission System ModelMaintain Mission System Model
Manage Support System (Services)Model Support SystemModel Support SystemVerify Support System ModelMaintain Support System Model
Manage Enabling SystemModel Enabling Systems Support ArchitectureModel Support Services Verify Enabling System ModelsValidate Enabling Systems ModelsMaintain Enabling Systems Model

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).

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.3.1Business strategy

The Business Strategy element of this architectural approach is aimed at aligning the enterprise to the business objectives, defence or other business Sevicescape, criteria for making decisions and understanding of assumptions and constraints. These collectively form the basis for ongoing project activities. The business strategy is supported by a Business Model, Business Data and the capability to perform business analysis.

5.3.2Characterisation of existing capabilities

For existing systems the architectural approach is to either integrate existing models or to “reverse engineer” existing products or services to be able to evaluate against the capability architecture. Previous Verification and Validation data is used to determine fit to the capability architecture.

5.3.3Integration

Once characterised and accepted as suitable, the products/services undergo adaptation and integration into the required product-service system. The maturity of this integration is measured through Integration Readiness Levels. Any new development elements are integrated with the adapted elements to form the new systems.

5.3.4Transition into service

The transition into Service utilises Project Views of Architecture to schedule the requisite elements of products and services for deployment and use. At this stage the product-service systems are used in their intended environment and undergo validation against the capability architecture.

5.3.5In service support

Throughout the sustainment period, product and service measures are captured and analysed against the metrics design to support performance based contracting requirements and form the basis of process improvement. Progressively, the capability architecture, system and service models are validated. As changes are undertaken the architecture and models are updated. Any potential change can be modelled prior to commitment to change to ensure changes will contribute to lower life cycle cost.

5.3.6Enabling engineering capability

The architectural approach requires the deployment of architectural frameworks, models and engineering systems as an integrated data system governed by a data schema. This is necessary to ensure interchange of information between the architecture, models and metrics systems.

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.

Table 4

Summary Relationship between System Engineering and Constituent Support Areas (Source: created by authors)

Systems Engineering ProcessTraining SupportEngineering SupportMaintenance SupportOperating SupportSupply Support
Requirements Development and AnalysisTraining RequirementsEngineering Support RequirementsMaintenance RequirementsOperating RequirementsSupply Requirements
Architectural DesignCompetence FrameworkSystem ModelMaintenance ModelOperating ModelSupply Model
Design to CostDesign for Skill OptimisationDesign for ReliabilityDesign for MaintainabilityDesign for OperationOptimise Supply Chain Cost
Technical ImplementationDevelop Training Systems &ServicesDevelop Engineering Support SystemsDevelop Maintenance Systems &ServicesDevelop Operating Support Systems and ServicesEstablish Supply Chains
Technical AcquisitionAcquire Training Systems &ServicesAcquire Engineering Support Systems, Facilities &Test EquipmentAcquire Maintenance Systems, Facilities and ToolsAcquire Operating Support Systems &ServicesOperate Supply Chains to Acquire Products
IntegrationTraining System IntegrationIntegrate Engineering Support Systems &ServicesIntegrate Maintenance Systems &ServicesIntegrate Operating Support Systems and ServicesIntegrate Supply Chains into the Required Solution
Test and EvaluationTraining System VerificationEngineering Support System VerificationMaintenance Support System VerificationOperating Support VerificationVerify and Validate the Supply Chain
Transition and ReleaseTraining Effectiveness DemonstrationEngineering Support DemonstrationMaintenance Support DemonstrationProvide Operational SupportSupply Support Demonstration
Technical MeasurementMeasures of Skills, CompetenciesMeasures of Engineering Support Changes Reliability Obsolescence GrowthMeasures of Maintenance Support MTBF, MTTR,Measures of Operating Support: Availability, Operational EffectivenessMeasures of Supply Support: Pipeline Shortages Wastage

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.

Table 5

Process Alignment (Source: created by authors)

Process AreasISO15288:2015BMSASDEFCON
Agreement ProcessesAcquisitionTechnical AcquisitionAcquisition
Development
SupplySupply Support
SupportSupport
Service
Organizational Project Enabling ProcessesLife Cycle Model ManagementSystem Engineering Management PlanSystem Engineering Management Plan
Infrastructure ManagementFacilities PlanFacilities Plan
Project Portfolio Management
Human Resource Management
Quality ManagementQuality ManagementQuality Plan
Project ProcessesProject PlanningEngineering Project PlanningSystem Engineering Management Plan (SEMP) Integrated Support Plan (ISP)
Project Assessment and ControlProject Monitoring and Control
MeasurementMeasurement
Risk ManagementRisk ManagementRisk Register
Configuration ManagementConfiguration Management Configuration Management SystemConfiguration Management Plan (CMP) Configuration
Information ManagementDesign Documentation System (DDS)Data Management System (DMS)
Decision ManagementJudgement of Significance (JOS)
Technical ProcessesStakeholder Requirements DefinitionOperational Concept Document (OCD) Function and Performance Specification (FPS)
Requirements AnalysisRequirements Development &AnalysisSystem Requirements Review (SRR)
Architectural DesignArchitectural DesignSystem Definition Review (SDR)
ImplementationTechnical ImplementationPreliminary Design Review (PDR) Detailed Design Review (DDR) Logistics Support Analysis Report (LSAR)
Technical Acquisition
IntegrationIntegrationDevelopmental Test and Evaluation (DT&E)
VerificationTest and EvaluationTest Readiness Review (TRR) Acceptance Test and Evaluation (AT&E) Verification Cross Reference Matrix (VCRM)
TransitionTransition and ReleaseAcceptance Test and Evaluation (AT&E) System Acceptance Audit (SAA) Training Readiness Review (TNGRR)
ValidationTransition and ReleaseOperational Test and Evaluation (OT&E) Initial Operating Capability (IOC) Final Operating Capability (FOC)
OperationOperating SupportOperating Support
MaintenanceMaintenance SupportMaintenance Support
DisposalDisposal Plan
Special ProcessesTailoringTailoring

6Conclusion

The proposed architectural approach provides a clear development pathway for migrating existing engineering system processes to a new support system architecture that is complete and adaptable. 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.

While it is expected to be significant variations in Mission System architectures, Support System and Support Service architectures for Defence align with the constituent support capabilities. An architecture template for support, consistent with the ILS Work Breakdown Structure (WBS) would allow current projects to initiate an architected support solution which can be linked to the Mission System architecture. From this early use of support architecture, successive projects could then evolve and improve the architecture to suit typical support solutions.

The Role of Solution Architect needs to be developed and skilled to the point where there are competent persons capable of applying Systems Thinking to the capability problem-space and generate the Product-Service architectural models can be used to support servitisation decisions at the early stages of a project, at least before any design decisions are made.

The proposed architecture for preparation of bids has been approved by company management to try in the next tender opportunity. Information in this paper represents the foundation structure of the new architecture. The outcome will be monitored by company management. Evaluation of the proposed architecture will be done after the new tendering process is complete.

References

[1] 

Mortimer D. , Going to the Next Level - The Report of the Defence Procurement and Sustainment Review, 2008. Pub. on 18 September, 2008. ISBN: 978-0-642-29688-7, 118 pages, available from: http://www.defence.gov.au/publications/mortimerReview.pdf

[2] 

Robinson K. , Tramoundanis D. , Harvey D. , Jones M. and Wilson S. Demonstrating Model-Based Systems Engineering for Specifying Complex Capability, Systems Engineering/Test & Evaluation Conference, Adelaide 2010, 3-5 May, Adelaide, Australia, 2010.

[3] 

Henry R. and Bil C. , Sustainment management in the royal Australian Navy. In transdisciplinary lifecycle analysis of systems, Ed Stjepandić J 1 (2015), 249–258.

[4] 

Mo J.P.T. and Downey K. , System design for transitional aircraft support, International Journal of Network Business Management 6(7) (2014), 45–56.

[5] 

Thompson D. and Mo J.P.T. , Optimum Support System Architecture for Air Warfare Destroyers, 22nd ISPE Concurrent Engineering Conference, 20-23 July, Delft, The Netherlands, 2015.

[6] 

Ertaul L.E. , Enterprise Security Planning with Department of Defense Architectural Framework (DoDAF), Proc. of The 2011 International Conference on Security and Management (SAM’11). LasVegas, Nevada, USA, 2011.

[7] 

CIO, DoD Architecture Framework Version 2.02. US Department of Defence, 2010. from: http://dodcio.defense.gov/Library/DoDArchitectureFramework.aspx, Retrieved Feb 3, 2016

[8] 

Handley H.A.H. , Incorporating the NATO Human View in the DoDAF 2.0 Meta Model, System Engineering 15(1) (2012), 108–117.

[9] 

Dimov A. , Stankov G. and Tagarev T. , Using enterprise architecture models to identify opportunities for improvement of acquisition management, Information and Security, An International Journal 23(2) (2009), 188–203.

[10] 

Jancuzura C. , Evaluation of defence architectures in support of system integration, Journal of Battlefield Technology 12(3) (2009), 9–13.

[11] 

Zhu L. , Staples M. and Nguyen T. , The Need for Software Architecture Evaluation in the Acquisition of Software-Intensive Systems, DSTO-TR-2936, pub. Defence Science and Technology Organisation, Adelaide, Australia, 2014.

[12] 

MoD. MOD Architecture Framework - Defence and armed forces – guidance. Retrieved 10 14, 2015, from https://www.gov.uk/guidance/mod-architecture-framework

[13] 

The Open Group,.TOGAF®, an Open Group standard. 2015. Retrieved Oct 14, 2015, from The Open Group: http://www.opengroup.org/subjectareas/enterprise/togaf

[14] 

Eastman C. , Teicholz P. , Sacks R. , Liston K. , BIM Handbook – A guide to Building Information Modelling for Owners, Managers, Designers, Engineers, and Contractors, pub. John Wiley, 2008, ISBN: 978-0-470-18528-5, 506 pages.

[15] 

Department of Defence, 2016 Defence White Paper, 2016. ISBN: 978-0-9941680 5-4. Available from: http://www.defence.gov.au/whitepaper/Docs/2016-Defence-White-Paper.pdf

[16] 

Department of Defence, Contract Template Selection and Tailoring Guide, 2016. Version 2.1, April, 2016. Available from http://www.defence.gov.au/casg/Multimedia/CTSTG_Version_2_1-9-3879.pdf

[17] 

Li Q. and Wang C. , Process modelling based integration. 13th IFAC Symposium on Information Control Problems in Manufacturing, IFAC Proceedings Volumes, 42(4) (2009), 644–649.

[18] 

Conger S. , Six sigma and business process management. In Handbook on Business Process Management 1, Eds vom Brocke J., Roseman M., pub. Springer-Verlag Berlin Heidelberg, 2015, ISBN 978-3-642-45100-3, pp. 127–146.

[19] 

Bryne T. and Mo J.P.T. , Critical factors for design of successful performance-based contracting environment, Int. J. Agile Systems and Management 8(3/4) (2015), 305–331.

[20] 

Lockheed Martin, Autonomic Logistics Information System (ALIS) – Maintaining and Sustaining Critical F-35 Lightnight II Systems, Product information, 2016, Available from: http://www.lockheedmartin.com.au/content/dam/lockheed/data/gtl/documents/CS00086-55%20(ALIS%20Product%20Card).pdf, viewed 21 December, content/dam/lockheed/data/gtl/documents/CS00086-55%20(ALIS%20Product%20Card).pdf, viewed 21 December, 2016.

[21] 

Sauser B. , Forbes E. , Long M. and McGrory S.E. , Defining an Integration Readiness Level for Defense Acquisition. International Symposium of the International Council on Systems Engineering (INCOSE), 2009, July 20-23, Singapore, 2009.

[22] 

Hilton M. , Troung T. , Homes C. and Ferrige W. , Realising The Benefits of Commercial off The Shelf for Defence Systems. 2014 Australian Defence Engineering Conference (ADEC 1014).. Melbourne, Australia: Engineers Australia, 2014.

[23] 

Zeuschner M. and Mo J.P.T. , Transformation pathway to high reliability support service system, Journal of Aerospace Operations 3 (2015), 125–146.