New flexible IT infrastructure

A Note to The Reader

This section describes the purpose behind implementation of a new IT infrastructure and a new IT architecture with product and information domains. The continuous technical development in the IT field affects the company’s IT infrastructure multiple times during a product’s life cycle regarding military fighter aircraft. This makes it especially important to be able to separate product information from different system development environments.

It must be ensured that the IT infrastructure is sufficiently flexible, effective and robust to handle changes when new IT capabilities are implemented. Moreover, changed business and operational requirements will constantly place challenging demands on IT support.

Background

During the mid-2000s the business area was facing new challenges in initiating large-scale collaboration with international partners.

With Saab's engagement in the Neuron Project in the mid-2000s, a secure and cost-effective solution was required for information exchange with international partners.

This necessitated changes to the existing IT infrastructure to enable effective collaboration with many different partners, and at the same time, fulfilment of all security and confidentiality requirements.

Recommended reading

The author recommends the following texts that relate to this story: In chapter Having a low life cycle cost under the heading Challenging changes in production in chapter Adaptability for new requirements under the heading Creative engineering capabilies – MBD and in chapter Keeping unique development skills under the heading Agile methods in software development.

This section concerns the marked areas in A Journey of Change in the Aircraft Industry

Summary

Until the end of the 1990s, the IT environments were developed based on a single-customer perspective with the focus on the Gripen product. The business strategy was thereafter changed with initiatives for several products and customers.

This entailed that the IT infrastructure that constituted the backbone of the entire IT environment also had to reflect this change, specifically the capability for being able to separate all product information by product and customer. Moreover, all security and confidentiality requirements from the authorities and various customers had to be met. The conditions for development and sales of the Gripen were expected to undergo significant changes during the years 2000–2015.

The purpose of implementing a new IT infrastructure and IT architecture with product and information domains was to gather product data by product family throughout an entire product life cycle. This orientation was necessary for being able to reduce life cycle costs for products, and of special interest, was the capability to support parallel product development for several customers.

Description of content

  • When a new business orientation in the business area required more flexible working procedures in the mid-2000s, the fundamental IT infrastructure had to be changed.
  • This necessitated changes to the existing IT infrastructure to enable effective collaboration with many different partners, and at the same time, fulfilment of all security and confidentiality requirements.
  • It was thus necessary to secure structured access to all information. The existing IT environment also needed to be further developed to support future product development operations.
  • With a product domain concept, it would also be possible to create an IT platform that gave users access to computers with special security protection.
  • The GRIDE Project was conducted during the years 2009–2013 and was preceded by an investigative phase in 2008. The project was configured with deliveries of three versions of the GRIDE concept.
  • With the GRIDE concept's implementation, a new upgraded IT environment was attained.
  • Conducting an infrastructure project over a five-year period places major demands on project management. By the project being well organised and pragmatically managed, the problems that arose could be overcome.

Background – New Business Orientation Changes It

Until the end of the 1990s, Saab's IT environments were developed based on a single-customer perspective with the focus on the Gripen product. The business strategy was thereafter changed with initiatives for several products and customers.

This entailed that the IT infrastructure that constituted the backbone of the entire IT environment also had to reflect this change, specifically the capability for being able to separate all product information by product and customer. Moreover, all security and confidentiality requirements from the authorities and various customers had to be met.

All information related to products and development was previously arranged by the line organisation’s areas of expertise, instead of being related to the respective products. The product information was handled in a number of different computer environments, making it difficult to implement a common working procedure that would facilitate personnel moves to new product projects. This limitation in flexibility from a product perspective entailed high costs.

The continuous technical development in the IT field affects the company’s IT infrastructure multiple times during a product’s life cycle regarding military fighter aircraft. This makes it especially important to be able to separate product information from different system development environments. It must thus be ensured that the IT infrastructure is sufficiently flexible, effective and robust to handle changes when new IT systems are implemented.

