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 Suite | Description | Relevance to Project |
Strategic Materiel | High risk, software intensive systems with complex integration relating to major platforms or highly developmental systems | Most complex template for large acquisition projects |
Complex Materiel | Procurements 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.0 | In-service support services for Defence materiel capabilities | Relevant to performance based contracting for services |
Support Short | Procurement of support services for Defence materiel and equipment where the assessed level of complexity and risk is low to medium | Shortened version of ASDEFCON Support |
Services | Engage consultants, professional service providers and other contractors to provide services to Defence | Specifically for the contracting of professional services – not suited for logistics services |
Support Version 3.0 Exposure Draft | Version 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) and 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
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
Case | Misson system | Support system | Support service | Opportunities |
Developmental Mission and Support System | New Development Mission System | New Development Support System | New Support Service | Architecture Driven Performance Based |
Unmodified MOTS | Unmodified Mission System | Unmodified Support System | Unmodified Support Service | Limited by Legacy Arrangements |
Modified COTS/MOTS | Modified COTS/MOTS | Adapted Support System | Adapted Support Services | Reduce Life Cycle cost |
Sustainment Only | Existing | Existing | Innovative Support Solutions | Reduce 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
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
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
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
Purpose of Architecture | Strategy | Solution | Transition | Support |
Manage Capability | Establish Capability Architecture | Obtain Capability Architecture | Verify Capability Architecture | Validate Capability Architecture |
Manage Mission System (Operation) | Model Mission System | Model Mission System | Verify Mission System Model | Maintain Mission System Model |
Manage Support System (Services) | Model Support System | Model Support System | Verify Support System Model | Maintain Support System Model |
Manage Enabling System | Model Enabling Systems Support Architecture | Model Support Services Verify Enabling System Models | Validate Enabling Systems Models | Maintain 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
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
Systems Engineering Process | Training Support | Engineering Support | Maintenance Support | Operating Support | Supply Support |
Requirements Development and Analysis | Training Requirements | Engineering Support Requirements | Maintenance Requirements | Operating Requirements | Supply Requirements |
Architectural Design | Competence Framework | System Model | Maintenance Model | Operating Model | Supply Model |
Design to Cost | Design for Skill Optimisation | Design for Reliability | Design for Maintainability | Design for Operation | Optimise Supply Chain Cost |
Technical Implementation | Develop Training Systems &Services | Develop Engineering Support Systems | Develop Maintenance Systems &Services | Develop Operating Support Systems and Services | Establish Supply Chains |
Technical Acquisition | Acquire Training Systems &Services | Acquire Engineering Support Systems, Facilities &Test Equipment | Acquire Maintenance Systems, Facilities and Tools | Acquire Operating Support Systems &Services | Operate Supply Chains to Acquire Products |
Integration | Training System Integration | Integrate Engineering Support Systems &Services | Integrate Maintenance Systems &Services | Integrate Operating Support Systems and Services | Integrate Supply Chains into the Required Solution |
Test and Evaluation | Training System Verification | Engineering Support System Verification | Maintenance Support System Verification | Operating Support Verification | Verify and Validate the Supply Chain |
Transition and Release | Training Effectiveness Demonstration | Engineering Support Demonstration | Maintenance Support Demonstration | Provide Operational Support | Supply Support Demonstration |
Technical Measurement | Measures of Skills, Competencies | Measures of Engineering Support Changes Reliability Obsolescence Growth | Measures of Maintenance Support MTBF, MTTR, | Measures of Operating Support: Availability, Operational Effectiveness | Measures 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 Areas | ISO15288:2015 | BMS | ASDEFCON |
Agreement Processes | Acquisition | Technical Acquisition | Acquisition |
Development | |||
Supply | Supply Support | ||
Support | Support | ||
Service | |||
Organizational Project Enabling Processes | Life Cycle Model Management | System Engineering Management Plan | System Engineering Management Plan |
Infrastructure Management | Facilities Plan | Facilities Plan | |
Project Portfolio Management | |||
Human Resource Management | |||
Quality Management | Quality Management | Quality Plan | |
Project Processes | Project Planning | Engineering Project Planning | System Engineering Management Plan (SEMP) Integrated Support Plan (ISP) |
Project Assessment and Control | Project Monitoring and Control | ||
Measurement | Measurement | ||
Risk Management | Risk Management | Risk Register | |
Configuration Management | Configuration Management Configuration Management System | Configuration Management Plan (CMP) Configuration | |
Information Management | Design Documentation System (DDS) | Data Management System (DMS) | |
Decision Management | Judgement of Significance (JOS) | ||
Technical Processes | Stakeholder Requirements Definition | Operational Concept Document (OCD) Function and Performance Specification (FPS) | |
Requirements Analysis | Requirements Development &Analysis | System Requirements Review (SRR) | |
Architectural Design | Architectural Design | System Definition Review (SDR) | |
Implementation | Technical Implementation | Preliminary Design Review (PDR) Detailed Design Review (DDR) Logistics Support Analysis Report (LSAR) | |
Technical Acquisition | |||
Integration | Integration | Developmental Test and Evaluation (DT&E) | |
Verification | Test and Evaluation | Test Readiness Review (TRR) Acceptance Test and Evaluation (AT&E) Verification Cross Reference Matrix (VCRM) | |
Transition | Transition and Release | Acceptance Test and Evaluation (AT&E) System Acceptance Audit (SAA) Training Readiness Review (TNGRR) | |
Validation | Transition and Release | Operational Test and Evaluation (OT&E) Initial Operating Capability (IOC) Final Operating Capability (FOC) | |
Operation | Operating Support | Operating Support | |
Maintenance | Maintenance Support | Maintenance Support | |
Disposal | Disposal Plan | ||
Special Processes | Tailoring | Tailoring |
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. |