This places considerable demands on how the architecture is built for an IT infrastructure, since it must be possible to handle product data based on product life cycles that are commonly 30–40 years in length. Changed business and operational requirements will also constantly place challenging demands on IT support, requiring all information to be separated based on its confidentiality classification.

The IT infrastructure is therefore structurally configured both with IT environments that contain classified military information (referred to here as Red IT Environments) and company restricted information (referred to here as Yellow IT Environments).

Demands on security and confidentiality must be handled within an IT infrastructure so that the following factors are taken into consideration:

  1. Security requirements in the form of protective requirements entail that the information may not be altered, destroyed or lost due to unauthorised access, technical faults, errors in handling, errors during conversion/migration or other physical events such as fire, flooding, etc.
  2. Confidentiality requirements are established by restricting requirements regarding who will be able to access information with consideration to the consequences of the information becoming available to unauthorised parties.

Increased International Collaboration – Administering Regulatory Requirements

The business area was facing new challenges in the mid-2000s in initiating large-scale collaboration with international partners.

With Saab's involvement in the Neuron Project in the mid-2000s, a secure and cost-effective solution was required for information exchange with international partners.

This necessitated changes to the existing IT infrastructure to enable effective collaboration with many different partners, and at the same time, fulfilment of all security and confidentiality requirements.

The government agencies that issue various operational permits to Saab require that Saab must be able to demonstrate that product information can be separated for all products and customers, as well as for all partners. There must be complete control of where the classified military information is stored. An IT infrastructure must be configured so that all security requirements can be fulfilled.

This necessitated the implementation of a number of new security mechanisms in the IT infrastructure. One way of resolving this was to create functions for role-controlled authorisation, but this would then require logging in for traceability reasons. Resolving the problem of user authentication consequently became a significant boundary condition.

To obtain effective working procedures, it is necessary to configure these procedures with as much balance as possible between simplicity and flexibility, and at the same time, complying with the requirements for security and confidentiality. To achieve high security, IT systems, environments and IT infrastructures must be configured so that the requirements for security and confidentiality are satisfied, but this also requires that users’ demands for simplicity are satisfied in the system design.

Working procedures and functions must be found for cost effectively interacting with various partners in development projects. Moreover, standardised working procedures are needed to enable prompt starts in partner collaboration. It must be easy to separate the information required for a specific partner collaborative project from other information.

The conditions for development and sales of the Gripen were expected to undergo significant changes in the years 2000–2015. When the assessment was made in 2008 that the IT environment required change, the scenario described in the figure below was employed.

The IT architecture had to be built with a modular approach. The reason for this was that consideration had to be taken to new opportunities for renewing the technology and increasing capacity. Extensive changes should not be needed that would negatively affect productivity in another part of the organisation.

Business Area's Operational Development Plan Oriented To Model-Based Working Procedures

Within the framework of Saab’s 7-year, long-term operational development plan, there was also an IT plan. Important parts of the IT plan called for implementation of various rationalisation and streamlining measures. To accomplish this, a flexible and scalable IT infrastructure had to be developed that would assure structured access to all information. The existing IT environment also needed to be further developed to support future product development operations.

To achieve reasonable cost levels, extensive streamlining within the IT organisation was also necessary.

At the beginning of the 2000s, system developers had begun working with model-based systems engineering (MBSE). At the same time, work was underway with implementing a model-based working procedure in the structural engineering technology area, MBD (Model Based Definition). In both cases, streamlining of information and value streams was needed, which entailed that product information must be kept together through a product’s life cycle.

The MBD working procedure was later successfully implemented in the Neuron Project.

ODIN – Creating a sustainably lower cost level

The goal was to implement a new service structure for IT to obtain improved control of IT costs, and at the same time, reduce administrative costs.

To reduce the costs for the entire IT organisation and to establish a sustainably lower cost level, a rationalisation programme was conducted during 2004–2006 called ODIN.

Within the framework of this programme a new control model was established in the IT organisation to ensure long-term higher efficiency. This higher efficiency could be attained by ensuring that all IT investments could be steered to the areas with clear added value for Saab's business operations. Moreover, a number of larger cost efficiency measures were taken in the ODIN Programme for the IT environments and IT services that were procured from various IT vendors.

Adapting IT environments – for international collaboration

This roadmap included the following:

  • Efficiency in control of IT operations with reduced overall costs for product-related IT administration.
  • Replacement of the organisation-oriented IT environment with a product-oriented IT environment.
  • Creation of a scalable and modular IT infrastructure for product data to streamline collaboration with partners and suppliers.
  • Investigation of how applicable security requirements affect implementation of role-based working procedures. Special study of mechanisms for ensuring that users could access the information needed for their work, but no other information.
  • Creation of a verification environment for product-related IT operations for the purpose of being able to study, evaluate and test new IT solutions for product development.

One of the fundamental projects was preparation of a product domain concept.

Product domains – IT environments for product development

Development of product domains was started in conjunction with Saab needing an IT environment for administering all information that concerned the Neuron Project. A development environment was created for the Neuron Project that was included in a product domain intended for unmanned vehicles. This domain was called SUAVE.

The development environment was the first step in developing a new IT infrastructure and product domain concept. It was later further developed to embrace all development and production environments for products. The focus on developing the product domain concept however, was oriented to the Gripen product, although the concept can be applied to any product of sufficient size.

Business and operational benefits – Reducing life cycle costs for products

The purpose behind creating a new IT architecture with product and information domains was to gather product data by product family throughout an entire product life cycle. This orientation was necessary for being able to reduce product life cycle costs. Of special significance was the capability to support parallel product development for multiple customers.

Another important orientation was structuring information so that access would be role-based. This is essential from an information security perspective.

With the orientation to increased international collaboration with various types of partners, the requirement arose for being able to support work at remote sites and collaboration with several partners. For this to be feasible from the security perspective, among other things, all external communications must be encrypted.

Strategic Orientation to It – Flexibility for Future Working Procedures

At the beginning of the 2000s, it became more apparent as to which concepts would be essential for IT in the years to come. One important concept with a new IT infrastructure was the ability to work virtually. Explanations of these essential concepts are defined below; see Note 1.

Note 1 – Virtualisation, a technique for distributing a single computer's resources, often the CPU, to several simultaneous applications. By permitting a physical server to handle several operating systems at the same time, server power can be more optimally distributed between servers to reduce redundancy and to significantly increase availability. Modern server hardware is sufficiently powerful to install more than 20 servers on one and the same computer. With the help of software, the virtual machines can be transparently moved from one physical server to another without interrupting operations.

With a product domain concept, it would also be possible to create an IT platform that gave users access to computers with special security protection.

The concept includes two different types of computers. For one type, the user has access to an own CPU. These computers are designated as protected fat clients and are only used for specific tasks and by a limited number of users.

The majority of users receive computers with special security protection, with the users storing their information and software in a server-based IT environment. These computers are called thin clients and are used in a virtual IT environment that works with centrally located computers (servers). This entails that no information can be locally stored by users. In the virtual IT environment, all tools, systems and information the users need are made available under the condition that the user has the appropriate role authorisation.

Note 2 – A production domain is a specific IT environment in a separate virtual network with the domain being isolated from the IT environment that contains product-common information for multiple products. A domain is equipped with basic functions such as directory services, email, meeting systems, etc.

In certain systems where work is conducted with graphic design, virtualisation utilises a thin graphics solution, with graphics cards on servers instead of on clients.

In creating a new IT infrastructure, strategic work was conducted that defined general frameworks/rules for how the product domains would be built. This produced guidelines for how role-based access to product information would be created.

Note 3 – A virtual infrastructure is a layer located between the physical hardware and the operating systems. Several different operating systems can be run isolated from each other on the same hardware.

Cost reductions – with virtual infrastructure

A virtual infrastructure simplifies use so that companies achieve maximum benefit from their storage units, servers and network resources at the same time as costs are reduced.

With a virtual infrastructure, users see software, systems, servers and functions as usual, while the administrators can handle IT resources in a very effective manner.

IT vendors gain the capability to more quickly fulfil requirements from business organisations, and can more easily administer and allocate resources to where they are needed for various services. A data centre can be seen as a pool of processing power and storage surfaces.

New servers can be deployed in minutes instead of days. There are no interruptions for hardware maintenance and resources can be dynamically allocated. These are significant characteristics for substantially improving accessibility and performance, as well as the overall efficiency of an IT infrastructure.

Product domain concept, 2008–2015 – Implementing GRIDE

A project plan for implementing a product domain concept was prepared in 2008. The plan encompassed changes from 2008 to 2015 and was based on assessments of future business scenarios. Because the product domain concept was primarily oriented to the Gripen product, the concept now developed was called GRIDE (GRIpen Development Environment), which was also the name of the project that would implement the product domain concept. This project subsequently created an effective development environment for continued Gripen development.

The requirement was for an IT infrastructure that could administer and separate classified military information from company information in a more cost-effective manner.

The GRIDE Project was scheduled to start in 2009.

City Plan – Development of new IT infrastructure

To be able to build a new IT infrastructure and manage all the previously mentioned requirements, a strategic plan was prepared. This plan was called the City Plan. Preparation of the City Plan was intended to describe an IT infrastructural architecture and a plan of action for creating an effective, flexible and controlled flow of information throughout the product life cycle. This in turn required being able to separate and administer information in the product domains. This consequently necessitated a survey of the functionality, performance and flexibility of the existing IT environments and IT infrastructure.

Preparation of the City Plan was also needed to realise model-based working procedures such as MBSE.

The City Plan described step-by-step, how a new IT infrastructure would be developed. Significant parts of the plan were constituted by descriptions and the orientation for building domains for products, resources (general services and systems) and clients for use both by Saab and partners. To simplify administration, special resources were created that included general services and systems. There was potential for major savings with this arrangement, both with regards to efficiency and security.

As defined in the City Plan, a line- and organisation-dependent product environment would be created that was independent of the physical location of the IT environment and the users’ geographical position. Performance, security and so forth were also defined.

The City Plan also provided an orientation for how communications networks were to be built and how interoperability would function, as well as how various types of security matters were handled.

Experiences from development of the Gripen Demo technology demonstrator would be used as input for developing future working procedures, development environments and IT tools.

Departure point 2008 – Existing IT environments

To assess the difficulties and feasibility in such an extensive project as changing an IT infrastructure, an inventory and analysis were conducted of the existing infrastructure.

The analysis was specially oriented to the parts of the IT infrastructure that handled defence confidentiality. These parts were called Red IT Environments and encompassed domains (areas) that had been created based on organisational or functional needs.

In Red IT Environments, there were domains in the form of system development environments that were used by 12 different technology areas. Additionally, there were domains for simulator operations and system testing.

Parts of the existing CAD environment, client environments and various types of communications services would also be changed.

The IT environment was comprised of 3,400 accounts belonging to 1,800 users.

Conceptual diagrams – for development of the product domain concept

In preparation for the project launch, a number of conceptual diagrams were prepared to define several primary activities and goals for the various development steps. The idea was to develop a product domain concept in steps. The project that would realise the product domain concept was based on the conceptual diagrams.

The basic technology produced for SUAVE was later further developed in the GRIDE concept. The development of SUAVE became a pilot installation that constituted the basis for development of the GRIDE concept, with the SUAVE domain handling all information and all services required during the products’ life cycles.

The schedule for implementing the GRIDE concept was very aggressive.

Departure point assessment – 2008

The departure point was that information needed to be separated into domains in a new way to make work more efficient. A domain handles all information and all services required for the respective products’ life cycles. Another especially important measure was developing domains for model-based systems engineering (MBSE) to handle information in value streams.

The concept also included developing a test domain. In a test domain, system developers gain access to a slimmed but complete copy of the production environment for testing and evaluating new working procedures and IT tools.

To be able to make these substantial changes in the IT infrastructure, it was necessary to begin using a new administrative methodology for handling all IT environments. The methodology was ITIL (Information Technology Infrastructure Library), which contain detailed descriptions of how various IT related tasks can be conducted.

Targets – for development of the product domain concept

To implement the product domain concept and make the changes in the existing IT infrastructure, it was necessary to define a number of targets to conduct the change project. For development of the GRIDE product domain, four targets were defined.

Target 2009 – Product domains begin to take form

  1. Completion of a City Plan with a roadmap of the IT infrastructure’s development.
  2. Completion of migration and phase-out plans for domains in the Red IT Environment.
  3. Creation of information structure for simple and secure access to information with product domains.

Target 2010 – New requirements for IT vendors

  1. Establishment of a general partner portal for information exchange and collaboration between various partners, with virtualisation.
  2. Launch of resource and product domains, consequently creating an information structure that meets future demands for collaborative and client capabilities.
  3. Creation of requirement specifications for providers of IT administration and operational services from a function perspective, but chiefly from a comprehensive perspective.

Target 2012 – Product domains implemented

  1. Full implementation of the product domains. Information can now be handled with the focus on good business practices and security as viewed from a life cycle perspective. Methodology, tools and techniques are configured to enable cost-effective and flexible working procedures.
  2. The prerequisites for ISO 20000 certification are clarified and an “information factory” is created that is independent of a physical platform.
  3. Providers of IT services and resources are included as a part of Saab's portfolio of services and products.

Target 2015 – Flexibility and scalability

  1. Product domains constitute a standardised concept that is included in the working procedures.
  2. There is a flexible configuration of IT systems and information with virtual access to these systems. Information is connected to the product and can be made available to all authorised persons.
  3. Costs for using IT services are based on usage (variable costs). There is a flexible IT infrastructure that can meet external demands for change in a sound and business-like manner.

Gride Project

The GRIDE Project was tasked with developing an effective IT infrastructure, with the GRIDE product domain being used in continued Gripen development. The basis for the product domain was defined in the City Plan for the IT infrastructure and developed incrementally in five different stages. To facilitate the changes, these were implemented by technology area.

The changes affected all IT environments, both those that contained classified military information and those that handled company restricted information. The GRIDE Project thus affected all types of information classifications, which in turn made it necessary for the IT system to either be given a different structure or be moved. The network topology in the IT infrastructure was consequently affected and creating fewer information domains became an important goal.

The GRIDE Project therefore conducted a survey of how information was classified in order to change the entire IT infrastructure. The IT environments that were affected mostly concerned operations in production, development, calculation, simulation and testing.

Project scope – Implementation in stages

The scope of the various stages was as set out below, presented with the number of persons or user accounts:

  • Stage 1 – 70
  • Stage 2 – 500
  • Stage 3 – 750
  • Stage 4 – 200
  • Stage 5 – 400

Examples of necessary changes were:

  • Moving users
  • Moving data storage capacity
  • Moving calculation resources between different networks and domains
  • Creating new product domains
  • Implementing new IT services
  • Phasing out old system development environments
  • Moving data and information to new hardware

This entailed that a large number of very extensive and time-consuming activities were conducted.

Project targets – Principle diagram

The GRIDE product domain was built in a new network structure with components in accordance with the principles defined in the City Plan.

At Saab, there are several product domains, resource domains, administrative domains and client domains for the internal product network. Partners have a corresponding domain structure but the number of domains depends on needs. To secure communications there are encrypted connections, such as dedicated links or connections via the Internet. For communications with group-wide systems and services, one-way terminal traffic is used to these systems and services and one-way file transmission from them.

Scalable concept – Role-steered authorisation

The GRIDE Project created common authorisation management with role-steered authorisation. It is based on a new general information structure and a new concept for data storage. The entire concept is expandable and scalable so that area-specific systems can be easily added.

The GRIDE Project entailed a very big change to development and production environments, both in the way of handling information and for how information was to be structured and classified.

Investments were made in modern hardware – a 10 Gbit network for improved broadband and better communications between server clusters. Due to the rapid rate of technological development in IT, replacement of these networks began as early as 2014. The networks were then upgraded to a capacity of 40 Gbit.

GRIDE Project – Prerequisites

The demands on the GRIDE Project were substantial due to the project’s scope, the considerable complexity as well as the aggressive schedule. The project's allocated budget was heavily influenced by the technology choices. This led to a decision for a technical solution for data storage that was advantageous both from the price and function perspectives. As it turned out however, the system was not yet a fully developed and sufficiently mature product.

In planning the changes to the IT environment, responsibility was delegated so that the GRIDE Project was responsible for the different versions of GRIDE in the Red and Yellow IT Environments.

The various technology areas in development operations were responsible for implementing a number or operational-related tasks. These were as follows:

  • Inventory and classification of information
  • Inventory of requisite IT tools
  • Survey of roles and authorisations
  • Migration of information and IT tools

The subprojects in GRIDE were as follows:

  1. IT project with new IT infrastructure for Red and Yellow IT Environments
  2. Information inventory/information management
  3. Survey as well as installation and testing of IT tools
  4. Subproject for IT security
  5. Subproject for roles and authorisations
  6. Subproject for training and administration

It was decided that all product data would have a uniform file structure. For information associated with the Gripen, this entailed that the materiel group structure would fully reflect the product structure. This decision also facilitated information inventory and migration, and it increased information security.

Important activities – Collaboration between the line organisation and GRIDE Project

The GRIDE Project provided considerable support to the organisations when inventorying information with regards to which information existed, where it was located and whether it was correctly classified. In conjunction with this, a survey was made of how the information was structured, and what was important for being able to classify information and to later be able to allocate appropriate roles and authorisations.

To enable information restructuring, each operational area was given responsibility for surveying how information was classified within its own area of operations. They were also charged with migrating this information to the new structure. In collaboration with each organisation, the GRIDE Project conducted extensive function and performance tests after all data/information had been migrated. Each operational area had primary responsibility for these function tests.

The GRIDE Project also performed inventories of which IT tools and systems were used and investigated whether they could be phased out or replaced.

Service structure in a product domain

The figure illustrates the common services that can be accessed by a product domain.

Execution of gride project – 2008–2013

The GRIDE Project began with an investigative phase during 2008. The project continued through the years 2009–2013 and was structured with deliveries in three versions of the GRIDE concept.

For this, the line organisation funded the parts that it was normally responsible for, such as information classification and information migration. The administrative organisation for the IT environment funded among other things, replacement and installation of equipment.

The investigative phase underway during 2008 defined the product domain concept. General frameworks/regulations were specified for how product domains would be configured and made ready in a first edition. The investigation was completed and the results presented in a general strategic plan for development of the GRIDE product domain.

Various investigations were also initiated that were essential for the GRIDE concept. These investigations concerned the following:

  • Networks
  • Role-based authorisation management
  • Information management
  • Terminal server concept for remote access.

Deliveries, 2009

Decisions

Important strategic development and investment decisions were made. The most important decisions concerned common authorisation management with implementation of role-steered authorisation. It was also decided to implement a general information structure. For information and authorisation management, an information inventory was performed in which a role matrix was produced. The entire information structure was completed and decisions were made on design and implementation.

The decision was also made to invest in a new type of data storage. The technical solution for data storage had not yet been fully tested at this point, which entailed a number of problems that delayed information migration.

Security

At the IT security function, assessments were made of present and future threats. Based on this, the requisite security goals were defined for the entire GRIDE concept. Preparation of the security goals was one of the most important criteria in the general accreditation documentation that was produced in order to gain the approval of the authorities for the GRIDE concept.

Development and results

A system and tool inventory was also conducted in which all IT tools for version 1 were tested and verified, and certain new software was installed. The documentation for administration was completed, including administrative directives and training materials.

New activities

The GRIDE Project had to deal with extensive activity that was not planned for in the original delivery plan. This concerned production of a new communications solutions and development environments for Saab's partner Akaer in Brazil. Akaer was responsible for structural engineering in the airframe design technology area in which CAD systems were used.

Deliveries, 2010

Security

Security accreditation and approval of the GRIDE concept were received, permitting administrative directives for the GRIDE version 2 product domain to be completed. Other activities conducted were information inventories, information classification and preparation of migration plans. Within the framework of these activities, a risk inventory was also performed.

Development and results

An external communications solution in the form of a link connection to Akaer was commissioned in January. The first version of the GRIDE product domain with classified military information was commissioned and transferred to administration in April. An administrative domain was also commissioned in the IT infrastructure. The majority of activities in the CAD environment were completed, including establishment of a resource domain for CAD – Mechanics.

Migration of information and IT tools continued during the year, and various types of user tests and commissioning activities were conducted. The concerned technology areas were:

  • Avionics
  • Tactical Systems
  • Airframe Design
  • Basic Aircraft Systems
  • Strength and Structural Analysis
  • Aeronautics

New activities

To resolve the technical problems that arose in the data storage concept, it was decided in 2009 to implement a more proven concept. The original concept was retained however, for certain applications. Improvements were made to the original data storage concept, but some problems remained for a period of time.

Deliveries, 2011

Development and results

The communications solution for the partner Akaer in Brazil was upgraded with approved results and commissioned in May.

The first version of the GRIDE product domain with company restricted information was commissioned at the beginning of the year and transferred to administration. An upgraded second version was completed and transferred to administration, and the first version of the IT environment for CAD – Mechanics was commissioned.

This entailed that approximately 200 designers could now begin working in the environment and could analyse test data for the Gripen 39-7 test aircraft.

Migration of information and IT tools continued during the year, and various types of user tests and commissioning activities were conducted. The concerned technology areas were:

  • Aeronautics
  • Basic Aircraft Systems

Deliveries, 2012

Decisions

It was decided that the GRIDE Project would be concluded in 2013.

Development and results

Migration of information and IT tools continued during the year, and various types of user tests and commissioning activities were conducted. The concerned technology areas were:

  • Structural Engineering
  • Tactical Systems
  • Weapons Integration
  • System Integration
  • Aeronautics
  • Flight Testing
  • HMI & Avionics

The operations related to the Gripen E product project were now fully migrated to the GRIDE product domain.

New activities

A pilot study was conducted for building a test domain for system development. Work with the construction and development environments for the MySim NG testing environment was included in the GRIDE Project.

Deliveries, 2013

Security

Modern hardware was installed in all IT environments, which resulted in virtualisation and the thin graphics solution now being used in day-to-day work. There was now also a common system solution for authorisation management with role-steered authorisation. The general information structure for the entire concept was established.

Development and results

The entire basic IT infrastructure for the GRIDE production domain was completed and commissioned, both for IT environments that handle classified military information and company restricted information.

Migration of information and IT tools continued during the year, and various types of user tests and commissioning activities were conducted. The concerned technology areas were:

  • Structural Engineering
  • Tactical Systems
  • Weapons Integration
  • System Integration

Moreover, a number of product and resource domains were commissioned for several other operational areas.

New activities

The administrative organisation for GRIDE took over all activities and responsibilities for long-term planning of the GRIDE concept. A roadmap for future development of the GRIDE concept was prepared.

Final results from GRIDE Project – Good results with incremental development and successive implementation

With the implementation of the GRIDE concept, a new upgraded IT environment was gained that kept pace with technological developments and the more stringent operational requirements that evolved over the years. The GRIDE concept was successively implemented with constant improvements to availability and performance in the different GRIDE versions.

Through incremental development of the GRIDE concept, information could be consolidated in the product domains within the business area. Implementation of the GRIDE concept has also recently begun in other parts of the group for Red IT Environments.

Through an upgrade of the IT environment, both increased flexibility and increased security were obtained.

A module-based IT architecture had now been created with a virtualised IT environment. It is also scalable to enable simple and cost-effective compliance with new needs for increased performance.

Experiences – and success factors

Good collaborative forms between the GRIDE Project and the various technology areas enabled development and streamlining of existing working methodologies within several technology areas. A better understanding was also gained of how the balance between computer power, good methodology and effective software should be handled. A different configuration for management of the technology areas’ work with migration of information would have been preferable, since the implementation period was excessively long.

Success factors for achieving the good results were that:

  1. The pilot project (SUAVE) was conducted. In the pilot project both the technical concept and forms of working with the technology areas and product projects could be evaluated.
  2. Staff rotation in the steering groups based on the needs for support, expertise and experience. Consideration was then taken to the relevant project phase and to which technology areas or product projects were affected.
  3. Collaborative forms were adapted with the different technology areas based on their prerequisites.
  4. Project participants had extensive experience from previous infrastructural IT projects.
  5. The methodology used for inventory of IT tools was very well prepared. The entire flow could be managed, from inventory and installation to testing.
  6. Work with security was an integrated part from the start of the project.

Analysis

Conducting an infrastructure project over a five-year period places substantial demands on project management. It was unique for an IT project that the functions defined at the start of the project could be delivered at a cost that was 84 percent of what was originally calculated. This is especially noteworthy in consideration to the project's complexity, which for a period, had significant problems with the data storage concept.

By the project being well organised and pragmatically managed, the problems that arose could be overcome.

Personnel resources – How were they secured?

Other problems that arose during the project were mainly due to a lack of personnel resources. This affected certain schedules, especially for migration of information.

This is often a problem in many capability development projects – that personnel resources provided by line managers are gradually lost. In general, modified resource allocation is necessary between product projects and capability development projects. One way of solving this is for the product projects to have proprietorship of the capability development projects that directly affect deliveries in the product projects.

Technology selections – Mature solution?

Certain technical problems with the storage method took a relatively long time to rectify. One vendor's method of data storage was not sufficiently mature when it was procured with regards to capacity and performance. It can be noted that it is especially important to conduct practical and large-scale performance and capacity tests with full loads and functions for the critical systems. The technical problems continued over a two-year period.

Working procedures – the GRIDE Project and technology areas

During the course of the project, new needs for development environments have arisen and many of these needs could be managed. New needs for measures in the IT infrastructure and for the GRIDE concept are now managed in a well-structured manner within the framework for administration of the GRIDE environment.

Despite optimism in reducing the number of IT tools, it turned out to be difficult to eliminate certain of these. Substantial effort is usually involved in migrating information and learning new tools, which often prevents streamlining since time is often at a premium in product project schedules. By not reducing the number of tools, long-term efficiency gains are missed. The remedy is to standardise work for the areas that can utilise the same tools and consequently make it easier to collaborate.

There are normally many different reasons for not being able to achieve this, which is usually not the case once a decision has been made.

At the conclusion of the GRIDE Project, it was apparent that the goals of the original strategic plan had been achieved.

Through changes to the product portfolio, new product domains have been added, including a number of development and production environments. These have been possible to create in the new IT architecture.

Administration and development of results – Administrative directives and roadmaps

Good planning for project conclusion enabled a smooth transition between the GRIDE Project and the administrative organisation. There were a few activities that had not yet been started by the administrative organisation upon project conclusion. It is very important to attain continuity between project work and transfer to administration, which was conducted very smoothly due to the personal unions between the GRIDE Project and the administrative organisation staffs.

The administrative organisation's work is based on an updated roadmap for the GRIDE production domain, which describes planned development for the coming years. This provides stability in planning for new functionality and contributes to good control of costs and future investment needs.

Continuous work with roadmaps does not really entail heavier workloads because in the long run, maintaining control of development and the goals the organisations are to achieve is a major factor for success.

The author´s reflections